[Andrew Lindsay]

Following on from this, I have 2 nodes, both using the same version of libraries (mdot 121, mdot-rtos 110, libmDot 14), the first output below is from a mdot that uses the RTC to wake up from deep sleep, the second uses the interrupt pin to wake it up. There are some differences in what is output in the DEBUG and TRACE results, can someone explain why there are differences when it should be identical code within the library that is being executed?

The other difference is that the second device using interrupts to wake up doesn’t appear to send any data and is re-joining the network each time even though the code for both is almost identical and is set to preserve the session. The first one is able to join, send data, sleep, wake, restore session, send data, sleep, etc which is what I’d expect to see.

[INFO] Joining Network
[TRACE] Initiating join…
[TRACE] Join Network – Auto OTA
[TRACE] Join attempt #1
[DEBUG] Send Join Packet with DR0
[TRACE] Number of enabled channels: 3 Mask: 00ff
[TRACE] Check freq: 2 – 868500000
[TRACE] Preparing frame
[TRACE] FRAME_TYPE_JOIN_REQ
[DEBUG] txPower: 14 AntG: 3 radioPower: 11
[INFO] TX Frequency: 868500000 SF: 12 BW: 125 kHz POW: 11 dBm
[DEBUG] Time on air: 23 bytes 1482 ms
[DEBUG] Time off air: 148200 ms duty-cycle: 1.0 %
[TRACE] Rx Window 1 – Frequency: 868500000 BW: 0 SF: 12
[TRACE] Rx Window 2 – Frequency: 869525000 BW: 0 SF: 12
[TRACE] RxDone -75 30
[TRACE] Rx Packet Type: 1 Size: 33
[TRACE] FRAME_TYPE_JOIN_ACCEPT
[TRACE] mic: d57c91d7 rx: d57c91d7
[DEBUG] Network joined
[TRACE] Computing session keys…
[TRACE] NetID: 0x0E0E0E
[TRACE] DevAddr: 0x1D3FF247
[TRACE] rxDrOff: 0 rx2Dr: 3 rxD1: 1000
[TRACE] Add Channel Frequency 867100000
[TRACE] Add Channel Frequency 867300000
[TRACE] Add Channel Frequency 867500000
[TRACE] Add Channel Frequency 867700000
[TRACE] Add Channel Frequency 867900000
[INFO] Joined Network
[TRACE] Number of enabled channels: 5 Mask: 00ff
[TRACE] Check freq: 6 – 867700000
[TRACE] Preparing frame
[TRACE] FRAME_TYPE_DATA_UNCONFIRMED_UP
[DEBUG] UplinkCounter: 0
[TRACE] Encrypting application packet to buffer…
[DEBUG] txPower: 14 AntG: 3 radioPower: 11
[INFO] TX Frequency: 867700000 SF: 10 BW: 125 kHz POW: 11 dBm
[DEBUG] Time on air: 22 bytes 370 ms
[DEBUG] Time off air: 370000 ms duty-cycle: 0.1 %
[INFO] send data: 33332e382c32302e33
[DEBUG] Session saved to flash
[DEBUG] wrote 256 bytes
[DEBUG] file size: 256 bytes
[TRACE] 0 : 370000
[TRACE] 1 : 138774
[TRACE] 2 : 0
[TRACE] 3 : 0
[TRACE] configuring RTC Alarm A to wakeup 300 seconds from now
[TRACE] save timers: 138314 369540 0 0 0 138251
[INFO] entering deepsleep (standby) mode 00000037

Lines marked XXX are ones I’ve identified as being extra in this output.

