Bit strange, i did added some fields to the json status recently. If the TTN parser was not updated and is not resilient against field changes (which is a ‘bit rot’ bug), than it can cause this problem. The extra fields were: “pfrm”, “mail” and “desc”. These changes were communicated.
See also this thread: New Gateway Registration
Adding pfrm, mail and desc doesn’t seem to change the behaviour. Still no show at http://thethingsnetwork.org/api/v0/gateways/
I don’t understand your remark. You cannot add these fields, or you can, but that does not change anything of course, these new fields [which are part of the communication between the forwarder and the backend] may be the cause of the problems because of the TTN parser. It’s hard to imagine since this would really be a sign of bad code design on that side, but if so, it could explain it. Just a moment, i can think i can test this quickly.
if you want to use gps log and lat to apear on some status/map you need to run gps_pkt_fwd, not basic_pkt_fwd
fake_gps field in json is used only in gps_pkt_fwd (and beacon_pkt_fwd)
Okay, after some tests i found the following on TTN:
So … their is some heavy maintenance work to be done here it seems @turiphro
The status updates are broken indeed (they were implemented using the deprecated DB instead of API; @Jorma is fixing it). Unrelated to the API though. The /gateways/ shows GW status packets, the /nodes/ shows packets, so they’re not necessarily both there if one of the two packet types aren’t sent.
@johan can there be some reason gateway status messages with new IDs don’t get through? Or can you help debugging this problem? (give him some time, he’s workshopping downstairs ;))
I followed @nestorayuso 's advice and changed from basic_pkt_fwd to gps_pkt_fwd. Immediately, my gateway showed up in http://thethingsnetwork.org/api/v0/gateways/008000000000A452/ and I see packages in the tcpdump containing this info.
Not all available fields are shown, but they are also not showing on other hosts, so I guess that’s on the server todo list.
Now it’s time to make the gateway waterproof and hang it on the roof!
I understand, so i made sure packets were send and locally sniffed if the status messages were there too.
Btw, this nodes list [ http://thethingsnetwork.org/api/v0/nodes/ ] is ridiculously short, none of my node packets are show there, while in the gateway lists is says (few snapshots …)
{
“longitude”: 4.70053,
“last_seen”: “2015-11-20T12:38:19.599Z”,
“latitude”: 52.69021,
“status_packets_count”: 1368,
“eui”: “1DEE1DB50A0D5C5E”,
“altitude”: 5.0
}
…
{
“longitude”: 4.70053,
“last_seen”: “2015-11-20T13:17:57.024Z”,
“latitude”: 52.69021,
“status_packets_count”: 1389,
“eui”: “1DEE1DB50A0D5C5E”,
“altitude”: 5.0
}
…
{
“longitude”: 4.70053,
“last_seen”: “2015-11-20T13:44:27.010Z”,
“latitude”: 52.69021,
“status_packets_count”: 1416,
“eui”: “1DEE1DB50A0D5C5E”,
“altitude”: 5.0
}
so the status packet counter is increasing and i send much more RF packets than node packets:
Nov 20 13:03:33 lorank8 lorank8v1[12672]: # RF packets forwarded: 2 (74 bytes)
Nov 20 13:03:34 lorank8 lorank8v1[12672]: # RF packets forwarded: 3 (111 bytes)
Nov 20 13:03:34 lorank8 lorank8v1[12672]: # RF packets forwarded: 3 (111 bytes)
Nov 20 13:05:07 lorank8 lorank8v1[12672]: # RF packets forwarded: 3 (111 bytes)
Nov 20 13:05:08 lorank8 lorank8v1[12672]: # RF packets forwarded: 3 (111 bytes)
Nov 20 13:05:08 lorank8 lorank8v1[12672]: # RF packets forwarded: 1 (37 bytes)
Nov 20 13:45:08 lorank8 lorank8v1[12672]: # RF packets forwarded: 3 (111 bytes)
many more repetitions …
Nov 20 13:48:02 lorank8 lorank8v1[12672]: # RF packets forwarded: 3 (111 bytes)
Intersting, given the data
{
“longitude”: 6.55738,
“last_seen”: “2015-11-20T13:47:12.764Z”,
“latitude”: 53.18977,
“status_packets_count”: 7210,
“eui”: “008000000000A050”,
“altitude”: 5.0
}
and the fact that the forwarder sends out a status packet every 30 SECONDS is seems that this gateway is already recognised for 7210/2/60 = 60 hours! How could that be?
@devlaam that is approximately the time it has been on! Maybe the server does count the packages without location, but doesn’t show them in the list?
Yep something like this must be going on, i have the feeling this part needs some testing 
In order to check if your gateway is running use iot.semtech.com for the moment.
(All API calls have limit=20 by default and max 100, which is why the lists are short by default)
That makes sense, but why is it not updating? Or at least, it seems to update selectively.
Hello @nestorayuso
Being trying to get the raps + card to work and after following the instructions from https://github.com/mirakonta/lora_gateway/wiki/Part-3:-Compile-LoRa-gateway-software we keep getting the ERROR: [main] failed to start the concentrator. We get this error with and without the card plugged in. Clearly it seems it is not detecting the card. We connected pins 23 & 25 to 5V on the Mini PCIe card as per you instructions (or what we understood). Any ideas?
Many thanks
Hi,
I got the same problem while connecting the Multitech mCard to a Raspberry Pi 2 Model B using exactly the same instructions from @nestorayuso. Because I used the mCard earlier on another server (OpenSuse on Intel i7) without problems, I knew the mCard was fine. In my case the failure to start the concentrator depends on which USB power supply I used. Looking for some clues, I learned that the R-Pi 2 Model 2 has some USB current limiters installed that could prevent the concentrator to start up correctly.
I fixed the problem by adding the following line to the /boot/config.txt file: max_usb_current=1
Then reboot and the concentrator worked fine since then.
I am not sure you have the same issue here, but it may be worth trying.
regards,
Pieter
@pietervn Thanks much!!! will give it a shot and post the results.
@pietervn I just tried your suggestion and it worked. Thanks much!!
I created a device for just this purpose: https://www.happybubbles.tech/presence/detector
It scans for BLE advertisements/beacons and passes them over Wifi/MQTT as JSON payloads. Is that something that would be useful for you?