[Ajay K]

Thanks Jeff, we switched the timezone to UTC. Thanks for your inputs.

[Ajay K]

Thanks Peter that is good know. I am guessing if we can use the 33 bytes, I would definitely want to use it. Thanks once again for your inputs.

Thanks,
Ajay

[Ajay K]

Thanks Peter for taking the time to respond.

I am using Conduit AEP and the node-red LORA output node to transmit. I don’t think I have the ability to configure “DROffset and which receive window to use”, if my understanding of your response is correct. Also the conduit is being used in the US Market. Most of the times I see the SF/DR for my upstream packets depending on where it is situated in the field has been either SF10 or SF8BW500 and plus i have ADR enabled on the mdot.

But based on your comments although the LORA input does tell me what SF/DR the upstream packet was delivered, I am guessing that can not be used reliably to determine the packet size for future transmissions or I think it would be hard. So my best bet is to set the least of the packet size of 11 bytes?

Thanks,
Ajay

[Ajay K]

Thanks Jeff for taking the time to respond and for the information provided. Especially thanks for sharing the path for the SD card as we do use the SD card and plan to use it for a custom APP.

Thanks,
Ajay

[Ajay K]

Also is there a delay between retries when Ack fails?

Thanks,
Ajay

[Ajay K]

So in my application currently I have setAck(1), so I need to change it to 8 that is after 8 retries it will switch the data rate and/or transmit power? Just curious why pick 8?

Thanks,
Ajay

[Ajay K]

Thanks Jason, But that did not happen then. Then my initial concern that it was stuck at SF8BW500 and the device did not adjust the transmit power or lower the data rate. How do we address that at this point, if the device was expected to do that with Ack’s enabled and ADR enabled?

Thanks,
Ajay.

[Ajay K]

Thanks Jason for taking the time to respond. We have acks’ enabled both on the MDot and Conduit for our transmissions.

If ACK is enabled above 2 retries on the mdot, after two missed packets the device will restore max tx power. Then after 2 more missed packets it will lower the datarate.

In the above statement, by “it” you mean the conduit right? But for the conduit to lower the rate, it needs the mdot to communicate with it right? For example for the conduit to restore it to SF10 which is the lowest data rate in the US either because of an uplink or downlink occurs. Also with a Class A, a downlink will never occur unless an uplink occurs.

I just want to be clear as to in the specific scenario I just described at the beginning of the thread if the conduit can not lower the DR or increase it to max power since there is no communication between the mdot and conduit, should the mdot reduce the lowest DR on its own say SF10 as its default, until communication is restored at which point the ADR may set it back to a lower data rate/higher data rate?

Also btw, when the custom application we built starts up in the mdot, by default it sets the DR to SF10. Its the ADR which upped the DR to SF8BW500.

Thanks,
Ajay.

[Ajay K]

Hi Heath,

You are correct it is the Standard size. Well cellular companies fortunately have a standard names for all the different types of SIM cards and the ones I listed earlier in the thread is what they use currently and the multitech conduit can fit both the standard and Micro SIM cards.

Thanks,
Ajay.

[Ajay K]

Thanks we figured this out.

[Ajay K]

Hey Mike,

I was just thinking, you must be figuring out at your end when to call the txTimeout and the receive window timeout right? Can I just not use those timeouts as to how long I need to wait before giving up in my main thread This is just to keep a fail safe in the event worst case the mac events don’t fire. However we will be doing testing at our end for various ranges and see what the timeout windows as you suggested earlier. But my guess is the mdot code base must have either a calculated timeout or a hard timeouts set? Would you be able to share that information?

Thanks,
Ajay

[Ajay K]

Thanks Mike it works now. I just had to reset my Config and called the setAdr at the right place in the code and works well right now. Thanks for breaking up the Mac Header and frame details, that helped me to validate the ADR was enabled.

Thanks,
Ajay.

[Ajay K]

Hi Mike,

Thanks of your response. I am guessing is this happening because i am using AUTO_OTA mode and whatever I had configured earlier in terms of network settings, is saved in the flash and now that my previous settings have not changed, I am probably not even calling the piece of code below.

