GPS selection

[Kiogora]

Hi,

Great work you have done so far. I also wanted to try to create a gateway myself then I stumbled on your project. I have gone through the LoRaGW userspace C code and currently they use the Ublox GPS sensors as it outputs raw GPS time, not UTC. I have not yet confirmed what the GPS time is used for but your project has motivated me to check up on it later today. Do you have info on this?

As to my questions:

1. I have some Quectel L96 and L80 parts and the most they do is give UTC time. Did you have to change the codebase to accept the quectel version NMEA strings?
2. Any plans to do a PoE version? That would be something interesting and I would be willing to look into.

[will127534]

Hi Kiogora,
Answering the first one: No, I replace GPS module to MAX-7Q, see #5
Second one: Yes, I'm actually deploying some gateway in the wild, and find out that I really need POE to simplify wiring, building PoE sink board is definitely is on my todo list.
But I won't build PoE with this board, there is not much space for isolated dc-dc and a large PoE RJ45 connector. Two plans here, one is to build a new POE shield for RPI, the other one is using computer module or other SBC module like MT7688 to build a PoE capable RPI-like board or single board with SX1301. I'm still finding easier PoE solution to give it a try, before then, I'll use commercial PoE injector/isolator to power RPI Gateway.

Thanks for the compliment!

[Kiogora]

Thanks for the quick reply and clarification on the GPS chip.

I will go for an off the shelf solution also, for now as I chalk up a new design of a concentrator controller using the ESP32.It should be quick to port and test. I notice that you had two issues with your testing:

1. PLL lock and supposedly thermal issues. As a suggestion: You could try adding more via spaced at lambda/20 to the design to reduce the inductance on the board, especially near the RF sections that connects the ground planes. It may solve unforseen problems.

[piratfm]

With such a small patch, it's possible to use ATGM336H-5N11 cheap GPS-module, which is also supports UBX messages format, required by the gateway. The only requirement - is not to connect pin 7 (NC) to the power line.

diff --git a/libloragw/src/loragw_gps.c b/libloragw/src/loragw_gps.c
index c0e0ded..3fd40de 100644
--- a/libloragw/src/loragw_gps.c
+++ b/libloragw/src/loragw_gps.c
@@ -529,13 +529,14 @@ enum gps_msg lgw_parse_nmea(const char *serial_buff, int buff_size) {
     } else if (match_label(serial_buff, "$G?RMC", 6, '?')) {
         /*
         NMEA sentence format: $xxRMC,time,status,lat,NS,long,EW,spd,cog,date,mv,mvEW,posMode*cs<CR><LF>
-        Valid fix: $GPRMC,083559.34,A,4717.11437,N,00833.91522,E,0.004,77.52,091202,,,A*00
+        Valid fix: $GPRMC,083559.34, A,4717.11437,N,00833.91522,E,0.004,77.52, 091202,,,A*00
+                   $GPRMC,083559.34, A,4717.11437,N,00833.91522,E,0.004,77.52, 091202,,,A,V*11
         No fix: $GPRMC,,V,,,,,,,,,,N*00
         */
         memcpy(parser_buf, serial_buff, buff_size);
         parser_buf[buff_size] = '\0';
         nb_fields = str_chop(parser_buf, buff_size, ',', str_index, ARRAY_SIZE(str_index));
-        if (nb_fields != 13) {
+        if (nb_fields < 13 || nb_fields > 14) {
             DEBUG_MSG("Warning: invalid RMC sentence (number of fields)\n");
             return IGNORED;
         }

[mikini]

Nice, haven't seen the ATGM336H-5N GNSS module before.

It's supposedly LEA (possibly even NEO and MAX) series compatible, but if you experience failing NMEA output that seems odd. Unless the loragw parser is more restrictive than the NMEA protocol dictates. It is also my previous impression that the GPS time from the UBX protocol was important. Have you verified how it behaves when parsing the UBX-NAV-TIMEGPS packet?

Just dumping some info on the ATGM336H-5N here for reference;

• $9 on Tindie; https://www.tindie.com/products/ICStation/atgm336h-gps-bds-gnss-positioning-module12420/

• VoltLog; https://youtu.be/pfpyvJWgOqM?t=418
  He warns of differing constellation support of different chip variants, most I've seen was -31=GPS+BDS, -11 should be only GPS. The datasheet mentions also Galileo and QZSS support but it is not included in the product matrix. Allegedly it has a triple channel receiver.

• User Manual; http://www.icofchina.com/d/file/xiazai/2016-12-05/b5c57074f4b1fcc62ba8c7868548d18a.pdf

• It seems to be based on the generic GNSS chipset AT6558, datasheet; http://www.icofchina.com/d/file/xiazai/2016-12-05/b1be6f481cdf9d773b963ab30a2d11d8.pdf

• Info on some Western sites:
  https://www.robotics.org.za/NEO-M8N-MOD
  https://www.electrodragon.com/product/gnss-module-atgm336h/

The ATGM332D-5N also from Hangzhou ZhongKe Microelectronics seems completely identical except it is 50% physically larger which might be a nice tradeoff for easier hand soldering, datasheet; http://www.icofchina.com/d/file/xiazai/2018-01-08/3da2d50a6084c0e2570f2a3ecbdbcc11.pdf.

[piratfm]

Here is sample of log of ./test_loragw_gps:

Note: parsing UBX frame> b5 62 01 20 10 00 58 e1 b4 1b f6 ff ff ff ff 07 12 07 38 00 00 00 83 7c 24 47 

~~ UBX NAV-TIMEGPS sentence, triggering synchronization attempt ~~
    * Synchronization successful *
    UTC reference time: 1554455221.000000000
    GPS reference time: 1238490438.999999989
    Internal counter reference value: 5946088
    Clock error: 1.000000000
    * Test of timestamp counter <-> GPS value conversion *
    Test value: 6446088
    Conversion to GPS: 1238490439.499999989
    Converted back: 6446088 ==> 0µs
    * Test of timestamp counter <-> UTC value conversion *
    Test value: 6446088
    Conversion to UTC: 1554455221.500000000
    Converted back: 6446088 ==> 0µs

The gateway periodically (once per 30s) showing such info:

INFO: Disabling GPS mode for concentrator's counter...
INFO: host/sx1301 time offset=(1554455463s:612158µs) - drift=-3µs
INFO: Enabling GPS mode for concentrator's counter.

Also it's still giving me some warnings about out-of-sync sometimes, after long time of work, but that might be bad TXCO.