Does anyone know where I can find any information on the type of data sent across the USB or SERIAL port of a PC from an AMB Decoder box?


Thanks,
Shan

The serial is the easy part.
I have them somehwere...(I will see if I can find them)

USB is a pain and AMB won't give them out....

A USB Sniffer could be used.

The serial is the easy part.
I have them somehwere...(I will see if I can find them)

USB is a pain and AMB won't give them out....

A USB Sniffer could be used.

Thank you so much! I figured the serial part wouldn't be to hard.

I imagine it just sends the transponder ID across everytime the person crosses the wire and the software does all the timing calculations.

For the USB part I may just have to make a small app that just listens on the USB port to see what the decoder sends across.

Thanks again!
Shan

I looked at the info from the older AMB20 systems. The decoder sends info such as tansponder number, total time, lap time, split times.... a lot of info. When I did timing of the Saturday Night Lightning kart races for ESPN2 they custom made some software to pull the info from the decoder for the live TV feeds and I was able to work with them while they did that. Basically, the software just sorted and formatted the info from the serial port.

This info is saved in the decoder so if your computer would happen to "go down" you can actually keep running the race and recall the info that is stored on the decoder. But I doubt that any aftermarket RC software can do that... it was mainly there for use with events such as kart races.

Thanks Hank!

I did not know the decoders actually stored any info or processed the lap times. I thought it was all PC Software driven.

Hi, i'm a bit interested in this topic, in particular about the serial protocol, if anyone got any infos please tell me :)

Best bet would be just to open up terminal and connect it to the serial post and view what is coming across the serial port.

Best bet would be just to open up terminal and connect it to the serial post and view what is coming across the serial port.

that's true, but atm i've no decoder, and i'm interested only to know the protocol and the datagram sent to made up a linux timing system :)

It's all sent in ascii text so if you look at the info with a terminal program you can clearly read what is being sent by the decoder.

the transmissiom= 9600 8N1
the string = AMB20 Output @010204382050 (Car1;hours2;min4;Sec38;20Mil Sec;50Hits)

If you have some schematics about AMB20 decoder and transmitter or equivalent please sen me

Best regards
Coraz

the transmissiom= 9600 8N1
the string = AMB20 Output @010204382050 (Car1;hours2;min4;Sec38;20Mil Sec;50Hits)

If you have some schematics about AMB20 decoder and transmitter or equivalent please sen me

Best regards
Coraz

I too am trying to find info on the tcp protocol used by the AMB decoder. I can read port 5403 and I am receiving data but it is not ascii - does anyone know how to read this data?

Try some of the other options in Wireshark for decodes.
Hex, etc....

Try some of the other options in Wireshark for decodes.
Hex, etc....

Wireshark is a good "sniffer" but it will not be able to decode the data.

Not to worry though... I already figured it out.

Typical stream:
8E 02 33 00 0F 08 00 00 01 00 01 04 3D 00 00 00 03 04 1D 73 87 00 04 08 E8 7E 98 69 24 50 04 00 05 02 22 00 06 02 03 00 08 02 00 00 81 04 B0 14 02 00 8F

This stream is a "passing" (identified by bytes 9 and 10),
It is passing number 61
Transponder ID is: 8876xxx
RTC TIME in hex is: E8 7E 98 69
RTC DATE in hex is: 24 50 04 00

Plus a few other types of info.

Does anyone know how the end data is stored in the AMB software? I'd like to be able to pass the data in XML to a web service to store in a database.

Hi myosin, I'm trying to emulate the an AMB decoder to connect my lap counter system directly with all software supporting the AMB protocol.

Do you have any other information about the proctocol :

1. initialization data send by the decoder on port opening
2. Any other data send, not related to the Lap data.

Thank

Hi myosin, I'm trying to emulate the an AMB decoder to connect my lap counter system directly with all software supporting the AMB protocol.

Do you have any other information about the proctocol :

1. initialization data send by the decoder on port opening
2. Any other data send, not related to the Lap data.

Thank

It issues a "status" every 5 seconds - noise level, gps setting, temperature and a few more not-so-important items

other than the lap data and the status every 5 seconds, it doesn't send anything unless a command is sent to it to do things like ask for version number, resend the passings, clear the passings, reset tcp/ip connection, etc.

Unless you know how to read hex, I would recommend using the RS232 port - I haven't checked it because I don't have a serial port but I was told that it is straight ascii text. Fire up any terminal program and you should be able to connect and log everything coming across.

