RAK4270 AT Command at+abp_inf

Is the AT Command supported on the RAK4270 - at+abp_inf ?

I cannot find it in the AT Command Manual




Welcome to RAK forum @dingoxx :slight_smile:

This is the AT Command manual of RAK4270 - RAK4270 Module AT Command Manual | RAKwireless Documentation Center

What are you trying to achieve with the at+abp_inf command? That is not part of the standard RAK4270 AT command set.


I saw the at+abp_inf command was included in the RAK811 for getting the join data after a successful OTAA join - see link above

I wished to retrieve the keys in the same manner on the RAK4270

Thank You

Kind Regards

It would be useful to know the why to this - there is a limited amount you can do with the information - perhaps there is a solution to the unknown problem you are trying to solve?

Hi Nick
Good Question

  1. Mostly for debug - so we can record / store the join data after a successful OTAA join
  2. And I would not have asked but I spotted the RAK811 had this command

One big disappointment is that the AT Commands for the RAK811 are not all supported on the RAK4270 (at least comparing the AT Command Documentation).

We moved away from the RAK811 to the RAK4270 for better batter life (without checking that the AT Commands are compatible)

Do you know if there is a reason for this ?

Thank You

Nope, I’m not staff.

Whilst I can think of some circumstances where I may want to turn off the radio module to save power, it would be at the extremes where I’d default to ABP by preference. Given the module sips 2uA in sleep mode, you are looking at battery life in years so turning the radio off isn’t worth it.

What would you do with this information to debug with?

Hi Paul,

This is the right AT Command for both RAK811 and RAK4270 to get the parameters you need even before or after a successful or even a failed join at+get_config=lora:status

May I know the AT Command that you are saying that RAK4270 doesn’t support on the RAK811?

Hi Carl

The RAK811 has the at+abp_inf command and the RAK4270 does not.

The problem with the at+get_config=lora:status command that in an embedded solution the reply has to be parsed to find what you are looking for - There are 25 lines of data in the reply !

Our biggest misunderstanding is : How does our embedded uP via AT Commands know that the RAKXXX is connected to a Lora Server and that it does not have to rejoin again

Thank you all for your assistance

Devices aren’t connected to the server - they broadcast blind in the hope that a gateway picks up the message.

Once they have joined the network they will continue to broadcast blind. It may take a few goes to join for a variety of reasons, but a year later it should still be trucking on using the same join keys. And two years later. And three, etc etc. The presence of the join keys does not mean that uplinks are successfully arriving - particularly given the number of other moving parts before it gets to your server(s).

If you have an absolute need for all uplinks to arrive, LoRaWAN is not best suited for that.

If you want a reasonably degree of certitude, then this is the scheme I employ:

  • Confirmed uplink set on a schedule (see below)
  • Expectation of the device that it will get a downlink (see below)
  • A response to the downlink to report the RSSI & SNR of the gateway plus reconfirmation of other housekeeping information
  • A pile of meta data processing software that looks at uplink signal info & number of gateways hearing a device which results in a certainty value which then informs a schedule for the device to:
    ** send a single confirmed uplink - say once a week for a device in a good area
    ** expect a housekeeping downlink - perhaps once a fortnight in place of the single confirmed uplink

With some appropriate retry, blind ADR** and back-off code, after a while a device will come to the assumption that it is off the network and perform a re-join.

And in all of this, on the server side is code that looks for devices that haven’t uplinked as expected and actions some alert & perhaps a downlink to provoke a response. As well as identifying at-risk devices - those that are only heard by a single gateway with a weak signal.

** Blind ADR would be the device progressively decreasing its DR on a confirmed uplink to see if it gets through.

I also keep readings on the device - summarised, a rolling window or everything (as memory allows) until the next housekeeping downlink comes in that can confirm status. In exceptional circumstances, usually when there are too many gaps in the data, I may request some data to be resent.

1 Like


Good discussion and reply and being a newbie I think I am getting there

Two Points:

  1. Our Sensor will be connected to a server in OTAA mode because it sends the join request and this is acknowledged by the server (with what ever response)
  2. In your reply you mentioned the word “confirm” with “upload”. So I can send an uplink from my sensor which the server will acknowledge. Do you send it only once a week to save battery life and traffic ?

What’s your professional interest in Lora ?
Am I allowed to contact you directly ?

Kind Regards

1 Like

Hi Paul,

What FW version is running in your RAK811?

It is not supported on latest FW V3.0.0.14. And probably won’t be supported by RAK4270. Based on your explanation, your main concern is to ensure that your device (RAK811 or RAK4270) is within a LoRaWAN gateway and can successfully send packets. I don’t think at+abp_inf is the best way to ensure that.

@nmcc shared ways how to do it. I strongly suggest you consider those.

Btw, there is no single correct way or approach to do it. It really still depends on your use case :slight_smile:

I know it may appear nit-picking, but LoRaWAN is connection-less. The device radio broadcasts in to the ether, mostly it will be heard but there is still some processing to ensure the data gets to your application. Having this in your mind will help you with debugging. TTN consider 10% packet loss a norm - interference, gateway downlinking at time of the uplink, truck parked next to antenna (either end) etc.

You can ask an uplink to be confirmed the network server will direct the most appropriate gateway to send back a short acknowledgement, usually in the Rx1 or Rx2 window following the uplink.

I only send once a week for devices I need some degree of certitude as it both saves battery but also keeps gateway Tx time down - gateways can not hear ANY uplinks from ANYTHING whilst transmitting. For emphasis, I don’t deploy a scheme like this unless it’s an appropriate balance between being sure about getting data &/or changing device settings and the extra workload for the whole system & environment. Some devices are in areas where it might be fortnightly and some may have the check-in frequency remotely increased to every other day. Depends on situation, the back end application can usually build a profile and alter device settings dynamically. The situation that arises mostly is the loss of a gateway, the back end can identify that no packets are being heard by a gateway which could have an impact of coverage at a site and alert the system admin.

Most of the devices I deploy don’t do any of this extra processing - either because they are not system critical, have overlapping sensor coverage in the area or easy to get to if they go on the fritz. That’s not to say clients don’t get alerts if something fails to phone home after an appropriate period of time. But there’s not lots of two way interaction.

As @carlrowan says, you need to look at what you want to do with the technology and figure out the pros & cons of different levels of management.

My professional interest is solving problems where IoT is a solution as a boutique service. So proof-of-concept & initial deployment, device design, back end, dashboards etc. Not roll out of 1,000’s of devices for some corporate conglomerate, I’d train them on how to DIY and leave the management to someone less geeky.

If your query is commercial then message me. If it’s discussing generalities, then keep it in public so the information helps others. I’m also on the TTN forum for LoRaWAN type discussions.

Thank you Carl & Nick