search

will127534 / LoRa-concentrator

A simple Board for SX1301 and SX125X LoRa Gateway / Concentrator
MIT License
340 stars 123 forks source link

GPS selection #12

Open Kiogora opened 6 years ago

Kiogora commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

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;

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 commented 5 years ago

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.