Gateway receiving in wrong Frequency band?

arjanvanb · August 18, 2018, 7:26pm

Also, people have seen multiple receptions for a single signal:

Due to bad soldering on a printed circuit board.
Due to cross-talk when the node and gateway are not at least a few meters apart:

OTAA slow join problem on TTN network

The problem with using nodes too close to a gateway is that the gateway receives the same packet on multiple frequencies (cross-talk).

I guess the 2nd bullet might apply, along with erroneously configuring the gateway to use EU868?

Though that would not explain:

So indeed, changing the DevAddr in your own node is a very good start.

iob · August 18, 2018, 9:51pm

Did a search “find global_conf.json” but that did not find anything. If I just use “find” then I get a file structure, so I will go through some of the directories manually today and see if I can find it.

iob · August 18, 2018, 9:52pm

Thanks Arjan, will play around with that more today and report back.

iob · August 18, 2018, 9:54pm

Hi Hobo,
Here is the document I used as a guide: RAK831-Raspberry-Pi3-Gateway-&-RAK811-LoRaNode-User-Manual

hobo · August 18, 2018, 10:02pm

find / -name global_conf.json -print

and also

find / -name local_conf.json -print

LoRaTracker · August 18, 2018, 10:52pm

I would expect that the filters on the RF input side would not be so sharp that a 915Mhz module would completly exclude all 868Mhz signals.

arjanvanb · August 19, 2018, 6:59am

…which tells you to:

$ git clone -b spi https://github.com/ttn-zh/ic880a-gateway.git
$ cd ic880a-gateway/
...
$ sudo ./install.sh
…

The installation step will ask you if you want to enable remote configuration. Type ‘y’ or ‘n’ and continue with the installation. […]

Here we type ‘n’ for local configuration. If you want to use the remote configuration option, please make sure you have created a JSON file named as your gateway EUI (e.g. B827EBFFFE7B80CD.json) in the Gateway Remote Config repository here: GitHub - ttn-zh/gateway-remote-config: Provides settings for TTN gateways that receive their settings automatically on start.

Assuming you selected “n”, then without the .git suffix, GitHub - ttn-zh/ic880a-gateway: Reference setup for iC880a gateways running The Things Network shows that install.sh executes, among many other things:

INSTALL_DIR="/opt/ttn-gateway"
...
pushd $INSTALL_DIR
...
git clone -b legacy https://github.com/TheThingsNetwork/packet_forwarder.git
...
ln -s $INSTALL_DIR/packet_forwarder/poly_pkt_fwd/poly_pkt_fwd ./bin/poly_pkt_fwd
cp -f ./packet_forwarder/poly_pkt_fwd/global_conf.json ./bin/global_conf.json

So, your global_conf.json should be in /opt/ttn-gateway/bin/global_conf.json. I guess its file permissions are such that you needed sudo find to locate it. Also, the above shows it’s taken verbatim from packet_forwarder/poly_pkt_fwd/global_conf.json at legacy · TheThingsArchive/packet_forwarder · GitHub so I’m quite sure it’s using EU868.

Still curious if you’re seeing uplinks from another EU 868 node, or that your own AUS/NZ 915 node is too close to the gateway.

iob · August 19, 2018, 9:16am

I have actually selected “y”, and created the following remote config:

github.com

ttn-zh/gateway-remote-config/blob/master/B827EBFFFEA4CDF9.json

{
  "gateway_conf": {
    "gateway_ID": "B827EBFFFEA4CDF9",
    "servers": [
      {
        "server_address": "thethings.meshed.com.au",
        "serv_port_up": 1700,
        "serv_port_down": 1700,
        "serv_enabled": true
      }
    ],
    "ref_latitude": -41.22723286,
    "ref_longitude": 174.83515247,
    "ref_altitude": 195,
    "contact_email": "jan@ttn.nz",
    "description": "Newlands-01, Wellington"
  }
}

I have tried to test again today with the same test node, but today I could not get any packets coming in on the new full channel gateway - only on the single channel gateway.

I also searched for the “global_conf.json” using the command @hobo supplied and found the following instances:
/opt/ttn-gateway/lora_gateway/util_pkt_logger/global_conf.json
/opt/ttn-gateway/packet_forwarder/poly_pkt_fwd/global_conf.json
/opt/ttn-gateway/packet_forwarder/basic_pkt_fwd/global_conf.json
/opt/ttn-gateway/packet_forwarder/gps_pkt_fwd/global_conf.json
/opt/ttn-gateway/packet_forwarder/beacon_pkt_fwd/global_conf.json

The only file I could access was this one:
/opt/ttn-gateway/lora_gateway/util_pkt_logger/global_conf.json

And yes, it had no 916 frequencies included in it. I updated the file to match this one:

github.com

TheThingsNetwork/gateway-conf/blob/master/AU-global_conf.json

