Many thanks for your input. I misread the datasheet; yes, it looks like the UART will run at 1.25 MHz with the 20 MHz clock. It's nice having others check up on me to catch my mistakes!

I was thinking about using the UART to read the demodulated signal from the transponder, but then realized that the format isn't compatible-- the transponder doesn't send start and stop bits. This might not be a big deal; even a garbled result from the transponder would still be useful as long as the result is unique to that transponder. But at the moment I think I should keep all of the information intact, just in case.

Also, it is unclear to me whether or not the UART in the ATmega devices re-synchronizes to the incoming data on each bit or each start bit, or simply times everything from the first detected start bit. The transponders send a pulse train having 98 total bit "slots", and their bit rate isn't very accurate, so errors can occur if the UART doesn't re-synchronize at least a few times during reception of the transponder data. My SPI design re-synchronizes on each received phase inversion (which I have been calling a logic 1).

The FPGA would be the logical route to take for production runs. It would also be nice to have for prototyping, but I don't have the programming tools laying around here. I do have a bunch of 74HC logic laying around, so that's what I'm using. Do you have any suggestions for a very inexpensive FPGA family and the associated tools?

There is another benefit using standard 74HC logic: If we make this design open-source, then the decoder could be constructed by others with minimal effort and expense.

Do you have a diagram of the packet makeup? or picture? Attempting to get an idea of what the protocol is. 98bits is alot of data to send a ID that would be less that 40bits and a checksum (8/16 bits?). guessing the remaining data if for the new telemetry

AFAIK, all basic UART implementations only look for start bit (done by sampling at 8 or 16x baud rate, hence the need for a system clock 8 or 16x faster than baud). although wiki leads me to believe that there are implementations that resync on bit inversions, however i can see the downside to this if the line is subject to impulse noise.
Either way you are right, uart would not work because of the start/stop bits not being considered data.

Sounds like your method is the best. Makes me wonder if you could do the same with a spi receiver and a timer/counter on a micro controller, where you generate the "spi" clock in the timer (pwm mode). when you detect a phase inversion you do a calculation to see if you and too fast/slow and update the counter threshold value (or reset the counter, or something else). basically brute forcing spi to act as a asynchronous receiver. Although at 1.25MHz, don't know of any device capable.

Funny enough an FPGA would be perfect to implement a custom receiver. It is just unfortunate that the words "reasonably priced" and FPGA are seldom used in the same sentence. While the price is falling quite quickly, i think you will still be in the $100 mark (although some boards based on older devices ~$50).
Also worth keeping in mind that there is a significant learning curve as the design process is quite different to software.
This website has a good list HERE, generally you want a spartan 3e or 6 to learn (only considering xilinx as that is what i use, there are other brands with their own merits). the avnet LX9 MicroBoard is a good example as the board has usb programming and comes with "upgraded" versions of the free tools.

i'm trying to understand how demodulator works.
demodulator is a BPSK or a QPSK?

I really have no idea of the information in the data stream. Here are a few things I have observed, based on a sample size of 26 different transponder numbers (from 4 AMBs, 2 custom MRT numbers, and the 20 alternate MRT numbers). I am calling a carrier phase inversion a logic 1:

The number of ones transmitted is always even.

Maximum run of zeroes = 13
Maximum run of ones = 10

The first 16 bit slots always contain the same pattern: 1111100100010110. I'll call this the "preamble". It might be a type identifier, or number of bytes in the packet, or ???

The following bit slots are always either 11 or 00:
17 and 18
83 and 84
85 and 86
87 and 88
89 and 90
91 and 92
93 and 94
95 and 96

I don't see any patterns in the rest of the data stream. I would expect that some of the commonalities will disappear if the sample size is increased.

Of course, for my current purposes it's not necessary to understand the information in the data stream. As long as the stream is unique for any given transponder, it's useful. In fact, I intend on doing as little manipulation of the data as possible in the decoder; I'll simply send what is received to the PC, and it can do what it likes with the data. It might be a good idea for the PC to strip off at least the first 16 bits before reporting the rest as the transponder ID, which still leaves about 1.2 million million million million possible numbers-- most of which would not be recognized by an AMB decoder if it uses a checksum.

Now THAT is a cool idea! I love using things in ways that their creators didn't foresee!

The data is transmitted via BPSK on a 5 MHz carrier, with a bit rate of 1.25 MHz (one possible phase inversion every four carrier cycles).

Decent data set. when you say maximum number of ones/zeros, do you mean sequentially? That first 16 bits definitely sounds like a header. played with it but never got out any anything that looked like a payload length (inverted, word/byte/nibbles), maybe the last nibble if inverted (=9), but you need to do some creative math to make it fit (header(16bits) + footer(8bits) + nibble(9)*8bits).

