Can't tell you how many PTs I've ordered... but they come through with the numbers all over the scale. Even though there are less numbers then you think (there are no numbers below 2000001.. even the software doesn't recognize them)....you're still building on someone elses number.. (besides your own). This is the problem with building a compatible system.

I had one of my programs register as #458053 on the AMB decoder at my local track. It still counted, but it wasn't the number I had copied. I had made an error in my program.

This leads me to believe that I can create all sorts of random numbers by just twiddling bits in the pulse train. I don't care what the number is, as long as it's different from the others. All of the pulse trains I have recorded so far have even parity, but there doesn't appear to be any kind of built-in CRC that would keep me from doing that.

People said that when MRTs came out...

3 years later, I have NEVER seen a conflict.


Even if there is a conflict, it takes an extra 2s to assign the proper ## at the start of the race.

Really

How do you correct it... if there is nothing to correct it to?

I understand that this is pic12f or attiny. I'm interested in the name of the transceivers chip. I am intersted in tupical schematic for transiver on 74hc logic.

There is no transceiver chip. The transponder only transmits, it does not receive. The transmitted pulse train is created by the microprocessor.

Here's a couple of interesting, unrelated tidbits on the transponder design:

1) I tested one of my MRT's by heating it, and came up with a frequency temperature coefficient of about 17PPM/C. I think this confirms my guess that the MRT uses a ceramic resonator rather than a quartz crystal to set the frequency, as the temperature coefficient is in the right ballpark for a resonator. I'll test one of the AMB transponders soon.

2) One of the programs I created simply refuses to function on the AMB decoder at the local track. Interestingly, its pulse train has the longest run of zeroes (lack of phase inversions) of any pulse train I have recorded so far. While basing conclusions of any kind on a sample size of one is not particularly wise, I'm still wondering if this tells me that the decoder is running at a different enough clock rate from that of the transponder to cause "bit slip". In other words, a phase inversion in the pulse train will re-synchronize the decoder to the transponder, but when no phase inversion is present in the pulse train for a long enough time, then the next phase inversion will fall into the wrong time slot in the decoder, causing an error in the received data.

Maybe this is one reason why there are rumors that not all 10 million AMB numbers are not, or will not, be used?

Are you sure you didn't miss a digit? I can tell you for fact that 4 of the current race programs will not allow you to enter a racer or enter a house transponder with a number lower then 2000001. It just won't let you do it. We had this dicussion on here 6-7 years ago... and I believe I posted a screen shot of the results.

Now I don't have a TP with a lower number to see what happens... but what can you do with it? If you try to drag and drop it on a racer... it will say invalid..

Not a rumor... If you write to MyLaps to get permission to write software for there equipment, you will find its in there.

Thanks for the info, Ed. No, I didn't miss a digit. Actually, I was as surprised as you would have been!

I'll see what lap counting software and which version AMB decoder the local track is using, and post the result. If I have time this Sunday, I'll try running #458053 in a race and see if it works. (The computer was in practice mode for all of my testing.)

You mentioned getting permission from MyLaps to write software. I assume this would be lap counting software? Do they require execution of a Non-Disclosure Agreement (NDA)?

I have a left field question. But with the advent of 2.4Ghz and two way receivers, why doesn't a radio manufacturer work out a serialized receiver that is also a transponder so we don't have to worry about transponders in the future. I guess I know the answer to that and it means that AMB would loose money.

That's not "left-field" at all. Having the radio operate on 2.4 GHz does make it easier to put the transponder in the same case as the receiver. The transponder operates at 5 MHz, so it wouldn't cause interference problems due to the great disparity in frequencies.

I think that before a manufacturer would commit to doing this, we would need to have an accepted standard for transponder and decoder operation so that the radio manufacturer doesn't design something that can be easily obsoleted. (An example would be MIDI for electronic musical instruments. The manufacturers all got together many years ago and worked out a system, and the technology is free to anyone who wants to use it.)

We had a de facto standard for many years, created by AMB. Then MRT started making transponders. Now AMB wants to update their system so that only AMB transponders work. That's entirely within their rights, but it basically screws the racer.

What we need is another, competitive decoder that accepts all the existing transponders. I know of one manufacturer who claims to have a system ready for testing, and I'm currently playing with such a design.

If the technology for both transponders and decoders were made open-source, then we would have our standard. It's very tempting to do that.

The lap counting software is RC Scoring Pro, 10 Car Pro Version. I could not find a version number, but the build date is 5/13/11. The decoder has no part number or version identifier on it, but is serial number 14093. The track owner says it is an RC2.

Here's an update on the transponder project:

I had time yesterday at the track to test nine out of the ten programs I created by observing the pulse trains of the MRT PTX Number Set Two. All nine functioned correctly. (I would have tested all ten programs, but I inadvertently made two copies of the program for the same number!) This was using the perfboard prototype shown in the first post, mounted in a 1/10 scale 235mm-wide pan car.

I also had success with the program for the custom number from one of my MRT PTX transponders. I still need to record the pulse train for the custom number from my other PTX.

Printed circuit boards should arrive by the end of the week!

I just heard that MRT has two possible solutions for club transponders:

The first, as I understand it, is currently available, has a yellow case, and uses ID numbers that are unique to the club transponders, so if it should disappear and show up again later, it would be easily recognizable.

The second is a rechargeable transponder. It has not yet been released, and I don't know if the form factor will match the AMB rechargeables.

Here's more info on the MRT club transponders, from Terry at MRT:

"Our yellow PTX club transponders have the same numbering as the AMB rechargeables a 7 digit ID, last digit identifier 0 to 9. We use '01', '02' etc to show which is which.

"The battery-powered transponders for use on the AMBrc system basically operate the same as personals, they have a 7 digit ID rather than 1 to 20 on AMB20 etc."