Why is my ABP device not seen in V3?

End Devices (Nodes) LMIC
1

Hello,

Since Imigrated to V3, I registed my devise with OTAA. But one of my devise give me some trouble, and I already experience that with V2.

As it is not an important devise, I registed it with ABP. I am a bit suprise because wen I switch it on, devise devise run well and my console printed that the data has been sent.

633067: EV_TXCOMPLETE (includes waiting for RX windows)
COMPLETED in 2123ms

I have two Gateway close to my devise and both work well, and seen in V3 console

But now when I go to TTN V3 console, the devise is not seen.

I wonder, if I regised well my devise in my TTN

apb1
apb11276×1292 60.5 KB

In the following window

  1. I kept empty the devEUI field
  2. for Devise Address, AppSKey and NwkSKey, I cliked in Generate buton.
  3. I gave an id to my devise as st-20

abp2
abp21302×1376 61.5 KB

When done, I went to my V3 console, and I selected my new devise. From the overview tab

abp3
abp31160×834 25.1 KB

  1. copied the DevAddress
  2. On NwkSKey, I clicked on the eye, then the the two arrow, and I copied the msb number

abp4
abp41139×95 7.14 KB

  1. I did the same for the AppSKey

Then I pasted in my ino file. as the following (I changed my keys with some 00 to keep it secret :slight_smile: )

//ST-20
  static const u4_t DEVADDR = 0x26000000; // <-- Change this address for every node!  
  static const PROGMEM u1_t NWKSKEY[16] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x74, 0x02, 0x44, 0x0F, 0xA2, 0xBF, 0xBE, 0x87, 0x00, 0x00 };
  static const u1_t PROGMEM APPSKEY[16] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xAD, 0x34, 0x2D, 0x95, 0x59, 0x1B, 0x77, 0xB5, 0x00, 0x00 };

I ma used to do that, then I wonder why my devise is not seen at V3 console. As it the first time I registed a devise in the V3 console, I wonder if I make some thing wrong, following the picture I attached.

I am annoyed, I have to move the devise into the field today… :frowning:

Many thanks for your clarification
Cheers

2

Have you looked at the Frame Counters - every time you power cycle the device it will need to reach the previous number of uplinks before they will be valid for the Network Server.

Or use OTAA which does this automatically.

Forum search for ABP frame counters will yield many discussions on this for v3 which, to be honest, is harder than it should be. Mostly I use the CLI to reset the very few ABP devices I have around.

3

descartes suggestion with the Frame Counters worked for me when I migrated

4

Thanks descartes, I will look around this. Could you tell me what is a CLI?

5

If I well unerstand, I have to check this option, that’s right?

abp6

In that way, I can start and restart my devise?

6

Unfortunately setting frame counter reset will not always solve the issue. As well @lex_ph2lb as I have ABP devices that will not start receiving messages. I discussed this in person with @johan. he suggested that this might be caused by the wrong setup of frequencies for the device. bt @lex_ph2lb and I have confirmed that this was not the solution.

7

Have you tried it? What happened when you did?

As @pe1mew says, this is not always the solution although I’m not convinced it’s frequency related, or at the least, the database design should be predicated on the frequencies & the frame counter interacting but in the absence of any design docs for the stack, it’s hard to say so we have to rely on the oracle. It’s definitely comes under the heading of needing more scientific review as I’ve totally lost track of what does & doesn’t work in the setup of a non-Frame-Counter ABP.

The last time I needed such an ABP device, which I normally use for ease of development so I’m not waiting on a join, I used the CLI to create it.

Curious minds would wonder what’s wrong with OTAA, that would have got you going within minutes of you finding a problem with ABP.

8

Just for information purposes, because some applications benefit from ABP: In my case, the reason for using ABP is that I have a number of devices for drive testing purposes that start working when no coverage is available and OTAA will fail. Using ABP will allow me to start measuring immediately when starting the node.

9

I was referring to @pierrot10 who urgently needs to deploy his device, wondering why he couldn’t switch to OTAA but he’s talked himself through getting that setup on another thread now.

I’m not in to mapping as much as I should be, but yes, that’s definitely a time ABP is used for me - along with some blind ADR.

10

I suspect the following; the end device does not have factory preset frequencies configured in The Things Stack while it boots with The Things Network’s frequency plan and/or “resets frame counter” is off. These are independent issues leading to the same behavior, namely that frames are dropped:

When the end device transmits on a frequency that the Network Server did not expect, the frame is discarded. This is per LoRaWAN spec. So when the end device resets, and transmits on 867.7 MHz for instance, and you did not configure factory preset frequencies, the frame is dropped. As soon as the end device uses one of the mandatory channels (868.1, .3 and .5), the Network Server will process the message and will start scheduling MAC commands to configure the other 5 channels. Therefore, ABP devices that are personalized with a channel plan must have factory preset frequencies set.

When the ABP device resets its frame counters (which is not LoRaWAN compliant since 1.0.3) and the Network Server does not know that, it will only process frames with a frame counter higher than the previous.

Misconfiguration of both settings lead to similar issues. Not enabling frame counter resets leads to waiting for the end device to reach the previous FCnt. However, the session is not reset in the NS, meaning that the end device’s session and the NS session is out of sync. Not having factory preset frequencies configured lead to the NS rejecting frames.

BTW, only if frame counter resets are enabled, the factory preset frequencies are applied to the reset session (or when the device is first seen).

Note that ABP devices from LoRaWAN 1.0.3 are required to have persistent state. They must store not only frame counters but the entire MAC state. This whole “resets frame counter” feature is not LoRaWAN compliant since 1.0.3 and strongly discouraged since the first LoRaWAN versions. If a session reset is necessary, NS needs to know exactly what the end device knows, including but not limited to frequencies.

So if you want a device to just start sending data, you can also use OTAA because you need persistent memory anyway. Just activate the device when you have coverage and every time, save the state to persistent memory.

4 Likes
11

Thanks, @johan. I pinged @lex_ph2lb about this post and we continue to look into this.
Prior to further results my first responses.

Happy to know that I use 1.0.2 :wink:

Good suggestion. However how can this be implemented using an RN2483?

1 Like
12

Thanks @johan for that clarification.
I could put devise in the field and it work fine with OTAA: But I still have one ABP but I can not work on it right now, because it is in the field as well. I will check later

1 Like
13

See arduino-device-lib/src/TheThingsNetwork.h at master · TheThingsNetwork/arduino-device-lib · GitHub

The raw command is mac save iirc.

2 Likes
14

Hope to have some hobby time this week to take a look at it. Thanks for the ping and will keep you posted.

15

OMG, so much forum debugging all suddenly makes sense. Also explains why my CLI command that setups up all the frequencies works - but trying to retrieve someone’s setup either on the console or via the CLI was going round in circles.

@benolayinka, not sure how or where this would fit in to the docs, but it’s certainly the sort of info that help people step away from hacking away at the settings & either do ABP properly or not at all.

3 Likes
16

On it!

1 Like
17

Hello Pierrot,
is your ABP related problem solved now ?
I had some problems with my devices (ABP) . It has been solved in reseting Frame counters and in setting them in 32 bit size. Since no more problem.
Good luck otherwise.