Joker, did you ever get anywhere with this? I'm kind of interested in how you would go about emulating the hardware decoder?

Wireshark is a good "sniffer" but it will not be able to decode the data.

Not to worry though... I already figured it out.

Typical stream:
8E 02 33 00 0F 08 00 00 01 00 01 04 3D 00 00 00 03 04 1D 73 87 00 04 08 E8 7E 98 69 24 50 04 00 05 02 22 00 06 02 03 00 08 02 00 00 81 04 B0 14 02 00 8F

This stream is a "passing" (identified by bytes 9 and 10),
It is passing number 61
Transponder ID is: 8876xxx
RTC TIME in hex is: E8 7E 98 69
RTC DATE in hex is: 24 50 04 00

Plus a few other types of info.

My amb decoder send for example this :
$1E0254A10D002D2249433E00

can you help me to traduce it ?
Thanks

Anyone have what the full translation of the hex that is sent? someone out there must have the translation. This is an exchange of data between the decoder and the PC with the racing app and I believe is AMBrc3

From decoder to desktop
8e:02:33:00:cf:02:00:00:01:00:01:04:b2:9b:01:00:03 :04:27:fc:70:00:04:08:e8:19:e6:bd:8a:75:04:00:05:0 2:33:00:06:02:10:00:08:02:00:00:81:04:fc:05:04:00: 8f

desktop to decoder
an ACK

decoder to desktop
8e:02:1f:00:3d:27:00:00:02:00:01:02:1b:00:07:02:21 :00:0c:01:7a:06:01:00:81:04:fc:05:04:00:8f

desktop to decoder
an ACK

decoder to desktop
8e:02:1f:00:98:e8:00:00:02:00:01:02:1b:00:07:02:22 :00:0c:01:7a:06:01:00:81:04:fc:05:04:00:8f

desktop to decoder
an ACK

Thanks for any help -r

Same here, I am trying to translate the Hex but can't get it.

i can translate it

Hi.

I am from Spain.

Sorry for my English :)

I have a AMB decoder and I want to buy a soft for it.

But I don't have the protocol to communicate with it.

Somebody have this protocol or info.

Thank's a lot.

Bye.
Darkus

Anyone have what the full translation of the hex that is sent? someone out there must have the translation. This is an exchange of data between the decoder and the PC with the racing app and I believe is AMBrc3

From decoder to desktop
8e:02:33:00:cf:02:00:00:01:00:01:04:b2:9b:01:00:03 :04:27:fc:70:00:04:08:e8:19:e6:bd:8a:75:04:00:05:0 2:33:00:06:02:10:00:08:02:00:00:81:04:fc:05:04:00: 8f

desktop to decoder
an ACK

decoder to desktop
8e:02:1f:00:3d:27:00:00:02:00:01:02:1b:00:07:02:21 :00:0c:01:7a:06:01:00:81:04:fc:05:04:00:8f

desktop to decoder
an ACK

decoder to desktop
8e:02:1f:00:98:e8:00:00:02:00:01:02:1b:00:07:02:22 :00:0c:01:7a:06:01:00:81:04:fc:05:04:00:8f

desktop to decoder
an ACK

Thanks for any help -r

I have stared att these dumps for a while and have done a lot of assumptions. I do appreciate all kind of help with calculating the "checksum" or what it is in the beginning of the message, whithout this the decoder seems to reject all commands.

