Raspberry Pi 3 + IC880a + GPS

(Marssystems) #21

Is it true that only the Ublox ver.7 GPS is supported in the HAL at the moment?

(Ralph) #22

I successfully connected an uBlox NEO 6M module to the RPi -IC880a-resin.io set-up based on the UDP-forwarder.

As I connected the RX and TX lines to the RPi, it was necessary to suppress echo on the line as this conflicts with proper NMEA communication.

I accomplished this by adding the commands [stty -F /dev/ttyAMA0 -echo] and [stty -F /dev/ttyS0 -echo]
to the script in run.sh. Look for section # Set up environmental defaults for local.conf

if [[ $GW_GPS_TTY_PATH == "" ]]
    # Default to AMA0 unless this is an RPi3 with core frequency set in fleet config vars
    stty -F /dev/ttyAMA0 -echo
    if [[ "$RESIN_MACHINE_NAME" == "raspberrypi3" && "$RESIN_HOST_CONFIG_core_freq" != "" ]]
        stty -F /dev/ttyS0 -echo

This has worked like a charm now for many weeks:

### [GPS] ###
# Valid gps time reference (age: 0 sec)                                                                                                          
# System GPS coordinates: latitude 51.45391, longitude 5.40206, altitude 63 m                                                                    
##### END #####
NOTE: [down] beacon ready to send (frequency 0 Hz)                                                                                               
--- Beacon payload ---                                                                                                                           
0xEE - 0xFF - 0xC0 - 0x00 - 0x00 - 0x00 - 0x00 - 0x84                                                                                            
0x00 - 0x00 - 0x65 - 0x3C - 0x59 - 0xF6 - 0x03 - 0xDD                                                                                            
0x78 - 0x00 - 0x00 - 0x00 - 0x00 - 0x00 - 0x00 - 0x00                                                                                            
--- end of payload ---                                                                                                                          
NOTE: [down] beacon sent successfully

(Marssystems) #23


I'm running this build of the gateway - https://github.com/jpmeijers/ttn-resin-gateway-rpi

So, unfortunately there is no run.sh for me to update.

(Ralph) #24

@marssystems Yep I understand.
I just wanted to highlight the issue I experienced when not suppressing echo on the serial lines, as this effectively jammed the NMEA communications after a short while. This might be just as true for the new TTN-packet forwarder.

(Jac Kersing) #25

Right, I've committed the updates required for NMEA compatible GPS to work to the mp_pkt_fwd repository on GitHub.
A small fix to run.py will be as well required, line 169 now reads:

if(os.getenv('GW_GPS', False)==True):

This needs to be changed to:

if(os.getenv('GW_GPS', 'false').lower()=='true'):

GPS needs to be set to 9600 bps, 8n1. For non ublox ver.7 modules do not connect the RX of the GPS to TX of RPi.

The PPS output of the GPS should be connected to pin 19 of the iC880a.

EDIT: corrected line number.

(Marssystems) #26

OK - sounds good. I'll try it now.

A small fix to run.py will be as well required, line 308 now reads:

My run.py only goes up to 305 and there is no code which resembles if(os.getenv('GW_GPS', False)==True):

I'm running this build of the gateway - https://github.com/jpmeijers/ttn-resin-gateway-rpi

I'll let you know how it goes soon.

(Jac Kersing) #27

Line number is 169 in your file. Without that fix the software will not attempt to access your GPS.

(Marssystems) #28

Sorry - yes it is - found it. Its 1 o 'clock in the morning - need some kip :sleeping: :sleeping: :sleeping:

(Marssystems) #29

YEP!! - Excellent! - works a treat!

