Big STM32 boards topic

[GrumpyOldPizza]

@bluejedi

@GrumpyOldPizza

Contunued from here: Murata CMWX1ZZABZ-xxx LoRaWAN Module Breakout Board - #17 by GrumpyOldPizza

@GrumpyOldPizza

All of the functionality is wrapped into a nice and way more useful Arduino Class. Lot’s of examples how to use things. Here the link to the include file to show the API (sorry, I am notoriously bad about writing docs)

With all respect, what docs?
The code doesn’t contain any (and the LoRaWAN library code is rather cryptic).
Adding some documentation to the code and adding a description of the library will increase it’s usability for others tenfold.

Yes, as soon as this goes to beta. I have still a long list of things to address. While addressing those I really need to keep the freedom to mock around with the API.

The code is not that cryptic … it just needed to be as small as possible. I still have this notion that a decent LORaWAN sensor application might fit into a STM32L052.

@GrumpyOldPizza

I tried the included basic examples TTN_OTAA.ino and TTN_ABP.ino using #define REGION_EU868 (on a B-L072Z-LRWAN1 board).
Unfortunately I directly ran into several issues:

• TTN_ABP.ino
  The examples use LoRaWAN keys/id’s in string format.
  The only (byte array) string format that TTN Console uses is msb-first format.
  (The TTN Console supports both msb-first and lsb-first formats only for the array initializer notation with brackets.)
  Unfortunately the TTN_ABP example expects the devAddr string variable to be in lsb-first format which is not consistent with the format that TTN Console provides and neither is it documented that devAddr requires lsb-format instead of msb-format. nwkSKey and appSKey use msb-first format, like presented on the TTN Console, but again information about the required format is missing.

Thanx for pointing out. I’ll updated the comments in the examples. Yes, “devAddr” is LSB and the keys are MSB. I did follow there the common convention (Arduino MKR 1300, Murata’s own AT-Command set …).

@GrumpyOldPizza

• TTN_OTAA.ino
  Different from TTN_ABP.ino, TTN_OTAA.ino expects all LoRaWAN keys/id’s in msb-first format.
  That is at least the only way where I can get a JOIN ACCEPT on a JOIN request.
  I tried devEui, appEui and appKey in different msb-first / lsb-first combinations but only when all were msb-first did I actually see JOIN ACCEPT’s on the gateway and application consoles.
  But then it stops. The JOIN ACCEPT is not followed up by an upstream message from the node. I see no data arriving.
  What can this be? Why doesn’t the node send any data messages?

Keys are MSB first as common convention, the rest is LSB first. So perhaps this is the issue. Does the gateway send out a CFlist in the JOIN_ACCEPT to populate the rest of the channels ? I heard different things from users (I am in US915 based, so testing EU868 is somewhat tricky).

EU863-870

But even if the gateway would not send a CFlist, you’d still be able to use the core 3 channels. However then there is the dutycycle issue, which means the system will wait till it is allowed to send again. Perhaps for debugging you’d want to use:

LoRaWAN.setDutyCycle(false);

@GrumpyOldPizza

• Both the OTAA and ABP examples start communication at SF12 instead of the usual SF7.
  The examples do not specify a spreading factor so SF12 appears to be the default.
  I think the default should be SF7.
  Where can the spreading factor be specified?

Yes, per default ADR is enabled, so the setup starts with SF12BW128 (i.e. DR_0). SF7 is unclear. There is SF7BW125 (DR_5) and SF7BW250 (DR_6).

What you’d do is:

LoRaWAN.setADR(false);
LoRaWAN.setDataRate(5);

Thanx for the good feedback.