[Ajay K]

Hi Peter,

I am not sure what that exactly means i.e. mosquitto-sub? Is this a tool that I need to install so I can troubleshoot issues with the mosquitto server?

Also with my custom app I could successfully connect to mqtt broker and receive packets, just FYI, if that was what you meant?

Thanks,
Ajay

[Ajay K]

Thanks Peter for responding so quickly. There are around 50 mdots communicating with the Conduit. Which are not very many, however there are some of them that are far enough from the conduit that they end up having to re-join the network every now and then and transmit packets as soon as they join the network. So I am guessing the repeated rejoins and transmits cause the traffic to be higher than normal.

Having said that I was planning on using the MQTT broker, but just wanted to ensure that if there were any advantages directly connecting to the tcp port, there by preventing any packet loss. Also I do know the LORA input node is getting disconnected from the broker as it logs it in the node-red logs, but happens very sporadically and if uplink packets arrive at this time the packets get lost. But since the lora wan server receives it first it acks the packet receipt and the packet is lost for good, since the mdot assumes the packet was received and processed successfully by the conduit/node-red.

Also I am hoping in the future design I am hoping the packets submitted to the broker, and if there are no subscribers at that point yet, the packet is retained in the broker until the packet is either received by node-red lora-in node or some custom app which can load faster than node-red.

Thanks,
Ajay

[Ajay K]

Any thoughts regarding this issue, as I am not sure how to explain the occurrence of this error when all the checks have been made?

Also does the “send” method return a specific error code for this scenario?

Thanks,
Ajay.

[Ajay K]

Hi Laurent,

I usually create the custom log files in the /var/log directory for ex: “/var/log/<app dir name>/<app name>.log” and if you would like to see what is being written to your log in your debug window, you could import the flow below it displays the last few log entries that were written to your log file.

[{"id":"cee3424f.dcdbb","type":"tail","name":"App Log","split":true,"filename":"/var/log/<app dir name>/<app name>.log","x":91,"y":72,"z":"513a453e.d720dc","wires":[["886f21d3.2faf8"]]},{"id":"886f21d3.2faf8","type":"debug","name":"","active":true,"console":"false","complete":"true","x":338,"y":72,"z":"513a453e.d720dc","wires":[]}]

Also if you would like to see your log file in its entirety, connect to the conduit via the ethernet port and I typically use the WinSCP tool to connect to the conduit and this displays a windows explorer like tree structure to view the directories/files and you should be able to browse down to your log file.

Thanks,
Ajay

[Ajay K]

Also Jason, just seeing the duty cycle requirements mentioned in your earlier response, does it apply for the US frequency bands as well as I thought most duty cycle requirements were for the European frequency bands and also does the same duty cycle requirements apply when uplinking packets using the “Send” method?

FYI we are operating in the US915 frequency bands.

Thanks,
Ajay

[Ajay K]

Thanks Jason for taking the time to explain the Join Back off interval calculations. Although the gateway wouldn’t be down that long, for two times now because of a power outage we lost power on the gateway/conduit for over 24 hrs and hence we are hitting these scenarios where the mdots are attempting to join the network several times over the 24 hrs.

Any best practices on how best to join the network when you have a conduit outage such as the one I have described above other than just adhering to the Join Back off intervals?

Thanks,
Ajay

[Ajay K]

Just another update, so we have either put the mdot to sleep for a period equal to the join back off or a larger interval as much as 5 minutes when we have over 12 contiguous join/ack failures.

Here is trace log of the mdot writing out to the debug o/p. We have been disconnected from the network for 40 minutes, we would get the getNextTxMs, either return 0 seconds, 1 second or 2 seconds, and we have ensured all the join back of times were adhered to, however all of a sudden we got a join back of time of 3276 seconds, which is massive. So I was hoping if we can get a better sense of the algorithm behind the getNextTxMs call as to how does it decide what the interval would be?

4/19/2017 1:11:50 PM: [ERROR] Failed to join network

4/19/2017 1:11:50 PM: [ERROR] failed to join network -4:Join Error, Join Attempts: 2

4/19/2017 1:11:50 PM: [DEBUG] getNextTxMs: 0

4/19/2017 1:11:51 PM: [TRACE] Initiating join...

4/19/2017 1:11:51 PM: [TRACE] Join Network - Auto OTA

4/19/2017 1:11:51 PM: [TRACE] Join attempt #96

4/19/2017 1:11:51 PM: [INFO] Send join request RxDelay: 1 Rx1Offset: 0 Rx2Freq: 923300000 Rx2Dr: 8

4/19/2017 1:11:51 PM: [TRACE] DevEUI:

