Not able to receive data using ABP

End Devices (Nodes)
1

Summary

Hello!
I’m currently to send data to a TTSS application trough ABP activation.
Currently is not possible for me to do an OTAA activation for reasons that are currently being solved, eventually, it will, but in the meantime, I really need to send basic information from 1 end-device to run some basics test.

Sadly, when I try to connect trough ABP I see the data on the gateway (on TTSS), but I don’t see nothing on the end-device tab, even if I activate the verbose stream, there’s nothing at all.

I’m sure that I’m inputting the following data correctly:

  • devaddr
  • NWKS_KEY
  • APPS_KEY

The current configurations are as follows:

General information

  • Frequency plan: Europe 863-870 MHz (SF9 for RX2 - recommended)
  • LoRaWAN version: LoRaWAN Specification 1.0.4
  • Regional Parameters version: RP002 Regional Parameters 1.0.3

Information regarding the ABP connection
image

Logs
The received packet in the gateway tab (just the information that should be relevant):

{
  "name": "gs.up.receive",
  "time": "2024-05-29T08:31:22.842547298Z",
  "identifiers": [
    {
      "gateway_ids": {
        "gateway_id": --------------,
        "eui": "7276FF002E090355"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.GatewayUplinkMessage",
    "message": {
      "raw_payload": "QEAwIBAAAgAKjTyF/KxL3ItFqVBLyRo=",
      "payload": {
        "m_hdr": {
          "m_type": "UNCONFIRMED_UP"
        },
        "mic": "UEvJGg==",
        "mac_payload": {
          "f_hdr": {
            "dev_addr": "10203040",
            "f_ctrl": {},
            "f_cnt": 2
          },
          "f_port": 10,
          "frm_payload": "jTyF/KxL3ItFqQ=="
        }
      },
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 12,
            "coding_rate": "4/5"
          }
        },
        "frequency": "866100000",
        "timestamp": 2740349556
      },
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "eui-7276ff002e090355",
            "eui": "7276FF002E090355"
          },
          "timestamp": 2740349556,
          "rssi": -117,
          "signal_rssi": -129,
          "channel_rssi": -117,
          "snr": -12,
          "frequency_offset": "417",
          "location": {
            "latitude": 45.7862056,
            "longitude": 4.87972983,
            "altitude": 20,
            "source": "SOURCE_REGISTRY"
          },
          "uplink_token": "CiIKIAoUZXVpLTcyNzZmZjAwMmUwOTAzNTUSCHJ2/wAuCQNVEPTU2ZoKGgwI2s/bsgYQk8HukAMgoKq/zODmIg==",
          "channel_index": 6,
          "received_at": "2024-05-29T08:31:22.840671379Z"
        }
      ],
      "received_at": "2024-05-29T08:31:22.840671379Z",
      "correlation_ids": [
        "gs:uplink:01HZ1QKBPTPNV7HN86R802S1A8"
      ],
      "crc_status": true
    },
    "band_id": "EU_863_870"
  },
  "correlation_ids": [
    "gs:uplink:01HZ1QKBPTPNV7HN86R802S1A8"
  ],
  "origin": "ip-10-100-6-18.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_GATEWAY_TRAFFIC_READ"
    ]
  },
  "unique_id": --------------------
}

Hardware
I’m using a LR1110 DevKit

My question
Why I don’t see any data at all in the end-device tab?
What should I do to start receiving data on the application server?

2

You have removed too much from the json to be able to provide useful feedback on what the issue might be. Post the full json message please.

3

The reason for this would be of interest, using Semtech dev board with <guess_mode> LoRaMAC-node </guess_mode>.

As you appear to have abandoned the other thread regarding LR-FHSS and now ABP is causing issue, perhaps you could rewind to the start & tell us how much LoRaWAN you’ve done previously so we can advise accordingly.

Have you read the Learn section (linked top of forum page)???

Also everything in the gateway JSON is shared with any gateway that heard your device. The mind boggles why redacting the DR was needed. The ONLY thing to keep secret is the AppKey or for v1.1, the two keys, everything else is in plain text at some point for local to your device gateways.

4

As above from Jac & Nick, but also what device which firmware stack and does it support :

(As other thread capability does not alway mean actually implemented in a given instance so how is device configured)

5

I have edited the topic, and I added more information to the Json

6

Which is not good forum ettiquite - do the rest of us go back and edit our replies so that they make sense?

7

As Nick says, however, getting somewhere wrt info now.

Where are you relative to that Kelink GW just of Boulevard Laurent Bonnevay in N.E. Lyon? Some of the area east/north of you should be giving decent coverage and so your low signal quality (and at SF12!) suggests significant distance or an antenna problem on your device…if debugging you should aim to have the RF live in the ‘goldilocks range’ say -60 → -105 RSSI but with channel and signal RSI’s down at -117/-129 with SNR at -12 you may struggle and will be batteling variable a RF environment. (Mis-matched Ant SMA types?)

Can you get closer to the GW? Do either of the GW’s SW of the Kerlink by ~600m & 1km on the other side of the National Institute of Applied Science also see your signal? (Check Metadata).

Usually when there is an ABP problem it is the keys - are they typed correctly and set in correct LSB/MSB order if applicable (detailed device/firmware info will help us assist/guide) - please double/treble check before you say yes! :wink:

8

