Data received on an MQTT topic

As part of the device configuration phase, a Destination is added and assigned to the device. The destination determines whether the received device data is forwarded directly to an MQTT topic or it is sent to a rule for processing. In this instance the data is forwarded to an MQTT topic as the payload does not change over time and can be decoded manually.

Destination is an MQTT topic

If we invoke the MQTT test client and subscribe to ‘topic/p2', we can see the following payload being received:

The most interesting part of the received data is the payload, which here is

Using a Base64 decoder, the payload can be recovered as: Hello!

Of course, on a real system the payload is most likely a packed binary representation of sensor outputs and not human-readable text.

The back-up plan

After spending a lot of time trying to resolve the failure to receive the Join Accept message, an alternative was ordered just in case the problem could not be solved. It is the RAKWireless RAK3172 which can be sourced as a module to be mounted directly to a PCB or fitted to an header for use on the RAK WisBlock base board. RAK3172 is a Low-Power Long Range Transceiver module that is based on STM32WLE5CC chip. It provides an easy to use, small size, low-power solution for LoRa applications. The module complies with Class A, B & C of LoRaWAN 1.0.3 specifications.

Copyright ©RAKWireless: RAK3172 Evaluation Board.

RAK3172 Bring-up

Connecting to the AWSLPWAN (LoRaWAN) network was trivial in comparison to porting the SX126x-Arduino MAC. From initial power-up of the board until successful downlinks (not just uplinks) was achieved in approximately forty minutes. This is many orders of magnitude faster and less painful than porting a LoRaWAN MAC.

To create a LPWAN device on AWS requires the DevEUI, the AppKey and the AppEUI. These three parameters are pre-programmed into the RAK3172 and can be accessed over the AT interface as follows:

The LPWAN device can now be created using the values above, of course these will be different for different devices and can be changed on the device if required.

Once the LPWAN device is ready, the RAK3172 needs to join the LoRaWAN network. This is accomplished with:

A successful join is reported as:

The command to send data over LoRaWAN is as follows:

This breaks down to:

Send a message to FPort 3 (Frame port, similar in concept to a UDP port) . The payload has to be an even number of nibbles and each digit is the hex representation of a nibble.

The payload received on the MQTT topic looks like this:

Decoding this from Base64 to binary gives this:

Finally a queued downlink. As the LoRaWAN device is running as a Class A device, it can only receive a downlink (cloud to device) after it has transmitted an uplink (device to cloud). A downlink can be added via the AWSLPWAN console:

AWS Console view to initiate a downlink.

Click on the Queue downlink message tab. Use an online Base64 encoder to create a suitable message payload for the downlink. This site works well: https://www.base64encode.org/ (https://www.base64encode.org/

Here we have converted Green Custard into R3JlZW4gQ3VzdGFyZA==

Click on the submit and then switch to the AT interface.

Send an uplink as follows:

After a short delay, the queued downlink is received. Notice a second SEND_EVEN_CONFIRMED, this is to acknowledge that the downlink was received which was chosen in the Queue downlink message console window. The received event can be broken down as follows:

Taking the received data:

Interestingly the Base64 encoded payload sent from the cloud has been converted back to ascii values.

Lessons Learned

During the porting work, an alternative part was identified the RAKWireless RAK3172. This is a LoRaWAN module that uses an AT-interface, but the most interesting feature is that the entire LoRaWAN MAC runs on the module. One distinct advantage is that it is certified with the LoRa Alliance Certificate of Compliance:

https://downloads.rakwireless.com/LoRa/RAK3172/Certification/RAK3172_LoRa_Alliance_Certification.pdf

This certification means that the RAK3172 complies with the LoRaWAN v1.03 specification and will effectively communicate with a similarly compliant gateway. The benefits for this are enormous, interoperability between gateways when the device is installed is key. It may be that the device works perfectly when developed on the bench, but as soon as it is installed, any areas that have borderline timings, such as join request/accept procedure, may fail with an alternate gateway. Another area that was not tested on the P2-Core1262-HF combination was receiving downlinks. This requires an accurate timing window and could easily have demonstrated similar issues as seen on the Join request/accept procedure.

It is possible to take the custom hardware and software implementation of the LoRaWAN device to a LoRa Alliance Certified test lab and gain certification. This takes approximately one day (assuming no problems are encountered) and involves travel to either Germany, Spain or Sweden.

https://lora-alliance.org/lorawan-certification-test-houses/

The RAK3172 also has CE and FCC certification. When the module is mounted inside an enclosure and an external antenna is attached, the RF configuration is different to that presented for the certification test. This means that it will need to be CE or FCC certified as a complete product. However, certifying a product containing a pre-certified module is a far easier task as only the EIRP (due to a different antenna) should be affected

Summary

This series of blog posts described the steps taken from identifying suitable hardware which was physically small enough and at a competitive price point, porting a LoRaWAN MAC library, problems encountered and finally an alternative that was both cheaper and easier to use.