What's the logic with NbTrans downlink?

ChirpStack (v4)
1

Hello there.

I have a prototype GPS tracker enabled by accelerometer . The device is parked so every one / two days I hit the tracker to make sure it’s alive and I don’t have bugs in my code :stuck_out_tongue:

This is the story of the device. Received uplinks. The time between fist and last uplink is 2 weeks.

(fcnt=1)
Jump because of restart of device. To protect EEPROM I write fcnt every 200 uplinks. So in restart I have to jump 200 uplinks.
(fcnt=201)
(fcnt=202)
(fcnt=203)
(fcnt=204)
(fcnt=205)
(fcnt=206)
(fcnt=207)
(fcnt=208)
(fcnt=209)
(fcnt=210)
(fcnt=211)
(fcnt=212)
(fcnt=213)
(fcnt=214)
(fcnt=215)
(fcnt=216)
(fcnt=217)
(fcnt=218)
(fcnt=219)
(fcnt=220)
(fcnt=221)
(fcnt=222)
(fcnt=223)
(fcnt=224)
(fcnt=225)
(fcnt=226)
(fcnt=227)
(fcnt=228)
(fcnt=229)
Network missed three uplinks. I don't remember the reason.'
(fcnt=232)
(fcnt=233)
(fcnt=234)
(fcnt=235)
(fcnt=239)
(fcnt=240)
missed one
(fcnt=242)
(fcnt=243)
(fcnt=244)
(fcnt=245)
(fcnt=246)
(fcnt=247)
Several missed. I think I forgot my GW closed.
(fcnt=253)
(fcnt=254)
(fcnt=255)
(fcnt=256)
(fcnt=257)
(fcnt=258)
(fcnt=259)
Downlink from Chripstack with nb_rep:3. Device conforms.
(fcnt=260)
Downlink from Chripstack with nb_rep:2 - probably not received.
(fcnt=260)
(fcnt=260)
(fcnt=261)
(fcnt=261)
(fcnt=261)

Funny think is now chripstack throws a warning about re-transmission. I disabled temporary frame counter validation.

I can program my device to ignore NbTrans but I fear that chirpstack will continue to try to send NbTrans > 1. So it will create noise on the band for no reason.

My questions.

  1. Can I control NbTrans? ex. disabled it.
  2. Why Chirpstack 4.7.0 sends NbTrans > 1? Maybe because of the initial jump?
    2b. Is there hope that will be reset to 1?
2

Multiple points need attention here:

  1. What device do you use, what LoRaWAN stack do you use? Your EEPROM solution sounds like a disaster waiting to happen (or already happening).
  2. Chirpstack throws warnings about duplicated frames, not errors: you can just ignore these. The frame is indeed duplicated because of NbTrans, but no reason to care about it.
  3. You can read up on the use of NbTrans: usually it is applied when the last few uplinks that were received had a good RSSI but bad SNR. In that case it would make no sense increasing SF / Tx power, but it does make sense transmitting the frame a few more times hoping that it can pierce through the high noise.
  4. In the same way, when the environment is better, the LNS will move the device back to NbTrans.

This is all part of the spec, so please do not mess with it. Therefore please expand on the first question.

3

@bns Thank you for the effort to help.

  1. My own library. SlimLoRa. As stated: it conforms. EEPROM has nothing to do with that. What disaster do you see?
  2. Of course I ignore them. It’s just funny that chirpstack wanted NbTrans > 1 and now it throws a warning.
  3. All with SF7, * rssi:-97 / snr:9.5, rssi:-103 / snr:7 e.t.c. Device is outside my GW indoors.
  4. see 3. Kind of difficult to find better environment. This is the ideal environment.
4

After fcnt 263 chirpstack-4.7.0 ordered NbTrans 1 so we are back on track. Still wondering the mechanism that triggered NbTrans > 1.

I test downlinks with another device already at 4000 fcnt tx with jumps because of restarts / testing. chripstack never sends NbTrans command or ADR as expected. Only bad thing that never orders SF7 downlink, only SF12 with MAX power.

5

It’s Adaptive Data Rate. As mentioned before, it’s part of the strategy to compensate for message losses. It aims to attain a packet reception rate of >95%. Gaps in FCntUp will be counted towards packet loss.

The SNR & RSSI alone, don’t indicate whether you will surely get all frames.

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.