RAK2245 TTN-Gateway: no GPS?

hdtodd · March 15, 2020, 7:10pm

I’m running a RAK2245 on a Pi-3B under Buster, and I’ve installed the TTN Gateway and have it communicating successfully, up and down, between an end device (SAMD21 Pro RF) and the TTN cloud. I’m running lora_pkt_fwd code with the following version info:

   *** Beacon Packet Forwarder for Lora Gateway ***
   Version: 4.0.1
   *** Lora concentrator HAL library version info ***
   Version: 5.0.1;
   ***

But I have not been able to get the lora_pkt_fwd code to recognize the GPS system. The message I get from lora_pkt_fwd is:

   ### [JIT] ###
   # SX1301 time (PPS): 3843045995
   #src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty
   ### [GPS] ###
   # Invalid time reference (age: 1584297215 sec)
   # no valid GPS coordinates available yet
   ##### END #####

I’ve set SPI_SPEED down to 1000000 in loragw_spi.native.c before compiling, and if I

   cat /dev/ttyAMA0

I get output that looks like this

   ,,,,,,,,N*30,,,,,,,,,0,00,9GPGSA,A,.99,99.9SV,1,1,0PGLL,,,,H?I????}?V,,,,,,,,,,N*53
   $G,,0,00,99.99,,,,GPGSA,A,1,,,,,,,.99,99.99,99.99*LL,,,,,,V,N*64

at 1 sec intervals. GPS antenna is under a window with a clear view of southern sky.
The global_conf.json has GPS settings as:

   /* gps enable */
  "gps": true,
  "gps_tty_path": "/dev/ttyAMA0",
  "fake_gps": false,
  "ref_latitude": 10,
  "ref_longitude": 20,
  "ref_altitude": -1,
  "autoquit_threshold": 20

And the Pi’s /boot/config.txt has

   # Uncomment some or all of these to enable the optional hardware interfaces
   dtparam=i2c_arm=on
   #dtparam=i2s=on
   dtparam=spi=on
   dtparam=i2c1=on, dtparam=i2c_arm_baudrate=100000

Does anyone have the TTN gateway code working with RAK2245 on a Pi that does get the GPS coordinates? If so, did you have to do anything (else) special to get it working? Ah, and where did you download that code from? I think I took mine from the github site, but it might have been copied over from a RAK Pi “firmware” install that I had first tried to use.

bpr · March 15, 2020, 8:50pm

Mine is working fine. I’m using the firmware from GitHub - RAKWireless/rak_common_for_gateway on top of a fresh installation of full buster, NOT the firmware from the RAKWireless site. Did not do anything special to install
EDIT! Sorry, correct link is GitHub - RAKWireless/rak_common_for_gateway

ZhuQI · March 16, 2020, 1:32am

@hdtodd
Have you not used the firmware provided by rak or used https://github.com/RAKWireless/rak_common_for_gateway?

If so, you can try

Add "dtoverlay = disable-bt" to /boot/config.txt
Execute "sudo systemctl stop [email protected]" and restart the gateway

hdtodd · March 16, 2020, 1:34am

Brian, thanks for the quick response.

Unfortunately, https://github.com/RAKWireless/rak_common_for_gateway/tree/master is no longer a viable git source. It looks like https://github.com/RAKWireless/rak_common_for_gateway/lora/rak2245 might have some of the RAK-specific files, but not the whole tree. I’ll poke through some of that to see if I can use it to update the tree I already have installed.

bpr · March 16, 2020, 1:37am

@hdtodd, Yeah, sorry, this is the correct link:

@ZhuQi beat me to that, I see

hdtodd · March 16, 2020, 1:37am

The RAK firmware is one major version back in Raspbian, and my other systems are on Buster, so I want to install over buster, not use the RAK firmware.

I’ll try your other suggestions and see if it makes a difference. Thanks!

David

hdtodd · March 18, 2020, 9:10pm

Brian & ZhuQi:

I’ve done a number of installs of Chirp and friends over the last couple of months as I learned about TTN and LoRaWAN, and I was not sure of the sources of some of the components. So I removed all prior installs of Chirp and ttn-gateway and started fresh.

I’m running Buster (updated to current) on a RPi-3B off a SSD.
I did apt-get --purge remove all the Chirpstack components, postgres*, rdis, mosquitto, ttn-gateway; removed the various associated directories left behind in /etc and /var and /lib.
I cloned https://github.com/RAKWireless/rak_common_for_gateway and installed with --chirpstack=not_installed this time (looking to just get the gateway working with GPS for now).
I used the /boot/config.txt and /boot/cmdline.txt files that came with the RAK install, and I checked to make sure "disable-bt" was in the config.txt file.
I configured the gateway with gateway-config to set for US frequencies.
I changed to "#define SPI_SPEED 1000000" in "loragw_spi.native.c" and recompiled. (Actually, I tried with 2MHz, too.)
I did the "sudo systemctl stop [email protected]" and then disabled it.
I’ve rebooted (multiple times) to make sure everything has been reset.