m_dot->setAdr(true)

Thanks Mike for confirming that the ADR is not being set to begin with in the mdot. I am guessing if I use the code below all the previous session and network information will be removed from the flash?

 m_dot->resetConfig();
 m_dot->resetNetworkSession();

Thanks,
Ajay

• This reply was modified 7 years, 2 months ago by Ajay K.

[Ajay K]

Hi Mike/Leon,

I removed the antenna first on the mdot and then I removed it on the conduit as well. But no matter what, the data rate stays at dr0 (SF_10) and I have it running for about 30 minutes now and that would mean I have sent close to 30 uplink packets and the data rate remained at SF_10, which I am guessing DR0. I have captured both the node-red input nodes message object to see what the RSSI and lsnr values in the debug o/p and also the debug/trace information from the mdot.

Also Is there a minimum distance between the conduit and the mdot that would help the ADR feature to be tested better. Let me know if you would like me to provide any other data point that will help you resolve this?

debug o/p from the node-red LORA input node, just a few off them, I have captured it for almost 30 minutes.

[msg] : object
{ "chan": 0, "cls": 0, "codr": "4/5", "datr": "SF10BW125", "freq": "907.1", "lsnr": "-7.2", "mhdr": "8002000000000800", "modu": "LORA", "opts": "", "port": 1, "rfch": 0, "rssi": -116, "seqn": 8, "size": 4, "timestamp": "2017-03-01T21:30:12.083536Z", "tmst": 611201364, "payload": [ 116 ], "eui": "00-80-00-00-00-00-cf-72", "_msgid": "4887831.fb7787c" }
‎3‎/‎1‎/‎2017‎ ‎12‎:‎57‎:‎36‎ ‎PM[feb26526.71c398]

[msg] : object
{ "chan": 1, "cls": 0, "codr": "4/5", "datr": "SF10BW125", "freq": "907.3", "lsnr": "-6.2", "mhdr": "8002000000000900", "modu": "LORA", "opts": "", "port": 1, "rfch": 0, "rssi": -116, "seqn": 9, "size": 4, "timestamp": "2017-03-01T21:31:16.421838Z", "tmst": 675537036, "payload": [ 116 ], "eui": "00-80-00-00-00-00-cf-72", "_msgid": "c4c68899.3b3978" }
‎3‎/‎1‎/‎2017‎ ‎12‎:‎58‎:‎40‎ ‎PM[feb26526.71c398]

[msg] : object
{ "chan": 7, "cls": 0, "codr": "4/5", "datr": "SF10BW125", "freq": "908.5", "lsnr": "-3.8", "mhdr": "8002000000000a00", "modu": "LORA", "opts": "", "port": 1, "rfch": 1, "rssi": -117, "seqn": 10, "size": 4, "timestamp": "2017-03-01T21:32:20.762888Z", "tmst": 739872716, "payload": [ 116 ], "eui": "00-80-00-00-00-00-cf-72", "_msgid": "645fe2c4.9ba01c" }
‎3‎/‎1‎/‎2017‎ ‎12‎:‎59‎:‎45‎ ‎PM[feb26526.71c398]

[msg] : object
{ "chan": 7, "cls": 0, "codr": "4/5", "datr": "SF10BW125", "freq": "908.5", "lsnr": "-6.8", "mhdr": "8002000000000b00", "modu": "LORA", "opts": "", "port": 1, "rfch": 1, "rssi": -118, "seqn": 11, "size": 4, "timestamp": "2017-03-01T21:33:25.084493Z", "tmst": 804208364, "payload": [ 116 ], "eui": "00-80-00-00-00-00-cf-72", "_msgid": "92a3b4d4.6d5c48" }
‎3‎/‎1‎/‎2017‎ ‎1‎:‎00‎:‎49‎ ‎PM[feb26526.71c398]

Debug o/p coming from the mdot, a few of the packets.

