RAK2243 Gateway errors

Trying to set up a new RAK2243 gateway, and seeing a bunch of errors, and it won’t connect to TTN.

JSON down: {“txpk”:{“imme”:false,“tmst”:2594486459,“freq”:923.3,“rfch”:0,“powe”:20,“modu”:“LORA”,“datr”:“SF12BW500”,“codr”:“4/5”,“ipol”:true,“size”:22,“ncrc”:true,“data”:“YEYvAiaKIUMDQAIAcQM1AP8B6w1XIA==”}}
src/jitqueue.c:251:jit_enqueue(): ERROR: Packet REJECTED, timestamp seems wrong, too much in advance (current=3244380216, packet=2594486459, type=0)
ERROR: Packet REJECTED (jit error=2)
INFO: [down] PULL_RESP received - token[212:60] :slight_smile:

JSON down: {“txpk”:{“imme”:false,“tmst”:2092530435,“freq”:925.7,“rfch”:0,“powe”:20,“modu”:“LORA”,“datr”:“SF7BW500”,“codr”:“4/5”,“ipol”:true,“size”:22,“ncrc”:true,“data”:“YCAvAiaqQmoDQAIAcQM6AP8BrsEcqg==”}}
src/jitqueue.c:251:jit_enqueue(): ERROR: Packet REJECTED, timestamp seems wrong, too much in advance (current=3244624583, packet=2092530435, type=0)
ERROR: Packet REJECTED (jit error=2)
WARNING: [gps] could not get a valid message from GPS (no time)
WARNING: [gps] could not get a valid message from GPS (no time)
WARNING: [gps] could not get a valid message from GPS (no time)
WARNING: [gps] could not get a valid message from GPS (no time)
WARNING: [gps] could not get a valid message from GPS (no time)
WARNING: [gps] could not get a valid message from GPS (no time)
WARNING: [gps] could not get a valid message from GPS (no time)
WARNING: [gps] could not get a valid message from GPS (no time)
WARNING: [gps] could not get a valid message from GPS (no time)
INFO: [down] PULL_RESP received - token[176:63] :slight_smile:

JSON down: {“txpk”:{“imme”:false,“tmst”:1240250619,“freq”:923.3,“rfch”:0,“powe”:20,“modu”:“LORA”,“datr”:“SF7BW500”,“codr”:“4/5”,“ipol”:true,“size”:22,“ncrc”:true,“data”:“YOYmAiaq2x8DQAIAcQM6AP8B9CQVxA==”}}
src/jitqueue.c:251:jit_enqueue(): ERROR: Packet REJECTED, timestamp seems wrong, too much in advance (current=3245068954, packet=1240250619, type=0)
ERROR: Packet REJECTED (jit error=2)
WARNING: [gps] could not get a valid message from GPS (no time)
WARNING: [gps] could not get a valid message from GPS (no time)
WARNING: [gps] could not get a valid message from GPS (no time)
WARNING: [gps] could not get a valid message from GPS (no time)
INFO: [down] PULL_RESP received - token[173:38] :slight_smile:

JSON down: {“txpk”:{“imme”:false,“tmst”:329030003,“freq”:923.3,“rfch”:0,“powe”:20,“modu”:“LORA”,“datr”:“SF7BW500”,“codr”:“4/5”,“ipol”:true,“size”:22,“ncrc”:true,“data”:“YMYsAiaqd08DQAIAcQM6AP8Bc8ovDA==”}}
src/jitqueue.c:251:jit_enqueue(): ERROR: Packet REJECTED, timestamp seems wrong, too much in advance (current=3245646565, packet=329030003, type=0)
ERROR: Packet REJECTED (jit error=2)
INFO: [down] PULL_RESP received - token[144:230] :slight_smile:

I’m getting valid data from the GPS:

