AB02S not connecting after updating Duty Cycle

For the context: I use an HTCC-AB02S with the following code LoRaWan_OnBoardGPS_Air530Z .

The problem is I can’t connect to TTN unless I’m in the same room with the gateway.
If I’m outside the building the connection is lost . My concern is that the problem is caused by a hardware problem. The serial monitor looks like this:

LoRaWAN EU868 Class A start!
joining...TX on freq 868100000 Hz at DR 5
TX on freq 868100000 Hz at DR 5
Event : Tx Done
RX on freq 868100000 Hz at DR 5
Event : Rx Timeout
RX on freq 869525000 Hz at DR 0
Event : Rx Timeout
TX on freq 868300000 Hz at DR 5
TX on freq 868300000 Hz at DR 5
Event : Tx Done
RX on freq 868300000 Hz at DR 5
Event : Rx Timeout
RX on freq 869525000 Hz at DR 0
Event : Rx Timeout
TX on freq 868300000 Hz at DR 5
TX on freq 868300000 Hz at DR 5
Event : Tx Done
RX on freq 868300000 Hz at DR 5
Event : Rx Timeout
RX on freq 869525000 Hz at DR 0

Any ideas?

Format posts and check your antennas.

What are the antenna look like, gateway and node?

What do you see in the console when it connects?

The antenna is the original one that came with the board. I don’t think it’s a problem with the gateway because I have another board (HTCC-AB01) with whom I can easily connect with 2 GWs from the neighborhood (that one included).

Here is the serial monitor when it connects. The board’s display remains stuck on “JOINING”.
The OTAA keys are the same as the registered device on TTN.

Copyright @2019-2020 Heltec Automation.All rights reserved.

AT Rev 1.3

+AutoLPM=1

+LORAWAN=1

+KeepNet=0

+OTAA=1

+Class=A

+ADR=1

+IsTxConfirmed=1

+AppPort=2

+DutyCycle=120000

+ConfirmedNbTrials=4

+ChMask=0000000000000000000000FF

+DevEui=...(For OTAA Mode)

+AppEui=....(For OTAA Mode)

+AppKey=...(For OTAA Mode)

+NwkSKey=00000000000000000000000000000000(For ABP Mode)

+AppSKey=00000000000000000000000000000000(For ABP Mode)

+DevAddr=00000000(For ABP Mode)

Format logs with the </> tool please

And check the entire of a response for all the questions because you’ve missed the most important info - the serial log with all the redacted info is of little value.

TTN: in my end device section (Live data) I see nothing, no activity registered.
On Arduino IDE serial monitor I see the logs posted above. The first thing to show is authentification keys and parameters, then it remains stuck in a loop like this

TX on freq 868300000 Hz at DR 5
Event : Tx Done
RX on freq 868300000 Hz at DR 5
Event : Rx Timeout
RX on freq 869525000 Hz at DR 0
Event : Rx Timeout
TX on freq 868300000 Hz at DR 5
TX on freq 868300000 Hz at DR 5
Event : Tx Done
RX on freq 868300000 Hz at DR 5
Event : Rx Timeout

The usual issue (forum search for the win), is that the device & gateway are too close and the gateway output is overloading the devices input stage - so you need 5m & a brick wall between them.

Another simple quick check is EUI’s aren’t as expected so worth making sure they match and they are the correct way round (endian).

Ideally check in the gateway logs to see if the device is actually managing to get some RF as no point fixing credentials if the RF isn’t arriving at a gateway. And check the gateway console to see if it is getting to the servers.

What do you see in the console when it connects? The console is the bit in your application on the TTN website, where you can see the device metrics.

You have not excluded the device antenna yet. That is why what you see in the console, both gateway and application can lead to clue why it only connects when it is close to the gateway.

There is no problem with the distance between the end device and the gateway. I have tested the connection in many ways: outside the building with the gateway and in a range of 0 - 2 km. It connects to the TTN and the gateway can see the end device only if they’re both in the same room.

The DevEUI and AppKey are generated by TTN and match the ones from the end device code. The AppEUI is set to 0000000000000000 and matches as well.

I can’t see anything from my end device in the gateway logs when I am not in the same room with it. The gateway is working correctly, it received RF from my other board and others from the neighborhood too.

We are going in circles here.

Show the console log (json) when the node is connected to the gateway.

And what distance is between the gateway and node?

The device antenna is either not attached, unplugged, has a mismatch in SMA connectors - Female to RP Female for instance or is damaged.

As for all 00’s on the JoinEUI, different code bases cope with varying levels of success with this as an option, it is useful to use an EUI generator to create one rather than leave it all 00’s

Around 5m when I’m in the same room and can connect. These are the first two uplink messages when is connected to the gateway.