4/19/2017 1:11:51 PM: [TRACE] AppEUI:

4/19/2017 1:11:51 PM: [TRACE] AppKey: 

4/19/2017 1:11:51 PM: [WARNING] Max time-on-air limit met for current join backoff period

4/19/2017 1:11:51 PM: [WARNING] JoinBackoff: 3276 seconds  Time On Air: 42368 / 36000

4/19/2017 1:11:51 PM: [TRACE] Sending 23 bytes

4/19/2017 1:11:51 PM: [TRACE] Number of available channels: 1

4/19/2017 1:11:51 PM: [DEBUG] Using channel 67 : 907800000

4/19/2017 1:11:51 PM: [INFO] Configure radio for TX

4/19/2017 1:11:51 PM: [DEBUG] Session pwr: 20 ant: 3 max: 26

4/19/2017 1:11:51 PM: [DEBUG] Radio Power index: 20 output: 19 total: 22

4/19/2017 1:11:51 PM: [DEBUG] TX PWR: 20 DR: 4 SF: 8 BW: 2 CR: 1 PL: 8 CRC: 1 IQ: 0

4/19/2017 1:11:51 PM: [INFO] Configure radio for TX

4/19/2017 1:11:51 PM: [DEBUG] Session pwr: 20 ant: 3 max: 26

4/19/2017 1:11:51 PM: [DEBUG] Radio Power index: 20 output: 19 total: 22

4/19/2017 1:11:51 PM: [DEBUG] TX PWR: 20 DR: 4 SF: 8 BW: 2 CR: 1 PL: 8 CRC: 1 IQ: 0

4/19/2017 1:11:51 PM: [DEBUG] mDotEvent - TxDone

4/19/2017 1:11:51 PM: [TRACE] Event: OK

4/19/2017 1:11:51 PM: [TRACE] Flags Tx: 1 Rx: 0 RxData: 0 RxSlot: 0 LinkCheck: 0 JoinAccept: 0

