The hard RAK831 cafe part 1

Gateways RAK Gateways
341

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
342

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

343

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?

344

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

datastorage

345

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
346

Thanks BoRRoZ ! I may use this… Right now I’m connecting via mqtt to get updates and process my data.

347

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.

348

Which packet forwarder are you people using with the RAK831? The (discontinued) Golang one or the ttn-zh?

349

the one used by the guide I linked to, which seems to be ttn-zh.

350

Mp forwarder :wink:

1 Like
351

ttn-zh

352

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).

353

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.

354

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.

355

With VAT + import taxes, wouldn’t this end up more expensive than the IC880a?

356

No it can not. GPS is required to meet timing requirements.

357

Current price of RAK831 KIT is €113.29, shipping is €4.82 making a total of €118.11. In the Netherlands the Dutch Customs will add 21% VAT plus €13 handling fee for the local parcel shipping company which makes a total of: €156. If you buy the basic RAK831 (non-kit) version you can save €6 making the total €150.

358

When stationary gateway, why would NTP time be insufficient and GPS time be required instead?

359

Because the GPS module is connected to the SX1301 to provide the 1pps as well. This allows for a sync resolution which NTP can’t provide.

360

@kersing

okay.
but it’s possible to transmit beacons using local timer, not gps right?
Assuming there is just one gateway in the network.