When I start ttn-gateway manually or enable/start ttn-gateway via systemctl, I get continual messages WARNING: [gps] could not get a valid message from GPS (no time). And in message processing, the log reports:

   ### [GPS] ###
   # Invalid time reference (age: 1584563907 sec)
   # no valid GPS coordinates available yet
   ##### END #####

The TTN network server “sees” my gateway, and it receives and processes packets, so the LoRaWAN code is working, but the GPS system is still not working. Again, the GPS antenna has a clear view of the southern sky (that’s the right direction from here in Vermont).

If I stop ttn-gateway and try some of the diagnostics in /opt/ttn-gateway/lora_packets/libloragw, the GPS test gives me

/opt/ttn-gateway/lora_gateway/libloragw# ./test_loragw_gps
Beginning of test for loragw_gps.c
*** Library version information ***
Version: 5.0.1;

~~ UBX NAV-TIMEGPS sentence, triggering synchronization attempt ~~
No valid reference GPS time available, synchronization impossible.

/opt/ttn-gateway/lora_gateway/libloragw# ./test_loragw_reg has most registers matching, but a few don’t, such as

 ###MISMATCH### reg number 4 read: 154 (9a) default: 0 (0)

… probably OK, but can’t tell (no user’s guide).

And /opt/ttn-gateway/lora_gateway/libloragw# ./test_loragw_spi gives

Beginning of test for loragw_spi.c
data received (simple read): 48
End of test for loragw_spi.c

Again, can’t tell if that’s right or wrong.

If I cat /dev/ttyAMA0 I get a constant stream of output that looks like:

$GPGLL,V,N64
?b H?)???Z?$GPRMC,V,N53
$GPVTG,N*30
$GPGGA,0,00,99.99,48
$GPGSA,A,1,99.99,99.99,99.9930

I’m not sure what other tests I can run.

It looks like the GPS is outputting information as it’s supposed to, but the lora_pkt_fwd code isn’t seeing it or is seeing a garbled version of it.

Any thoughts on other things I can try? I’d seen speed/parity/start-stop bit setting changes in some other post (to apply to /dev/ttyAMA0), but I wouldn’t think those would be relevant.

Brian, did you have to change any other settings to get your GPS to work, or did it just work “out of the box”?

David

ZhuQI · March 19, 2020, 10:00am

@hdtodd
Hello!

I just reinstalled it on a new Raspberry Pi system using GitHub - RAKWireless/rak_common_for_gateway.

Can successfully see gps.

I tried some other tests.
Test 1.
a) End the lora_pkt_fwd process first. "sudo systemctl stop ttn-gateway".
b) Use cat /dev/ttyAMA0 to view the following information. The information contains latitude and longitude.

Test 2.
a) Unplug the GPS antenna and restart the gateway.
b) End the lora_pkt_fwd process first. "sudo systemctl stop ttn-gateway".
c) Use cat /dev/ttyAMA0 to view the following information.
2020-03-19 17:28:17

Test2’s test results are very similar to yours.

You can completely disable serial login in “sudo raspi-config”.
2020-03-19 17:23:10
2020-03-19 17:23:19

Then see if your problem exists.

If the problem exists, can we resolve it remotely?
I am online from 01:00 to 11:00 UTC.

hdtodd · March 19, 2020, 11:13am

@ ZhuQI:

Thanks for the information. It gave me some helpful things to try.

I removed the GPS antenna. Checked the connectors under a magnifying glass and found no damage.
I disabled serial login and enabled the serial port, as your screen shots showed; I disabled ttn-gateway.service; then I rebooted.
cat /dev/ttyAMA0 now gives me a constant stream that looks something like:
?b ?I???2?$GPRMC,V,N*53
$GPVTG,N*30
$GPGGA,0,00,99.99,*48
$GPGSA,A,1,99.99,99.99,99.99*30
$GPGLL,V,N*64
$GPTXT,01,01,01,NMEA unknown msg*58

in which I’m now getting the NMEA word in the output (which I had not seen earlier) and some semblance of GPS readings.
Power off; reattach GPS antenna; reboot. cat /dev/ttyAMA0 now gives:

$GPGLL,V,N*64
?b ???׍$GPRMC,V,N*53
$GPVTG,N*30
$GPGGA,0,00,99.99,*48
$GPGSA,A,1,99.99,99.99,99.99*30
(no $GPTXT and NMEA phrases!)
Run ./start.sh in lora_pkt_fwd and I get # no valid GPS coordinates available yet, as before.
If I run the GPS tester again, I get

lora_gateway/libloragw# ./test_loragw_gps
Beginning of test for loragw_gps.c
*** Library version information ***
Version: 5.0.1;
~~ UBX NAV-TIMEGPS sentence, triggering synchronization attempt ~~
No valid reference GPS time available, synchronization impossible.