{
  "name": "gs.up.receive",
  "time": "2023-03-28T13:46:06.336488795Z",
  "identifiers": [
    {
      "gateway_ids": {
        "gateway_id": "ttnd35"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.GatewayUplinkMessage",
    "message": {
      "raw_payload": "AAAAAAAAAAAA3L4F0H7Vs3BQ1M195uc=",
      "payload": {
        "m_hdr": {},
        "mic": "zX3m5w==",
        "join_request_payload": {
          "join_eui": "0000000000000000",
          "dev_eui": "70B3D57ED005BEDC",
          "dev_nonce": "D450"
        }
      },
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 7,
            "coding_rate": "4/5"
          }
        },
        "frequency": "868100000",
        "timestamp": 892869875
      },
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "ttnd35"
          },
          "time": "2023-03-28T13:46:06Z",
          "timestamp": 892869875,
          "rssi": -99,
          "channel_rssi": -99,
          "snr": 9,
          "location": {
            "latitude": 44.435032291883,
            "longitude": 26.0477524995804,
            "altitude": 110,
            "source": "SOURCE_REGISTRY"
          },
          "uplink_token": "CgoKCAoGdHRuZDM1EPO54KkDGgwInt+LoQYQt8evoAEguKrEmf6WAQ==",
          "received_at": "2023-03-28T13:46:06.336323511Z"
        }
      ],
      "received_at": "2023-03-28T13:46:06.336323511Z",
      "correlation_ids": [
        "gs:conn:01GWM6DQN128ZDT878Z15A84SC",
        "gs:uplink:01GWM7G0M0F4BQ9JMJW8TY5YE3"
      ]
    },
    "band_id": "EU_863_870"
  },
  "correlation_ids": [
    "gs:conn:01GWM6DQN128ZDT878Z15A84SC",
    "gs:uplink:01GWM7G0M0F4BQ9JMJW8TY5YE3"
  ],
  "origin": "ip-10-100-6-190.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_GATEWAY_TRAFFIC_READ"
    ]
  },
  "unique_id": "01GWM7G0M0R5DC8QWHFPJ9V1NT"
}








{
  "name": "gs.up.receive",
  "time": "2023-03-28T13:48:16.976996954Z",
  "identifiers": [
    {
      "gateway_ids": {
        "gateway_id": "ttnd35"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.GatewayUplinkMessage",
    "message": {
      "raw_payload": "gHy1CyYAAAACpqiPT1+nL7OywPKtwbDTZdncN66hBBkmL850QWSt",
      "payload": {
        "m_hdr": {
          "m_type": "CONFIRMED_UP"
        },
        "mic": "dEFkrQ==",
        "mac_payload": {
          "f_hdr": {
            "dev_addr": "260BB57C",
            "f_ctrl": {}
          },
          "f_port": 2,
          "frm_payload": "pqiPT1+nL7OywPKtwbDTZdncN66hBBkmL84="
        }
      },
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 7,
            "coding_rate": "4/5"
          }
        },
        "frequency": "867700000",
        "timestamp": 1023590644
      },
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "ttnd35"
          },
          "time": "2023-03-28T13:48:17Z",
          "timestamp": 1023590644,
          "rssi": -103,
          "channel_rssi": -103,
          "snr": -3,
          "location": {
            "latitude": 44.435032291883,
            "longitude": 26.0477524995804,
            "altitude": 110,
            "source": "SOURCE_REGISTRY"
          },
          "uplink_token": "CgoKCAoGdHRuZDM1EPSBi+gDGgwIoOCLoQYQ+Ybn0QMgoPKGluWaAQ==",
          "received_at": "2023-03-28T13:48:16.976864121Z"
        }
      ],
      "received_at": "2023-03-28T13:48:16.976864121Z",
      "correlation_ids": [
        "gs:conn:01GWM6DQN128ZDT878Z15A84SC",
        "gs:uplink:01GWM7M06G7CW3HBE1JTHRAX4G"
      ]
    },
    "band_id": "EU_863_870"
  },
  "correlation_ids": [
    "gs:conn:01GWM6DQN128ZDT878Z15A84SC",
    "gs:uplink:01GWM7M06G7CW3HBE1JTHRAX4G"
  ],
  "origin": "ip-10-100-6-190.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_GATEWAY_TRAFFIC_READ"
    ]
  },
  "unique_id": "01GWM7M06GVYXG8DXVXF573HSA"
}






If in the same room per prior posts this is indicative of disconnected Antenna at one end or the other -possibly both!

1 Like

If your antennas were correct this should be -40 or so, look carefully at the antennas.

Pay attention to the connectors, they need to match male to female. The center pins can be tricky.

The antenna could also be broken inside.

Swap the antennas out if you cant see anything wrong.

I’m having the same issue with a Heltec Wireless Stick Lite V3.

It’s either the hardware or the library but there’s something really wrong. I’m pretty sure the steps for sending and confirming are not being called properly and there’s a timing issue. I’ve been at this for 2 weeks. Everything works fine on Helium Console, but once I move to an LNS, everything starts breaking again.

rxtimeout

Which one?

Note this is the Forum for the Things Network - nothing Helium here :wink:

“Sent the trap status to the Helium network”?!

Sounds like firmware still configured to H Net or at best some ba$T4rdized half way house. Suggest if trying to get running on TTN purge and start with a clean set of firmware if you need Forumites/volunterrs to help.

Depending on how comfortable you are with running a beta-stack, you could give RadioLib a try. Confirmed working well on the WSL V3 as that’s the board I used for all my work on that stack. But it’s still in development (as you can see from the PR that’s open), so can’t guarantee a bug-free experience - at least it’s a Work-in-progress opposed to the Heltec #+&(@

Yeah I’m diving into RadioLib :slight_smile: I really appreciate the help.

Seems to be a semi-duplicate post and on the wrong website to boot, despite the clear hint from Jeff above.

1 Like