The circuit boards have arrived:

http://i1191.photobucket.com/albums/...r/DSC02605.jpg

The tank inductor has a few more turns on it than the breadboard had. The number of turns was determined by the available room and minimum trace width/spacing allowed. I might use fewer turns with wider trace width/spacing on the next revision. It looks a bit fragile as is, and is easily shorted by sloppy soldering. Solder mask would fix that, but I didn't want to spend the extra money for it on the prototypes.

I selected the tuning capacitors for the tank to make it resonate at the carrier frequency, and give a Q/bandwidth that's between that of the AMB and MRT transponders I've already measured. I may reduce the Q further and set the resonant frequency slightly higher than the carrier frequency to help the output "ring up" faster on each phase inversion. The waveform maintains its peak-to-peak level better that way, but I don't know if that would make any improvement to the reception error rate.

I disagree, if he makes a decoder capable of reading all transponders (old, clone and new), then this is a very worth while thread. People want an alternative and this can be it. It has already been mentioned in other threads, MyLaps firmware is what makes the difference in reading MyLaps vs MRT for the RC4 decoder, so this thread in conjunction with the decoder thread.. WIN WIN!!

Whether or not existing MRT transponders work on the new AMB decoder has no impact on this thread. My transponder design is different from the MRT.

I have yet to establish whether or not my design is compatible with anything other than the AMB decoder at my local track. It might work with the new decoder, or it might not. If it is not compatible with the new AMB decoder, I could make it compatible if given sufficient access to the new AMB decoder.

The obvious solution to ensure that the MRT transponders continue to function is to simply not upgrade the AMB decoder.

I am working on a decoder design that will be compatible with the existing AMB and MRT transponders. You can read about it here:

http://www.rctech.net/forum/radio-el...g-decoder.html

There is also a very reputable company that already has such a decoder ready for testing. (I would be overjoyed if it made my decoder thread "useless"!)

One use for a forum is to disseminate information. I think this thread, and my decoder design thread, fulfill that function nicely. If I am not successful with either design, the information could still be used by someone else to create their own design.

^^^ Keep up the good work. Loving the progress!

Since we have mentioned the compatibility issues of the existing MRT transponders with the new AMB RC4 decoder, readers may find my very first post in this thread interesting. It shows several differences between the radiated fields of the MRT and AMB transponders that could be used by the new RC4 decoder to exclude the MRT devices. The differences could probably be easily minimized by changing a few passive components on the MRT. I suspect that's what MRT will do, if in fact this is the problem.