[TRACE] Join Network – OTA
[TRACE] RTC ISR 00000037 00000020 00000020 00000000
[TRACE] restore timers: 0 0 0 0 0 0
[TRACE] Enable milli band
[TRACE] Band 0 : 0
[TRACE] Enable centi band
[TRACE] Band 1 : 0
[TRACE] Enable deci band
[TRACE] Band 2 : 0
[TRACE] Enable vari band
[TRACE] Band 3 : 0
[INFO] Joining Network
[TRACE] Initiating join…
[TRACE] Join Network – Auto OTA
[TRACE] Join attempt #1
[DEBUG] Send Join Packet with DR3
[TRACE] Number of enabled channels: 3 Mask: 00ff
[TRACE] Check freq: 0 – 868100000
[TRACE] Preparing frame
XXX [TRACE] FRAME_TYPE_JOIN_REQ
XXX [TRACE] PACKET: 23 bytes
XXX [TRACE] BUFFER: 00f60000d07ed5b370c59f0000000080005cb98b0b54a2
[DEBUG] txPower: 14 AntG: 3 radioPower: 11
[INFO] TX Frequency: 868100000 SF: 9 BW: 125 kHz POW: 11 dBm
[DEBUG] Time on air: 23 bytes 205 ms
[DEBUG] Time off air: 20500 ms duty-cycle: 1.0 %
[TRACE] Rx Window 1 – Frequency: 868100000 BW: 0 SF: 9
[TRACE] Rx Window 2 – Frequency: 869525000 BW: 0 SF: 12
[TRACE] RxDone -75 23
[TRACE] Rx Packet Type: 1 Size: 33
XXX [TRACE] FRAME_TYPE_JOIN_ACCEPT
XXX [TRACE] PAYLOAD SIZE: 33
XXX [TRACE] APPKEY: ec22cbc24733e3397b83c4c9dea685a8
XXX [TRACE] BUFFER: 20d91edf0e0e0e0145601c0301184f84e85684b85e84886684586e8400b6a3bbe0
[TRACE] mic: e0bba3b6 rx: e0bba3b6
[DEBUG] Network joined
[TRACE] Computing session keys…
XXX [TRACE] DNONCE: b95c
XXX [TRACE] ANONCE: d91edf
XXX [TRACE] NETS: dc7f91426ada01eacde85a6a428f5d6d
XXX [TRACE] APPS: 5cccbdd44b1f896a0cf4ca15ada9b6c5
[TRACE] NetID: 0x0E0E0E
[TRACE] DevAddr: 0x1C604501
[TRACE] rxDrOff: 0 rx2Dr: 3 rxD1: 1000
[TRACE] Add Channel Frequency 867100000
[TRACE] Add Channel Frequency 867300000
[TRACE] Add Channel Frequency 867500000
[TRACE] Add Channel Frequency 867700000
[TRACE] Add Channel Frequency 867900000
[INFO] Joined Network
// Data
[TRACE] Number of enabled channels: 5 Mask: 00ff
[TRACE] Check freq: 3 – 867100000
[TRACE] Preparing frame
[TRACE] FRAME_TYPE_DATA_UNCONFIRMED_UP
[DEBUG] UplinkCounter: 0
[TRACE] Encrypting application packet to buffer…
XXX [TRACE] PACKET: 14 bytes
XXX [TRACE] BUFFER: 400145601c000000017f87d9f070
[DEBUG] txPower: 14 AntG: 3 radioPower: 11
[INFO] TX Frequency: 867100000 SF: 7 BW: 125 kHz POW: 11 dBm
[DEBUG] Time on air: 14 bytes 46 ms
[DEBUG] Time off air: 46000 ms duty-cycle: 0.1 %
XXX [INFO] sent data to gateway
Sleep
[DEBUG] Session saved to flash
[DEBUG] wrote 256 bytes
[DEBUG] file size: 256 bytes
[TRACE] 0 : 46000
[TRACE] 1 : 12241
[TRACE] 2 : 0
[TRACE] 3 : 0
[TRACE] save timers: 12101 45860 0 0 0 12030
[INFO] entering deepsleep (standby) mode 00000037

Regards

Andrew

[Andrew Lindsay]

A diagram always helps!

Thanks for this Mike.

Andrew

[Andrew Lindsay]

Thanks for the detailed response.

If I have a mDot::getInstance and soon after a deep sleep call without any network interaction such as a join or send data will this break the session?

Thanks

Andrew

[Andrew Lindsay]

Thanks Mike.
I have tried the OTA mode and the mDot still saves session before sleeping and loading it again after waking.

I already have the instructions and firmware for fixing the bad flash as this has happened to a number of mDots now.

Thanks

Andrew

[Andrew Lindsay]

It seems that the version requirements are pretty specific. Previous versions of the library required mbed-rtos r110 otherwise join wouldnt work.

Multitech need to get their act together to produce a stable library.

Andrew

[Andrew Lindsay]

I’m seeing:

[INFO] Saved session was not Joined

in the trace output, the previous section showed the mDot had joined the network, but after sleeping and waking it had lost the join information.

One other thing I have noticed is that if it joins successfully, it claims to have then send the data payload but in fact nothing is received at the gateway, only if the join session is successfully restored might I actually see data on the gateway.

Is setting any of the parameters actually breaking the join session?

Andrew

[Andrew Lindsay]

