# Big STM32 boards topic **URL:** \ **Category:** End Devices (Nodes)\ **Created:** [April 10, 2018, 7:21pm UTC](https://www.thethingsnetwork.org/forum/t/big-stm32-boards-topic/13391 "2018-04-10T19:21:26Z")\ **Posts on this page:** 1\ **Showing post:** 100
**Author:** ![GrumpyOldPizza](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/grumpyoldpizza/32/44891_2.png) [@GrumpyOldPizza](https://www.thethingsnetwork.org/forum/u/GrumpyOldPizza)\ **Post date:** [June 5, 2018, 1:48pm UTC](https://www.thethingsnetwork.org/forum/t/big-stm32-boards-topic/13391/100 "2018-06-05T13:48:17Z")
> [@Murata CMWX1ZZABZ-xxx LoRaWAN Module Breakout Board](https://www.thethingsnetwork.org/forum/t/murata-cmwx1zzabz-xxx-lorawan-module-breakout-board/14551/10): > > @GrumpyOldPizza > > Contunued from here: [Murata CMWX1ZZABZ-xxx LoRaWAN Module Breakout Board - #17 by GrumpyOldPizza](https://www.thethingsnetwork.org/forum/t/murata-cmwx1zzabz-xxx-lorawan-module-breakout-board/14551/17) > > > [@Murata CMWX1ZZABZ-xxx LoRaWAN Module Breakout Board](https://www.thethingsnetwork.org/forum/t/murata-cmwx1zzabz-xxx-lorawan-module-breakout-board/14551/10): > > > > 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. > [@Murata CMWX1ZZABZ-xxx LoRaWAN Module Breakout Board](https://www.thethingsnetwork.org/forum/t/murata-cmwx1zzabz-xxx-lorawan-module-breakout-board/14551/10): > > 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 …). > [@Murata CMWX1ZZABZ-xxx LoRaWAN Module Breakout Board](https://www.thethingsnetwork.org/forum/t/murata-cmwx1zzabz-xxx-lorawan-module-breakout-board/14551/10): > > - 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](https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html#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); > [@Murata CMWX1ZZABZ-xxx LoRaWAN Module Breakout Board](https://www.thethingsnetwork.org/forum/t/murata-cmwx1zzabz-xxx-lorawan-module-breakout-board/14551/10): > > - 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. --- _[View the full topic](https://www.thethingsnetwork.org/forum/t/big-stm32-boards-topic/13391)._