The other simple, obvious thing that AMB could do is to release new software that excludes the alternate ID numbers used in the MRT. MRT would then respond by changing those numbers to something else, which would cause AMB to again update their software... ad nauseum. The result would be like "Spy vs. Spy". (Here's a link for those too young to remember: http://spyvsspyhq.com/ ) Of course, this does nothing to exclude those MRT transponders having ID numbers "cloned" for a customer from the customer's AMB device.

I tested a transponder with the new PC board layout at the Hobbyplex in Omaha yesterday. I raced it in a Tamiya Mini M05 (my “don’t care car”, in case there were problems). Everything functioned perfectly. The Hobbyplex uses an AMB RC3 decoder and RC Scoring Pro. (My previous tests had used an AMB RC2.) The biggest problem, if you can call it that, was that the clear heat shrink tubing I used to protect the transponder was too large, and barely fit when fully shrunk. I’ll use a smaller size next time!

I also finally ported the code over to the correct microprocessor, a PIC12HV609. I had been using PIC12F508’s that I had left over from my music synthesizer and dynamic timing module projects, but those are only guaranteed to run at 4 MHz (though I had no problems at 5MHz). The PIC12HV609 has a higher clock limit of 20 MHz; more RAM, although this is not necessary for this application; twice the program space, which may come in handy if I add the ability to select more than one ID number; an extra input pin for future use; and a built-in regulator that permits operation over a wider input voltage range of 5V to 7V (which means it will run from most BEC circuits and a 2-cell LiFe receiver pack).

The code now includes a 8-bit random delay routine that varies the transmission repetition rate between about 2 and 4 milliseconds in 16 discrete steps. Previous code had a fixed repetition rate.

looks good, any schematic ?

I think the design is now stable enough to provide a schematic:

http://i1191.photobucket.com/albums/...r/DSC02616.jpg

As you can see, there's not much to it! A 74AC86 exclusive-OR gate serves as the oscillator, changes the carrier phase under control of the microprocessor, and provides high output current to the tank circuit. (I may change to the 74HC86 to reduce high-frequency emissions, but that will require increasing R4 and R5 to reduce the output current, giving less field strength. Right now the field strength is just about the same as my AMB and MRT transponders.)

One interesting thing that I mentioned previously about the design is that the tank is driven differentially (bridge drive), which substantially reduces the second harmonic level in the output spectrum. This could help with meeting emissions requirements.

The values of CT1 and CT2 might have to be changed to match whatever tank inductor you use. My original perfboard prototype used 16 turns of 30 gauge Kynar (wire-wrap) wire, while the PC board has 20 turns of traces (10 on each side). The ratio of the two capacitors will set the tank Q (CT1 larger gives higher Q), while the series combination of CT1 and CT2 sets the resonant frequency.

R1 was originally a limiting resistor for the shunt regulator inside the intended microprocessor, the PIC12HV609. It is shown as a diode because I have been using PIC12F508 microprocessors left over from another project. The diode drops the input voltage by about 0.6V to keep the 12F508 happy (it has a maximum operating voltage of 5.5V), and as a bonus protects the transponder from reverse polarity. Using the 12F508 (or almost any 12F series device other than the 12HV609) means the supply voltage to the transponder is restricted to 6.1V maximum. That's okay for virtually all BEC circuits, but is not compatible with a 5-cell NiMH or 2-cell LiFe battery. I stopped using receiver batteries a long time ago! Adding a separate Zener diode would let the transponder operate from the same large voltage range as the PIC12HV609 permits.

I am considering changing to the PIC12F683 for its larger memory and EEPROM.

The 47uF cap is probably not necessary for use with ESCs having linear BECs. If the BEC is a switcher (like a voltage booster for 1s LiPo cells) then it helps filter out voltage ripple. But further testing might reveal that it is extraneous.

J2 is a jumper block to select the transponder ID number. Currently the code supports two ID selections.

nice design....
As the microcontroller have built-in OSC (4M) and the I/O can drive 20mA max., is it possible to use internal OSC and direct output to drive the tank ??? So, you may save one more IC..

That would be great, but it won't work in both cases.

First, the absolute maximum I/O pin current spec for all three microprocessors I mentioned is 25mA, but that doesn't imply that they should be operated at that level. The 74AC logic series is specified for operation at 24mA, and this is what is required.

Second, the 12HV609 and 12F683 internal inverters will oscillate with a 5MHz crystal, but the output level is insufficient to drive U1B and U1C.

Additionally, the XOR gates let the microprocessor run at the maximum bit rate of 1.25 MHz (the PIC12F series requires four oscillator cycles per machine cycle), since it is only generating the modulation, not the carrier. Eliminating the XOR gates requires the microprocessor to use a 20MHz oscillator and run straight-line code to generate the 5MHz carrier. While this is certainly possible, it takes more program space (that I'm trying to conserve to hold more ID numbers). And we would still need external buffers to drive the tank, so it doesn't gain much.

There certainly could be a microprocessor that can do all of the above, but I haven't seen it yet.

I'm so intrigued and confused and impressed all at the same time. Great work! :nod:

x2 wish I know what I was looking at. Great work Howard.

I dont understand all of the electronics either, but, if it will work with old and new AMB decoders, and counts every time, and I hear a beep as I cross the loop.. :smile:

I previously mentioned trying to conserve microprocessor program space to hold more ID numbers. This got me started with some initial efforts to compress the code used to create the modulation patterns for transmitting the transponder ID numbers. It looks like I can achieve something in the range of a 2:1 reduction in size, which means that the PIC12F683 could likely hold 32 or more different numbers.

My initial try at simply twiddling bits to generate random new numbers didn’t pan out, so there does seem to be a checksum or something similar embedded in the data stream. It looks like I’ll need to purchase more transponders to record more ID numbers if I want to fill up that program space!

There is, of course, some point of diminishing returns. I imagine that if a transponder had 100 different ID number choices, then conflicts would be extremely rare, considering only a few people at any race meet might be using my design (if, in fact, it were to become available to the public). Even 50 ID numbers would probably be sufficient.