How to Migrate ABP Devices from V2 to V3

ceonuvathings · February 25, 2021, 10:48pm

Yes, the only alternate nowadays for IOT commercial , and countrywide it is NB-IOT/LTE-CAT-M1

cslorabox · February 25, 2021, 10:49pm

Not true; LoRaWan is only one of the ways of taking advantage of LoRa modulation; granted, it’s the only one which is on topic here.

ceonuvathings · February 25, 2021, 10:49pm

Country wide, and deep indoor?, really ?

ceonuvathings · February 25, 2021, 10:50pm

Anyway thank you for the rich discussion, i’ve learnt a lot!, have good night

pe1mew · February 26, 2021, 6:38am

@roman
Using console I have set RX1 delay to 1 because the device uses 1 second too. Because I set it 1 I expect that MAC state will not try to set the device to 1. Such behavior suggests that MAC is not “accepting the setting as a fact” but that it feels that it should force the device to 1.
The current behavior is confirmed in the name of the setting “–mac-settings.desired-rx1-delay” where “desired” is the word. I would expect set not request and though control over the mac settings.

remko@DESKTOP-RLF1S9G:~/ttn-lw-stack$ ./ttn-lw-cli device get geocaching gc-10 --mac-settings.rx1-delay --mac-settings.desired-rx1-delay
{
  "ids": {
    "device_id": "gc-10",
    "application_ids": {
      "application_id": "geocaching"
    },
    "dev_eui": "AF5EE00000009C03",
    "dev_addr": "260B204B"
  },
  "created_at": "2021-02-18T13:27:47.737Z",
  "updated_at": "2021-02-25T20:03:48.897103376Z",
  "network_server_address": "eu1.cloud.thethings.network",
  "mac_settings": {
    "rx1_delay": {
      "value": 1
    }
  }
}

roman · February 26, 2021, 9:18am

If not configured for device:

mac-settings.rx1-delay is assumed to be 1 as per the spec
mac-settings.desired-rx1-delay is assumed to be 5 on our networks

So given your device NS reads the MAC settings as:
Device is using RX delay of 1 by default, but RX delay of 5 is desired - send RxTimingSetupReq to make device use RX delay of 5.

If you want your device to use RX delay value of 1, please set mac-settings.desired-rx1-delay to 1

pe1mew · February 26, 2021, 4:00pm

@roman I followed your advice but I see always a downlink message scheduled.
Unsure what is happening and what to do to stop it.

afbeelding

Can you explain?

"data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.DownlinkMessage",
    "raw_payload": "YEsgCyaBAwAGgK5iqQ==",
    "payload": {
      "m_hdr": {
        "m_type": "UNCONFIRMED_DOWN"
      },
      "mic": "gK5iqQ==",
      "mac_payload": {
        "f_hdr": {
          "dev_addr": "260B204B",
          "f_ctrl": {
            "adr": true
          },
          "f_cnt": 3,
          "f_opts": "Bg=="
        },
        "full_f_cnt": 3
      }
    },

cslorabox · February 26, 2021, 4:16pm

Your log shows a “Device Status Request” enqueued, and if you decode the base64 f_opts that’s exactly what was sent, the singular byte 0x06. There are no ADR data rate or power adjustment commands, or RX window timing change commands in that downlink, and it seems to be have been scheduled in your desired 1-second RX1.

At present devices registered on V3 are absolutely required to understand and answer the device status request as described in the LoRaWan specification.

Devices that can’t do that must not be used on V3.

(Do also note that while it’s been explained how you can request to keep an RX1 with V3, you need to also keep in mind that the reason V3 goes to a longer downlink delay is to give more allowance for infrastructure delays both in gateway backhaul and in more complex routing between infrastructure pieces - if downlinks don’t get back to the gateway in time to be transmitted, then the 1-second setting is not going to be usable)

pe1mew · February 26, 2021, 4:58pm

Curious to see if MCCI_LoRaWAN_LMIC_library does support device status. For now, I let this rest and focus on more important topics that came with the pile of work that was introduced with the introduction of V3.

cslorabox · February 26, 2021, 5:00pm

Since they’ve expended quite a bit of effort working through LoRaWan compliance tests it should; if it doesn’t it’s well within their goals and worth raising with them - though do check for any existing issues or threads in their support before creating a new one.

Of course device status request can only work when the code is running on top of a hardware port correct enough for downlink timing to work; eg, it’s a library issue if it doesn’t work on their reference feather or Catena platform, while it’s a port issue if it merely fails on an unofficial target where downlink itself is not yet working reliably.

smbunn · May 3, 2021, 3:48am

I have searched everywhere to see how to set up for AU915 devices using ABP.
The instructions above (and on the guide) says:

