mDot Configuration/Join Issue

[Martin Bures]

We have a device using mDot modems.

We configure them as-follows:
AT&F
AT+TXDR=1
AT+FSB=1
AT+NJM=1

Then we set:
AT+NI=1,<network name>
AT+NK=1,<network key>

As we are investigating moving to be Lora-compliant, we began to adjust these values and started setting AT+PN to Lora Public.

We had a new batch of devices built and accidentally set this new PN value into all of the modems and they will not join to our network now.

Previously, the configuration reported:
Public Network: off

Now, it reports:
Network Mode: Private MTS
or
Network Mode: Private LoRaWAN
if I select 0 or 2 but even if I reset the factory configuration, I cannot get it to look as it did originally where it just states the above and does not list anything related to Public Network.

I have tried swapping modems in the device with one working with the previous connection and it joins the network. The join sequence looks very similar.
(successful)

20:34:16:186|INFO| GW:00:80:00:00:00:00:b7:c2|FRAME-RX|Parsing 1 packets
20:34:16:189|INFO| ED:00-80-00-00-00-01-34-96|DEV-ADDR|Found End Device in DB 6000008
20:34:16:193|INFO| ED:00-80-00-00-00-01-34-96|QUEUE-TX|JOIN SIZE: 17
20:34:16:194|INFO| ED:00-80-00-00-00-01-34-96|JOINREQ-OK|JOINS: 66203 UP: 6478699
20:34:16:219|INFO| ED:00-80-00-00-00-01-34-96|JOIN-ACCEPT|DevAddr: 06000008
20:34:16:220|INFO| ED:00-80-00-00-00-01-34-96|SCHED-TX|Use RX1 TOA:92 ms
20:34:16:991|INFO| GW:00:80:00:00:00:00:b7:c2|FRAME-TX|IP: 127.0.0.1:36287 CH: LC6 NODE: 06:00:00:08 FCNT: 00000000 REPEAT: 0
20:34:16:996|INFO| ED:00-80-00-00-00-01-34-96|SCHED-TX|Q-SIZE: 1 PKT-SIZE: 17 PKT-ROOM: 242
20:34:17:2|INFO| GW:00:80:00:00:00:00:b7:c2|UDP-TX|JSON-SIZE:257

(unsuccessful)
21:6:17:292|INFO| GW:00:80:00:00:00:00:b7:c2|FRAME-RX|Parsing 1 packets
21:6:17:295|INFO| ED:00-80-00-00-00-01-4d-69|DEV-ADDR|Found End Device in DB 6000009
21:6:17:301|INFO| ED:00-80-00-00-00-01-4d-69|QUEUE-TX|JOIN SIZE: 17
21:6:17:301|INFO| ED:00-80-00-00-00-01-4d-69|JOINREQ-OK|JOINS: 66208 UP: 6478704
21:6:17:322|INFO| ED:00-80-00-00-00-01-4d-69|JOIN-ACCEPT|DevAddr: 06000009
21:6:17:322|INFO| ED:00-80-00-00-00-01-4d-69|SCHED-TX|Use RX1 TOA:22 ms
21:6:18:91|INFO| GW:00:80:00:00:00:00:b7:c2|FRAME-TX|IP: 127.0.0.1:36287 CH: LC9 NODE: 06:00:00:09 FCNT: 00000000 REPEAT: 0
21:6:18:95|INFO| ED:00-80-00-00-00-01-4d-69|SCHED-TX|Q-SIZE: 1 PKT-SIZE: 17 PKT-ROOM: 242
21:6:18:101|INFO| GW:00:80:00:00:00:00:b7:c2|UDP-TX|JSON-SIZE:255

How can I fully restore the modems’ configuration or correct this configuration issue? We need to get this resolved to get these devices out the door.

Thanks.
Martin.

• This topic was modified 4 years, 9 months ago by Martin Bures.

[Jason Reiss]

The previous value of AT+PN=0 – Public Network: off can be set with these commands:

AT+PN=0
AT+JD=1

The default Join Delay was changed to 5 seconds to be LoRaWAN compliant. In previous versions changing from AT+PN=0 to AT+PN=1 or vice-versa would adjust the Join Delay. This must be done explicitly now.

[Martin Bures]

THANK YOU!

Thant did the trick.

Martin.

[Martin Bures]

So with the updates to the configuration that you mentioned, I can now join and pass data.

With our existing design/firmware, the system mostly starts up but fails during one of the command transactions – seemingly on the firmware side before transmission. For the failing command, we send a 0x27 and expect a response back. For this command the gateway never sees a message.

Earlier transactions succeed with messages going back and forth.

If I take the modem out of the device and put it in your development kit and run all of the commands manually, this process succeeds.

Could there be any other configuration options that need to be set? Could there be some sort of transmission problem with 0x27 and some sort of serial mode? We have many of these devices running the same firmware and they seem fine. As I said above, if I put a working modem into the device, this transaction sequence completes successfully.

Here is the manual sequence:
AT+sendb=00
AT+sendb=23
AT+sendb=27

I am going to capture the serial traffic to see what is happening during the transaction between the device and the modem.

[Martin Bures]

Furthermore, is there a way to fully dump all config values from one modem so we can mirror that configuration on another?

[Martin Bures]

We have gone deeper into our issue and do not necessarily think this has anything to do with configuration settings.

We have modems in units purchased a while ago. We also have 100 modems that we purchased for new units within the last few months.

With the new modems we cannot fully communicate. We are with the above help able to join. We then send the above traffic sequence. What we see is that everything transmits correctly until the AT+SENDB=27 line. The previous command – the AT+SENDB=23 requests time information which comes back correct. The next command, the 27 requests configuration. It comes out garbled and never is actually transmitted to the gateway. We attempt to retry this command a few times and this is what we see if we capture the traffic on the uart between the mdot and our device:
AT+SENDB=1576302e310000000000323631663537322d6469727479000000000000000000000000000000000

Occasionally it will send a correct sequence but that is rare.

If I put in an older version of the modem, the system works correctly – no problems.

Both modems were flashed with the same firmware and have the same configuration setting.

The modem version is: 3.0.0-US915-mbed-os-5.4.7.bin

Current examples of working/non-working modems:
Non-working:S/N 20144285
Working:S/N 19056253

Any help is appreciated.
Martin.

[Martin Bures]

I have additionally tried updating the firmware version on the new mDot to 3.1.0 and get the same behavior.

[Jason Reiss]

If the same software works on another hardware without issue then it may be a hardware issue.
I suggest opening a ticket at support.multitech.com to report the issue.

[Author]

Posts