11.06.17 00:09:07 (+0000) ##### 2017-06-11 00:09:07 GMT #####
11.06.17 00:09:07 (+0000) ### [UPSTREAM] ###
11.06.17 00:09:07 (+0000) # RF packets received by concentrator: 0
11.06.17 00:09:07 (+0000) # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
11.06.17 00:09:07 (+0000) # RF packets forwarded: 0 (0 bytes)
11.06.17 00:09:07 (+0000) # PUSH_DATA datagrams sent: 0 (0 bytes)
11.06.17 00:09:07 (+0000) # PUSH_DATA acknowledged: 0.00%
11.06.17 00:09:07 (+0000) ### [DOWNSTREAM] ###
11.06.17 00:09:07 (+0000) # PULL_DATA sent: 0 (0.00% acknowledged)
11.06.17 00:09:07 (+0000) # PULL_RESP(onse) datagrams received: 0 (0 bytes)
11.06.17 00:09:07 (+0000) # RF packets sent to concentrator: 0 (0 bytes)
11.06.17 00:09:07 (+0000) # TX errors: 0
11.06.17 00:09:07 (+0000) ### BEACON IS DISABLED!
11.06.17 00:09:07 (+0000) ### [JIT] ###
11.06.17 00:09:07 (+0000) # INFO: JIT queue contains 0 packets.
11.06.17 00:09:07 (+0000) # INFO: JIT queue contains 0 beacons.
11.06.17 00:09:07 (+0000) ### [GPS] ###
11.06.17 00:09:07 (+0000) # Valid gps time reference (age: 0 sec)
11.06.17 00:09:07 (+0000) # System GPS coordinates: latitude 53.44995, longitude -2.27440, altitude 16 m
11.06.17 00:09:07 (+0000) ### [PERFORMANCE] ###
11.06.17 00:09:07 (+0000) # Upstream radio packet quality: 0.00%.
11.06.17 00:09:07 (+0000) # Semtech status report send.
11.06.17 00:09:07 (+0000) ##### END #####
11.06.17 00:09:07 (+0000) INFO: [status] TTN send status success

Thanks very much for all your help.
:joy: :ok_hand:

(Marssystems) #30


I've attached the PPS output from my Adafruit GPS module to pin 19 of the ic880a board but I'm still seeing that the Beacon is disabled, in the log. Do I need to connect the PPS output to a GPIO pin on the RPi3 to enable the beacon?

Thanks in advance.

(Jac Kersing) #31

No. I urged you to connect PPS as it provides better time stamping of received packets.

Beacons are for Class B devices. As
1) TTN currently does not support Class B (or Class C)
2) I haven't found any Class B (or Class C) devices available yet,
I did not invest time yet to refactor the required code out of the Semtech protocol stack. (Class B and C are on the roadmap so I will probably look at it in due time, commercial projects have priority right now, TTN has become a money sink over the last year and half so I would like to have a bit of the 'LoRaWAN pie' as well)

If you really want beacons at this moment you will need to connect the packet forwarder to a back-end using the Semtech protocol (the Semtech site is a candidate) and also enable beacons in the configuration.
Keep in mind enabling beacons means the gateway will be sending more often and the current generation of gateways do not listen while transmitting so you are more likely to miss transmissions from nodes.

(Marssystems) #32

Thanks for the explanation @kersing. I now understand.

So it looks like my first gateway is now fully operational :grin: . All I need to do now is put it in a box and release it into the wild for it to do it's 'thing'.

(Kalon33) #33


GPS needs to be set to 9600 bps, 8n1. For non ublox ver.7 modules do not connect the RX of the GPS to TX of RPi.

Is that what happen out of the box? I just soldered a ublox GPS module on my RisingHF board where it was planned to be, along with the proper SMA connector.

I’m wondering if I need to do this. And when you say “For non ublox ver. 7 modules” is that all non ublox ver. 7, or only ver. 7 and newer, or ver. 7 or older? I have a MAX-8Q there.

Thanks for your help.

(Kalon33) #34

Dear all,

For now I use a USB connected GPS, that is accessible as /dev/ttyACM0, until I can properly access my soldered GPS module from my RisingHF board (from the IOT discovery kit). Unfortunately, I got these kind of messages:

09.01.18 21:09:44 (+0100) ### [GPS] ###
09.01.18 21:09:44 (+0100) # Invalid gps time reference (age: 1515528584 sec)
09.01.18 21:09:44 (+0100) # System GPS coordinates: latitude 48.69460, longitude 2.29808, altitude 45 m

Why is the time reference invalid when I got proper System GPS coordinates (that got refreshed at each log update)?

(Bsiege) #35

Unix epoch. Your system boot with date 1.1.1970 and somehow you do not sync system time to gps time.


(Kalon33) #36

How can I fix this? I use a resin.io container (from jpmeijers)

(Kalon33) #37

I just checked a date -R and correct time is returned…

(Bsiege) #38

No idea. sorry. Try to check from where the time reference comes. Since GPS have coordinates and hwclock is adjusted it must be another counter. (Epoch+Uptime)Proof

(Kalon33) #39

@jpmeijers @kersing an idea about this problem?

(Bsiege) #40

github I think you still use fake gps…