Deciphering Basic Station output

I am having some issues with CONFIRMED uplinks not receiving any confirmation. I am using a WLR089 dev kit as an end device with a PI based SX1302CSS915 Dev kit running Basic Station 2.0.4.

With the end device, I can join the TTN NS and send a small data packet (board temperature), however, the demo app on the WLR089 board is configured for CONFIRMED uplinks and always responds with a NO_ACK error (because the confirmation is not received).

After the uplink from the end device, I can see the NS attempting the downlinks (repeats 5 time I think). I can also see packets rx’ed/tx’ed at the gateway which I think are attempts to forward the downlink to the end device. However, the end device never seems to receive them?? I also see in the logs (attached) during the attempted downlink, I can often see there are errors messages stating that the “radio is not emitting frame” and “class A has no more alternate TX time”? :

::1 diid=8 [ant#0] - radio is not emitting frame - abandoning TX, trying alternative
2022-10-25 17:58:39.623 [HAL:XDEB] [lgw_abort_tx:1534] — IN
2022-10-25 17:58:39.623 [HAL:XDEB] [lgw_usb_rmw:302] ==> RMW register @ 0x5200, offs:0 leng:1 value:0x00
2022-10-25 17:58:39.623 [HAL:XDEB] [reg_w:1128] ==> READ MODIFY WRITE @ 0x5200 (offs:0 leng:1)
2022-10-25 17:58:39.623 [HAL:XDEB] [lgw_usb_rmw:302] ==> RMW register @ 0x5200, offs:1 leng:1 value:0x00
2022-10-25 17:58:39.624 [HAL:XDEB] [reg_w:1128] ==> READ MODIFY WRITE @ 0x5200 (offs:1 leng:1)
2022-10-25 17:58:39.624 [HAL:XDEB] [lgw_usb_rmw:302] ==> RMW register @ 0x5200, offs:2 leng:1 value:0x00
2022-10-25 17:58:39.624 [HAL:XDEB] [reg_w:1128] ==> READ MODIFY WRITE @ 0x5200 (offs:2 leng:1)
2022-10-25 17:58:39.625 [HAL:XDEB] [lgw_abort_tx:1545] — OUT
2022-10-25 17:58:39.625 [S2E:VERB] ::1 diid=8 [ant#0] - class A has no more alternate TX time
2022-10-25 17:58:39.625 [S2E:WARN] ::1 diid=8 [ant#0] - unable to place frame

When this is happening I am only connecting a single end device and sending a single short uplink packet. The only other traffic should be the attempted downlink confirmations.

Is there a document somewhere that can help someone decipher the Basic Station output a little easier to assist with debugging??

capture_1.txt (136.8 KB)

Recommend in strongest terms that if using TTN turn that off in the nodes firmware config! Be cognicent of TTN FUP - max 10 downlinks per day - and really that should be thought of as per fortnight or per month - each of your uplinks will trigger a (downlink) response from the LNS. Remember each downlink supporting any user effectively renders the gateway sending it deaf to all users - including the other nodes of the user whose node triggered it! …Problem solved at source :slight_smile:

Your node seems to have very high RSSI-values, your gateway uses a power of 26dBm for transmitting. There are some hints on this forum concerning the distance between node and gateway.

Assuming you are going to be writing your own application for the WLR, it would be a good start to turn off the confirmed uplinks as the general view on the forum is you don’t need to do that unless you are doing your own link check or there is a seriously important piece of information to move.

That and FUP for the uplink interval.

Then without the blizzard of logs info, we may all be able to spot what the issue is with the ACK, although the gateway appears to be trying to call the police to let them know about the breach of legal limits.

Understood - will do. But does that explain why it wouldn’t work at all? Even on the first attempt?


Yes understood. I have turned off the confirmed uplinks. I just reenabled it to try to understand why no confirmations (ACKs) got through at all? Even on the very first attempt.


ok thanks. Will do a search.
Currently they are sitting on a bench only 1m apart which is probably not good.

We recommend (for EU Tx pwr levels!) min 3m apart - pref 5-10m with an absorber inbetween such as thick window or a wall…look to get RSSI (both ends!) < -45 → -115 ideally < -55 → -110 for development activity so you are debugging the system not self inflicted RF problems :slight_smile: