wm-sg-sm-42: too much slow reading downlink messages on serial port

[marcoratto]

Hi,

There is someone that can help me with this issue ?

I updated the firmware correctly to the latest version: sm42_monolithix_v4.0.1.hex

I'm connecting via OTAA to TTN and it works fine.

For the first message I have a few seconds from uplink message and downlink message.

For the second message I have a few minutes (always 2 minutes and 12 seconds) from uplink message and downlink message.

Can I speed up the read of the downlink messages ?

Below there are the log of the serial command read:

Sending request: AT+JOIN=1 at 2025-01-27 15:47:39.911145
Received response: '# OK' at 2025-01-27 15:47:39.971146
Received response: '# +JoinAccepted' at 2025-01-27 15:47:48.325081
Transitioning from AT_JOIN to AT_SENDB1 at 2025-01-27 15:47:48.325166

Sending request: AT+SEND=2,50494E4731,1 at 2025-01-27 15:47:48.325312

Received response: 'OK' at 2025-01-27 15:47:48.365047
Transitioning from AT_SENDB1 to WAIT1 at 2025-01-27 15:47:48.365111
Sending request: AT+STAT at 2025-01-27 15:47:48.365143
Received response: '# +STAT=1,0,1,0,0,0,0,0,0' at 2025-01-27 15:47:48.373067
Received: 'OK' at 2025-01-27 15:47:48.373221
Received: '# +RCV=14,12,E79E39DFDE1FE76EDAE3DEFC' at 2025-01-27 15:47:55.941175

Transitioning from WAIT1 to AT_SENDB2 at 2025-01-27 15:47:55.941251
Sending request: AT+SEND=2,50494E4732,1 at 2025-01-27 15:47:55.941320
Received response: 'OK' at 2025-01-27 15:47:55.975199
Transitioning from AT_SENDB2 to WAIT2 at 2025-01-27 15:47:55.975306
Sending request: AT+STAT at 2025-01-27 15:47:55.975347
Received response: '# +STAT=2,0,2,0,0,217,8,1,1' at 2025-01-27 15:47:55.987187
Received: 'OK' at 2025-01-27 15:47:55.988255
Received: '# +RCV=14,12,E79E39DFDE1FE76EDAE3DEFD' at 2025-01-27 15:50:07.857554

Transitioning from WAIT2 to AT_SENDB3 at 2025-01-27 15:50:07.857626
Sending request: AT+SEND=2,50494E4733,1 at 2025-01-27 15:50:07.857685
Received response: 'OK' at 2025-01-27 15:50:07.891495
Transitioning from AT_SENDB3 to WAIT3 at 2025-01-27 15:50:07.891555
Sending request: AT+STAT at 2025-01-27 15:50:07.891583
Received response: '# +STAT=3,0,3,0,0,223,6,2,2' at 2025-01-27 15:50:07.903591
Received: 'OK' at 2025-01-27 15:50:07.904522
Received: '# +RCV=14,12,E79E39DFDE1FE76EDAE3DEDA' at 2025-01-27 15:52:20.075649

Transitioning from WAIT3 to AT_SENDB4 at 2025-01-27 15:52:20.075707
Sending request: AT+SEND=2,50494E4734,1 at 2025-01-27 15:52:20.075777
Received response: 'OK' at 2025-01-27 15:52:20.108809
Transitioning from AT_SENDB4 to WAIT4 at 2025-01-27 15:52:20.108959
Sending request: AT+STAT at 2025-01-27 15:52:20.109064
Received response: '# +STAT=4,0,4,0,0,217,7,3,3' at 2025-01-27 15:52:20.121105
Received: 'OK' at 2025-01-27 15:52:20.121622
Received: '# +RCV=14,12,E79E39DFDE1FE76EDAE3DDF4' at 2025-01-27 15:54:31.991944

Transitioning from WAIT4 to END at 2025-01-27 15:54:31.992002
State machine finished.

Thanks in advance for your support.

Marco

[Andrew Neil]

That's the USI module on the old, obsolete I-Nucleo-LRWAN1, isn't it?

You'd have to go to USI for support with that - it's their module, and their firmware ...

Does the TTN console give any indication whether the delays are in TTN, or in the module?

Also, have you asked on TTN's forum?

[marcoratto]

The board is board I-Nucleo-LRWAN2: https://www.st.com/en/evaluation-tools/p-nucleo-lrwan2.html

The delay is on the radio module, not on TTN.

[Andrew Neil]

That's P-Nucleo-LRWAN2 - which is a Pack containing a gateway and an I-Nucleo-LRWAN1.

---

@marcoratto wrote:

The delay is on the radio module, not on TTN.

---

How do you know that?

[Tesla DeLorean]

"On the sensor-node side, the NUCLEO-L073RZ, based on an ultra-low-power STM32L0 Arm® 32-bit microcontroller, controls a USI® I-NUCLEO-LRWAN1 ARDUINO® expansion board used as a sensor node.

The I-NUCLEO-LRWAN1 end-node is an ARDUINO® compatible expansion board. This board is designed by USI® around a LoRa® module powered by an STM32L05 device hosting a friendly AT command stack."

You might be able to port firmware on to this platform, but it's quite old, and I doubt USI is actively supporting it.

[marcoratto]

On the log of TTN and on the log of the device:

I execute the AT command "AT+STAT" and report the counter updated with the new messages but the event +RCV arrives 2 minutes after.

Transitioning from WAIT1 to AT_SENDB2 at 2025-01-27 15:47:55.941251
Sending request: AT+SEND=2,50494E4732,1 at 2025-01-27 15:47:55.941320
Received response: 'OK' at 2025-01-27 15:47:55.975199
Transitioning from AT_SENDB2 to WAIT2 at 2025-01-27 15:47:55.975306
Sending request: AT+STAT at 2025-01-27 15:47:55.975347
Received response: '# +STAT=2,0,2,0,0,217,8,1,1' at 2025-01-27 15:47:55.987187
Received: 'OK' at 2025-01-27 15:47:55.988255
Received: '# +RCV=14,12,E79E39DFDE1FE76EDAE3DEFD' at 2025-01-27 15:50:07.857554

[Andrew Neil]

---

@Tesla DeLorean wrote:

I doubt USI is actively supporting it.

---

USI's support could hardly be described as "active"  even when this board was current ...

@marcoratto Here's a contemporary thread:

https://community.st.com/t5/stm32-mcus-products/i-nucleo-lrwan1/m-p/325119/highlight/true#M77077

It seems that the USI GitHub no longer exists, neither does their web page.

PS:

USI website is now here: https://www.usiglobal.com/en - no search hits for wm-sg-sm-42 (with or without the hyphens)

[marcoratto]

I asked to USI to restore the github repository:

https://github.com/USIWPModule/USI_I-NUCLEO-LRWAN1

[Tesla DeLorean]

Sure, the USI firmware was read-protected, I recollect my FAE just reprogramming it, as did I, but the implementation was generally less capable than the LRWAN-DISCO board, other than all the sensors attached to this one.

They had a GitHub or notes related to the modifications to the LRWAN 1.x.x libraries, and I recall making a pin list for the internal MCU and SX1272 from the schematic

[Andrew Neil]

Great - if you're in contact with USI, that's the place to get support.

Good luck!