I never got it to work and need to try again.

can you post a picture of your wire and loop? Perhaps this is my issue!

Yes, I will try to take pictures of it as soon as I can. The only thing we did was follow the part list, place all components at its place, make sure all errata items were coverred and thats it.

Only testing we did was to make sure we had the same voltage at the loop wire than the schematic. At first our loop wire wasn't good. as soon we changed it, it worked.

thanks that would be great!

I did the same as you many many times, i get the same voltage. So perhaps it is my wire.

if you get 1.20 volts at the loop, it could be the wire itself.

Question for the master itself, Howard.

Have you ever tried your decoder with BBKRc software?

Only FlipSide and ZRound have made the necessary changes to support the Cano decoder. The chance of any other software just by coincidence having the same data format is zero.

Here is the data format for anyone who would like to write PC software to accept the Cano decoder:
http://www.rctech.net/forum/12089668-post201.html

Completed system
 

Here is a picture of our Cano Decoder and Loop Amp, all in their boxes. Ready to start counting laps.

That looks great!

first 6 bytes are transponder id
next 8 bytes are timestamp

are the final two to make it 16 bytes CR-LF ("\r\n")?

That is correct.

The RCM software can read the decoder via a network interface. The P3 protocol I believe. The Cano decoder does not support this, but would it be possible to create a computer program that reads the decoder input from serial and convert it to P3 protocol packages and deliver that to a server, just as you set up an AMB rc3 decoder to do for instance? And to be complete the computer could even duplicate the P3 protocol on serial out as well.

If that is possible then we would have the same R/C software compatibility as the AMB decoder itself.

Possible or not?

Creating a Cano->P3 bridge is possible. But how well it will work with RCM is unknown. Since the Cano protocol is very easy, RCM guys could add support for it directly.

I added Cano support in an evening but I had to refactor my code before that to unmarry my code from p3.

I would guess that RCM would like a physical device in order to test their implementation. How else can they verify and guarantee that RCM will work 100% with the Cano decoder? And to optain or build a device is not that easy...

Btw, anobody that has some printed circuit boards extra?

Someone that has a device can dump data to a file and send to them. They can test their implementation using vspe or something like it.

I don't have a cano device either, but the spec is very straight forward so I just added an implementation that *should* work and released it without guarantees. I posted the C# source code for ourlaps cano plugin, which can be used any way anyone sees fit.

Howard provided me with sample decoder data when I asked him. It may even have been posted in this thread already? idunno.

The decoder data is very simple. This post has a complete description:
http://www.rctech.net/forum/12089668-post201.html

The data below is what I sent to Torg. It is for one transponder, with laps of about 4 seconds.

The first line is a power-up message (which now also says "REV B"). All other lines are as described in the post given above.

COPYRIGHT 2013 HOWARD W. CANO
CA72F2000027CE
CA72F20000683C
CA72F20000A71A
CA72F20000E2C8
CA72F200011F5E
CA72F200015EE1
CA72F200019D62
CA72F20001DCFA