First: the decoder seems to use big endian (i think it's the correct term), the data fields should be read from right to left.

Let's take a look at your example:

8e:02:33:00:cf:02:00:00:01:00:01:04:b2:9b:01:00:03 :04:27:fc:70:00:04:08:e8:19:e6:bd:8a:75:04:00:05:0 2:33:00:06:02:10:00:08:02:00:00:81:04:fc:05:04:00: 8f

8e: start of message
02: unknown, a minute ago i thought it was 00 for TO the decoder and 01 FROM the decoder
33:00: the length of the message in hex, 0033=51 bytes* read from L to R
cf:02:00:00 the evil checksum I can't figure out 000002cf=719
01: type of message, this is a passing
00: guess: the data length for the passing is 0 bytes
01: sequence number
04: length 4 bytes
b2:9b:01:00 value of sequence number 00019bb2=105394 (seems to have great uptime?)
03: transponder number
04: length 4 bytes
27:fc:70:00 value of transponder number 0070fc27=7404583
04: lap time
08: length 8 bytes
e8:19:e6:bd:8a:75:04:00 lap time in seconds if you divide by one million, 1255138658.753000 hmm... never seen this huge values on my system. Hope it got natural causes...
05: signal strength
02: lengt 2 bytes
33:00: value of signal strength 0x0033=51
06: hits
02: length 2 bytes
10:00: 0010=16 hits
08: unknown
02: length of this unknown
00:00: value of unknown: zero (doesn't make it easier...)
81: ID of the decoder (the last four bytes of the mac address, guess the first two is the IANA assigned number for AMB.it)
04: length of ID 4 byted
fc:05:04:00: xx:xx:00:04:05:fc
8f: end of message

*If the value is in the range 8A to 8F (could be the range 80-8F i guess) the value is prefixed/escaped by 8D followed by the byte value plus 0x20. The prefix/escape is NOT counted in the length of the message.
Example: signal strength whith the value of 142 0x8E: 05:02:8D:AE:00
Action: subtract AE whith 0x20 => 8E and delete the byte containing 8D.
Result: 05:02:8e:00

Now: please help me find out how to calculate the "checksum" or what it is.
If someone do I will post all the keys I've found.

Hello !!!

Somebody possesses the coding of date and an hour because the weft it hexa is not clear ?

Excuse for my average English....

Thanks

@marcmarc3333 : Just look at what ambhobby said. You just have to parse the eight bytes after "00 04" to get the time, then divide it by 1 million to get it in secs (uint64 => divide => double).

Anyway, did someone figured out how to send commands to the decoder ? Does any program use them actually ? If so we could sniff some of these to help finding the checksum calculation

Edit: I've done some searches, it looks just like a simple CRC calculation. Sending this :
8E 00 00 00 5B EB 00 00 24 00 01 00 04 00 05 00 8F

Make the AMB return some result (Race session initialization) :
8E 02 1F 00 00 86 00 00 24 00 01 08 C5 81 79 1A E2 8A 04 00 04 02 00 00 81 04 FA 05 04 00 8F

It looks like C5 81 79 1A E2 8A 04 is the current AMB time (to initialize it for drivers)


Changing the checksum results in "CRC Error" reply from the AMB (in pure ascii text).
Still no clue about what data to check-in for the checksum, but I think we're pretty close.

Hi All,

I am trying to do much the same thing. I have tried sending 8E 00 00 00 5B EB 00 00 24 00 01 00 04 00 05 00 8F to my AMBrc3 decoder but it doesn't seem to make a difference. When a passing comes in (either Serial or TCP/IP) i get the same data. Just a transponder number, ticks since the decoder came online, hits and signal strength.

How do i get the decoder to send me the 'verbose' information that you have above i.e. 8E 02 1F 00 00 86 00 00 24 00 01 08 C5 81 79 1A E2 8A 04 00 04 02 00 00 81 04 FA 05 04 00 8F

Hi all,

I've also done som reverse engineering on the protocol (of mx3) and reached just about the same point as ambhobby and xplodwild. I created a little program acting as a proxy server relaying the traffic between the software and the decoder while logging it.

However, I have not been able to reverse engineer the checksum... I've used an online crc calculator (not allowed to post link, google it) to test different combinations of the input string, but still no success... Perhaps someone else have better luck...

I'll continue bashing my head aginst those checksums!

Cheers.

So I am able to see the data in hyper terminal that the decoder is sending after initializing the decoder with another lap counting program. However if I do know do the initializing with the other software first it does not work. Does anyone know what commands I need to send to do the initialization.

Hi All,

I am trying to do much the same thing. I have tried sending 8E 00 00 00 5B EB 00 00 24 00 01 00 04 00 05 00 8F to my AMBrc3 decoder but it doesn't seem to make a difference. When a passing comes in (either Serial or TCP/IP) i get the same data. Just a transponder number, ticks since the decoder came online, hits and signal strength.

How do i get the decoder to send me the 'verbose' information that you have above i.e. 8E 02 1F 00 00 86 00 00 24 00 01 08 C5 81 79 1A E2 8A 04 00 04 02 00 00 81 04 FA 05 04 00 8F

The decoder is listening on two ports/tcp.
I don't have my notes available but I think it's 5400/tcp and 5900/tcp
The lower port is the "simple" version.

If I remember the wrong numbers: either you can portscan the decoder or connect with Orbits (or what program you is using) and do a "netstat -an|find ESTAB" and find out the port number from the list.

I have read previous posts and seems to me more of you were close to finding the solution.

Does anyone found an answer regarding TCP/IP communication (especially CRC)?

Don't you have a piece of C++ code able to communicate with RMBRc using TCP/IP (decoding the whole string, sending commands)?

BTW: is there any free software able to use TCP/IP communication?

Thanks

I'm investigating how to kickstart the software Prolap32 from AMB232 interface.

I dont have the AMB232 interface-card but I'm trying to emulate this by sending my own signals to ProLap32 over serialport.

We have an old AMB8800 with upgrade to AMB20 transponders, and an very old ISA8 PC-card. The problem is that this ISA8 card inly works with Windws95c as tha latest operating system and a very old computer that supports the ISA8-port PC-BUS.

To buy a AMB232-card is just to expensive.

We are investigating a solution where we just convert the physical signals from the AMB20 interface cable that normally connexts to the ISA8-card but we convert this through a Paralell-to-USB converter and build a software (we are 2 software developers by profession that do this, but we have less hardware and AMB20-ISA8 skills).

We have already the software in our development environment set upp but I have some problems to know exactly what protocol-signals to send to the ProLap software (when interfacing over AMB232).

We receive CtsHolding, DsrHolding and CDHolding from ProLap32 but what should I send back to get ProLap32 start kicking?

Our objective is to make our software AMB232 Compatible by a combination of hardware and software interface. This whould make it possible to do without the old Win95 computer and we can build som softwatre to make more information availible, but still using marketleading software as competition system.

We have the TimeRecord-format and the LapCount-format, but I think it is some problem when ProLap32 starts and it expects some pin to be set to start the timing software.

Any Ideas how to solve this in the com-port communication?

Regards,
Conny

have you had any luck with the software development? I have an old 8800 system with amb20 transponders aswell. Trying to bypass the ISA card for a more portable solution. Its either that or upgrade or try and find an old AMB20 Decoder with serial.

Anything to get usb to parallel or a PCMCIA or powered parallel port to work with alycat or even Freelaps...

any help would be appreciated...

No, I'm still working on the problem....

Will put more time into this because it's interesting to learn about this.

I have stared att these dumps for a while and have done a lot of assumptions. I do appreciate all kind of help with calculating the "checksum" or what it is in the beginning of the message, whithout this the decoder seems to reject all commands.

First: the decoder seems to use big endian (i think it's the correct term), the data fields should be read from right to left.

Let's take a look at your example:

8e:02:33:00:cf:02:00:00:01:00:01:04:b2:9b:01:00:03 :04:27:fc:70:00:04:08:e8:19:e6:bd:8a:75:04:00:05:0 2:33:00:06:02:10:00:08:02:00:00:81:04:fc:05:04:00: 8f

8e: start of message
02: unknown, a minute ago i thought it was 00 for TO the decoder and 01 FROM the decoder
33:00: the length of the message in hex, 0033=51 bytes* read from L to R
cf:02:00:00 the evil checksum I can't figure out 000002cf=719
01: type of message, this is a passing
00: guess: the data length for the passing is 0 bytes
01: sequence number
04: length 4 bytes
b2:9b:01:00 value of sequence number 00019bb2=105394 (seems to have great uptime?)
03: transponder number
04: length 4 bytes
27:fc:70:00 value of transponder number 0070fc27=7404583
04: lap time
08: length 8 bytes
e8:19:e6:bd:8a:75:04:00 lap time in seconds if you divide by one million, 1255138658.753000 hmm... never seen this huge values on my system. Hope it got natural causes...
05: signal strength
02: lengt 2 bytes
33:00: value of signal strength 0x0033=51
06: hits
02: length 2 bytes
10:00: 0010=16 hits
08: unknown
02: length of this unknown
00:00: value of unknown: zero (doesn't make it easier...)
81: ID of the decoder (the last four bytes of the mac address, guess the first two is the IANA assigned number for AMB.it)
04: length of ID 4 byted
fc:05:04:00: xx:xx:00:04:05:fc
8f: end of message

*If the value is in the range 8A to 8F (could be the range 80-8F i guess) the value is prefixed/escaped by 8D followed by the byte value plus 0x20. The prefix/escape is NOT counted in the length of the message.
Example: signal strength whith the value of 142 0x8E: 05:02:8D:AE:00
Action: subtract AE whith 0x20 => 8E and delete the byte containing 8D.
Result: 05:02:8e:00

Now: please help me find out how to calculate the "checksum" or what it is.
If someone do I will post all the keys I've found.

Our club bought a AMBrc3 system early this year and we are thrilled about it. Very nice to have, and very nice to race with proper timing system.

We are also investigating the AMB P3 Protocol and how to make the most use of it. Since we have access to several members that are system developers by profession (my self included).

I read your article and we have also tested with TCP-listeners like the Wireshark-software (thanx for the tip).

I guess that what you think is lap time actually is the total elapsed time from when the decoder was started. When we made some calculation of the time we just subtracted the time from the previous lap and we got quite reasonable times (about 5.38 seconds). I tested by first subtracting 0xFFFFFFF000000000 (7 Fs and 9 Zeroes) to lower the value in the calculation.

I also guess the second byte 0x02 after the 0x8e can be the section code for the packet header.

As you also noticed it seems each section onsists of a section code of 1 byte directly followed by a length specifier. I think this is also valid for the packet header maybe with the exception that it is 2 bytes for the packet length specifier.

I wonder if byte 4 value 0x00 actually is the section code of CRC-checksum section?

I doubt that byte# 10 is a length, as its value is 0x00, this seems odd?

I think the sequence number is a unique lap identification number? I have also read the RMonitor Timing Protocol (dated October 1, 2001 from Track Timing Software Solutions) and it seems to have some similarities with the AMB P3-protocol.

I found a very useful page about Cyclic Redundancy Check (CRC)-checksums at Wkipedia (http://en.wikipedia.org/wiki/Cyclic_redundancy_check) and some sample source-code at codeproject.com (http://www.codeproject.com/script/Articles/ViewDownloads.aspx?aid=5597). We also have to concider what bytes are included when calculating the CRC-checksum. I have asumed that all bytes after the checksum itself are included, and i have made some calculations by reversing the order of all bytes... I have to try more....

It seems to be a lot of different variants of calculating the CRC-Checksum. I'm investigating more about this.

I also guess that the section with code 0x08 at the end of the "Passing" packet can be either temperature or GPS coordinates of the decoder, byt I'm just guessing. Maybe someone have a GPS or temperature installed and have the possibility to run Wireshark to investigate this?

I think it is a pitty that MyLaps doesn't publish the P3 protocol. It seems so old fashioned these days. Soon enough we will succeed in reverse engineer this information anyway in our open community, this just a matter of time by the hobbyists.

connywesth, If I can help in anyway let me know.

I am a Sr. software engineer and although C#/.Net is my daily I am heavily skilled in C++ and proficient in VB. So if you need an extra hand with something let me know.

I had thoughts about buying a used system to do a breakdown to see if I could come up with an alternate solution to break the monopoly they have on this hobby!

CreativeIndy,

The most important task is probably to analyse the AMB P3-protocol (P3 for short) and what output information from the Decoder, but almost equally important is to analyse what CRC routine is used for calculating the CRC-checksum in the P3. This is important to send comands to the Decoder. The Decoder rejects all comands with wrong CRC record.

The messages that is sent from and to the Decoder is build up as bytearrays with certain record structure, we have in this discussion threat, analysed parts of the "passing message", when a RC Car passes over the antenna loop.

At this moment I work with C++ to learn how to set upp a TCPSocket to do the same work as I did in C# some weeks ago.

It is easy to set upp a TCPListener-class (depreciated) or TCPClient-class i C#, VB.NET and any orther managed .NET code, is is easy to set up a Decoder simulator (by using the TCPServer-class) with the only purpose to send out randomly generated messages for testing the TCPListener oc TCPClient. The tricky part is to have the protocol specification and working to get any meaningful work from the setup.

I just build an TCPClient application that reads the IPAddress from the Decoder and outputs the binary values (represented as two-char Hex-values like xFF for decimal 255 and xA0 for decimal 160) in my local network.

What you need to set this up for testing:

- AMB/MyLaps Decoder rc3 or rc4
- Loop cables and LoopBox
- 1 personal transponder (I use MRT PTX) with battery powersupply (like when it is installed in a RC Car)
- A portable or stationary Computer
- A simple network Switch or Router
- 2 network-cables to connect the computer and the decoder to the Switch/Router
- Some powersupplys to get it all to work
- Some software to listen to the TCP-Ports like WireShark (availible for both Windows and Linux)
- And a really sharp mind... ;-)

I'm not an expert developer in the protocol area so any help in analysing this is apreciated.

Thanx for asking....