So the problem persists. This looks like the GPS system just isn’t getting signal from the antenna or that the antenna just doesn’t have a clear view of the sky (but it does).

If the problem exists, can we resolve it remotely?
I am online from 01:00 to 11:00 UTC.

I’m not sure how to solve this remotely, but I’m willing to give it a try. It’s now 12:04 UTC so you’re offline. 1:00 UTC is 20:00 my time; I’ll likely be spending time with my wife then but should be available about 22:00 (3:00 UTC).

Meanwhile, if you can think of anything else for me try, please let me know.

David

ZhuQI · March 20, 2020, 1:06am

RAK2245 has two antenna interfaces, one for lora antenna and one for gps antenna.

Connect the gps antenna to the gateway, and place the gps antenna in an open outdoor area. If gps data is not obtained, you can try to contact the after-sales service to replace the entire RAK2245.

hdtodd · March 20, 2020, 10:49am

@ZhuQI,

Thanks. Sounds like we’ve exhausted options.

I’ve checked again to make sure that the GPS antenna is on the correct connector (the one labeled “GPS”): it is. And the LoRa antenna is attached to the other connector and is functioning, since LoRaWAN packets are seen by TTN.
The GPS antenna has a clear view of the southern sky from a south-facing, second-floor window. It’s supposed to be warmer today, so I’ll stick it outside and try again, but I don’t expect it to work. It still seems like an antenna or connection issue, not GPS electronics, but I can’t think of anything else to try.

Presuming that my outdoor GPS antenna test fails later today, how do I contact after-sales service?

I’ll post if that outdoors test is successful, as that would save others a good deal of time if they run into the same problem and putting the antenna outside solves it.

David

hdtodd · March 21, 2020, 9:32pm

@ZhuQI,

I just confirmed that with the GPS antenna outside, on a clear day, with an unobstructed view of the southern sky, cat /dev/ttyAMA0 continues to produce a steady stream of:

?b `???x?$GPRMC,V,N*53
$GPVTG,N*30
$GPGGA,0,00,99.99,*48
$GPGSA,A,1,99.99,99.99,99.99*30
$GPTXT,01,01,01,NMEA unknown msg*58

With many “$GPTXT” messages between data streams.

I also disconnected the GPS antenna again and examined the GPS socket on the RAK board and the connector on the U.FL cable, and both appear to be fine (pin not bent).

So, after 3 months of thinking I had it set up wrong, I’m willing to admit that the problem is probably not me but the board. So I’d like to pursue getting a replacement RAK2245.

David

brosr · March 22, 2020, 4:10pm

David,
how long was the time to give it a chance for a fix? I can remember on my setup (indoor, antenna in front of the window) it took me one night to acquire a fix.
Rudi

hdtodd · March 22, 2020, 4:28pm

Thanks for the idea, Rudi. I had the same thought. It’s been running for about 18 hours now and still no fix. I’ll just continue to let it run, but by now it should have gotten a fix if it’s going to at all.

Good idea, though: thanks for the suggestion. I’m willing to try any ideas at this point. The RAK2245 looks well constructed, and it’s hard for me to believe that it’s either the board or the antenna that’s causing the problem, but I can’t find anything else.

David

ZhuQI · March 23, 2020, 2:15am

I have feedback your question to my superior.
We will reply you as soon as possible.

ZhuQI · March 23, 2020, 2:25am

Could you please provide your email address? I want to send you a test program to do a test.

hdtodd · March 23, 2020, 9:53am

@ZhuQI

Sent my email address in a message.

By the way, just to be clear, the updated lora_fwd_pkt.c code did fix the problem in which the gateway wouldn’t process downlink packets from TTN that had requested tx power 17.

But the new code does not fix the problem of being unable to get the GPS time or coordinates.

My RAK2245 gateway has been happily sending device packets off to TTN all along, so the LoRa section works; it’s the GPS that isn’t functioning.

The fact that it now adjusts the power for the downlink packets does suggest that I’m at least running the most recent version of the code this time!

David

ZhuQI · March 23, 2020, 10:20am

I have sent you the test program, please check it.

hdtodd · April 1, 2020, 6:26pm

Just to bring this to closure, for anyone else who has this kind of problem:

My problem turned out to be the GPS antenna!

After working with @ZhuQI to try solutions and test the GPS unit, RAK was kind enough to send a replacement unit. Before installing the new 2245, I removed the old antenna from my old 2245 and installed the new antenna on my old RAK2245. Powered my Raspberry Pi up, and lora_pkt_fwd immediately saw the GPS and within seconds had a fix on coordinates and time.

So it was either the GPS antenna or its connecting cable/u.fl connector that had caused the RAK2245 to not be able to get GPS coordinates.

Many thanks to @ZhuQI for working through this with me and to the RAK staff for the quick turnaround on the replacement 2245. It’s much appreciated. The replacement RAK2245 is on it’s way back to the factory.

This issue can be closed now.

David