RAK831 config issue?

Gateways Raspberry Pi Gateways
1

Hi all,

I’m new here, trying to get my first LoRaWAN gateway on TTN happening.

I was wanting to know, in the rpi based gateway, is any way to tell what the concentrator thinks it’s doing? Ie retrieve its settings ideally from the device itself or at least in the lorawan software somewhere (particularly frequency plan!) or do a reset or anything else beyond the GPIO based board reset that I already have happening?

Also, if anyone wants to wade through my waffling below, and can identify what else might be a good place to look at with my setup right now, I’d really appreciate it. this is a big thing with a bunch of moving parts I freely admit I don’t fully understand yet.

So - I have just got a RAK831 board with the PI adapter, to make my own pi based gateway. (with no GPS attached for now, if that makes a difference, though I do have one I can solder on if needed) I followed all the steps as described (including auto-config by pushing my setup data into that git repo) and ended up with a gateway showing up on TTN with the “last message received” counter always resetting at 30 seconds.

My issue is, now I have setup a remote device (RAK811-tracker) by following the instructions using the included project, modifying the compiler symbols for my specific location (AU 915MHz) and matching the details I registered in TTN for my application and my device, but I’m not seeing any data come through. And my thing just sits there, running through to the “OTAA Join Start…” message then hanging, and retrying.

Looking at the relevant logfile my gateway is basically never receiving any messages (though VERY occasionally does see something that it claims has bad CRC and discards) I’m trying to work out what could be wrong?

one weird thing, in the logfile, the log data I"m seeing is identifying itself “Jan 24 18:33:39 ttn-gateway ttn-gateway[816]” I hope the gateway isn’t assuming it’s running at 816… that would be a problem… it is meant to be running at 915-928 to fit in our sub-G ISM band.

For reference, my tracker is cycling through transmitting on 8 bands according to my specan… (roughly measured on a 64MHz span so not that accurate…) 915.74, 917.4, 919.0, 920.5, 922.3, 923.9, 925.5, 927.2.

gateway and tracker are maybe 4m apart.

The only “issue” I see with my logfile as it runs is that there is a reference to an invalid GPS time reference…

Anyway - here’s a pretty common stream of logfile info…
from running tail -f /var/log/syslog

Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: ### [DOWNSTREAM] ###
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: # PULL_DATA sent: 3 (100.00% acknowledged)
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: # RF packets sent to concentrator: 0 (0 bytes)
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: # TX errors: 0
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: ### [GPS] ###
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: # Invalid gps time reference (age: 1516779729 sec)
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: # Manual GPS coordinates: latitude -33.67586, longitude 150.74483, altitude 46 m
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: ##### END #####
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: INFO: [up] PUSH_ACK for server router.au.thethings.network received in 3 ms
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: INFO: [down] for server router.au.thethings.network PULL_ACK received in 2 ms
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: INFO: [down] for server router.au.thethings.network PULL_ACK received in 2 ms
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: INFO: [down] for server router.au.thethings.network PULL_ACK received in 2 ms
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: ##### 2018-01-24 07:42:39 GMT #####
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: ### [UPSTREAM] ###
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: # RF packets received by concentrator: 0
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: # RF packets forwarded: 0 (0 bytes)
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: # PUSH_DATA datagrams sent: 1 (234 bytes)
Jan 24 18:42:39 ttn-gateway ttn-gateway[816]: # PUSH_DATA acknowledged: 100.00%

thanks in advance!

2

have you edited in Commissioning.h

#define LORAWAN_DEVICE_EUI { IEEE_OUI, 0x00, 0x47, … } ← DELETE IEEE_OUI

invalid gps-time: I assume that you have configured „fake gps“, so it´s „normal“

1 Like
3

Don’t worry about the ttn-gateway[816], 816 is the process ID of the forwarder application, it is not the frequency.

1 Like
4

hey there! Thanks for your response!

Sorry for my slow reply, I’m working on a few things right now.

The instructions that came with my gear said to use the device EUI I picked when I setup the device in TTN… so I’m using that… 8 plain hex bytes. though my issue seems to be more fundamental - that I’m not receiving anything to send up to TTN…

My gateway is apparently running and I’m watching the logfile output by tailing syslog. Every few minutes it seems to post a summary of what’s been going on… normally it says it’s seen no lora pakets, and very occasionally claims to have seen one with a bad CRC and thrown it out…

But I have my tracker device powered up - and when I look at the serial debug out on that, I can see it’s regularly trying to make a connection, then waiting, timing out, and trying again. (and with my spectrum analyser I can see at least that this one is talking on channels in my ISM range)

So I’m thinking there’s an issue with the actual radio or the radio setup on my gateway?

That’s why i was hoping to be able to get a little insight into debugging the concentrator and the software… ie to double check what rx channels are set, and stuff like that.

I looked into the fake_gps config option… I actually don’t have that configured. But where I see examples of this in blogs, the format of the local_conf.json is different (less heirachical) than the template I filled out for the autoconfig system… also my template doesn’t have this entry… probably easier for me to just solder on the GPS receiver, and see if that makes a difference, though GPS reception in here won’t be fantastic, I do have window access, it should get a lock I guess…

5

and thanks for letting me know that’s the process ID!
if it had been something very different it’d be less worrying, but seeing an “800” range number when I’m trying to work out why my gateway wasn’t receiving my tracker made me wonder if that was some frequency range indicator for the setup… :wink:

6

