Include the possible reason for missing uplinks in the Device Troubleshooting guide

[ymgupta]

Summary

Add the possible reason for missing uplinks in device live data but reaching gateway live data.

Why do we need this?

Adding common reasons for missing uplink in device live data to the Devices troubleshooting documentation will be useful for the Users.

What is already there? What do you see now?

Troubleshooting points for missing uplinks in device live data. https://www.thethingsindustries.com/docs/devices/troubleshooting/#i-can-see-some-received-uplinks-in-gateway-live-data-events-but-i-do-not-see-them-in-device-events

What is already there? What do you see now?

Add the below troubleshooting points in the I can see some received uplinks in gateway Live data events, but I do not see them in device events. section. Insights: We have observed missing uplinks in device live data when an ABP devices transmit uplinks at a frequency that is not part of the standard frequency plan used in TTS V3 (lorawan frequency plan).

• For suppose, the ABP device is configured with an EU frequency plan. If the device transmits the uplink in the 866900000 frequency, the packet will be dropped at the gateway live data and will not be seen in the device live data in TTS Console. Here, 866900000 is not part of the standard EU frequency plan used in TTS V3.
• In this case, the user had to check at the end device level and configure it with the correct frequencies.

  How do you propose to document this?

  ...

  Can you do this yourself and submit a Pull Request?

  No.

[nejraselimovic]

Can you please elaborate on how is this different from what we already have:

Using inappropriate frequencies

This case applies only to ABP devices and EU/IN/AS frequency bands. Since the Network Server is initially accepting >uplinks from devices only in default channels, uplinks from the device that is using non-default channels are dropped. In this >case, Factory Preset Frequencies have to be set either in device’s overview in The Things Stack Console, or by setting MAC >commands using the CLI. If these settings are applied to an existing device, you might need to reset the device as well.

The example you mentioned is using a non-standard EU frequency, i.e. an inappropriate frequency. Could the issue in your case be solved by setting MAC commands or Factory Preset Frequencies instead of re-configuring the device?

[ymgupta]

@nejraselimovic, The existing scenario refers to the device using the frequencies that are part of the EU frequency plan used in TTS V3. (868100000, 868300000, 868500000, 867100000, 867300000, 867500000, 867700000, 867900000)

The current scenario refers to the device using a few frequencies (Eg: 866900000 instead of 867900000) out of 8 that are not part of the EU frequency plan used in TTS. (868100000, 868300000, 868500000, 867100000, 867300000, 867500000, 867700000, 866900000)

True, setting the MAC commands or Factory Preset Frequencies should serve the purpose here. But, we are not sure if it is a suggested practice in the current scenario or not.

@adriansmares, Let us know your thoughts.

[adriansmares]

The original issue that @ymgupta was thinking about when he wrote this issue is strongly related to migration.

When an end device is migrated from v2, we don't add any factory preset frequencies, as these were not stored in v2, since v2 did not actually check the frequency in which the end device has sent a message. The problem becomes then that these end devices, whose session we have migrated, will still use them, but the uplinks are lost in v3.

There are two solutions, depending on what the customer can do:

• If he can physically reset the device (so rejoin, or at least reset the frame counters for ABP devices), he can add the factory frequencies, as we currently mention in the documentation, and rejoin / reset the MAC state using the Console button. This forces the NS to accept the uplinks from these 'custom' frequencies at the start of the session.
• If he cannot do that, then the rejoin / reset is out of discussion. In such situations, setting the factory preset frequencies won't help, as these are taken into consideration only after a join / reset. For these rather weird moments, the closest solution that we had was to add the channels manually in both the mac_state.current.channels and mac_state.desired.channels parameters in the JSON file generated by ttn-lw-migrate. This basically tells the stack 'hey, the end device will also use these channels, allow it' - it's a workaround.

I think that the workaround should be added to the migration guide, and maybe add a small callback in the device troubleshotting guide that says 'If you migrated and have this issue, you may experience this', and link to this explanation.