lexer should know frame lengths about fdxread HOT 5 CLOSED

Did you found a documentation about the meaning of 3 bytes frame ?

from fdxread.

There is no public documentation on FDX, as far as I know. There are mentions online of a developer document from Nexus AB, but I haven't been able to find it. If anyone has a copy, send it to me!

I've written a smarter lexer that knows about frame lengths, but it came with a major reorganization of decode.py so I decided to take another pass at it before commiting it.

from fdxread.

To understand the second byte with frame length is an large advance.

We have to understand the first and the last byte ...

My impressions are

• the 0x81 byte is not at the end of the frame but is at the beginning, it permit the receiving software to decode the 3 bytes just after and permit easy synchronization when the receiver read on the fly.

• somewhere is the Unit ID of the equipment (32 max equipments=5 bits)
  The WSI box has always ID=2 and NX2 server has ID=0; the other equipments have usually IDs 16,17,...

from fdxread.

I forgot to update this issue when I did 13faaa4.

It implements a better tokenizer that uses the frame length in the header.

I agree that 0x81 should be looked at as the start byte and not the end byte. It makes more sense now that we know that the header has a length field.

Most of my data comes from the GND10 box, so getting a grasp on what may be the device id isn't easy since it generates all of them. If anyone has more data dumps from actual NX2 systems, I think that would help.

Closing this as the main issue has been solved.

from fdxread.

Do you known the Unit ID of your GND10 ?

from fdxread.