oh yeah - I should update here…
turns out the issue was I didn’t see the instruction to manually set my frequency plan right, so i was stuck on the EU plan, which obviously wasn’t helpful for receiving anything on my 915 configured HW, with my properly configured 915 configured tracker node…

A bit funny, as for the autoconfig process I went through, you do need to fill in what your operating frequency is, so I had assumed it was “just handled” but it’s not, at all.

This is probably due to the fact that the codebase that RAK tell you to use is based on another concentrator board (ic880a) that only is made in EU frequency range, so their github project that RAK leverage has no need to set the global_config.json file to anything but the one setting…

Also, I had a funny thing where my RPI SDcard stopped registering file system changes over a reboot (I could edit or create a file, go back and read it back out, but then on a reboot it would be gone!) I reinstalled from scratch on a new SDcard and that is gone…

7

Hi Julian,

Have you managed to get your RAK gateway up and going yet.

I am located in Melbourne and have set up a RAK 831 based gateway.
The easiest way I found to get it all working is to update the global config file to use the AU915 frequency plan. There is one available on Github that you can use to get things started.

I also modified the startup.sh file so that it does not keep trying to get the local config updates from Github. I just found it too time consuming to push local config file updates and have them then down loaded again.

Once it fires up correctly, you should see details in the syslog file to indicate that the gateway has all of the frequencies set correctly.

If you are still struggling, I can send you the conf file I have used to help get things going.

Cheers

Peter.

8

Incidently, I have also have SD card problems with my Pi3. I changed to a decent Toshiba micro SD card rather than the Kingston one that came with my RPi.

Peter.

1 Like
9

hi, thanks for the offer, but it seems all is good now.

I’m happy enough with the startup.sh in place for now. I just have to make sure I run the reset script if the gateway ever power cycles.

The only thing I’d missed was replacing the global config file (which I had just expected to “work” given the config info I had typed in, before I realised that the install script being used was written for a product that has nothing but an EU configuration that it’s used for.)

Once I jumped in and had a look at what the install package actually was doing, it was pretty obvious what to do.

hmm… maybe I should fork this ic880a repo and make a RAK831 repo that adds the reset script and fixes the international radio plan setup…

My “no disk writes survive over reboot” SDcard was an old noobs card I’d got 2nd hand along with 5 x rerurn/check RPi3 for a big discount… The one that’s currently working is a sandisk 16G which is the type I normally use for RPi. I have never seen this before, and for a while I was wondering if that was some feature of ic880a install script, but I couldn’t see anything it was doing that would directly cause that…

10

May be you can try this setup I done for RAK831, should works right out of the box (you can avoid setting monitor.py and step for ws2812 led)

thus it use new @kersing packet forwarder :wink:

1 Like
11

If I can go into this thread and ask - Can RAK831 operate on 920-925Mhz at all?

12

RAK831 is LoraWAN concentrator, thus it is normalized and frequencies depends on region. Best frequencies for you is US @ 915MHz (902Mhz to 928Mhz)

See here https://www.thethingsnetwork.org/wiki/LoRaWAN/Frequencies/Frequency-Plans

13

I am in HK and the regulators here is licensing 920-925mhz.

14

Yeah, they do not provide for that frequency, may be worth asking them if it’s on the roadmap

1 Like
15

Already dropped a message in the RAK Wireless forum. I guess it closing to Chinese New Year and the country will be in deep sleep mode for about 2-3 weeks

16

The RAK831 will happily operate on the frequencies you need.

You need to purchase the 915 version.

I have one and have run the 923 AS2 frequency plan in Australia. It can also support the AS1 frequency plan.
I currently have it set for the AU915 frequency plan.

Assuming you are going to drive this with a RAS Pi board then it is simply a matter of changing the config files to set the appropriate parameters for your region.

Cheers

Peter.

17

I have the 868Mhz version.
I will look in to the config file. The problem is I don’t think I have a end node in hand that operates on that frequency to test.

18

Oh.

I suspect you will need to get a 915Mhz one or speak to RAK about converting yours.
I am not sure a simple config file change will allow your gateway to work in the ISM band for Australia.

19

well this has drifted a bit off topic. :slight_smile:

coeus, you are in HK, right? well according to this page, the official LoRaWAN plan for HK is here… so as long as that plan doesn’t break the HK rules for their sub-G ISM, no need to hassle TTN people about it.

https://www.thethingsnetwork.org/wiki/LoRaWAN/Frequencies/Frequency-Plans#lorawan-frequencies_as923_as923-925 which sticks the whole range of your LoraWAN network inside 923-925MHz.

You WILL need a 915MHz version of the 831 concentrator to work properly in the HK frequency plan, not the 866 version. I would expect the RF components are slightly different across the two versions of the board. They are meant to work with two specific ranges of radio frequency!

BUT if they have designed these concentrator cards as I expect, with only a few filter components different, it’s possible you will get a bit of reception in your office to have a play, if you just set the 866 device to your HK 923-925MHz range plan. It’s not like the rf parts here acting like brick walls… signal will get through, just very far down in level (or you might even get coupling into the receiver past the filter network) but give up on making a proper active public gateway using the wrong board… unless you have the ability to select and change the filter parts yourself.

1 Like
20

PS, I do not recommend you get and run an 866 MHz lora device + gateway in HK.

Spectrum misuse by operating random things in a country’s non-ISM frequencies is generally frowned upon and if caught can carry large penalties… You could be messing with anything. Probably cell/mobile phones, but it could be military applications or anything else, too.

Whatever it is, someone else owns the rights to that bit of spectrum, and if you cause them to not be able to access it when they want to, they will have every right to be cranky.

1 Like