Help with receiving and decoding ugly bit-level tcp messages (LLRP)


#1

Hey there,
I’m trying to get an R1 to talk to an RFID reader over ethernet. The only way to talk to these things is LLRP, which is an ugly nonsensical protocol and has been driving me nuts. Nevermind any kind of xml or even strings, the header data isn’t even byte aligned. For example the Close connection and Close connection response commands are as follows:
Close Connection:
000 001 0000001110 00000000 00000000 00000000 00001010 followed by a 4 byte message ID.
(constant 000) + (3 bit version id) + (10 bit message type) + (4 byte Message length) + (4 byte message ID)
Close Connection Response:
000 001 0000000100 00000000 00000000 00000000 00001010 followed by a 4 byte message ID.
(constant 000) + (3 bit version id) + (10 bit message type) + (4 byte Message length) + (4 byte message ID)

And that’s just to close an LLRP connection. The full spec is [B]here [/B](200 page pdf warning) and the message formatting is on page 125. I can receive a message as a string and look at it in hex, I’m thinking I might be able to use magic numbers (there are no message numbers over 1023). But magic constants and crazy string to hex to int conversions and unpacking is not fun or very readable. I’d like to build a basic framework to build messages to send and extract fields from received messages with the eventual goal of being able to read rfid tags haha.

Currently I’m reading n characters and unpacking parts of the string into int32’s to get message id’s and other data, The Tag data itself is fortunately an actual string so I’ll unpack length to find the string index.

At this point I guess I’m just asking if anyone’s got some tips or sample code to make this a little easier or more robust. I hate making ugly code.

Thanks!!!

PS: also yes I’m aware the username is a little odd, the signup page was failing horribly when I joined.

PPS: I’ve just been recently acclimating to optoscript so if there’s anything glaringly obvious please do share. I have background in C++, C#, python, and a smidge of asm so I’m not starting from scratch but I’ve still got lots to learn about opto.


#2

Hello Canada, (FYI, let me know the username you’d prefer, I can change it for you)

Welcome to the OptoForums!

A couple things for starters, you used the term “unpack” but are you also using the PAC Control command called “Unpack String”? (In the String Commands.) It’s meant to help you do just what you describe. Also, are you using Subroutines? That can help make code less ugly too.

That page 125 was a bit scary with all those "SHALL"s in it, but not too bad. You might want to check out [U][B]this thread[/B][/U] (which was started before the OptoUser had a chance to play with that new-ish UnpackString command, BTW). My reply to his initial question includes some sample OptoScript syntax you might need, like bit shifting >> and [B]bitand[/B] keywords, stuff like that, not too different that C++ etc.

But perhaps you’re already beyond that? Care you share what you have so far?

-OptoMary


#3

Thanks OptoMary,
I was infact using unpackstring, it seems like most of the other parameters are byte-aligned. Right now all I’ve got is a very basic header parser. [I]Currently[/I] the three biggest issues I’m working on are as follows:

  1. What are the minimum parts of the spec I need to adhere to in order to do basic tasks like sending reader configuration packets and receiving basic error messages and storing them. (!!!)
  2. What is the best method of storing the different fixed length parameters (i.e. some fields don't include the field length so I'll need a table or array to search to see how many bytes to unpack)
  3. How the heck are the TLV parameters (Recursive sub parameters) aligned? (not an opto problem hah)

Sorry for the slow response but 195 pages of spec. containing 322 Shall’s and Should’s in a binary protocol does not make for light reading. Nor does it help that I have to manually decode example and test packets that I’ve sniffed because wireshark only picks up message id’s and parameter id’s.

With the whining out of the way I’ll post an update when I have something that can do more than extract the message ID haha.


#4

Has there been any progress on this issue? I have been asked to see what it would entail to have a R1 interface directly with a RFID reader (Speedway R420). I am just getting into learning about LLRP and it seems at this point it would be easier to use a PC to interface with the reader using a custom program (written in C# or similar) which could then also communicate with the R1.

Thanks.

Corey Hughes