You dont need to define the InterruptIn pin.

[Andrew Lindsay]

Thank you Leon,

I’ll give this a try.

Andrew

[Andrew Lindsay]

If someone has already opened a support call, can they please post the information here. I’ll only raise a support call as a last resort and would expect my mDots to be replaced.

Someone must have the information, why the secrecy? This is supposed to be a support forum for the Multitech products afterall.

Just share the info for all to see.

Thanks

Andrew

[Andrew Lindsay]

I’ve tried this a few times now and Ymodem file transfer doesnt seem to be very reliable. I am trying to transfer a 200byte file and it repeatedly times out.

I have gone back to trying plain text and raw binary but they dont seem to want to complete.

When the mDot is reset, I can see a 0 byte file when I list the files.

Any ideas?

thanks

Andrew

[Andrew Lindsay]

Can you share the steps to resolve this issue as I am now seeing it on one of my mDots.

Thanks

Andrew

[Andrew Lindsay]

Using the ymodem transfer, I’ve got this to work.

thanks

Andrew

[Andrew Lindsay]

OK, I used the recv simple option, how do I actually terminate the input? Is the file written to the flash once the upload is terminated?

thanks

Andrew

[Andrew Lindsay]

Are you saying I need to drop into the bootloader to transfer a file with a prefix of “u_”?
I was hoping to just drag the file to the mounted drive.

thanks

Andrew

[Andrew Lindsay]

Thanks Mike, figured it was likely to be something in the mbed library.
I have a few Nucleo boards to try, have a 411 so that should be the same.

Cheers

Andrew

[Andrew Lindsay]

Any update on when the new libmdot will be available?

thanks

Andrew

[Andrew Lindsay]

You shouldnt need to set the band. Using TTN works.
Example application is at https://developer.mbed.org/teams/Thing-Innovations/code/mDot_TTN_OTAA_Node/

Andrew

[Andrew Lindsay]

Depending on your Spreading factor, you may need to wait longer. Try command AT+TXN which will show you the number of milliseconds before you can transmit again.

Andrew

[Andrew Lindsay]

Try increasing the distance between nodes and gateway, the receiver in the conduit could be getting swamped by the signals.

time between transmissions is also another point. If the devices are CE/FCC/LoRa Alliance certified then they should be conforming to time on air restrictions for you.

I know the mDot does this in the 868MHz band.

Andrew

[Andrew Lindsay]

How long did you wait between sending messages?

[Andrew Lindsay]

Hi,

What sort of nodes are you using?

What is the distance between node and conduit?

What type of antenna are you using?

What spreading factors are you using?

Thanks

Andrew

[Andrew Lindsay]

How are you trying to update Node RED? Did you flash the latest AEP firmware?

Andrew

[Andrew Lindsay]

Had the same issue and reverted back to a previous mbed-rtos from 4 weeks ago and that worked. I was going to step forward 1 version at a time to see where it failed.

Thanks Mike for the info, I was scratching my head for a few days trying to work out why my code kept locking up in the join process.

Is there an issue logged with mbed to have this looked at?

Andrew

[Andrew Lindsay]

I’m guessing SPIFFS means something like SPI Flash File System which would indicate the external flash chip isn’t working on the mDot.
Also, ensure you’ve not accidentally used on of the I/O pins PC_6, PC_7, PC_8, PC_10, PC_11 or PC_12 as these are used for the flash chip.

Andrew

[Andrew Lindsay]

Never seen these messages, what do they look like?

[Andrew Lindsay]

Its just a warning and can be ignored, it doesn’t affect the running of Node-RED.

Removing them as previously described will get rid of them if you need to clean up.

Andrew

[Andrew Lindsay]

You probably want to add a 3.3V voltage regulator or even just a diode and rely on the forward voltage drop to reduce the voltage to below 3.6V. Also note that even though the LiPo battery says 3.7V, it could be as high as 4.1V.

Andrew

[Andrew Lindsay]

Perhaps this is a question for the pyOCD community rather than the mDot community.

Andrew

[Andrew Lindsay]

What are you using to send data to your Conduit?
Is it using the correct credentials?
Can you see that the device joined the network?
On the Conduit AEP gui, in the status and logs section, do you see the device showing as having joined?

Andrew

[Andrew Lindsay]

Hi,

Have you had a look at https://developer.mbed.org/platforms/MTS-mDot-F411/ It includes all the pinouts you need plus here are example applications on the right hand side that should help.

Andrew

[Author]

Posts