cat /dev/ttyAMA0
3,00,054,7B
$GPG242,08,10,345,14,21,62,2
$GPGSV,3,3,11,2,22,27,12,288,2253,14
45
$GPGL2743,N,07846.768506.00,A,A73
�b�’�Q$GPRMC,2,A,3541.62716,N,879,W,0.746,2606E
$GPVTG,T,M,A
2E
$3541.627,W,1,04,3,M,5115,21,2490,7.651,08,01,321,10,126,13,SV,3,2,11,14,07,26,20,70,345,15
$GPGSV,3,3,11,12,288,21,32,28,L,3541.62716,N,0507.00,A,A77
�b ��$GPRMC,2,A,3541.07846.76919,A
,1.274,NGPGGA,2157,N,07846.768668,M,-34.,A,3,10,90,7.64SV,3,1,1321,10,8,12,01,00,054,1,14,07,5,32,0540,345,1509,077224,59,0912,288,2253,1742657,N,0508.00,A,A72
�b ��$GPRMC,210509.0007846.76846,W,1.9,A
73
$GPVTG55,N,3.251,K,A3.00,3541.62620,N,04,2.90,62.7,M,PGSA,A,3,10,15,27,2.90,7.6305
,01,321,10,44,3,13,00,054,7A
,07,242,07,15,325,15,21,62,209,0,11,24,59,092,23,28,253,17
47
$,N,07846.76846,W1
�b � y��10510.00,A,3541.832,W,2.130,189.
$GPVTG,189.02,44,K,A35
$GPGG.62565,N,07846.7,62.2,M,-34.3,M,10,15,21,24,6,2.89,7.63
0C
,01,321,01,126,$GPGSV,3,2,11,14,15,32,054,26,2014,21,62,209,07SV,3,3,11,24,59,7,12,288,22,32,244
$GPGLL,3541,07846.76832,W,2
�b �$GPRMC,262498,N,367,185.
$GPVTG67,N,4.384,K,A3.00,35416828,W,1-34.3,M,10,15,21,24,.620E
$GPGSV,3,10,44,314,29,1254,7A
$GPGSV,3,15,32,054,26,20,209,07
76
$GPG092,24,27,12,28843
$GPGLL,35416828,W,210511.00 n��
n,A,3541.62405,N,616,182.35,26091,182.35,T,M,2.6E

When I kill the concentrator process, I see:

 ##### 2019-09-26 21:02:55 GMT #####
 ### [UPSTREAM] ###
 # RF packets received by concentrator: 0
 # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
 # RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (114 bytes)
# PUSH_DATA acknowledged: 100.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 1 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 12 (2347 bytes)
# RF packets sent to concentrator: 0 (244 bytes)
# TX errors: 0
# TX rejected (collision packet): 0.00% (req:109, rej:0)
# TX rejected (collision beacon): 0.00% (req:109, rej:0)
# TX rejected (too late): 0.00% (req:109, rej:0)
# TX rejected (too early): 77.06% (req:109, rej:84)
# BEACON queued: 0
# BEACON sent so far: 0
# BEACON rejected: 0
### [JIT] ###
# SX1301 time (PPS): 3238002688
src/jitqueue.c:452:jit_print_queue(): INFO: [jit] queue contains 4 packets:
src/jitqueue.c:453:jit_print_queue(): INFO: [jit] queue contains 0 beacons:
src/jitqueue.c:459:jit_print_queue():  - node[0]: count_us=3622703628 - type=0
src/jitqueue.c:459:jit_print_queue():  - node[1]: count_us=3622909212 - type=0
src/jitqueue.c:459:jit_print_queue():  - node[2]: count_us=3626639652 - type=0
src/jitqueue.c:459:jit_print_queue():  - node[3]: count_us=3627350364 - type=0
### [GPS] ###
# Invalid time reference (age: 100 sec)
# no valid GPS coordinates available yet
##### END #####
INFO: End of upstream thread
WARNING: failed to close GPS successfully
INFO: concentrator stopped successfully
INFO: Exiting packet forwarder program

So what am I doing wrong??

That looks a long way from what I would expect to see as ‘valid data’

Lots of missing and corrupt characters.

In looking at it more closely, you are indeed correct. Any ideas why that would be? The GPS unit is outside …

Its not a GPS indoors\outdoors issue, there is fix data there.

It looks like a software\firmware issue, in that the reading of characters from the GPS is stopping or missing characters. Note there are no complete sentences.

Why it does that, no idea.

Ask RAK perhaps ?

So, taking your sage advice, I contacted RAK. They weren’t a whole lot of help, but in the process I pulled the gateway software from source, rebuilt, and that seems to have had a positive impact.

