Labels LSB for View and Checksum calc

[f-alex]

Hi,

It is possible to add reverse byte order (LSB) option for protocol Labels Value (not for all message) and Binary-coded decimal (BCD) for Display format?

And LSB option (checkbox near Apply decoding may be) in Label Table for checksum calc in Edit Protocol window.

[jopohl]

I just added BCD display format in #386 . For LSB I think it would lead to too many display formats, because we would need to consider it for every exisiting one (LSB Bit, LSB Hex, LSB Decimal, LSB BCD). What you could do, is to work with Do Not Decode Labels.

For checksum calculation: Shouldn't it be enough to swap the bits of the CRC polynomial for LSB?

[f-alex]

Ohh, thanks, so fast...))
But for LSB I think about checkbox in addition (near) to Display format.
Not sure for second question. Think it is enough for bit order. Or for bytes also? As for crc16 or crc32 byte order also important.

[jopohl]

Not sure about a checkbox for this...this would add an extra column to the table and, therefore, improve complexity of the program.

I would like to get a deeper understanding here first. Could you tell me a bit more about your use case for this feature? Do you have a protocol that switches LSB for certain labels?

[f-alex]

Hi,
Yes, some 433,92Mhz (315,868Mhz etc) devises protocol, Oregon sensors for example.
http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf

Message divided for 4 bits blocks (nibbles), so swapping all bytes before will "destroy" packet structure. But data block fields fitted to bytes (2, 4, 6, 8 nibbles) with LSB. Sensor data (temp etc.) coding in BCD LSB.

[jopohl]

This is very interesting, thanks for sharing this link! The way I understand this is, that the LSB needs to be considered nibble wise? You should get this to work with an external decoding. You can use this python one for example:

#!/usr/bin/env python

import sys

bits = sys.argv[1]

# padding
while len(bits) % 8 != 0:
    bits += "0"

result = []
for i in range(0, len(bits), 8):
    result.append("".join(reversed(bits[i+4:i+8])))
    result.append("".join(reversed(bits[i:i+4])))

print("".join(result))

Just save the code to a file and specify the filename when creating a new decoding with External Program in decoding dialog.

Let me know if this helps!

[f-alex]

Hi,

Thank you! Yes I will try it tomorrow... I hope.

But sorry, my bad. In this protocol is not LSB (that need to swap all bits), it is LSDigit.
Here all of data field should be swapped by nibbles. A1B2 swaped like 2B1A.
In examples on page 13 of PDF you can see this. "4808" in transmit order swap to 8084 and decoded like 8 is "-" sign and 08.4 degrees temp.

Not sure but think this proc will help:

#!/usr/bin/env python

import sys

bits = sys.argv[1]

# padding by nibble
while len(bits) % 4 != 0:
    bits += "0"

result = []
for i in range(len(bits), 0, -4):
    result.append("".join(bits[i-4:i]))

print("".join(result))

If I understand all data message is fitted to bytes, If not then additional nibble added before Checksum field.

Checksum calculate as sum of all swapped to LSB bytes of data message and compared to Checksum field that also swapped to LSB. Overflow shifted to less order and added to Checksum sum. (p.9) But think it can be done with swapping bits polynomials as you said. But here I have some misunderstandings as it just Checksum but not CRC

BTW, I found one else page with some info
https://jeelabs.net/projects/cafe/wiki/Decoding_the_Oregon_Scientific_V2_protocol
Here most interesting is PDE file with decoding class for Atmel (Arduino?) for a lot of protocols.
https://jeelabs.net/attachments/49/Ook_OSV2.pde
I don't analyze it yet but hope it can be helpful for make some another external decoders

[jopohl]

Could you upload a signal from this protocol so we can have a look at it in URH?

[f-alex]

Hi, sure
https://www.dropbox.com/sh/nwhx1gewjbgtiap/AAAB_PvKs58NrDKvfi8QgXiSa?dl=0
Here two same messages (sensor send it twice for redundancy) from THN132N temp sensor. I made "Oregon" decoder (substitute mode) but it need double data package so I had set bit length twice shorter. And "Oregon" message type as well but it need to correct

[jopohl]

Thanks so far. The way I see it, we only need LSDigit for the data part which is in BCD code?

So just to be more clear on this: Do we need a whole flag for LSDigit or will it be enough to add another view type "BCD (LSDigit)" next to the normal BCD one?,

[f-alex]

I would suggest one more combobox, something like "bit order", with "none", "LSD" items, may be even "LSB".

PS. Hope that "LSD" will not associate with something else)

[jopohl]

Okay, I added such a combox with #390 . Possible values are "MSB", "LSB", "LSD". Looks like this now:

[f-alex]

Perfect! Thank you!

[jopohl]

Version 1.9.2 is out with this feature on board! Closing this one.