3/1/2017 12:57:35 PM: [TRACE] Generating Heart Beat Packet....
3/1/2017 12:57:35 PM: [TRACE] Queueing Heart Beat Packet....
3/1/2017 12:57:35 PM: [TRACE] Max Packet Frame Length: 11
3/1/2017 12:57:35 PM: [DEBUG] Check if connected to the network.....
3/1/2017 12:57:35 PM: [DEBUG] Sending LORA Packets.
3/1/2017 12:57:35 PM: [DEBUG] Send with tx timeout 5000
3/1/2017 12:57:35 PM: [INFO] Preparing frame
3/1/2017 12:57:35 PM: [TRACE] NA:  00000002
3/1/2017 12:57:35 PM: [TRACE] NSK: 0cbd3d8d907fd27a9349e1522d36c53a
3/1/2017 12:57:35 PM: [TRACE] DSK: f9b7392fb4b6f2574c3d23db347a0109
3/1/2017 12:57:35 PM: [TRACE] Adding MIC to frame
3/1/2017 12:57:35 PM: [TRACE] Sending 14 bytes
3/1/2017 12:57:35 PM: [TRACE] Number of available channels: 8
3/1/2017 12:57:35 PM: [DEBUG] Using channel 24 : 907100000
3/1/2017 12:57:35 PM: [INFO] Configure radio for TX
3/1/2017 12:57:35 PM: [DEBUG] Session pwr: 20 ant: 3 max: 21
3/1/2017 12:57:35 PM: [DEBUG] Radio Power index: 20 output: 19 total: 22
3/1/2017 12:57:35 PM: [DEBUG] TX PWR: 20 DR: 0 SF: 10 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
3/1/2017 12:57:35 PM: [INFO] Configure radio for TX
3/1/2017 12:57:35 PM: [DEBUG] Session pwr: 20 ant: 3 max: 21
3/1/2017 12:57:35 PM: [DEBUG] Radio Power index: 20 output: 19 total: 22
3/1/2017 12:57:35 PM: [DEBUG] TX PWR: 20 DR: 0 SF: 10 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
3/1/2017 12:57:35 PM: [DEBUG] mDotEvent - TxDone
3/1/2017 12:57:35 PM: [TRACE] Event: OK
3/1/2017 12:57:35 PM: [TRACE] Flags Tx: 1 Rx: 0 RxData: 0 RxSlot: 0 LinkCheck: 0 JoinAccept: 0
3/1/2017 12:57:35 PM: [TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 0 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
3/1/2017 12:57:36 PM: [TRACE] RX1 on freq: 925100000
3/1/2017 12:57:36 PM: [TRACE] RX DR: 10 SF: 10 BW: 2 CR: 1 PL: 8 STO: 12 CRC: 1 IQ: 1
3/1/2017 12:57:36 PM: [TRACE] Stats: Up: 10 Down: 9 DupTx: 0 CRC Errors: 0
3/1/2017 12:57:36 PM: [INFO] Rx Window 1
3/1/2017 12:57:36 PM: [INFO] RxDone 12 bytes RSSI: -116 dB SNR: -20 cB
3/1/2017 12:57:36 PM: [TRACE] Payload: 600200000020080026de82af
3/1/2017 12:57:36 PM: [INFO] Packet for 00000002
3/1/2017 12:57:36 PM: [TRACE] Check downlink counter 00000008
3/1/2017 12:57:36 PM: [TRACE] Ack received
3/1/2017 12:57:36 PM: [TRACE] Empty payload
3/1/2017 12:57:36 PM: [INFO] Packet Received : Port: 0 FCnt: 00000008 Size: 0 ACK: 1 DUP: 0
3/1/2017 12:57:36 PM: [DEBUG] mDotEvent - PacketRx
3/1/2017 12:57:36 PM: [TRACE] Payload: 
3/1/2017 12:57:36 PM: [TRACE] Event: OK
3/1/2017 12:57:36 PM: [TRACE] Flags Tx: 0 Rx: 1 RxData: 0 RxSlot: 1 LinkCheck: 0 JoinAccept: 0
3/1/2017 12:57:36 PM: [TRACE] Info: Status: 0 ACK: 1 Retries: 0 TxDR: 0 RxPort: 0 RxSize: 0 RSSI: -116 SNR: 236 Energy: 0 Margin: 0 Gateways: 0
3/1/2017 12:57:36 PM: [DEBUG] Rx 0 bytes
3/1/2017 12:57:36 PM: [INFO] Packet RSSI: -116 dB SNR: -20 cB
3/1/2017 12:57:36 PM: [DEBUG] mDotEvent - RxDone
3/1/2017 12:57:36 PM: [TRACE] successfully sent data to gateway
3/1/2017 12:57:36 PM: [DEBUG] Uplink Transmission Complete....
3/1/2017 12:57:36 PM: [INFO] RxDone 12 bytes RSSI: -116 dB SNR: -20 cB
3/1/2017 12:57:36 PM: [TRACE] Payload: 600200000020080026de82af
3/1/2017 12:57:36 PM: [INFO] Packet for 00000002
3/1/2017 12:57:36 PM: [TRACE] Check downlink counter 00000008
3/1/2017 12:57:36 PM: [TRACE] Ack received
3/1/2017 12:57:36 PM: [TRACE] Empty payload
3/1/2017 12:57:36 PM: [INFO] Packet Received : Port: 0 FCnt: 00000008 Size: 0 ACK: 1 DUP: 0
3/1/2017 12:57:36 PM: [DEBUG] mDotEvent - PacketRx
3/1/2017 12:57:36 PM: [TRACE] Payload: 
3/1/2017 12:57:36 PM: [TRACE] Event: OK
3/1/2017 12:57:36 PM: [TRACE] Flags Tx: 0 Rx: 1 RxData: 0 RxSlot: 1 LinkCheck: 0 JoinAccept: 0
3/1/2017 12:57:36 PM: [TRACE] Info: Status: 0 ACK: 1 Retries: 0 TxDR: 0 RxPort: 0 RxSize: 0 RSSI: -116 SNR: 236 Energy: 0 Margin: 0 Gateways: 0
3/1/2017 12:57:36 PM: [DEBUG] Rx 0 bytes
3/1/2017 12:57:36 PM: [INFO] Packet RSSI: -116 dB SNR: -20 cB
3/1/2017 12:57:36 PM: [DEBUG] mDotEvent - RxDone
3/1/2017 12:57:36 PM: [TRACE] successfully sent data to gateway
3/1/2017 12:57:36 PM: [DEBUG] Uplink Transmission Complete....
3/1/2017 12:57:34 PM: [TRACE] configuring RTC Alarm A to wakeup 60 seconds from now??[DEBUG] Session restored from flash

3/1/2017 12:57:35 PM: [TRACE] Generating Heart Beat Packet....
3/1/2017 12:57:35 PM: [TRACE] Queueing Heart Beat Packet....
3/1/2017 12:57:35 PM: [TRACE] Max Packet Frame Length: 11
3/1/2017 12:57:35 PM: [DEBUG] Check if connected to the network.....
3/1/2017 12:57:35 PM: [DEBUG] Sending LORA Packets.
3/1/2017 12:57:35 PM: [DEBUG] Send with tx timeout 5000
3/1/2017 12:57:35 PM: [INFO] Preparing frame
3/1/2017 12:57:35 PM: [TRACE] NA:  00000002
3/1/2017 12:57:35 PM: [TRACE] NSK: 0cbd3d8d907fd27a9349e1522d36c53a
3/1/2017 12:57:35 PM: [TRACE] DSK: f9b7392fb4b6f2574c3d23db347a0109
3/1/2017 12:57:35 PM: [TRACE] Adding MIC to frame
3/1/2017 12:57:35 PM: [TRACE] Sending 14 bytes
3/1/2017 12:57:35 PM: [TRACE] Number of available channels: 8
3/1/2017 12:57:35 PM: [DEBUG] Using channel 24 : 907100000
3/1/2017 12:57:35 PM: [INFO] Configure radio for TX
3/1/2017 12:57:35 PM: [DEBUG] Session pwr: 20 ant: 3 max: 21
3/1/2017 12:57:35 PM: [DEBUG] Radio Power index: 20 output: 19 total: 22
3/1/2017 12:57:35 PM: [DEBUG] TX PWR: 20 DR: 0 SF: 10 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
3/1/2017 12:57:35 PM: [INFO] Configure radio for TX
3/1/2017 12:57:35 PM: [DEBUG] Session pwr: 20 ant: 3 max: 21
3/1/2017 12:57:35 PM: [DEBUG] Radio Power index: 20 output: 19 total: 22
3/1/2017 12:57:35 PM: [DEBUG] TX PWR: 20 DR: 0 SF: 10 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
3/1/2017 12:57:35 PM: [DEBUG] mDotEvent - TxDone
3/1/2017 12:57:35 PM: [TRACE] Event: OK
3/1/2017 12:57:35 PM: [TRACE] Flags Tx: 1 Rx: 0 RxData: 0 RxSlot: 0 LinkCheck: 0 JoinAccept: 0
3/1/2017 12:57:35 PM: [TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 0 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
3/1/2017 12:57:36 PM: [TRACE] RX1 on freq: 925100000
3/1/2017 12:57:36 PM: [TRACE] RX DR: 10 SF: 10 BW: 2 CR: 1 PL: 8 STO: 12 CRC: 1 IQ: 1
3/1/2017 12:57:36 PM: [TRACE] Stats: Up: 10 Down: 9 DupTx: 0 CRC Errors: 0
3/1/2017 12:57:36 PM: [INFO] Rx Window 1
3/1/2017 12:57:36 PM: [INFO] RxDone 12 bytes RSSI: -116 dB SNR: -20 cB
3/1/2017 12:57:36 PM: [TRACE] Payload: 600200000020080026de82af
3/1/2017 12:57:36 PM: [INFO] Packet for 00000002
3/1/2017 12:57:36 PM: [TRACE] Check downlink counter 00000008
3/1/2017 12:57:36 PM: [TRACE] Ack received
3/1/2017 12:57:36 PM: [TRACE] Empty payload
3/1/2017 12:57:36 PM: [INFO] Packet Received : Port: 0 FCnt: 00000008 Size: 0 ACK: 1 DUP: 0
3/1/2017 12:57:36 PM: [DEBUG] mDotEvent - PacketRx
3/1/2017 12:57:36 PM: [TRACE] Payload: 
3/1/2017 12:57:36 PM: [TRACE] Event: OK
3/1/2017 12:57:36 PM: [TRACE] Flags Tx: 0 Rx: 1 RxData: 0 RxSlot: 1 LinkCheck: 0 JoinAccept: 0
3/1/2017 12:57:36 PM: [TRACE] Info: Status: 0 ACK: 1 Retries: 0 TxDR: 0 RxPort: 0 RxSize: 0 RSSI: -116 SNR: 236 Energy: 0 Margin: 0 Gateways: 0
3/1/2017 12:57:36 PM: [DEBUG] Rx 0 bytes
3/1/2017 12:57:36 PM: [INFO] Packet RSSI: -116 dB SNR: -20 cB
3/1/2017 12:57:36 PM: [DEBUG] mDotEvent - RxDone
3/1/2017 12:57:36 PM: [TRACE] successfully sent data to gateway
3/1/2017 12:57:36 PM: [DEBUG] Uplink Transmission Complete....
3/1/2017 12:57:36 PM: [INFO] RxDone 12 bytes RSSI: -116 dB SNR: -20 cB
3/1/2017 12:57:36 PM: [TRACE] Payload: 600200000020080026de82af
3/1/2017 12:57:36 PM: [INFO] Packet for 00000002
3/1/2017 12:57:36 PM: [TRACE] Check downlink counter 00000008
3/1/2017 12:57:36 PM: [TRACE] Ack received
3/1/2017 12:57:36 PM: [TRACE] Empty payload
3/1/2017 12:57:36 PM: [INFO] Packet Received : Port: 0 FCnt: 00000008 Size: 0 ACK: 1 DUP: 0
3/1/2017 12:57:36 PM: [DEBUG] mDotEvent - PacketRx
3/1/2017 12:57:36 PM: [TRACE] Payload: 
3/1/2017 12:57:36 PM: [TRACE] Event: OK
3/1/2017 12:57:36 PM: [TRACE] Flags Tx: 0 Rx: 1 RxData: 0 RxSlot: 1 LinkCheck: 0 JoinAccept: 0
3/1/2017 12:57:36 PM: [TRACE] Info: Status: 0 ACK: 1 Retries: 0 TxDR: 0 RxPort: 0 RxSize: 0 RSSI: -116 SNR: 236 Energy: 0 Margin: 0 Gateways: 0

3/1/2017 12:57:36 PM: [DEBUG] Rx 0 bytes

3/1/2017 12:57:36 PM: [INFO] Packet RSSI: -116 dB SNR: -20 cB

3/1/2017 12:57:36 PM: [DEBUG] mDotEvent - RxDone

3/1/2017 12:57:36 PM: [TRACE] successfully sent data to gateway

3/1/2017 12:57:36 PM: [DEBUG] Uplink Transmission Complete....

3/1/2017 12:57:36 PM: |74|
3/1/2017 12:57:37 PM: [WARNING] This mDot hardware version does not support deep sleep... using sleep.

Thanks,
Ajay

[Ajay K]

Hi Leon,

Thanks for your response. I will remove the antenna’s and try testing it.
I send a heartbeat packet every minute to the conduit and so there should have been enough packets exchanged for the determination to be made. I am guessing it uses the uplink packets to determine what data rate to operate in correct? As there are very few downlink packets being transmitted.

However one of the other questions I had should be setting any default data rate at all even though the ADR is enabled on the mdot? Currently I am setting a data rate of SF_10 assuming the longest range when I initialize the LORA network settings in the mdot, is that step even necessary?

Thanks,
Ajay

[Ajay K]

Thanks Leon, that for confirming and that helps a lot. I guess we will plan on using GPIO MTAC Card to read the voltages.

Thanks,
Ajay

[Ajay K]

Thanks Leon, for taking the time to respond. We have a requirement, that when an external connected power supply be it a battery or any other source that would power the conduit, is it if it hits some critical voltage range, we send a message out so that it can be replaced or handled appropriately. So if figure a way to measure it via GPIO card interface for the conduit, than we should be able to use Node-red to read values of the voltage levels? Does the Conduit GPIO card interface support, AnalogIn kind of GPIO configuration?

Thanks,
Ajay.

[Ajay K]

Thanks Mike for your response. I guess during testing we can figure out this better as what the optimal timeout could potentially be. However we are hoping we reduce the wake time to a more considerable number, so we don’t burn thru’ the battery. I wasn’t aware we could enable ack retries.

Thanks,
Ajay.

[Ajay K]

Thanks Mike, the LORA network is being used in private mode. So worst case 5 seconds per uplink is what you think I should wait for an inbound packet and ack, before I timeout on the main thread? Obviously I am guessing the spread factor effects this timeout and we will be having ADR enabled as well, so this time may change in your opinion?

Based on your last comment, the receive windows are not opened until a transmit is complete, in my case since Ack’s are enabled, until an ack is received correct?

Just one other question, although not related to the receive timeouts, if I enable ADR, I should still be setting a default Spread factor right/data rate right? I currently set SF10 the longest range by default for the US915 frequencies.

Thanks,
Ajay.

[Ajay K]

Thanks Mike for taking the time to respond. I do derive from the mDotEvent class to handle the receive packets. However I was wondering if should set out a timeout (a finite time to wait) in my main thread to ensure that the receive window and the ack window are accommodated for and worst case an mDot Event doesn’t fire, especially when there is no downlink packet to expect or for some reason the send fails or the recv fails.

Thanks,
Ajay

[Ajay K]

Thanks Mike for getting back on this topic. I have changed all my logging to use the MDot logging API, so I can control the amount of information that will be logged during development and pre-production stages, but going into production it will be set at default of NONE, unless someone plugs a mini-usb cable.

Thanks,
Ajay

[Ajay K]

Hi Mike,

Thanks for the clarifications regarding the logging level. No this is an mDot on a custom board. My only question can I treat the USBTX and USBRX as a GPIO pins? In which case I can toggle it as serial pins when needed and digital/Analog IO to save power consumption for the scenario i mentioned earlier. I will test it anyways but I was just wondering if you think this would be an issue configuring at run time as serial pins/as a GPIO pins depending on the mini usb cable is connected to it or not?

Thanks,
Ajay

[Ajay K]

Any thoughts on this multitech team?

[Ajay K]

Hi Mike,

Thanks for your inputs. I didn’t think I could configure USBTX and USBRX pins as AnalogIn/DigitalIn. My requirement is that one of the GPIO pins is connected to an FTDI chip and when they plug in the mini USB cable the GPIO pin goes high which indicates to me that UART needs to be used for logging purposes and when the mini USB cable is unplugged, then basically disable the UART or may be as you suggest, I can convert them to Digital In, pull down or Analog with no pull as in the sleep examples.

Do you have any concerns with this approach? Also, when the log level is set to NONE in the mdot library, other than blocking all logging, does it configure the UART in any way to prevent event any printf statements from being logged?

Thanks,
Ajay

[Ajay K]

Thanks Leon for your inputs. I just used the sample code in the dot_utils.cpp to configure the few pins that were unused on power up/reset as analog no pull. Although If look at the URL PeripheralPins.c file some of the pins I wanted to configure seem to be already configured for analog no-pull.

Thanks,
Ajay

[Ajay K]

Thanks Leon, So hopefully I am understanding what you have mentioned in your last post. So when the MDot goes into a deep sleep mode, are the pins configured as analog in no-pull? when they wake up the already pre-configured pins are restored to what they were configured for and all the rest of the unused pins stay analog in, no-pull?

So in summary I wouldn’t have to do initialize any of the un-used pins in my application. I have a couple of pins that I use as AnalogIn, Digital In, Digital Out, and I do use the MDot’s I2C pins, those will remain configured as is when mdot wakes up right?

Thanks,
Ajay

[Ajay K]

Hi Leon,

Thanks for taking the time to respond to my queries. I am using a version of the development library which supports the deep sleep version you mentioned and I do use the deep sleep mode. So I am covered in the case when the application is in deep sleep mode.

However I guess my question should have been what should I do with the unused IO Pins when the application is up and running so the power consumption is at the lowest? I have seen those methods in the dot_utils.cpp, however I assumed those were applicable only under sleep mode, can I use any of the code when the application is up and running?

Any guidance in this matter is greatly appreciated.

Thanks,
Ajay

[Ajay K]

Thanks Peter for your inputs, I got this working after I provided access via the access configuration page and also setting up the inbound rules as you suggested, although for testing purposes, I have not added any restrictions based on a specific port.

I have a follow up question, since our production application will be accessible via the cellular network and is going to be a private lora network, are there any best practices documented by Multitech/wiki page on how best to configure the conduits firewall and the access configuration and any other security configurations at the conduit that can be applied?

Thanks,
Ajay

[Ajay K]

Thanks Lawrence for your inputs. I am assuming the async node.send method is more efficient than sending it via an array object like i send it right now?

Thanks,
Ajay

[Ajay K]

Thanks Mike for your response. I am using the PC_13 as an analog input and I did see the page in the data sheet you mentioned in your response. So they seem to have restrictions in o/p mode, but not in the case of input, so I don’t see a concern, unless you see this as an issue using this pin? Is the 2.0.16 a dev build or a production build?

Mike is there a reason why some of the pins are generating these errors? In the older mbed os/mdot builds prior to mbed os5 I never got these kind of errors, is there a reason for not making some of the gpio pins available to use?

Thanks,
Ajay.

[Author]

Posts