Project Scope

The initial focus for this project will be in understanding and designing a circuit able to transmit a wireless signal with a low input voltage. Using a blog article on a simple scavenger ring as a starting point, it will be the team’s responsibility to analysis, modify and improve on the basic functioning ring that was created. This will be achieved by extensive use of literature and other research to create a much more extensive and functioning circuit which has been designed with a more comprehensive level of examination. Once completed, a secondary circuit will need to be designed to harvest a particular source of energy to power the circuit. The options available for this project include peltier, piezo electric, electromagnetic and magnetic coil. For this part of the project the optimisation and testing of the allocated energy source, used to power the sensor will be the main component of the thesis. The overall result will hopefully be a small device that can emit a signal from small amounts of energy harvested from the particular...

Use of microcontrollers and MEMS for condition monitoring.

The traditional methods for high frequency data analysis involve many piezoelectric sensors, signal amplifiers and spectrum analysers the size of a modern day desktop computer. However, with the arrival of low cost and easy to use microcontrollers and Micro Electromechanical Systems (MEMS), perhaps it’s time to reconsider some of the traditional methods. This blog post aims to outline some of the challenges, limitations and success encountered whilst trying to use a combination of microcontroller and MEMS devices for condition monitoring. The equipment: Arduino MEGA 2560: . The large user community along with extensive libraries available make this an ideal choice for experimentation. ADXL345: The ADXL345 is a small, thin, low power, 3-axis accelerometer with a measurement range of upto ±16 g.   Thanks to the advances in rapid prototyping, it is incredibly easy to produce PCB’s in low quantities whilst keeping cost to a minimum. We had designed and manufactured our own PCBs to support this project. The PCB houses the accelerometer, a temperature sensor, a voltage and current sensor and a various other electronics. This test setup cost us <$100.           Challenge #1: Data storage: The Arduino lacks an onboard flash storage. Therefore it requires an external storage space to store the data. An SD card shield is the simplest solution to overcome this problem. This method however, has one big disadvantage and that is the speed at which data can be written to an SD Card. Every time the Arduino has new data to be written to the SD Card, a file in the SD Card has to be opened, the data written and then closed. Failure to close it at...
Speeding Up I2C Communication

Speeding Up I2C Communication

So recently we were doing some data collection with an Arduino mega and an accelerometer, specifically the ADXL345. Now the datasheet on the ADXL345 stated that the maximum sampling frequency is 3200 Hz but we found that our data points we only coming through at about 900 Hz. After some digging around the web, we found a potential cause. Although the Arduino should be able to handle up to 400 kHz I2C communication, it is by default limited to 100 kHz in a particular library header file. Now 100 kHZ should be more than enough to sample a device which is supposed to be capable of 3200 Hz sampling but it’s not as straightforward as that. We think that although 100 kHz is the I2C bus speed, there is still going to be some time initiating communication. Depending on the library you choose to use. there could be several back and forths between the Arduino and the ADXL345 before any data is actually exchanged. We found however that by making the change to 400 kHz, we were able to obtain data at 2600 Hz which while not maxed out, is still a significant improvement! Perhaps the remainder is due to the aforementioned communication overhead. Here’s what we did to obtain the increased bus speed as laid out at this link.   Locate the twi.h header file at this location: C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\Wire\utility. Now instead of just telling you the full path, I’ll provide a picture as well so you can confirm you’ve found the correct file (note the path in the top right corner).  Once you’ve located the file, note...
General Design Process and Philosophy (Part 3)

General Design Process and Philosophy (Part 3)

Once we knew what we wanted to do, all that was left was to do it! This was not a quick process however. We discovered that knowing what we wanted to do and knowing exactly how to go about doing it were quite different things. There was a lot of Googling involved. Thankfully, most of our design tools were popular and well documented, specifically Solid Works for the mechanical aspect and Arduino for the electronic and programming side of things. We also drew heavily on our previous experience, pulling ideas and skills from seemingly unrelated previous projects. During the early stages, there was not much programming as we focused more on building a basic test rig, even if it lacked sophisticated sensors and data communication. As such, Solid Works was used a lot. We would design the different components separately and then use CAD to see how it fit it within the larger assembly. There were many iterations to get it all right but eventually we completed it. Once we were satisfied with our CAD drawings, we took it to the workshop and had it produced.  ...

General Design Process and Philosophy (Part 2)

After listing down our design considerations, we could move on to more specific designs. Concept level design decisions were made using decision trees. Here’s a specific example. We knew that as a truck, our test rig would have to have some form of driving. So we brainstormed the various options available: electric motor, heat engine, etc. We then qualitatively assessed each of these options again the design considerations we had. Based on this, a decision was made that impacted the next step in the decision tree. In this case, we decided to go with the electric motor option and then had to consider how to power it: battery, charged track, etc. We would go back to the assessment stage and keep carrying out this process till we reached the end of the tree, a very specific decision that could not really be debated on. We kept records of these trees in case we ever needed to back track at a later...