Beacon CRC calculation does not match LoRaWAN specification examples

[catsup]

The beacon calculation for CRC1 and CRC2 as implemented here does not match the examples from the LoRaWAN 1.0.1 specifications section 16.2, Beacon Frame content (or equivalent section number in other versions of the specification).

The aforementioned section states that

This is a valid EU868 beacon frame:
AA BB CC | 00 00 02 CC | 7E |  00 | 01 20 00 | 00 81 03 | DE 55

The CRC-16 of the NetID + Time fields is 0xC87E but only the 8LSBs are used in that case

However, BeaconCRC( AA BB CC 00 00 02 CC ) returns 0x39B0, not 0xC87E for CRC1.

The examples in the LoRaWAN specifications appear to use an initial crc value of 0x0000 (rather than 0xffff) for calculating their CRC value.

[mluis1]

Yes, you are right.

But, as mentioned in the LoRaWAN specification the ClassB is still experimental. ("Class B must be considered as experimental in this version of the specification", LoRaWAN1.0.1 Page 60 of 91). Which means that the specification will change a lot.

The current implementation is based on a newer version of the LoRaWAN specification which is still being discussed and not publicly released by the LoRa-Alliance.

The classB stack implementation it self is also under development. We decided to provide the current classB implementation for information purposes.

The beacon contents has changed in the new specification. For instance the NetID isn't anymore sent on the beacon and the CRC1 is now 2 bytes long instead of 1 byte. The time value format has also changed, before it was "Time in seconds since 00:00:00 Coordinated Universal Time (UTC), 1 January 1970" and now it is "Time in seconds since 00:00:00, Sunday 5th of January 1980 (start of the GPS epoch) modulo 2^32" this change suppresses the necessity to handle the leap seconds.

For information the packet_forwarder project also implements the beacons with the new format.

[catsup]

Hello,

thanks for your reply. I am aware of the upcoming 1.1 changes and the packet forwarder beacon differences - however, the examples in 1.1 also calculate the beacon CRCs with a 0 crc initialiser value, unlike both the packet forwarder and the end node MAC code.

If we are going to use a CCITT CRC-16 initialized with 0xffff rather than 0x0000, it probably is a good time to update the the draft specifications before release.

FYI, below are the calculated CRC values for all beacon examples in the different specs. The first CRC matches the spec example and is calculated using the CCITT CRC-16 with a seed of 0, the second one is the results from BeaconCRC().

 LoRaWAN 1.0/EU CRC1 [ aabbcc000002cc ] CRC c87e/39b0
 LoRaWAN 1.0/EU CRC2 [ 00012000008103 ] CRC 55de/a410
 LoRaWAN 1.0/US CRC1 [ aabbcc000002cc ] CRC c87e/39b0
 LoRaWAN 1.0/US CRC2 [ 0001200000810300 ] CRC d450/e56e
 LoRaWAN 1.1/EU CRC1 [ 0000000002cc ] CRC 7ea2/70b2
 LoRaWAN 1.1/EU CRC2 [ 00012000008103 ] CRC 55de/a410
 LoRaWAN 1.1/US CRC1 [ 000000000002cc ] CRC 7ea2/8f6c
 LoRaWAN 1.1/US CRC2 [ 0001200000810300 ] CRC d450/e56e

Regards, Marc

[kjendal]

@mluis1 the current draft has a typo. The correct epoch start date for GPS is Jan 6, 1980. This will be addressed in the next draft.

[mluis1]

Thanks @kjendal for the precision.

@catsup I'll ask the technical committee if we need to change the currently used seed (0xFFFF) in the different provided firmware or if we change the specification.

Another thing I'll ask is to include the seed value in the LoRaWAN specification instead of relying on an external document.

[catsup]

Thanks @mluis1