Results 1 to 5 of 5

Thread: Parser_variable_length

  1. #1

    Post Parser_variable_length

    I found PARSER_VARIABLE_LENGTH option in post #20 and it looks like itís almost able to do what I need (It might but I havenít been able to figured it out).

    Ron you mention that you added it to the manual and you have but only to the manual that is found from within Girder (it appears to be missing from the pdf and html manual found on

    I am trying to parse packages of variable length (EnOcean ESP3) based on 3 bytes in the package header.

    The values are in hexadecimal form and offset 1,2 and 3

    e.g. a message can look like this

    55 0007 07 01 7A F6 50 FF D5 C3 00 30 03 FF FF FF FF FF 00 31

    Byte 1 and 2 are Data Length, in this case 7 (0x0007) and as I understand they are read as one value from 1 to 65535 (0xFFFF = 65535)

    Byte 3 Optional Length, in this case 7 (0x07)

    So the length of the massage would be 21 bytes

    Sync Byte (1) + header (4) + CRC8 (1) + data (e.g. 7) + optional data (e.g. 7) + CRC8D (1)

    55 - 0007 07 01 - 7A - F6 50 FF D5 C3 00 30 - 03 FF FF FF FF FF 00 - 31

    Click image for larger version. 

Name:	Packet descripion.png 
Views:	34 
Size:	37.8 KB 
ID:	7023
    Click image for larger version. 

Name:	Packet structure.png 
Views:	32 
Size:	38.3 KB 
ID:	7024
    Click image for larger version. 

Name:	Packet structure2.png 
Views:	34 
Size:	18.4 KB 
ID:	7022

    I have added some pictures for clarification of the package construction.

    My question is, can this be done with PARSER_VARIABLE_LENGTH?

    If not could you consider adding it?



  2. #2
    Join Date
    Jan 1998
    Jupiter, FL


    Variable can only do one length field. Let me see if I can do a 2 field length or something more generic...
    No support through PM

  3. #3


    Hi Ron,

    I can imagine that this require some thinking in order to make in real generic and future prof. Let me know if I can be of any assistants in trying out any changes. I do all of my testing/development on Windows but I intend to run my final solution on a Raspberry PI 2 or 3.

    If you require more information about the ESP3 protocol you'll find it her. (see page 10 -13)

  4. #4



    Can't you do it "on the fly"? Either by decoding necessary fields and save x number of byte to a variable to decode later or by collecting the stream and look for the start byte (0x55).

    I had a similar issue where I wanted to decode a USB stream from a Oregon Scientific weather station.
    In short,
    I am saving all the data to a variable and look for the start pattern and once found I save the data and call a function to save it in a table based on the adress where the data is sent from.

    This is a Girder 5 lua script. I assume it should be fairly easy to get it running in Girder 6 but I do not know since I have not tried yet.
    It is not pretty but has been working for a few years. Sometimes there is smaller startup problems but they fix them self after a couple of minutes, haven't had the time to look further into this.

    function hid_cb(a,b)
    	if ( a ) then
    		print("A: "..math.formatbytes(a))
    		reportlen = string.byte(a, 1)
    		c = c..string.sub(a, 2, reportlen + 1)
    		pattern = string.char(255)..string.char(255).."(.-)"..string.char(255)..string.char(255)
    		st, en, wdata = string.find(c, pattern)
    		if ( wdata ) then
    			c = string.sub(c, en-1, -1)
    			wdata = nil
    function fnweatherdata(wdata)
    	ident = string.byte(wdata, 2)
    	print("Ident: "..ident)	
    	tempid = "0"
    	if ident == 66 then
    		tempidb = string.byte(wdata, 3)
    		tempid = math.zerobits(tempidb, 240)
    	wreports[ident.."."..tempid] = wdata
    	print(ident.."."..tempid..": "..math.formatbytes(wdata))
    hid = transport.New(transport.constants.transport.USBHID)
    -- HID devices always prepend a report ID number, for most this is unimportant, but you might need it.
    --Set the CALLBACK method to read the incoming data.
    hid:Callback(transport.constants.parser.STREAM, hid_cb)

  5. #5


    Hi Ron,

    I wonder if you have had time to think about how to make the Parser_variable_length more generic and flexible?

    My attempts to write a EnOcean driver is yielding some results, I can now build and send (calculate CRC8 for data and optional data etc.) an EnOcean message in order to turn device on and of.

    But to receive I need the parser to parse the incoming data so that I can process it (check CRC8, dig out the return message etc.).

    Any chance you could have a look at it?



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts