Pushing Past Power Problems (perhaps)

Making a semi-final product today allowed me to finally start taking semi-final power consumption measurements. These were done by inserting a small resistance into the positive power supply connection and then measuring the voltage over it (my multi-meter was not sensitive enough for direct current measurements).

These were terrifying, unmodified the board pulled almost 60mA  in its idle state, giving it just over a day of life on a single 18650 lithium ion cell. This is clearly far less than I had hoped and indicates that power consumption is now something I should be worried about. Off we go on a hacky adventure!

First off was removing the 5V regulator which (given it had been shorted out anyway) was just wasting power. That saved a full 5mA of consumption.

The next step was to stutter the RF field from the reader, adding periods where it is turned off, for instance when the microcontroller is doing non-RFID things. Additionally the addition of a sleep period to the polling cycle (with the RF field off) massively reduces the RF field duty cycle and in tests did not really change the user experience (and I was looking for it). That saves another 10mA and being more aggressive on the sleep saved a further 10mA. This pushes the time on single cell up to 3 days.

Clearly I have been optimistic that the cells will actually be able to discharge their full rated capacity, so maybe 1.5 days is more like it. This still allows the proof of concept to be programmed the day before any field trials and left on over night without having any danger of it running out of power!

The interesting thing about this development is that it indicates the next big development required of the ODOTS on its path to becoming ready for certification (certification being expensive and something I only really want to do once in the future)(And something that will be necessary to bring the ODOTS, or derived system, to the mass market). Frankly the current hardware architecture is not optimised for power consumption in any way at all, the use of Arduino in particular is a bit of a liability as it does not provide fine control over AtMega peripheral activation. This may be why I eventually shift over to a different architecture in the future. While I have made an effort to tame the ravenous beast that is the RF field the MRFC522 (or one of its alternatives) will provide methods for reducing its appetite further. I have commented in the past about the ability for the ST Micro chips to passively detect tags, this would be ideal as it would massively reduce the power consumption with potentially little (randomised) impact on competitor visit recording times.

I suppose my dreams of networking the ODOTS units with LoRa and implementing a 6WLoPAN network are going to be a long way off indeed!

Standard Struggle (or how I learned to stop worrying and love NXP)

Part of the ODOTS project is about tackling the problems that other people wont want to, and I think that I have taken a month to do just that. Today I finally admitted defeat to NXP - if I want the ODOTS competitor timing cad to be a MIFARE device (which I do, they are ubiquitous, diverse and likely to be around for a while) I am going to need to use their Reader/Writer ICs. The bit that finally pushed me over the edge was the realisation that not using an NXP chip was going to doom me to having to run the authentication and encryption on the Micro-controller. A day of searching for a friendly application note/datasheet/tutorial showed up nothing.

Up to this point I had mostly worked out the firmware for the CR95HF (from ST Micro) up to the ISO14443a layer and was feeling like I was understanding how it all hung together (a good indication that you are about 10% of the way there). Unfortunately while the CR95HF is MIFARE Classic compliant it requires encryption and authentication to be handled by the host (the micro-controller), while NXP chips will take the bulk of the work off you conveniently meaning the task of encryption and authentication are not often tackled by the sorts of people that will leave behind handy code libraries and examples. Thus I could continue to try and write code to run MIFARE tags through the CR95HF, but it would be a significant piece of work with little benefit (in the short term) over just using an NXP device.

The beaten track beckons, so I am flipping into complete Arduino-friendly mode and using the MRFC522 chip that has a development board that has been mass produced to the point that you can pick them up for £5 from mystery-meat ebay and amazon sellers. My development article is coming from a more reputable source in the hope that it allows me to avoid the classic block-of-resin-with-solder-pads knockoff syndrome! With all RF and surface mount components handled by the wonder board most other components are going to be possible to do with through hole components (or DIP) - for that sweet sweet 90s look. this will also make it more straightforward to prototype and 'mass' produce proof of concept timing units for demonstrations. Naturally as the likelihood of the ODOTS actually being used goes up the more and more it will approach a single PCB, all surface mount, state. Additionally using a shady source RF board may make it tricky to prove that the device is not producing large amounts of EMI - so it will need to be replaced at some point.

ODOTS, the nitty gritty