4/19/2017 1:11:51 PM: [TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0

4/19/2017 1:11:52 PM: [TRACE] RX1 on freq: 925100000

4/19/2017 1:11:52 PM: [TRACE] RX DR: 13 SF: 7 BW: 2 CR: 1 PL: 8 STO: 16 CRC: 1 IQ: 1

4/19/2017 1:11:52 PM: [TRACE] Stats: Up: 155 Down: 48 DupTx: 0 CRC Errors: 2

4/19/2017 1:11:52 PM: [INFO] Rx Window 1

4/19/2017 1:11:52 PM: [TRACE] Event: RX_TIMEOUT

4/19/2017 1:11:52 PM: [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 1 LinkCheck: 0 JoinAccept: 0

4/19/2017 1:11:52 PM: [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0

4/19/2017 1:11:53 PM: [TRACE] RX2 on freq: 925100000

4/19/2017 1:11:53 PM: [TRACE] RX DR: 8 SF: 12 BW: 2 CR: 1 PL: 8 STO: 12 CRC: 1 IQ: 1

4/19/2017 1:11:53 PM: [TRACE] Stats: Up: 155 Down: 48 DupTx: 0 CRC Errors: 2

4/19/2017 1:11:53 PM: [INFO] Rx Window 2

4/19/2017 1:11:53 PM: [TRACE] Event: RX_TIMEOUT

4/19/2017 1:11:53 PM: [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 2 LinkCheck: 0 JoinAccept: 0

4/19/2017 1:11:53 PM: [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0

4/19/2017 1:11:53 PM: [ERROR] Failed to join network

4/19/2017 1:11:54 PM: [ERROR] failed to join network -4:Join Error, Join Attempts: 3

4/19/2017 1:11:54 PM: [DEBUG] getNextTxMs: 3274000

[Ajay K]

Hi Jason,

The other thing we noticed that is the getNextTxMs returns a non-zero value right after a join fails, I thought for US915, this should always return a zero, until we encounter a join-back off? We got a 2000 ms value after the very first join failure. Is this expected?

Thanks,
Ajay.

[Ajay K]

This was in the MDot logs, how come we are getting such a big number from the getNextTxMs for the join backoff interval? The percentages called out in the Join Backoff features, is that a function of time? FYI we have not been connected to the conduit for about 14-15 hours now, also when we get into a series of join failure we get into a 5 minute sleep cycle, so technically we shouldn’t have reached such as large back off time correct?

4/18/2017 12:55:25 PM: [TRACE] Checking if connected to the LORA Network.....

4/18/2017 12:55:25 PM: [TRACE] Not connected to the network.....

4/18/2017 12:55:25 PM: [TRACE] joining network....

4/18/2017 12:55:25 PM: [TRACE] Initiating join...

4/18/2017 12:55:25 PM: [TRACE] Join Network - Auto OTA

4/18/2017 12:55:25 PM: [TRACE] Join attempt #446

4/18/2017 12:55:25 PM: [DEBUG] Join Backoff: 71122 s

4/18/2017 12:55:25 PM: [ERROR] Join backoff

4/18/2017 12:55:25 PM: [ERROR] failed to join network -4:Join Error

4/18/2017 12:55:25 PM: [DEBUG] getNextTxMs: 71122000

4/18/2017 12:56:31 PM: [TRACE] Initiating join...

4/18/2017 12:56:31 PM: [TRACE] Join Network - Auto OTA

4/18/2017 12:56:31 PM: [TRACE] Join attempt #447

4/18/2017 12:56:31 PM: [DEBUG] Join Backoff: 71057 s

4/18/2017 12:56:31 PM: [ERROR] Join backoff

4/18/2017 12:56:31 PM: [ERROR] failed to join network -4:Join Error

4/18/2017 12:56:31 PM: [DEBUG] getNextTxMs: 71057000

4/18/2017 12:57:36 PM: [TRACE] Initiating join...

4/18/2017 12:57:36 PM: [TRACE] Join Network - Auto OTA

4/18/2017 12:57:36 PM: [TRACE] Join attempt #448

4/18/2017 12:57:36 PM: [DEBUG] Join Backoff: 70991 s

4/18/2017 12:57:36 PM: [ERROR] Join backoff

Thanks,
Ajay

[Ajay K]

Thanks a lot Jason, that helps a lot.

[Ajay K]

Thanks Jason. One last question is there a way to figure out if we have hit the Join Back off error scenario. The reason I ask is that we could make potentially decisions based on that in the code. Currently when I call the joinNetwork method, we always get -4 error code and that is generic join network error I am guessing. Is there a way to retrieve the actual error in this case being the join back off error?

Thanks,
Ajay

[Ajay K]

Thanks Jason for responding back so quickly. You are right about what else can a module do, during a join back off :).

On the joins however is it possible to force it to use SF_10 spread factor always? Since we use ADR, I am guessing the conduit will eventually drive the DR to DR4 when it deems it can operate at that DR?

Thanks,
Ajay

[Ajay K]

Thanks Peter for the response. I am new to the MQTT concept. I am assuming if I subscribe to that topic, then I would receive that message in the node-red flow, but this won’t in any way effect the packet being downlinked correct? As any MQTT subscriber to this topic would receive a copy of this message?

Thanks,
Ajay

[Ajay K]

Thanks a lot Jason for pointing me to the forum article. Just a few follow up questions based on the forum article notes.

1) I am assuming all that applies to private networks?
2) In the US frequency bands will the getNextTmMs return the back off time in ms and if this is significantly greater than a minute, its better to enter a deep sleep and then trying joining again?

3) In the forum article it mentions that the join is alternated between DR0 and DR4. One of the issues we face while joining is that the MDot tries to join at DR4 for a node that is at a significant distance from the conduit and not sure why the mdot is trying this data rate. Shouldn’t it be trying DR0 first and then if it manages to successfully connect to the conduit and then up the DR based on what the conduit drives the DR needs to be.

Thanks,
Ajay

[Ajay K]

Thanks Peter. Is there a way to figure out the payload that was transmitted during the downlink, for future troubleshooting. One of the issues we discovered was that we were on an older version of the conduit firmware 1.2.2. Once we upgraded this to 1.3.3 and it is working mostly. we will wait and see if a packet loss occurs again. However your point is taken that a re-transmit may be required.

Thanks,
Ajay

[Ajay K]

This is what I got from the lorawan-servers logs and not sure how to interpret this?

Would the log below indicate that an uplink?

Apr 11 21:07:39 mtcdt user.info lora-network-server: Check response size: 0000001d sf: 7 bw: 2 dur: 17 < tm: 20 wnd: 1
Apr 11 21:07:39 mtcdt user.info lora-network-server: TransmitQueue canIncreaseDuration 22767364 20 0
Apr 11 21:07:39 mtcdt user.info lora-network-server: Transmit UDP message to Gateway 184 bytes
Apr 11 21:07:40 mtcdt user.info lora-network-server: Parsing 1 rx packets
Apr 11 21:07:40 mtcdt user.info lora-network-server: SeqNo: 000000fc PrevSeqNo: 000000fb Duplicate: no^M
Apr 11 21:07:40 mtcdt user.info lora-network-server: Addr: 00:00:00:04 MIC Check: passed
Apr 11 21:07:40 mtcdt user.info lora-network-server: Packet accepted from Node 00:00:00:04  GW 00:80:00:00:00:00:00:79  (127.0.0.1)  Seq# fc  ADR enabled SF7BW125

Would the log below indicate that an downlink of a queued packet occurred here?

Apr 11 21:07:40 mtcdt user.info lora-network-server: Schedule TX Time on air: 17 ms
Apr 11 21:07:41 mtcdt user.info lora-network-server: Frame transmitted to 00:00:00:04 via GW (00:80:00:00:00:00:00:79 Chan FC1 127.0.0.1:58905)  Seq# 149

Thanks,
Ajay

[Ajay K]

Thanks Peter for taking the time to respond and for your inputs. However
when you say

You must then manually configure a “Serial” node for the serial port.

Are you talking about doing that in node-red or is this a linux related configuration step? I am little new to the configuration requirements around Linux OS.

Thanks,
Ajay.

[Ajay K]

Thanks for the information Peter.

[Ajay K]

Thanks Jeff for the information regarding the SMS node. I am making a http rest api call using the HttpRequest node from the node-red flow and then based on the resulting json returned, i figure out if the PPP link is up or not.

Thanks,
Ajay.

[Ajay K]

Hi Peter,

For Conduits having the LORA card, can I pull the LORA statistics as well? Although the API link doesn’t have any end point related to LORA statistics, is there an end point that you can share that is not documented by the link above?

Thanks,
Ajay

[Ajay K]

Thanks Jeff, for the suggestions. Last night I did run the top command and it seems like the node-red fluctuates between 35-56% CPU and this morning too it was around the same. Also I am not using the SMS node. I am guessing that node can cause issues? We are planning to use the SMS node only in critical errors that needs someones attention to handle any issues wrt to the conduit/gateway, but so far we haven’t used it.

Also is there a better way to determine if the cellular connection is up and running, instead of using the PPP rest api? Sometimes I have noticed that the PPP api will return that the PPP link is up, but all my http calls would fail.

Thanks,
Ajay.

[Ajay K]

Hi Jeff,

Thanks for taking the time to respond. Last night around 11pm I was able to get in, until then it I was totally blocked from logging in. I was wondering would this happen, if there is a lot of data flowing because of inbound and outbound https requests via node-red? I just couldn’t either SSH into it remotely or login via the admin screen either. The reason I ask that is because the data flow slows down after 7-8pm and does that have an impact on the login?

Also I use the internal multitech rest api to query the PPP status every 10 minutes to see if the Cellular connection is up and running? Would this effect it in anyway?

Thanks,
Ajay

[Ajay K]

Just also wanted a clarification regarding this setting on the access configuration tab under administration. I have the brute force protection enabled. so based on the comments below in the help file, it says “This feature tracks login attempts at the RESTFUL API level”. What does that exactly mean? Login into the node-red or the admin screen?

Brute Force Protection:

This feature tracks login attempts at the RESTFUL API level. Its purpose is to prevent Dictionary attacks that attempt to brute force the user’s password.

Thanks,
Ajay.

[Ajay K]

Thanks Jeff for taking the time to respond. With respect to question no.3, you mentioned I could use “/etc/init.d/node-red restart”. Do I need to run it from the SSH prompt? I am a little lost when it comes to Linux based OS.

Is this something that can be made available to run from the Admin screen as a feature, to restart node-red, that way if it needs to be done remotely as well, it can be done, without SSHing into the box or the equivalent to run the script?

Thanks,
Ajay.

[Ajay K]

Any thoughts on this or if this has been addressed in the forum, can you please point me to this forum thread.

Thanks,
Ajay

[Ajay K]

Thanks Steve for taking the time to respond. I did log a ticket and we got the necessary support from your support team.

Thanks,
Yogesh

[Ajay K]

Hi Jason,

Setting the Ack retry count to 8 didn’t help either. It just keeps retrying and doesn’t seem like it is scaling it back to SF_10. I am not sure how to attach a file here, so I could share the trace o/p of the mdot?

Thanks,
Ajay

[Ajay K]

Hi Jason,

Thanks for your response. Is there a way to get a list of nodes that have joined the lora network from the node-red flow and so I can check before queuing those packets?

Thanks,
Ajay

[Ajay K]

Thanks Jason for your inputs. Will log a ticket for this issue.

Thanks,
Ajay.

[Ajay K]

Any thoughts on this Multitech team?

Thanks,
Ajay

[Author]

Posts