Answering these things:

  • The LR1110 is just a modulation module, which means that the LoRaWAN protocol has to be manually programmed. There are libraries made by Semtech that implement the whole LoRaWAN protocol and other functionalities (LoRa Basic / SWL2001), but this is not suitable for our application (explained in the following point).
  • The LR-FHSS modulation hasn’t been abandoned. I haven’t done any updates on that topic because, for the time being, it might be easier to use another kind of deployment. We are currently studying more suitable options, but in the meantime, I’m preparing the most basic LoRaWAN functionalities. That’s why I’m implementing an ABP connection as a starting point. Trying to modify the LoRa Basic library is not an easy task because it was (reasonably) not designed to be used with LR-FHSS modulation.
  • Yes, of course, I have deployed LoRaWAN networks before (only class-A and with OTAA), but I have never actually implemented the whole LoRaWAN protocol from scratch. I have read the LoRaWAN specification 1.0.4 and the regional parameters RP002. Currently, in the firmware, I only have an uplink function that sends an uplink with a counter. I have checked in the gateway, and using this website, I verified that the data received by the gateway is actually the data sent, in the right bit order.
    what I’m doing exactly is sending the uplink (unconfirmed), skipping the Join-request (so an ABP activation), this means that the devaddr, NWKS KEY and the APPS KEY, are manually hard coded into the end-device (just for the record, yes, I’m aware of the security problems regarding this, is just for testing purposes and it’s not meant to be used in a final deploy or in several devices).

I was just trying to delete the data that I thought would be useless in this scenario, I can see that was a mistake, I’m sorry.

9

I’m using an LR1110 devkit. As previously stated, the LR1110 doesn’t have any native LoRaWAN capabilities, so in this case, it’s custom firmware that is being developed to support the LoRaWAN specification 1.0.4 (at least the capabilities that are relevant for us at this time).

10

A interesting perspective - the LR1110 is a LoRa radio (hardware) that needs to be driven by some software which is available as LoRaMAC-node that needs to be implemented.

Do you have any idea what you are getting in to??

It is not appropriate to use TTN, a shared community environment, to test your coding attempts.

I can’t imagine why you think of the LR1110 being deficient in not having native LoRaWAN capabilities. A microwave without any firmware is just a big radio module but we tend not to consider them as not having native cooking facilities.

There is no need to repeat the same information, we can all read the topic.

But most of all, please stop using TTN, you can’t achieve your end goal of having an LR-FHSS based device working on it, so this is radically off-topic and prone to being closed.

11

So to clarify from your recent posts if I understand TL:DR what you are attempting to do and asking for help with is to debug a custom LoRaWAN stack, of limited capability that you are currently testing against the Community deployment of TTN/TTS Sandbox?

Are you a student at the aforementioned Institute?

5 main comments - others may say different/suggest other paths

  1. If latter true we do not do Students homework for them :wink: (Ok a little nudge or advice where possible)

  2. We have no visibiity to this custom stack and cant really assist

  3. TTS expects a reasonably well behaved stack - with certain behaviours (MAC decode/response etc.)

  4. Might be more approriate to test and debug against a private instance vs the TTN deployment (remove risk of network disruption to other users)

  5. When doing device dev/debug, even when using established/existing Stacks’s vs home brew, recommendation is get you own GW for dev/test (run outside TTN if needed), and have regard to recommendation wrt RF values & seperation (Forum search is your friend!)

Edited to add - See Nick has broadly commented same, above, please follow recommendations/advice given…

12

Does that imply you are not receiving and processing MAC commands? If so, switch to a private LoRaWAN implementation please because you will be causing a DoS on TTN gateways.

Is this a valid frequency in the EU868 frequency plan? I am surprised there is a gateway that receives that transmission as it totally out of the normal frequencies used by TTN. And any packet received on a frequency TTN does not recognize will be dropped by the LNS and not forwarded to any application.

13

Sctatched my head on that one also - but then wondered if a Student and had some access to see GW data and poss mod GW config? Also if actually running on none standard adjacent freq that may explain poor signal quality as a good GW (such as the Kerlink) might detect and decode as a side-band signal - in much the same way that users getting to close and shouting RF end up with channel bleed - system expects lower level vs loud signal and so processes that vs the main shouty shouty feed! Hence question about where OP is wrt the physical GW…

Also wondered if a mis-type and should be one of the 3 mandatories - 868.1? (Think this was lost in the original metadaa/json edit so dont know what original value was?!)

14

Not sure it really matters, OP is aiming to use LR-FHSS in the medium term.

I’ve no idea why anyone would have to write a stack when you only need to change the calls to the radio.

Or indeed why you need an LR1110 when an SX1262 will do the job as well.

But mostly, using a device radio protocol that can’t be supported without re-writing the gateway code as well seems to be very bizarre.

Hopefully none of this will disrupt any viniculture based sensors - that would be bad. :wine_glass:

15

After reading all of your answer, I will be moving to a private instance, so I don’t disrupt the network (I’m sorry for the troubles)

So answering some final questions:
@Jeff-UK: No, I’m not a student, this is not a homework, but I understand where that’s coming from
@kersing: I’m confused about the frequency as well, I was checking out the LR1110 configurations and I didn’t send that frequency, maybe a calibration problem? (other reasons to move to a private deployment?), but even so, no idea why the gateway is picking up that

Thank you all for your time and patience