The Advanced settings must be set on registration.
Changing these settings later may not work.
The Frame counter width is probably 32 bit
The RX1 Delay is 1 second
The RX1 Data Rate Offset is 0
The device probably resets frame counters
The RX2 Data Rate Index for EU868 devices coming from v2 is 3
The RX2 Frequency for EU868 devices coming from v2 is 869525000
The Factory Preset Frequencies for EU868 devices coming from v2 are:
for all devices:
868100000, 868300000, 868500000
for devices that use 8 channels
867100000, 867300000, 867500000, 867700000, 867900000
(in addition to the 3 channels above )

but I have AU915 so have no idea what to put into RX2 data rate and RX2 frequency. Would be useful to us newbies to explaln where to find these options. Is RX2 data rate the same as Spreading Factor?

bluejedi · May 3, 2021, 6:07am

The answer is already in your question. They can be found in the console when adding a new ABP device: in section Network layer expand Advanced settings to reveal the advanced settings parameters.

AndyG · May 3, 2021, 7:34am

I have 1 device that I set up on V3 using ABP on AU915 a couple of months ago to try V3 . I defined the 8 AU915 frequencies when I created the device in the V3 console and had no downlinks. Recently I’ve noticed that I’m seeing a downlink for every uplink. The V3 console expands it out to 35 “new channel request enqueued” messages for:

“frequency”: “915200000”
“channel_index”: 1, “frequency”: “915400000”
all the way up to
“channel_index”: 35, “frequency”: “922200000”

It’s one way to push everyone to OTAA. I’m not going to type in 36 frequencies in the advanced settings so that I can use ABP.

descartes · May 3, 2021, 8:19am

But if you ask nicely, a tool may come along that does that for you, or you could add a feature request to the GitHub repro …

kersing · May 3, 2021, 9:28am

Sounds like a bug/configuration issue. There are no gateways serving 36 channels so pushing all of them to a node would result in it transmitting on channels not being listened to for a fair amount of its transmissions.

@htdvisser is TTN really meant to be pushing 35 additional channels???

htdvisser · May 3, 2021, 1:32pm

No, that doesn’t sound right.

I’m not quite sure if/what advanced settings need to be set for US915/AU915 ABP devices. I actually thought that you didn’t need to set those at all, but I could be wrong.

And just for completeness, I’d like to repeat the first bullet point from the first post in this thread:

ABP is terrible; you can save yourself (and others) a lot of trouble by using OTAA.

descartes · May 3, 2021, 2:38pm

OTAA is terrible, you can save yourself a lot of trouble by using ABP when you are developing your firmware as you don’t have to reset DevNonces and wot not.

bluejedi · May 3, 2021, 8:55pm

That sounds like an opinion. ABP is part of the official LoRaWAN specifications however.
Users are much better served with an article where this is explained in detail and properly motivated.

Stating that “ABP is terrible” is not convincing and does not have any educational value because it lacks substance. Where can users find information with pros and cons about this?

You may be correct in your statement but I miss the motivation. What I can confirm though is that manually adding (‘Custom’) an ABP device in the console currently is a terrible and error prone process for the user, having to enter every single (advanced) setting manually for each and every device.

smbunn · May 3, 2021, 9:46pm

I think my post was misunderstood. I know how to get to ‘advanced settings’, my question was WHAT do I put into these settings for AU915 since the only example is for EU868.

Can I put in any value into RX2 data rate? anything at all?, Where would I find useful information on what is an appropriate value to use for AU915?

What RX2 frequencies are appropriate for AU915? There are a lot listed as transmit and receive,

AU915-928 
Uplink:

916.8 - SF7BW125 to SF12BW125
917.0 - SF7BW125 to SF12BW125
917.2 - SF7BW125 to SF12BW125
917.4 - SF7BW125 to SF12BW125
917.6 - SF7BW125 to SF12BW125
917.8 - SF7BW125 to SF12BW125
918.0 - SF7BW125 to SF12BW125
918.2 - SF7BW125 to SF12BW125
917.5 - SF8BW500
Downlink:

923.3 - SF7BW500 to SF12BW500 (RX1)
923.9 - SF7BW500 to SF12BW500 (RX1)
924.5 - SF7BW500 to SF12BW500 (RX1)
925.1 - SF7BW500 to SF12BW500 (RX1)
925.7 - SF7BW500 to SF12BW500 (RX1)
926.3 - SF7BW500 to SF12BW500 (RX1)
926.9 - SF7BW500 to SF12BW500 (RX1)
927.5 - SF7BW500 to SF12BW500 (RX1)
923.3 - SF12BW500 (RX2)

so do I put them all in?

Do I just put in 923300000 for RX2?

thanks

kersing · May 3, 2021, 10:45pm

Have you considered taking a look at the regional parameters?

From LoRaWAN regional parameters, chapter 2.5.7 AU915-928 Receive windows:

The RX2 (second receive window) settings uses a fixed data rate and frequency. Default parameters are 923.3Mhz / DR8