Yesterday I posted about the next project lined up, the Open Design Orienteering Timing System - today I will attempt to go into a bit more depth about what I have done so far, including design choices.

The orange and white checkpoint flag hides, trying to ignore the now well trodden path that leads directly towards it...

To start off the entire system will just be a big RFID network, Orienteers will travel between RFID read/Writers collecting their ID's and timestamps which can then be used to determine who completed the course the fastest. Therefore the RFID stations need to be able to both read cards (to detect them) and then write to them, ideally in a short enough time span that the user does not notice. The first step in this project was to decide on a broad RFID standard that will provide this capability and have widely available components (and compatible tags).

RFID has a wide variety of implementations and the first discriminator is operating frequency. Lower frequencies (such as 125kHz) do not provide sufficient read/write capability (or memory) and are also on the verge of becoming antiquated (HITAG, NXP's standard for this frequency had its last update in 2007). Age could be seen as a boon, the technology is proven, however there is a risk that the ICs will stop being manufactured (not brilliant for availability) and there have been dramatic improvements in communication protocols in the recent past that newer technology will have been able to leverage.

Higher frequencies come with their own problems. RF design becomes harder, which would be an issue if I was to try and start designing my own PCB's. Another issue is that higher frequency spectrum becomes useful for other things too, there are increasing numbers of users all competing for spectrum access, interfering with each other or operating in protected bandwidth.

Therefore 13MHz RFID is a good compromise. The 13MHz standards are currently receiving a lot of love (NFC, contactless payments) and will therefore probably have supporting ICs around for the foreseeable future. 13MHz RF design is hard but not impossible/evil. 13MHz also means that we will have to try hard to become spectrally abusive, power output will be limited by the fact that any antenna we make cannot be well matched to a signal that has a wavelength of 10m. A quick look at the OFCOM band map shows that there are users of this spectrum, however there is specific spectrum usage set aside for Inductive Applications (aka Near Field Communications) and the other users are tolerant enough/wideband enough that the restrictions are not too bad - official testing may be required if the ODOTS were ever to go into widespread usage.

Again NXP loom large in the 13MHz protocol lists their NTAG and MIFARE standards form a large portion of the compliance advertisements for cards and transceivers. To be a rebellious engineer I immediately looked beyond NXP for my RFID chip, in the hope that a separate manufacturer would also be able to cater for non NXP communications if needed. In walks ST Microelectonics with their development boarded CR95HF. This strays off the beaten arduino-compatible path (which about sums up most of my software work so far), but has good higher level drivers - when I can get the basics working. ST Micro are also releasing some very tasty IC designs with capacitive (passive) tag detection. These will be a prime target for upgrading to in a couple of years time if the ODOTS works!

Don't worry LM741 - the fancy RF/digital chips will never have your charm.

I have just mentioned Arduino, so that probably gives my Microcontroller game away. I have opted for an ATMEGA to allow me to sneakily use the Arduino bootloader and maintain compatibility with the beginner friendly Arduino IDE. For all the embedded engineers currently crying about the injustice of it all the 'under the hood' code is written far more practically to ensure that is can fit in the ATMEGAs resources. Using the nice friendly IDE for the top level embedded software will hopefully mean that it remains accessible to anyone who wants to have a poke around. Additionally it will allow me to rely on the many tutorials on how to burn in the bootloader/program for when other people try to use my designs.

The legendary MSP430 got a brief consideration (Energia is nice), but unfortunately it just does not have quite enough memory.

Finally I have given some though to other parts of the design, using the ATMEGA is likely going to mean my Vpp will be 5V - pushing Lithium Ion batteries out of the window, luckily 9V batteries are a thing and if I can come up with a nice openable/resealable enclosure replacing them should not be too difficult. Real time clock options have been glanced at briefly, it looks like I may have to put multiple devices on the same SPI bus which would be really cool to do! The actual user interface is something that also needs to be thought about at this point too - the checkpoint interface is pretty simple but the data needs to be read off the card somehow. Luckily if I am using the ATMEGA chips I can 'just add USB ports' and have a RFID tag's contents read and spat off into a computer for displaying/recording.

Pipe Post-Script

The end of the big engineering project came and went fairly swiftly, but not without a few fairly long experiment/analysis/writing sessions to finish it off. (It wouldn't be a proper project without them ... riiight??)

The result was that my visions of a brilliant new way of detecting pipes was only partly correct. The final experiments involved sweeping the antenna in front of a pipe, which had been hidden behind a very large wooden board. The pipe could be clearly seen in the reflection data and with a bit of processing the peak in reflected power could be made rather significant.

The pipe is causing that ripple!

And with a bit of manipulation of the underlying phasors we can make the peak magically appear!

Unfortunately the usefulness in the reflection data for distinguishing pipes and non-pipes was not tested (a year is a remarkably short time in the end). Looking at the initial goals for the project - they were all met, the method was tested in the ways proposed and experience in how the data generally worked allowed me to build a schematic of the pipe detector!

Inevitably the question after every project is what next? - well I think it is time for something completely different...

Phasor Phun

So, turns out I had forgot one of the more important parts of a VNA's function, that it outputs Phasor values, that is vector-like quantities with defined phase and magnitude used to represent sinusoids.

Sadly not our favourite Star Trek ray guns...

So why do we use this form of data?

1. The VNA is already providing information in a frequency sweep - every data point represents a sinusoid of a specific frequency.
2. A sinusoid can be represented with three bits of information, its frequency, its magnitude and its phase offset.
3. Therefore, given we already have frequency we can easily store the other two bits of information as a phasor and be quite happy!
4. Phasors lend themselves quite well to multiplication/division operations - addition/subtraction is achievable after a simple conversion to rectangular (Cartesian) coordinates.

Of course to simply represent our two quantities as two different elements of a vector would be too nasty - we use imaginary numbers instead, in exponential form.

This realisation gives me the opportunity to work with way information than before. By taking phase into account when comparing two signals we can identify more properties to identify them, for instance phase differences, or absolute magnitude differences.

Clearly at this point I am sitting on top of a folder bursting with graphs (3D graphs!!), however they need a bit more work before anyone but me will understand them so I will save them for later...

Further Engineering Excitement

 So a follow on from the previous post, mainly because I ran a second set of tests, but this time transmitting around 10GHz.

As before I hooked a nice polarised antenna up to the lab VNA and moved a pipe around in front of it, while looking at the power reflected into the VNA from the antenna (and calibrating out the power literally reflected by the antenna itself to try and isolate the reflections due to the pipe). Of course being 4th year engineering means that all of this is automated after the initial setup!

I had a few predictions about this second set of tests:

1. Our lovely dominating sinusoid (the one with the increasing and decreasing reflectivity) would increase in (spatial) frequency to match our increase in RF frequency.
2. The sample would induce a greater reflection as its size (in RF wavelengths) was now bigger.
3. The tail end of the previous reflectivity graph started to look flatter, I was expecting this flat region to develop earlier on in the graph

Of these only 1. turned out to be true, the increase in size relative to wavelength of the sample appears to have been swamped by greater path loss, the radiation losing energy as it travels, which is greater at higher frequencies. Additionally the flat area did not appear, making me suspicious that its manifestation in the earlier graph was an artifact of me 'under-sampling' the distance/reflectivity waveform.

My pipes at this point were about a wavelength wide (as opposed to the half-wavelength width they have for 5 GHz waves) which has another important part of the test as my trusty textbook had illustrated that the reflectivity properties change around this point (and a bit lower). This appears to have been observed, certainly the PVC pipe appears to now be reflecting more power when it is horizontal, earlier it was reflecting marginally more when it was vertical. The metal pipe appears to be reflecting equal amounts of power independent of its orientation - which is interesting and requires further investigation...

Anyway, the results graphs:

Reflectivity Graph, now pointier...

FFT plot, also pointier

One of the brilliant bits about these experiments is that they produce megabytes of information, the two graphs here only use a fraction of the data produced. This means that there are many, many, many different ways the data can be displayed and different properties that can be explored ... brilliant news for at-home-playing-around-in-matlab me!

Engineering Excitement (or: more MATLAB graphs and FFT fun...)

So, end of the degree means that some fairly cool research gets to be done to produce a thesis. My project has ended up being trying to explore the effects of a cylinders orientation with respect to RF (Radio Frequency electromagnetic radiation) wave polarisation on their RF reflectivity. A bit of a mouthful that ends up with: can I find a method to detect pipes really easily? If I can that would be really useful for the construction of pipe-detecting devices. The really cool bit was that initial research indicated that dielectric (non-metal) cylinders also exhibited properties along these lines, which is really intriguing, and could represent a massive improvement over current methods of pipe detection.

So a couple of months of reading and simulation later I found myself in the lab collecting data from a physical experiment, the results of which are below. For this test I had a plastic and a metal pipe which I rotated between vertical and horizontal in the testing apparatus. My investigation had indicated that 

Data!!!!

This graph shows the approximate power reflected from a set of sample cylinders at varying distances from a test antenna hooked up to a VNA (meaning I was actually looking at the total power reflected from the antenna).

Two points, firstly I can be fairly certain the figure above shows power reflected due to the samples as there is another set of data that was collected with no sample in the testing apparatus - this established how much power was being reflected from (and into) the antenna under no-sample conditions. This power was subtracted from the result of tests when there was a sample to give the result displayed.

'But Wait!' I hear you say, 'you have negative power over there!'. I have cheated and used a dB, logarithmic, scale to display the results. Negative readings actually indicate that less power than the no-sample test was reflected under these conditions. This is due to RF wizardry, at these points the sample has put itself somewhere where it can absorb lots of power (or lead to it not being reflected into the measurement device), rather than reflecting it (into the antenna where hopefully the measurement device can detect it). This is a combination of the sample 'coupling' with the antenna, changing its characteristics, and it being close enough to provide an effective load to the transmission line the antenna is attached to! (I did say wizardry)

Secondly, the y, distance, axis is approximate - there is some offset which I have not accurately measured yet, unfortunately Lab-Me only took down a rough measurement! Additionally it is the nature of a lot of RF work that there is a certain level of roughness to results. This is mainly as the measurements we take are affected by all RF radiation waves being thrown about, including are own, that like to interfere with each other, themselves and reflect, refract and diffract off of whatever they can. This leaves us with a non-trivial system that is always going to have an element of randomness simply because we cannot predict everything that is going to be important to the behaviour of the system. The best that can be done is to try and calibrate all of our measurements to a baseline and then not change the test environment if we can help it. This is why the measurements all look very messy - luckily this data set represents about one of 640 (from this experiment alone) I can use to help reveal how the effects I am looking for are affecting the system! Additionally I have another antenna set made up able to look at a different set of frequencies (these tests were conducted at about 5GHz).

I got really interested in the oscillations in the data so, naturally, I ran a quick Fourier transform on the data to uncover its frequency content. Note that this frequency is separate from the frequency of the RF operation, it is actually the frequency of reflective peaks over the separation distance.

MOAR DATA!!! (ignore the vertical scale)

Unfortunately for those trying to avoid confusion, the frequency plot shows a definite peak at just over 0.3333333 Peaks/cm, or a wavelength (distance between two peaks) of just under 3 cm. Why is this interesting: because the wavelength of the RF radiation used to produce this graph was just under 6cm! In other words the sample reflects the most power when the sample-antenna separation is some multiple (plus an offset) of half the RF wavelength!

It is always nice to get results that indicate more investigation is needed!

Easter Roundup

As is the way of academic term time - things have been fairly busy recently! As a result I have missed writing posts about several different project events, so here they are, amalgamated into a mega post:

Blake Project:

Yes, we finally handed it in, presented at an outreach event and semi-satisfied our supervisors. We managed to automate one of the cars, dictating it's behaviour with a learning state machine. This solution required us to quietly ignore that the 'learning' involved the car loosing control and falling from the track!

The final system did not include the brilliant perspex track, unfortunately I was not able to get the rails to be smooth enough to maintain reliable electrical contact with the cars as they travelled!

GrAVITAS:

I reckon that I will need to rename this project "The Han Solo Memorial" given how often it has gone into hibernation. Since the last post I discovered major potential instabilities in the planned circuit design, which scrapped the planned layout. Then University projects happened and we find ourselves a couple of months in the future.

Luckily I have now extensively tested new signal chain components (as a lucky byproduct of aforementioned University projects) which should mean that the hardware is put together very soon (fingers crossed)...

Robots: The Rock and A Hard Plaice, I and II

A bit more action here, mostly due to the fact that the Rock and a Hard Plaice suffered almost 50% fatalities per entry into a competition.

They were a blast to drive, not least because with two drivers the clusterbot became quite a sociable thing. Sadly weight saving measures left both bots rather vulnerable to more destructive opponents the first iteration of The Rock I fell victim to a vertical saw blade that discovered the only thing guarding The Rock's flammable lipo battery was a sheet of decorative paper!

Hmmm - I didn't intentionally add a fire weapon...

Of course, a video: https://www.youtube.com/watch?v=aL26JNXmnOE

(Destruction at 2 minutes 15 seconds)

Naturally once wasn't enough so I went about redesigning the cluster bot to be slightly better armoured, and actually used a 3d printer (splutter, splutter) to produce the chassis! Somewhat undaunted by the fact that I was greeted at the next competition by "are you going to explode again" from some very excited organisers The Rock and a Hard Plaice II managed to not die at all.

Sturdier, right...

The next thing to do was to go a step too far, which I managed to do admirably by entering a public antweight robot wars event.

This was the result: https://youtu.be/N7zi8lK0Ia0?t=10m3s

(destruction occurs at around 10 mins 30 seconds)

I think the best bit was that I could find enough pieces to reconstruct the chassis and had to consolidate the available hardware into a single zombie-bot:

In retrospect the decision to add the 'Hard Plaice' picture to the underside was somewhat disturbing...

 Rubik's Cube Solver:

Perhaps the most enjoyable project I have ever taken part in, the Rubik's Cube Solver has also been one of the most time consuming!

In the past few months I have been able to design, build, redesign, rebuild and debug the communications hardware and software for sending information over the mandated audio cable.

For those interested m hardware consisted of a Sallen-Key filter designed with the Analogue Devices filter wizard (all praise the filter wizard) with non inverting amplifiers acting as input and output impedance buffers. The actual demodulation was done with an envelope detector circuit. Modulation was done with software driving a PC soundcard.

Amusingly today was supposed to be the have-everything-working day for the project with a presentation next term. However not a single group managed to hit the deadline, mainly due to integration issues, which meant that the unit director pushed the deadline back in an act of supreme benevolence! My group was 99.999999% of the way to hitting the deadline before we discovered some rather tricky bugs involving envelope detector fall of times (yes ... that was my section) which we were unable to both generate and integrate a solution for in time.

Given the state of things I am sure that I will be able to post a victory video shortly...

The initially planned communications tower, my demodulator fits into the second lowest box. 

Cube as it is now, with illuminating LED's and blackened actuation rods.

Satisfyingly not much has changed in the solver structure, except for the addition of a fluorescent-bulb-blocking shade. While it is not the most aesthetically pleasing structure coming together in the lab I am happy with it as the open frame and intentionally forgiving design has allowed us to test multiple system elements and interfaces well before full integration

The interior of the Demodulator box, I think the wiring leaves much to be desired!

Aaaand ..... there we go all caught up. With three weeks of holiday coming up either many more posts are about to be made, or my next post will be in a couple of months time after the next academic term!

GrAVITAS - the circuit board

Ha! 

GrAVITAS returns - a bit worse for wear (having been stored in carbonite for so long). Work has finally got manageable enough for me to return to work on the solar flare detector. Actually, I lie - there were a couple of brilliant team members who persisted with their task, even when I went quiet on the subject, who galvanised me into action.

So, the progress:

1. Much software doings, it is only the scheduling and reporting that needs to be done. Having said that I have discovered (from other similar projects on the web) that NOAA publish the information from GOES-15's solar instruments, which would be brilliant to compare with the data we capture - and could be used entirely automatically.

2.I finally got around to the hardware, and have now planned out the analogue signal chain. Luckily due to the audio card digitising the signal, it does not have to be too complicated. A couple of buffers, amplifiers, a notch filter and a bandpass filter and everything is awesome! Needless to say, I expect the receiver to work terribly in this first iteration, but maybe by the fifth.... I think that while the design below does not include them I may end up adding a load of potentiometers in the place of some of the resistors to allow me to bodge optimise the circuit parameters!

My planned matrix board layout for the analogue signal chain. All go for soldering up on Thursday.

Hopefully I can post soon about even more progress, but I expect that my targets may slip - we have another Blake Project presentation opportunity this weekend which may eat a lot of time.

An Update

Silence for months must be followed with an update post, it is a rule of nature.

At the beginning of the (academic) year I listed some of the projects that I am working on at the moment. Question: how are they going? Answer: ummmmmmmmmm - I'll get back to you.

Immediately.

Blake Project:

Turns out not spending eight hours a day on a project can really slow progress. The AI has been semi constructed, the algorithm has been written, and so has the car driving code. All that remains is to plug it all together (which is always the longest part anyway!).

The track, is in pieces. Not as many pieces as it was, but it is many hours from completion. Luckily we have a reading week at the moment with many hours in it, many fingers are being crossed.

Its all there! Just not together.

 Telescope:

The updates that need doing have been identified, I really need to install a focussing mechanism better than a loo roll and friction. Also, upgrading the optical tube frame to be more portable, yet sturdier, is definitely on the cards at some point.

The telescope has had some good outings recently, trying but failing to see Uranus, getting a peek at Mars and a good look at the Orion nebula. I was going to try and point it at Jupiter and Venus on Tuesday, but the only place I could see them was from the middle of a road (I live in a city and they were close to the horizon), which I did not think was appropriate. They were awesome enough with the naked eye!

Solar Flare Detector:

Designed, the project decided to change the receiver to an SDR (software defined radio) based one, plugging the antenna (after a couple of filters and amplifiers) into a microphone slot and using a computer to do all the hard work. As it should.

Of course given that the solar flare detector should be running fairly constantly we have elected to use a Raspberry Pi as our enslaved processor - which means I have to relearn linux.

Also it got a name the GRand Assembly for Versatile Ionosphere Tracking and Astronomy of the Sun or GrAVITAS, a ripe source of puns, a source of gravitas (can't help myself), and of course an oblique reference to Iain M Banks. It looks very good in email headers.

The engineer at work, all four monitors in use. More screens = more work being done right?

Rubik's Cube Solver:

Good progress, but nothing of note yet. At least nothing worthy of photographing!

Lunar Rover Mk2:

Wow - got assigned to other projects within the space society for the moment, which was rather unexpected. The sneaky plan of the committee is to shuffle members around between projects as work amounts change. Ideally this means that some point in the future there will be much posting about rovers, the ideas coming out of the rover team so far are really rather cool.

Random Shiny stuff:

It always happens.

Robot Wars.

So the university electronics society run an ant-weight (150g, 10cm cube size limit) competition twice a year, so I should have seen this coming. Because this is going to be the fifth time we have entered, my team is going to attempt to build a cluster-bot, fitting multiple independent robots within the restrictions. This is leading to all sorts of fun and games trying to reduce the mass of the individual components of the robots which is likely to be the tricky bit.

This one also has a name, The Rock and a Hard Plaice, more details to come soon.

Who needs scales when you have string, water and a measuring jug?

A New Project

Prepare.....for a spam of posts like no other

Prototyping on the road. At its finest.

GSM module, OLED display, custom keypad and a micro, can you guess what I am making?

In the next couple of posts I will provide several tutorials for the tools I used as well as how to use some of the components you see in the above photo.

Oh and don't worry, the final product won't use an Arduino :p
(I'm striving to learn lots of new stuff this project anyway)

PS: As of 23/08/2017, the project is still ongoing.

--------------------------------------------------
Andrey Miroshnikov

Your local digital designer/systems engineer ;)

The same, but different

Turns out that wireless communication is actually supposed to communicate information, rather than be used for somewhat dodgy range finding. (shock and horror)

Having spent a large portion of time on the latter use, it is now time for me to finally work out how to best use the former. While I have done the equivalent of 'hello world' during the RSSI measurements, I will now focus on maximizing the amount of useful data sent between transceivers. Initial testing of this meant simply hooking up a bunch of microcontroller units programmed to transmit random data as quickly as possible at a base station, and then reading the speed at which the data was being received by relaying it through a serial port to a waiting Python script.

A quick note, this method does mean that our speed measurements also include the speed at which information is being processed over the wired serial link, and some delays incurred by the software. I have deemed this to be acceptable, the wired serial link does not bottleneck the data flow, and other program delays are likely to mean that we get a data rate recorded that is closer to what will be achieved with the full system.

A quick Python session later and boom, I was recording data rate, with interesting results:

Program readout, showing a fairly stable data flow (such a relief after the instability of the RSSI readings!)

Unfortunately I realised that the receiving microcontroller was appending lots of information before relaying data down the serial link (like new line characters and RSSI measurements).

A quick C session later and boom, I was recording data rate with fewer pesky systematic errors in my results:

Program readout again, sadly the data rate dropped when we removed the extra characters

So, onward I must go, to either design a system capable of working within this data rate constriction, or find a way to boost the data rate of the transceiver modules.

A quick epilogue:

The Anaren Modules are actually quite sophisticated when they come to transmit, they will wait for the RF channel to clear before broadcasting and will limit the amount of time in for any given interval that they spend transmitting. While this may look like a prime target for removal when trying to boost data rate, this functionality is implemented for legal reasons (nobody likes a spectrum hoarder), and so is likely to remain.

More RSSI adventures

Some updates on the wireless system.

Having run a number of more trials of RSSI for distance in different conditions it is now obvious that RSSI is unlikely to be helpful over long ranges. I have included two graphs of my results, the first is of the raw data, which includes all measurements made (I took multiple for the same distance for almost all tests). The graph shows the general mess of values I was getting with very little correlation between distance and RSSI, especially when comparing results between tests.

This is evident in the second graph, which colour codes the results for the trail they were taken in. The most likely reason for these bizarre plots is reflections of the transmitted signal off of surrounding objects. This would explain why  the shape of the plots can vary so wildly between setting that the experiment was taken in, but remain fairly consistent for the same setting.  

The raw data, an enormous mess!

Results sorted by trial (with data averaged to ensure that there is only one point for each distance per trial). Clearly the devices surrounding affect the RSSI readings to a huge extent.

This is no problem for the project, it simply means that the RSSI readings are only effective over a short range. This can be easily counteracted by simply adding more receivers!

I just have to work out how to not clog up the airwaves...

Until next time!

A project - with fellow engineering students

So, three weeks into an outreach project and I decide to post about it (sounds like my usual behavior!).

The University has given two fellow electronic engineers and myself the chance to work on an eight week project over the summer, which is pretty cool. The purpose of this project is to bolster the outreach displays of the electronic engineering department with an exhibition of as many aspects of the discipline as possible. More simply, a scalextric track with autonomous cars, solar panels and radar, WOOHOO.

To be fair the past three weeks would have looked fairly unproductive to the casual observer, very few physical objects have come together. This is because the teams efforts have been directed towards learning how to use our micro controllers of (the University's) choice, the MSP430 manufactured by Texas Instruments.

While simple arduino-like interfaces exist for the MSP430, our project leader insisted that we mirror industrial practice more faithfully and use the more complex Code Composer Studio. While much of the past fortnight has been apparently fruitless as we began to understand how the interaction on the micro controller happened at a hardware level, as a team we now have a good understanding of the micro controllers at a hardware level (funny that).

My own part of the project so far has been focused on ensuring the cars do not collide, and that has mainly meant ensuring that they can communicate wirelessly. The idea behind this is that we can reuse the communicated signals to triangulate the positions of the cars via RSSI.

Having pushed my way up from register level code, today I was finally able to produce a signal strength for distance graph today!

the graph! note that I have no idea of the vertical scaling, hence the simple label, 'not dB'

Sadly the graph indicates that my job is only going to get more interesting from here on out, as clearly when I invert the axis to solve car positions I am going to end up with multiple solutions!

The graph also raises the question of the problem of signals being reflected and so on (at least some of the odd results recorded were unrepeatable after moving various items of equipment around). Finally the graph also reveals very odd behavior around 20 and 70 centimeters. While this most likely an inconvenient reflecting object, the dips correspond (if you squint) to one and two times the wavelength of the RF signal of around 34 cm.

This is going to be a long project so I am hoping to get most of the anomalies solved by next week when perhaps I shall have more to share.

A parting action shot, testing in progress!