{
	"SX1301_conf": {
		"lorawan_public": true,
		"clksrc": 1,
		"clksrc_desc": "radio_1 provides clock to concentrator for most devices except MultiTech. For MultiTech set to 0.",
		"antenna_gain": 0,
		"antenna_gain_desc": "antenna gain, in dBi",
		"radio_0": {
			"enable": true,
			"type": "SX1257",
			"freq": 917200000,
			"rssi_offset": -166.0,
			"tx_enable": true,
			"tx_freq_min": 915000000,
			"tx_freq_max": 928000000
		},
		"radio_1": {
			"enable": true,
			"type": "SX1257",
			"freq": 917900000,

This file has been truncated. show original

But unfortunately it did not change anything.

So, now I have decided to redo the whole config. Busy with a new 16 GB SD card, formatted it and I am currently busy doing it all over again - but with one change, this time I will answer “no” when the question comes about the Remote Config because I could not remember specifying the AUS band at any point in time when I did it the first time around. I am not sure where that question should have come up?

Will update once I have new information.

Thanks for all the ideas and support - much appreciated!

hobo · August 19, 2018, 11:41am

As @arjanvanb already said, this one should be that what you need. Gues you have to start your editor with sudo command to be able to edit it.

From their docs it seems that this question will not be asked and you have to edit config manually.

iob · August 20, 2018, 1:20am

@hobo, @arjanvanb,

Many thanks for your ideas and support!

I did the whole config over, but without the remote config (although that was not the problem).
After the install, I updated the /opt/ttn-gateway/bin/global_conf.json with the information found here https://github.com/TheThingsNetwork/gateway-conf/blob/master/AU-global_conf.json as it was still on 868 frequencies. And now I am happy to report that after the changes, the Gateway is working on the correct AUS/NZ frequencies. I will go back to my remote configuration as well and update it all in a similar fashion to make sure it all works that way as well.

As for my test node - need to look into it a bit more because there are definitely some dodgy activity as it is not just transmitting on the single frequency I thought I locked it on.

k5at · September 20, 2018, 2:31pm

I have the same issue as above, I try changing to the 915 band in the gobal_conf.json file, but I am unable to save my changes as the file is locked. I’ve tried chmod 777 global_conf.json, but that doesn’t work either.
any ideas?

arjanvanb · September 22, 2018, 8:15am

That’s too vague. Why are you executing the command you quoted? (Or: what command are you really running?) What’s the exact error? Did the chmod 777 itself fail or succeed?

If access is denied, then you might need to prefix the command with sudo, to execute it as root.

(As an aside: don’t use chmod 777; it’s making the file executable by everyone. Bad habit, even more so for a file that is meant as a configuration file, not an executable file, so would need 666 at worst.)

cherechi · July 25, 2019, 11:46am

Hello,
please i am currently trying to build and 8 channel gateway with RAK 831 and raspberry pi3. I have setup the gateway and done the necessary steps as i observed above for 915MHz because in am in Canada. First the gateway came up and presume worked fine but i did not receive data from my nodes although it showed connected on the things network. after a while, the gateway was no longer seen as connected on the things network and i do not see any data coming in on the Log. what do i do from here.
Note: i am in Canada and am using the 915Mhz.
I am currently working on a paper where i need to apply this. your help will be sincerely appreciated

cherechi · July 25, 2019, 11:53am

please these are my screen shots rasp%20screenshot rasp%202

cherechi · July 25, 2019, 11:53am

please i am in a fix

UdLoRa · July 25, 2019, 1:32pm

I see one CRC_FAIL 100% message in your output. If the node is too close to the gateway (<3 meters), communication can be difficult.
Regarding the gateway no more online, is very difficult to tell something with no information. Is it on, is it connected to the Internet, etc. Try to restart it also.

cherechi · August 4, 2019, 2:38pm

so sorry boss for the late reply, i will try to move the node away from the gateway. and see if i can log on the pi screen. but how can i make the node frequencies to match those of my gateway?. because am building a voltage sensor and i want each sensor to work on a fixed frequency that corresponds to the various channels of the gateway.

BoRRoZ · August 4, 2019, 3:13pm

that’s not the way to address your fellow TTN users imho

anyway… please start with the LoRaWAN basics

cherechi · August 4, 2019, 3:15pm

please sir explain more. i have been on this now, my latest discovery is that my gateway recieves pakects on 867.7. while it has a paste that its a 915MHz. what do i do in this case

cslorabox · August 4, 2019, 5:03pm

That’s not how LoRaWan works. Channels are dynamically and randomly chosen. End devices are distinguished by packet header, not by frequency.

i have been on this now, my latest discovery is that my gateway recieves pakects on 867.7. while it has a paste that its a 915MHz. what do i do in this case

The label would show the frequency for which the RF networks in the gateway were designed. The actual operating frequency is determined by the configuration files you use, you need to switch to the correct configuration files for your location. Hopefully those use a frequency matching that which your gateway was designed for, as trying to operate one on a frequency that the RF networks do not match will at best lead to poor range.