RAK2245 EU868 sends on 923.3MHz!?

[ClimberPS (Peter Stöcklein)]

I found on /var/log/syslog
Aug 5 16:46:23 rak-gateway ttn-gateway[1513]: JSON up: {“stat”:{“time”:“2019-08-05 14:45:53 GMT”,“lati”:49.86475,“long”:10.23891,“alti”:205,“rxnb”:1,“rxok”:1,“rxfw”:1,“ackr”:100.0,“dwnb”:1,“txnb”:0}}
Aug 5 16:46:23 rak-gateway ttn-gateway[1513]: INFO: [up] PUSH_ACK received in 35 ms
Aug 5 16:46:23 rak-gateway ttn-gateway[1513]: INFO: [down] PULL_ACK received in 33 ms
Aug 5 16:46:23 rak-gateway ttn-gateway[1513]: INFO: Received pkt from mote: 26011006 (fcnt=0)
Aug 5 16:46:23 rak-gateway ttn-gateway[1513]: JSON up: {“rxpk”:[{“tmst”:2979488828,“time”:“2019-08-05T14:45:59.136798Z”,“tmms”:1249051578136,“chan”:2,“rfch”:1,“freq”:868.500000,“stat”:1,“modu”:“LORA”,“datr”:“SF10BW125”,“codr”:“4/5”,“lsnr”:8.8,“rssi”:-64,“size”:22,“data”:“gAYQASaAAAAAdffg2sSzhQw4SrTsYA==”}]}
Aug 5 16:46:23 rak-gateway ttn-gateway[1513]: INFO: [up] PUSH_ACK received in 35 ms
Aug 5 16:46:23 rak-gateway ttn-gateway[1513]: INFO: [down] PULL_RESP received - token[220:24]
Aug 5 16:46:23 rak-gateway ttn-gateway[1513]: JSON down: {“txpk”:{“imme”:false,“tmst”:2981488828,“freq”:923.3,“rfch”:0,“powe”:20,“modu”:“LORA”,“datr”:“SF12BW500”,“codr”:“4/5”,“ipol”:true,“size”:19,“ncrc”:true,“data”:“YAYQASaloUsDVf8AAQFeJaHuVQ==”}}
Aug 5 16:46:23 rak-gateway ttn-gateway[1513]: ERROR: Packet REJECTED, unsupported frequency - 923300000 (min:863000000,max:870000000)
Aug 5 16:46:23 rak-gateway ttn-gateway[1513]: INFO: [down] PULL_ACK received in 33 ms

I see the concentrator software uses wrong frequencies for transmitting data packets.
The concentrator is the EU Version and so configured. But I see for incomming packets allways an answer with the wrong frequency of 923.3 MHz, Asia base frequency perhaps.

What went wrong? Software is 2.9R and 2.9.1

The error in update_gwid.sh is still existent. The script references only eth0 to calculate the gateway ID. This will go wrong with Pi 3 A+ or Pi Zero W without ethernet/lan!
This could also be a result of no eth0! The gateway was never seen at TTN.
With a Pi 3 B via eth0 i got a connection to the TTN server with RAK2245.

And no, I dislike the idea to plug a Pi plus RAK2245 with roof antenna in my home network.

[Fomi (Fomi Tong)]

Hi @ClimberPS,

LoRa gateway is only a packet forwarder device, so it is can receive all LoRa packets which are sent from the around LoRa nodes, not only yours. But after receiving, it will judge the packet, if it is incorrect, the packet will be discarded. As you see in the log, there is an ERROR log to show that this packet is an incorrect packet:

About EUI, yes, it can be generated based on eth0 MAC address automatically. But if you are using a Pi device which is no eth0, you can do as follow:

1. open this file: /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/local_conf.json.
2. set the gateway_id as you want, and this value will be gateway EUI.
3. Actually, in this folder, there are two other files, “set_eui.sh” and “update_gwid.sh”. Optionally, you can delete these two files or rename them to prevent generating EUI based on eth0 automatically.

[ClimberPS (Peter Stöcklein)]

Hi Fomi,
I disagree with you.
There is allways a downstream channel in gateways. And as you can see the first record is marked “rxpk”. It is a typical message from my T-Beam node with size 22. The second packet is marked “txpk”. These Tx packets follow immediately the received Rx packets. Though in my opinion these 923.3 MHz packets are downstream packets generated by the RAK2245 software! Some deeper layer reject than the transport/downstream because of the illegal frequency. So it’s Yours…
At a consequence the gateway becomes not active by TTN.

Yes, I found one quick and dirty solution on the RAK forum for the wlan0 issue. You have only to replace the two occurencies of ‘eth0’ by ‘wlan0’ in the update_gwid.sh scripts. Then it will work for wlan0 without eth0. For a more experienced shell programmer it will take not so long to code a solution for both eth0 and wlan0 in the update_gwid.sh script!
It would be better to document this failure in the RAK2245 manuals and technical description for Your customers.

Regards Peter

[ZhuQI]

If you are using the built-in loraserver, use the following command to view the loraserver configuration file.

sudo nano /etc/loraserver/loraserver.toml

Find the name line and see which band is set.

[ClimberPS (Peter Stöcklein)]

Of course I have installed the RAK2245 for EU863-870. According to this loraserver.toml has set name=“EU_863_870”. Also I have registered all motes and gateways in TTN for this frequency plan. But I’m using TheThingsNetwork server via ABP activation.
Studying https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html I found US902-928 and AU915-928 frequency plans with 923.3MHz as first entry for downlink channels!
As you can see my RAK2245 accepts uplinks from EU863-870 motes with LMIC based implementation and rejects transmitting 923.3 MHz packets.
I installed the 2.9R and 2.9.1 images fresh out of the box without further changes beyond wlan0 integration for the automated gateway ID generation.
Following this, it can be deduced that some inside parameters are not adapted for EU863-870???

My next step will be the data integration.

[ZhuQI]

Is this the problem with the ttn server?

The gateway cannot determine what its downstream frequency is. The downstream frequency is what the server tells the gateway.

Please check if the router configured by the gateway in ttn is correct.

[ClimberPS (Peter Stöcklein)]

Hi ZhuQI,
yes, it looked as showed in your listing. But I had registered all my devices, motes and gateways, with EU868MHz. I checked things again.
And in the boot sequence I found that the gateway used at first the calculated gateway ID B8…FFFE… to register and some lines later it registered with 00000000FFFE gateway ID. May this was the reason for the wrong behavior!?
Before, I had for two days the expected traffic on my registerd mote but nothing for my registered gateway. After deleting the local_conf.json file and rebooting I got the expected traffic for my gateway too. Therefore I argue that this was the reason for the strong behavior.
But the tool gateway-version delivered always the wrong ID the B8… This part of the RAK2245 software is of course a little bit clumsy.
[solved]
Regards,
Peter
PS
I prefer a graphical UI and the opportunity to install over an installed linux. There is place for some other services.