Could it be that you received the wrong board? Or that you have a board with the wrong band pass filters mounted?
Are these the proper freq for sub-band 1 ?
Ch - Freq
8 - 903.9
9 - 904.1
10 - 904.3
11 - 904.5
12 - 904.7
13 - 904.9
14 - 905.1
15 - 905.3
I believe my code for the RN2903 should enable these
for ch in range(0,72): # sub band 1
self.write_command('mac set ch status %d %s'%(ch,
'on' if ch in range(8,15+1) else 'off'))
…
I would think that if this were the case then it would fail the loragateway rx tests in private mode. It works fine at distance… 100%, I think I may have the RN2903 mis-configured (sub-band) as kersing mentioned (oops)
These frequencies look right. In your earlier message you mention band 7 and the code shows different channels enabled as well.
Well, I did find that the script I was using had these set wrong. I set them to 8 thru 15 and the script is now working… Ugh. I knew it had to be something obvious …
I’m guessing the frequencies I enable on the RN2903 must match those in the global_conf.json for things to work at all. The strange thing is , the script was working but it must have been because it was overloading the RAK as you suggested…
Tom
My gateway is up and running now. The installation was really simple, thanks to the guide linked by borroz earlier.
The gateway seems to be receiving packets:
Nov 11 11:35:13 B827EBFFFE8FE3C3 ttn-gateway[310]: # RF packets received by concentrator: 1
Nov 11 11:35:14 B827EBFFFE8FE3C3 ttn-gateway[310]: # RF packets received by concentrator: 0
Nov 11 11:35:14 B827EBFFFE8FE3C3 ttn-gateway[310]: # RF packets received by concentrator: 1
Nov 11 11:35:14 B827EBFFFE8FE3C3 ttn-gateway[310]: # RF packets received by concentrator: 0
Nov 11 11:35:14 B827EBFFFE8FE3C3 ttn-gateway[310]: # RF packets received by concentrator: 1
But I can’t see any packets on the “Traffic” tab in the TTN Console. Why is that?
I notice that the packet forwarder logs quite a lot to syslog (a little more than 1 line per second on average). Should I do something to prevent the SD card on the RPi from being fatigued by the writes?
I’ve noticed that if I open up the “data” page on TTN and leave it open before the device sends data, I will see the data on the page. If however, I open the page after the device has sent data, no data is shown.
The data is not kept on TTN. There is no database of your data that I’m aware of. However the browser app will cache what it receives and as long as you leave the page open you see the history of data sent.
Are you sure packets are being forwarded ? What is the “last seen” time for the device on TTN ? You can use tcpdump on your gateway to see the packets being sent. % tcpdump -AUq port 1700
1 Like
Thanks.
I’ve had the traffic tab open in my browser for several hours (including the time I quoted from syslog above).
The TTN console says that my gateway was last seen <30 seconds every time I check.
I see traffic using tcpdump, but nothing that looks like RF packets. Just lots and lots of these:
15:55:14.263606 IP B827EBFFFE8FE3C3.w3.mjo.se.46418 > 52.169.76.203.1700: UDP, length 225
E.....@.@.Z.....4.L..R....E......'......{"stat":{"time":"2017-11-11 14:55:14 GMT","lati":57.69952,"long":11.95215,"alti":13,"rxnb":0,"rxok":0,"rxfw":0,"ackr":100.0,"dwnb":0,"txnb":0,"pfrm":"IMST + Rpi","mail":"ttn@falkviddholding.com","desc":"FHAB #1"}}
15:55:14.315056 IP 52.169.76.203.1700 > B827EBFFFE8FE3C3.w3.mjo.se.46418: UDP, length 4
E.. .W@.-.7`4.L........R..~...................
15:55:16.868261 IP B827EBFFFE8FE3C3.w3.mjo.se.57710 > 52.169.76.203.1700: UDP, length 12
E..(..@.@.[.....4.L..n....D;.Q...'......
15:55:16.916195 IP 52.169.76.203.1700 > B827EBFFFE8FE3C3.w3.mjo.se.57710: UDP, length 4
E.. ..@...6.4.L........n..;X.Q................
15:55:26.988264 IP B827EBFFFE8FE3C3.w3.mjo.se.57710 > 52.169.76.203.1700: UDP, length 12
E..(..@.@.Y.....4.L..n....D;.sW..'......
15:55:27.037768 IP 52.169.76.203.1700 > B827EBFFFE8FE3C3.w3.mjo.se.57710: UDP, length 4
E.. ..@...4
4.L........n..{6.sW...............
15:55:37.118086 IP B827EBFFFE8FE3C3.w3.mjo.se.57710 > 52.169.76.203.1700: UDP, length 12
E..(.b@.@.XM....4.L..n....D;.0...'......
15:55:37.166704 IP 52.169.76.203.1700 > B827EBFFFE8FE3C3.w3.mjo.se.57710: UDP, length 4
E.. .[@...-\4.L........n..,y.0................
15:55:44.255547 IP B827EBFFFE8FE3C3.w3.mjo.se.46418 > 52.169.76.203.1700: UDP, length 225
E....*@.@.T.....4.L..R....E..`...'......{"stat":{"time":"2017-11-11 14:55:44 GMT","lati":57.69952,"long":11.95215,"alti":13,"rxnb":0,"rxok":0,"rxfw":0,"ackr":100.0,"dwnb":0,"txnb":0,"pfrm":"IMST + Rpi","mail":"ttn@falkviddholding.com","desc":"FHAB #1"}}
15:55:44.309819 IP 52.169.76.203.1700 > B827EBFFFE8FE3C3.w3.mjo.se.46418: UDP, length 4
E.. ..@.-.+.4.L........R..>h.`................
15:55:47.248299 IP B827EBFFFE8FE3C3.w3.mjo.se.57710 > 52.169.76.203.1700: UDP, length 12
E..(. @.@.T.....4.L..n....D;.S...'......
15:55:47.298212 IP 52.169.76.203.1700 > B827EBFFFE8FE3C3.w3.mjo.se.57710: UDP, length 4
The packet lengths are always 4, 12, 4, 12, 4, 255 and then it repeats
I seem to be getting CRC FAIL, so that’s probably why packets aren’t being forwarded:
Nov 11 16:00:00 B827EBFFFE8FE3C3 ttn-gateway[310]: ### [UPSTREAM] ###
Nov 11 16:00:00 B827EBFFFE8FE3C3 ttn-gateway[310]: # RF packets received by concentrator: 1
Nov 11 16:00:00 B827EBFFFE8FE3C3 ttn-gateway[310]: # CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
Nov 11 16:00:00 B827EBFFFE8FE3C3 ttn-gateway[310]: # RF packets forwarded: 0 (0 bytes)
Nov 11 16:00:00 B827EBFFFE8FE3C3 ttn-gateway[310]: # PUSH_DATA datagrams sent: 1 (225 bytes)
Nov 11 16:00:00 B827EBFFFE8FE3C3 ttn-gateway[310]: # PUSH_DATA acknowledged: 100.00%
Nov 11 16:00:00 B827EBFFFE8FE3C3 ttn-gateway[310]: ### [DOWNSTREAM] ###
Nov 11 16:00:00 B827EBFFFE8FE3C3 ttn-gateway[310]: # PULL_DATA sent: 3 (100.00% acknowledged)
Nov 11 16:00:00 B827EBFFFE8FE3C3 ttn-gateway[310]: # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Nov 11 16:00:00 B827EBFFFE8FE3C3 ttn-gateway[310]: # RF packets sent to concentrator: 0 (0 bytes)
Nov 11 16:00:00 B827EBFFFE8FE3C3 ttn-gateway[310]: # TX errors: 0
grep 'RF packets received by concentrator: [1-9]' /var/log/syslog -A1
Nov 11 16:04:33 B827EBFFFE8FE3C3 ttn-gateway[310]: # RF packets received by concentrator: 1
Nov 11 16:04:33 B827EBFFFE8FE3C3 ttn-gateway[310]: # CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
--
Nov 11 16:06:44 B827EBFFFE8FE3C3 ttn-gateway[310]: # RF packets received by concentrator: 2
Nov 11 16:06:44 B827EBFFFE8FE3C3 ttn-gateway[310]: # CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
--
Nov 11 16:06:44 B827EBFFFE8FE3C3 ttn-gateway[310]: # RF packets received by concentrator: 1
Nov 11 16:06:44 B827EBFFFE8FE3C3 ttn-gateway[310]: # CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
Does this mean there is something wrong with my concentrator?
no , it can be received data from another network/node far far away.
what’s important is what you see in the TTN console… your gateway and applications.
@tbalon… you can ad data storage in your application under integrations, then you have 7 days storage
It’s good that your gateway is shown as connected, but what I was referring to was the device in your application… If you go to your “application” select the “device” that you expect has sent data and look at the “last seen” time… it should be recent. If it says “never seen” then no packets have arrived at TTN from that device.
The tcpdump output should look like this for a packet being uploaded. Note the receive packet field in the UDP packet “rxpk” this show the packet is being properly forwarded.
m.B.$.4…g…’…yy.{“rxpk”:[{“tmst”:2581612820,“time”:“2017-11-09T20:59:15.026490Z”,“chan”:2,“rfch”:0,“freq”:904.300000,“stat”:1,“modu”:“LORA”,“datr”:"_
SF10BW125",“codr”:“4/5”,“lsnr”:-12.8,“rssi”:-109,“size”:15,“data”:“QMwcAiYACAABvEdHk6e5”}]}
I only see “stat” updates in your output. This is your gateway sending its status to TTN… This is all good. Make sure you sending device is properly configured…
1 Like
Thanks BoRRoZ ! I may use this… Right now I’m connecting via mqtt to get updates and process my data.
Thanks for clarifying.
At the moment, I don’t have a device. My interest is to verify that my newly installed gateway really works.
But I guess I’ll either have to wait for someone else’s device to send something that’s strong enough to be received, or build a device of my own.
So far, I have 210 packets failing CRC.
Which packet forwarder are you people using with the RAK831? The (discontinued) Golang one or the ttn-zh?
the one used by the guide I linked to, which seems to be ttn-zh.
Mp forwarder 
1 Like
ttn-zh
Today I’ll build a device to check my gateway. During the first 23 hours of operations, the gateway claims to have received 835 packets, with 100% CRC fail (and 0 packets showing in my open tab on the TTN console trafic).
If there are no (known) nodes that is to be expected. Packets with CRC errors are not a problem, just ignore them.
For you node, make sure to keep it at least 3 meters from the gateway, nodes closer to the gateway might have too strong a signal resulting in CRC errors as well.
Hi,
I’m using RAK831.
could RAK831 send beacons without gps module??
(like disabling gps)
I want to use RPI3 timer to periodic beacon transmissions.
when I look at the packet forwarder code from semtech, it seems gateway cannot transmit beacons without gps.
any advice?
regards.