2017-10-20 10:16 AM
I have:
all of the above purchased/downloaded in the last couple of weeks - so up-to-date.
I have watched this video:
https://www.youtube.com/watch?time_continue=497&v=np6oYopJyFI
But it is out-of-date with both the
I-CUBE-LRWAN firmware and the Conduit.
See:
https://community.st.com/community/stm32-community/blog/2016/11/30/stm32-lora-kit&sharpcomment-3834
It seems that the
demo called ''Class A'' in the video is now called ''End Node''.
So I think I managed to find all the points to tweak as mentioned in the video.
Not mentioned in the video is that STATIC_DEVICE_EUI has to be set for the LORAWAN_DEVICE_EUI edits to be effective!
The code built fine for the two boards, and downloads and runs.
I only run one board at a time. Both boards behave identically.
The Conduit sees the board as ''Joined'', but the Node-RED does not see any incoming data.
I don't see any ''JOINED'' message in the UART output from the board (the video shows one, but the UM2073 documentation says nothing about what should currently be expected on the UART).
Using the 'Download Logs' from the Conduit, the messages log contains stuff like:
Oct 20 08:03:18 mtcdt user.info lora-network-server: Parsing 1 rx packets
Oct 20 08:03:18 mtcdt user.info lora-network-server: Received join requestOct 20 08:03:18 mtcdt user.info lora-network-server: Device found in DB, assigning address: 1Oct 20 08:03:18 mtcdt user.info lora-network-server: Queue join response 33 bytesOct 20 08:03:18 mtcdt user.info lora-network-server: Send Join Accept - EUI: be-7a-00-00-00-00-00-c8 ADDR: 00000001Oct 20 08:03:18 mtcdt user.info lora-network-server: Schedule TX Time on air: 81 msOct 20 08:03:19 mtcdt user.info lora-network-server: Frame transmitted to 00:00:00:01 via GW (00:80:00:00:a0:00:05:a8 Chan LC2 127.0.0.1:34778) Seq♯ 0Oct 20 08:03:19 mtcdt user.info lora-network-server: Update DC Band: 1 Duration: 71 time-on-air available: 35929 msOct 20 08:03:19 mtcdt user.info lora-network-server: Transmit UDP message to Gateway 208 bytesOct 20 08:03:48 mtcdt user.info lora-network-server: Parsing 1 rx packetsOct 20 08:03:48 mtcdt user.warn lora-network-server:Recv'd frame failed CRC check
Oct 20 08:03:49 mtcdt user.info lora-network-server: Parsing 1 rx packetsOct 20 08:03:49 mtcdt user.warn lora-network-server:Recv'd frame failed CRC check
CRC errors would explain why the received data is not being seen.
So: has anyone actually got this working with a Conduit gateway using the current firmware?
The fact that the behaviour is the same for the 2 boards suggests that it's a configuration issue rather than a HW fault.
I also have some MultiTech mDot modules, and they communicated with the Conduit as originally configured.
#b-l072z-lrwan1 #multitech #p-nucleo-lrwan1 #lora #lorawan #stm32-l0Solved! Go to Solution.
2017-10-21 08:52 AM
The key thing that I'd missed (which is shown in the video) is that the Conduit's LoRa Network Server must be set to Public:
With that, I do now see 'JOINED' in the STM32 UART output, and there is something being received in the Node-RED - although it is currently barfing on it ...
2017-10-21 08:52 AM
The key thing that I'd missed (which is shown in the video) is that the Conduit's LoRa Network Server must be set to Public:
With that, I do now see 'JOINED' in the STM32 UART output, and there is something being received in the Node-RED - although it is currently barfing on it ...
2017-10-23 07:06 AM
For info, MultiTech's documentation says:
'Enable public compatibility mode: changes the join response time from 1 to 5 seconds and the sync word from 0×12 to 0×34'
In the I-CUBE-LRWAN code, commissioning.h has:
/*!
* Indicates if the end-device is to be connected to a private or public network
*/
#define LORAWAN_PUBLIC_NETWORK true
�?�?�?�?
and the sx1h and sx1h files have:
/*!
* Sync word for Private LoRa networks
*/
#define LORA_MAC_PRIVATE_SYNCWORD 0x12
/*!
* Sync word for Public LoRa networks
*/
#define LORA_MAC_PUBLIC_SYNCWORD 0x34
�?�?�?�?�?�?�?�?�?