I restarted everything and the output to the logs is currently looking like everything is working.

Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: ##### 2019-09-27 13:30:52 GMT #####
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: ### [UPSTREAM] ###
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: # RF packets received by concentrator: 0
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: # RF packets forwarded: 0 (0 bytes)
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: # PUSH_DATA datagrams sent: 0 (0 bytes)
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: # PUSH_DATA acknowledged: 0.00%
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: ### [DOWNSTREAM] ###
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: # PULL_DATA sent: 3 (100.00% acknowledged)
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: # RF packets sent to concentrator: 0 (0 bytes)
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: # TX errors: 0
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: # BEACON queued: 0
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: # BEACON sent so far: 0
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: # BEACON rejected: 0
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: ### [JIT] ###
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: # SX1301 time (PPS): 32367228
Sep 27 14:30:52 rak-gateway ttn-gateway[5191]: src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: ### [GPS] ###
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: # Valid time reference (age: 0 sec)
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: # GPS coordinates: latitude 35.69390, longitude -78.77940, altitude 134 m
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: ##### END #####
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: JSON up: {"stat":{"time":"2019-09-27 13:30:52 GMT","lati":35.69390,"long":-78.77940,"alti":134,"rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0}}
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: INFO: [up] PUSH_ACK received in 100 ms
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: INFO: [down] PULL_ACK received in 97 ms
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: INFO: [down] PULL_ACK received in 96 ms
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: INFO: [down] PULL_ACK received in 94 ms
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: INFO: Disabling GPS mode for concentrator's counter...
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: ##### 2019-09-27 13:31:22 GMT #####
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: ### [UPSTREAM] ###
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: # RF packets received by concentrator: 1
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: # CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: # RF packets forwarded: 0 (0 bytes)
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: # PUSH_DATA datagrams sent: 1 (155 bytes)
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: # PUSH_DATA acknowledged: 100.00%
Sep 27 14:32:52 rak-gateway ttn-gateway[5191]: ### [DOWNSTREAM] ###

Never having done this before, I would think that all looks like it’s working as expected. 31%20AM
That, however, indicates otherwise. What am I missing now?

dg

Your earlier log of transmit requests without sending any packet received reports makes me think you may have somehow ended up “sharing” an EUI with some other gateway. You could then have gotten transmit requests to respond to uplinks that the other gateway (and not yours) heard, and since each gateway’s timestamp counter is unique, the timestamps in those would naturally be wrong for your gateway.

How did you set the EUI on the gateway? Is it perhaps running with a default that is not unique?

In your new case, your packet forwarder just started running but has not reported any signals heard in to TTN yet.

Well now I’m confused, because the setup instructions for the Gateway show:
registration-bridge
Which shows a field to enter the EUI, but reality is slightly different:
10%20AM

No place to enter an EUI. The EUI looks like the MAC address of the device, but I can’t tell if it’s supposed to be the MAC address of the Ethernet interface, or the Mac address of the LoRA Radio (then there’s the question of how to get the Mac address of the LoRA radio if that’s what’s required).

Each new success brings yet more confusion. I can’t tell if I’m just being incredibly daft and incompetent or if the instructions are really not that great.

Thanks!
dg

The packet forwarder on your gateway is using the traditional UDP protocol rather than one of the halfway-finished newer ones, so you have to check the legacy packet forwarder box when registering it with TTN.

It is likely your gateway itself is still using a default EUI and you are mixing traffic with a gateway belonging to someone else who also didn’t change their EUI from the default.

I’m not familiar with your particular install but you probably need to find a file called local_conf.json on the gateway (maybe in /opt/ttn_gateway/bin or in /etc or who knows where…)

1 Like

I guess you are referring to the new Semtech Basic Station protocol? Not the ttn-gateway-connector protocol which is TCP based, is fully implemented and has been running very stable for a couple of years?

Ahhh, that was it. I had the EUI correct in my local_conf.json file, but None of the instructions (either for the RAK setup or elsewhere) mentioned checking the ‘legacy packet forwarder’ box. As soon as I did that and pasted in my EUI, the connection was instantaneous!

Thanks to all who responded to get this going!

I have the same issue, but at this moment there is no ‘legacy packet forwarder’ box. How can I fix the problem?

Triple post, closing.