Well partial success. The pt was being picked up but a little unreliably with 19 out of 25 laps picked up during my 1st heat. Plenty of signal strength just not recognition sporadically. Now it was RC4 so maybe that is part of it. I am racing on RC3 on Thursday so will try there but also the pt was a test build with socketed chips and I had to desolder a couple of things to fix the Zener issue. I will build up a new one and solder the chips in this time.

This is typical behavior of the RC4. Part of the "upgrade" that Mylaps included was a trap for MRT "clone" transponders, to render them obsolete. There are several threads here on RCTech that discussed this when it happened.

The RC4 recognizes my cloned transponders as such.

It didn't take Terry at MRT very long to figure out a work-around, and he released a new version of transponder whose signal would be indistinguishable (for the RC4, at least with its current software) from the old AMB transponders. I wish I were as smart as Terry!

Ok that is a relief as it will primarily be used with your decoder and possibly rc3. Thanks again. The decoder build continues tonight and I will post progress on the appropriate thread.

Heyas, just found this thread and read through it all. Nice work on reversing the transponder system! Been out of RC for about 10 years, but starting to dabble again. Is the RC2 frame structure (as currently reversed) documented somewhere? Post 279 (can't link) lays it out a little, but seems to be a lot of unknowns still out there. Also, has anyone been using GNU Radio or the likes for demodulation? Saw mention of people playing with SDRs earlier, but not much more.

Hi Howard, can you please explain this sentence? I'm running on a RC4 track and two of my transponders work fine. I've even made two races with them, no lap missed. Where do you see that 'cloned' information, on mylaps computer?

My apologies, that was a poor selection of words. The RC4, at least with updated software, can determine that my transponders are not manufactured by MyLaps or AMB, and therefore rejects them, resulting in sporadic lap counting. The same goes for the older MRT "clones", and that was what I meant.

There is no indication anywhere on the scoring computer that a transponder is being rejected, and I don't believe the decoder ever sends this information to it.

This was an attempt by MyLaps to kill sales of transponders made by any other manufacturer. MRT released an update to their transponders to get around this trap.

I have not put any effort into modifying my transponder design to work with the RC4 decoder, and don't intend to. There are too many other interesting projects waiting to be done!

Hi Howard

One of the decoders I built up using one of your numbers is showing two numbers rather than one. Can you think what that might be?

http://i23.photobucket.com/albums/b3...psxak1sfas.jpg

That's more a question for the decoder thread, but here's an answer:

The decoder does not use any sort of checksum to verify a transponder number, which would prevent this from happening. Sometimes the decoder will receive garbled data, and if it receives the exact same garbled data for three receptions in a row, then it thinks it is another transponder and reports loop crossings for it. This doesn't happen very often, and seems to be more likely when the transponder crosses slowly under the loop (resulting in low received signal levels).

We must rely on the lap counting program to mitigate this problem when it occurs. The lap counting program has a database of transponder numbers, and these are called up from the database when setting up a race. If an unknown transponder (one not in the database) shows up during a race, then it is up to the lap counting program or its operator to exclude it from the race results. The options for doing so will depend on the program you use.

Adding entries to the database is a bit tedious for any program, but only needs to be done once for each transponder, since the database is stored on the PC's hard drive. If the correct transponder ID is known, then it can be added manually to the scoring program's database (this number will be different for ZRound and Flipside; I believe FlipSide uses the first six hexadecimal digits of the data string as is, while ZRound converts it to a decimal value). If you are "grabbing" the transponder to add to the database as it passes under the loop, and see more than one transponder ID, then you'll need to cycle power on the decoder and try again.

Thanks Howard

I figured it might be similar to this but as it is just one of them that is doing it I was not sure. All the others are fine just pumping out one number. I have tried a few resets but it is determined to show two numbers each pass of the loop.

For those interested I tested Howard's PTs on a RC4 system a couple of weeks ago.
The program I was using was RC scoring pro. The program sees the PT go across as indicated by a light that blinks on the computer, but it is not counted or acknowledged other than the blink of the light as it crosses.

I belive this was answered in an earlier post here. In essence, if the decoder runs RC3 software, Howard's transponder works fine. If it runs RC4 software, then Howard's transponder will not work, or might miss some passings.

Yes quite correct. I have a couple of Cano PT's that I use at an RC3 track and they work beautifully with very strong signals but at the RC4 track they missed several laps despite the same strong signal.

Regarding the issue of the missing checksums. I have a working piece of code that can read the crc checksum off the AMB decoder network/serial protocol written in Java. Is there some "magic" concerning how the crc checksum is computed in the transponder signal that hinders Howard's code from creating a correct checksum? In that case would it help to look at how the AMB decoder does this in case there are similarities in how it works? After all, both the AMB decoder and the mylaps transponders are created by the same company.

Barsk,
I don't think there would be a problem with Howard's code creating a checksum, but I don't believe Howard has any interest in pursuing this. He has moved on to other interests.

Howard has shared his code for the transponder, I have looked at it and it is way beyond my meager skills to figure how his code works, yet alone modify it to include checksum generation.

All 3 scoring programs I have tried don't handle the "ghost numbers" well. They just complain that an unregistered number is on the track and usually quit counting the transponder.

Arnie

I took a look at the code and though I am really rusty on assembler I can see how it works basically. But it is really low level coding that doesn't give any clues to the actual bit-stream protocol which is broadcasted. So unless we can break the protocol I don't know where to insert the checksums... Has the actual protocol been documented somewhere?