It’s alive!

Back from Maplin, I was eager to try out running the accelerometer on the car.

The circuit has now got a little complicated.  I was hoping to draw it out but that will take longer than it took to wire up, so you’ll have to do with a description.

I need two voltages – the 9v battery powers the transmitter, and I use a 1k resistor and 3.3v Zener diode to generate 3.3 volts for the accelerometer and ATTiny.

The output from the Tiny now has to be amplified back up to 9v for the transmitter.  I had a TS358 Op Amp around that I’m using to achieve that.  The positive input to the Op Amp is connected to the output from the Tiny, and the negative input to a voltage divider of two 100k resistors, between 3.3v and ground.  The result of that is the negative input is held at around 1.6v, so when the Tiny drives the positive input low, the output goes low, and when the Tiny drives the positive input high (3.3v) the output goes high (9v).  The output from that then goes to the transmitter.

The result looks like this:

The problems I have now are that transmitting the readings back takes too long – a corner only lasts a few transmits – and I’m still seeing odd bit errors despite the checksum.  I hear that there might be a bug in the Manchester library though, so that could explain that.

Plans going forward (not necessarily in order) are to:

  • Speed up the transmission (the library is only writing data at 500bps, I think we can do better than that)
  • Look into error correction with a Hamming code
  • Transmit only the useful range of the accelerometer output, and only at useful resolution
  • Get the readings to my FPGA so I can visualize the G force (I already have that driving a 1024×768 display)
  • Think about how I’m actually going to control this in software!

Accelerometer reading transmission

The RF link is slow, and unreliable, so given that I came up the following scheme for transmitting the readings back:

  • Only transmit readings when they change
  • Transmit each reading 3 times when it changes
  • Add a checksum so the receiver can tell if the reading was transmitted OK

The Manchester library I’m using (originally from here) just transmits 16-bit integers, so I want to pack everything into 16 bits.

The reading you get out the ADC on the ATTiny is 10-bits, and for now I’m transmitting the whole of it.  The next 2 bits identify the axis the reading is for, and the final 4 bits are a simple checksum (XOR of each of the groups of 4 bits together).

The receiver checks the checksum, discards the reading if it’s wrong, and otherwise updates the axis and sends the reading out to serial (for now) so I can see what it’s up to.

Rather than pasting the whole source in here, I’ve put it up on github: Transmitter, Receiver.

Finally, a screenshot of it in action:

A 9V idea

I’ve been worried that the watch battery solution wouldn’t work well – the voltage you can expect from a battery is barely enough for the RF transmitter.

So I’ve decided to try this with a 9V battery instead.  They are fairly light, and as the pictures below show, my car can carry them round the track ok (and crash and spill the breadboard and battery on the floor – oops, maybe I need a better solution for holding them than blu-tac – nah, just more blu-tac :-) ).

 

Also, that means I don’t have to go to Maplin today!  One thing I do have to do though is go pick up the new Scalextric motors I got from ebay (all but one of the rather ancient cars have dead motors).

Next up though, sorting out that accelerometer data transmission.

Power to the accelerometer

The manchester encoding library from mchr3k worked great, and I quickly made a reliable connection between the Tiny and the Uno.

I was worried about RF interference from running the Scalextric car, so I left the transmitter by the track and ran the car round.  That seemed to make no noticeable difference to the signal quality, so I’m  happy that I’ll be able to get data back, and at a pretty reasonable data rate.

Next up was adding a header to the Accelerometer board and giving it a go.  The setup for the accelerometer is very simple, 1.8 – 3.6V in and analog outputs for the X Y Z readings.  I got the Uno hooked up and used the inbuilt ADC to read the pins – and it worked first time.

Finally, I wanted to get it going with the Tiny.  Only minor problem here is that I’m powering the Tiny with a 4.5V battery pack.  I’m planning to get this working from coin batteries eventually, but I haven’t bought them or the clips yet.  So I just used a simple voltage divider (two 5.1K resistors I had about) to give a sensible voltage for the accelerometer for testing.

With that all wired up, I could transmit the three readings using the ADC on the Tiny to the Uno!  Only problem I have at the moment is the Uno can’t tell which reading is which, so if a single reading is lost the axes all rotate one place :)   I’ll post the code once I’ve added some markers to fix that up.

 

Shiny things!

The shiny things have arrived!  I now have:

The ATTiny and transmitterThe Uno and receiver

The idea is to mount the accelerometer on the Scalextric car, and use the ATTiny and the RF transmitter to get the readings back to the Uno or my FPGA (or maybe RaspberryPi when they are finally released).  I’ve already got logic and a circuit which allows me to control the power to the car from the FPGA (using a PWM signal).

As a start, I’ve been trying to get a reliable signal from the Tiny to the Uno.  Unfortunately libraries such as VirtualWire don’t work on the Tiny, so I tried going back to basics.  By the end of last night I’d written something to just bang bits out at 2400bps with a preamble but no checksum.  That worked some of the time, but wasn’t very reliable at all (even with both on the same coffee table).

Luckily, a friend is working on a similar sort of project, and he’s got a Manchester encoding library working on the ATTiny85, with a reasonable amount of success.  So I’m going to steal use that and see if it improves things.