I just tested ad8302 phase detector wit LO but it is not usable for this purpose as this have only 180deg range. I will use AD8309 IF LOG detector. Just trying to develop test pcb for it. It looks that it can drive mcu directly.

Probably this is due to my poor RF experience, but using the AD8309 will only give you a sort ot AGC and a logic level output. Is that right or am I missing something ?

I think that the tricky part is to detect the phase inversion; I understood your method, but I think that it will not be easy (I repeat, possible but not easy) to write the right mcu code due to the fast frequency of the signal received from the loop.

That's correct, and it's not really AGC, it's just hard limiting. This makes the signal very susceptible to noise, since the noise is amplified by a whole bunch, along with the signal. And there's plenty of noise caused by the motor, ESC, etc.

I find DigiKey's $17 unit price for it distasteful, but it does seem like a nice part for its intended use.

It’s time for another update on the decoder:

The “preamble detector/stripper” (this is the best name I could think of for it!) is working nicely. It examines 15 of the first 16 bits in the data train from each transponder (which are always the same) and determines if they are valid. If valid, it removes them from the train and passes only the remainder of the data to the microprocessor. If they are invalid or garbled, then no data is presented to the microprocessor. This reduces the workload for the microprocessor, giving it more time to do other tasks. There’s no point of having it spend its time processing garbage!

I made a few minor changes to the SPI converter-- which is directly before the preamble detector/stripper in the signal chain-- to maximize the data setup, hold, and clock times presented to the microprocessor. (The ATMega would have been fine when running at 20 MHz, but the PIC would have been right on the edge.)

So we now finally have reduced, validated data at the input to the microprocessor!

Both the ATMega328 and PIC16F887 microprocessors have arrived. At the moment, I only have a programmer for the PIC. I’ve found a DIY programmer on the web for Atmel devices, but I’m unsure if it will handle the ATMega328, so I might have to just purchase a programmer. The ATMega328 is probably the best choice of microprocessor for many reasons, including speed and RAM size, but for the proof-of-concept decoder, the PIC will do.

When the proof-of-concept is working, it’s quite likely I will release all of the schematics. This seems to be the best way to get other people interested in doing the PC software, among other things!

Hi Howard, nice to hear about progress. I just finished writing non coherent bpsk decoder in cpld so now it is working in simulator. Input is logic level, output is spi or uart decoded data. Have to check it now in silicon, dev kit should arrive tomorrow.
For avr programming you can use avrdude sw, which supports several hw programmers, i am using since years.

That's fantastic! Which CPLD are you using?

Thanks! I'll check it out.

I just laugh thinking guys from Mylaps are reading this thread. Awesome job!

lattice machx02, have to find which model will be enough for my code, smallest model is 32pin, larger are 100pin. I decide for lattice because they have chips with normal pinout e.g. 32 tqfp etc

Fantastic job Howard!

I wish i had the skills to help you, but unfortunately...

You are a kind of messiah for all little clubs that can't afford the silly overpriced amb system!

Keep up the good work!

How about using a Raspberry Pi board as the brains behind the decoder? A Rev B board (with 512MB RAM, Ethernet, HDMI, GPIO, USB, etc), can be purchased for $35. It runs open source Linux. All of the development tools are free for download.

http://www.raspberrypi.org/faqs

I tested RPI had some troubles with speed, but did not any optimization. Other option is e.g. MK802 Android Mini PC(changed to linux). From my tests is much faster but does not have wired eth, only wifi. Have to finish decoder first. Is is working fine in cpld simulator. I just tested in real silicon, works ok for generated test signal but i am waiting for rf fronted amp pcb.

I looked at it when it was first announced, and was quite impressed. It would probably have the power to do everything including the scoring program!

But I'm always concerned about availability of parts. I don't think the Pi will last more than a few years, and our fellow racers may be in countries where this type of high tech simply can't be had at all. Gate arrays concern me similarly. For this reason, everything I've used so far is what we would call "low tech". (Other RCTech members posting here are taking different approaches, and have different priorities. More power to them!)

However, this would be an excellent tool for others wanting to contribute to this project. Given the necessary circuitry-- which I will hopefully be able to present shortly-- to receive the transponder data and pass it off to a board such as the Pi (via SPI, serial, USB, or whatever), then others can continue from there with the software.

decoding signal test
 

Hi Howard,

I attached my decoding test signals, rx data is input, packet are shortened to be better visible

Howard, at present there is no standard equipment for reasonable money which will be available for decades. The price of rpi or other small arm devices is so low that it is worth to change it after few years. I plan to write app under linux system and use standard sw technology like java a web based gui. These sw tech can run moreless on any hw available today and in future so even when rpi will be not available you can replace it with newer hw and use the same apps. So i would not be afraid of using these new gadgets as far as you can choose flexible sw technology for them.

+1

As long as architecture remains the same, hardware upgrade won't be a problem.