Out of interest, have you tried any hybrid rc4/ rc4 transponders? just guessing, but if the hybrid transponders can communicate with the older equipment, they should be using the same protocol. BUT they will be unique because they should have a packet that changes (dependent on supplied voltage and temperature is it?) allowing the design of the packet to be picked apart a little. does not explain why the rc4 transponders are not backwards compatible however, as the hybrid transponders have the same telemetry, but work on the older system.

Of course not useful for the hardware design, but an interesting problem. Even just cloning existing transponders would be infinitely preferable to having knowledge of the protocol and nothing to use it with.

Yes, maximum sequential run of ones or zeros. The maximum run of zeros was a concern because the SPI converter uses ones to re-synchronize to the transponder data stream, and too many zeros in a row combined with too large a variation of the bit rate from nominal (1.25 MHz) can lead to bit slip. I'm considering using the carrier edges for synchronization, which would eliminate this problem, but haven't come up with anything so far.

I was under the impression that the new RC4 system uses a higher carrier frequency, and the hybrid transponders transmit on both the old frequency and the new. If this is the case, the old and new data formats might be entirely different, thereby not offering any clues toward understanding either.

If someone has a hybrid transponder they could loan to me, I'd be interested in "sniffing" the output with my scope. But I don't think I would spend my own money just to do that.

This brings up an interesting point, though it is tangential to the above information. My experiments so far have treated the transponder as a "black box". All of the information I have gleaned so far was gained using a single loop of wire to receive the signal from the transponder, and examining it with a relatively inexpensive digital sampling oscilloscope. There was no need to open up the transponders to look inside. Indeed, that would have ruined their resale value, which is entirely at odds with one of my original reasons for starting this project: save money! I hope to pay for the parts and PC boards I have purchased by selling the original transponders when I'm done testing them.

I talked with the guy that wrote that Android program linked to earlier in the thread. He's under NDA and can't really share the protocol info or doco. All we could really do is work backwards from his code, since it's open source.

That's not surprising. If I were AMB I would also require an NDA. As we mentioned previously, there are other routes available, such as making the decoder appear as something other than an AMB (but still supported by typical lap counting software).

Thanks for checking!

I know that the carrier wave is used in smarter GPS receivers to improve accuracy and update rate. I know someone who is currently working on GPS processing (RTK GPS) so i can ask if there are any tricks.

Huh, had no idea that was the case. I guess that is one way to prevent people hacking the old decoders to work with the new transponders.

Just thinking out loud:
Am i right in my assumption that the amb transponders are nothing more than active RFID? in that case, would it make any sense to look at making the decoder system compatible with the 13.56MHz(ISM) (or the one around 3MHz) RFID tags? I guess you would have to duplicate the analogue stage due to difference in frequency. Advantage is you could use sub $1 tags...

The AMB and MRT transponders are actually simpler than an active RFID, because they don't receive any kind of signal from the timing loop; they just transmit repetitively, as long as power is applied. The AMB timing loop doesn't radiate; it only receives the signals from the transponders.

One of the design requirements I have for this project is that it must be usable with the existing AMB and MRT transponders. I think this requirement best serves the average RC racer, as no new equipment would need to be purchased.

Others have attempted to use low-cost, passive RFID tags for lap counting, but in general the reader is too expensive, and the system response too slow.

Oh I agree totally.

Active RFID can be single direction (Passive Reader Active Tag "PRAT"), but I have nothing to do with RFID so have no idea about the specifics.

Well other then I use a passive card several time a day and always hate how slow they are. Some times you would think someone was sitting at a computer with yes/no box and a list of allowed people.

I didn't know that. Thanks for the correction!

Now THAT'S funny!

Our local library uses the passive tags in the books and other items that can be borrowed. Sometimes it will take 10 seconds to read an item. (I know that's not typical, but it seems like I'm always the one subjected to the atypical situations.)

Its system based on RFID 125khz. Transmiter working at 125khz amplitude modulation. Transmit protocol based on Manchester code. ATTINY25 based.

Receiver is ATMEGA16 with schematics looks loke h_ttp://serg22.sibgtu.ru/radio/rfid-proteus02.jpg without 125khz transmitter, receiver only.

Receiver h_ttp://cs323523.userapi.com/v323523346/44f8/4YQLyLlZrg0.jpg
h_ttp://cs323523.userapi.com/v323523346/44ee/jVc5rwMd1_8.jpg

At this moment I am testing this system and waiting LCD for this project.
Sorry for my English.

That looks awesome! I think you should start a thread to document your work. I would definitely read it!

Here's how to post your photos, after you have uploaded them to Photobucket (it's free!) :
http://www.rctech.net/forum/10334159-post102.html