kersing / lora_gateway Goto Github PK

I am using the RisingHF SX1301 board from Seeed at this URL https://www.seeedstudio.com/LoRa-LoRaWAN-Gateway-915MHz-for-Raspberry-Pi-3.html.

It does not come with a GPS module so I purchased one thinking I was going to get a u-blox8 chip, however I didn't, it is a GE-A103 from Taiwan. I soldered it on the board and the PPS also is working correctly.

http://www.navisys.com.tw/products/SiRF_CSR_GPS_GNSS%20module/flyer/GE-A103_flyer-150429.pdf#search=%27GEA103%27
http://aitendo3.sakura.ne.jp/aitendo_data/product_img/gps/GE-A103/GE-A103_DS-161004.pdf

For some reason I keep losing the serial port so I added a bad tweak, and hopefully someone can come up with something better. Without the reconnect tweak "WARNING: [gps] read() returned value 0" is spammed on the terminal window and the GPS serial (/dev/ttyS0) is never reconnected.

Sorry I am not the greatest with git but this is what I changed.
in packet_forwarder/mp_pkt_fwd/src/mp_pkt_fwd.c

line 1922
`
void thread_gps(void) {
/* serial variables /
char serial_buff[128]; / buffer to receive GPS data /
size_t wr_idx = 0; / pointer to end of chars in buffer */

/* variables for PPM pulse GPS synchronization */
enum gps_msg latest_msg; /* keep track of latest NMEA message parsed */

/* initialize some variables before loop */
memset(serial_buff, 0, sizeof serial_buff);

while (!exit_sig && !quit_sig) {
    size_t rd_idx = 0;
    size_t frame_end_idx = 0;

    /* blocking non-canonical read on serial port */
    ssize_t nb_char = read(gps_tty_fd, serial_buff + wr_idx, LGW_GPS_MIN_MSG_SIZE);
    if (nb_char <= 0) {
        MSG("WARNING: [gps] read() returned value %ld\n", nb_char);
        MSG("WARNING; [gps] did we disconnect? attempting to reconnect...\n");
        lgw_gps_disable(gps_tty_handle);
        gps_tty_handle = lgw_gps_enable(gps_tty_path, "ubx7", 0, &gps_tty_fd); /* HAL only supports u-blox 7 for now */
        continue;
    }
    wr_idx += (size_t)nb_char;

`

This made a change necessary to make the serial handle global so it is now defined at top as a global.
line 257
int gps_tty_handle;

line 1366
In function
int main(int argc, char *argv[]) /* Start GPS a.s.a.p., to allow it to lock */ if (gps_enabled == true) { if ((gps_fake_enable == false) && (gps_tty_path[0] != '\0')) { /* do not try to open GPS device if no path set */ gps_tty_handle = lgw_gps_enable(gps_tty_path, "ubx7", 0, &gps_tty_fd); /* HAL only supports u-blox 7 for now */ if (gps_tty_handle != LGW_GPS_SUCCESS) { MSG("WARNING: [main] impossible to open %s for GPS sync (check permissions)\n", gps_tty_path); gps_active = false; gps_ref_valid = false; } else { MSG("INFO: [main] TTY port %s open for GPS synchronization\n", gps_tty_path); gps_active = true; gps_ref_valid = false; } } else { gps_active = false; gps_ref_valid = false; } }

Sorry if the above formatting is not coming through, I tried to get it to display correctly.

The above was altered so the handle is available in another function to close it before reopening it.
This is sloppy, not sure what other effects the sleep(1) has because I didn't want it to spam reconnecting the serial port.

Sorry this is not organized better, but I wanted to get it posted for others to see and hope someone can come up with a less tacky fix to reconnect the GPS when it disconnects.

Hi all,
I am using multitech conduit ip67 gateway in a project. the firmware has been updated to MTCDT AEP 5.0.0 (unsigned) . my app is Nodered but it hangs occasionally. How can i do for this problem?

Would it be possible to add support for this gateway, and new chips? Current provided packet forwarder and LoRa libraries sources are provided in this rak2287.tar.gz file, but is semtech legacy packet forwarder based and it would be great to be able to use yours.

Thanks for your nice work on this code, that I already use for a risinghf based (I think a SX1276 based module) gateway.

@kersing
Firstly, thanx for nice sw.
However, I had considerable problems getting the Lora gateway running with the multi packet forwarder. A little looking around in the logs with various debugging on, showed the problem was in libloragw, source loragw_radio.c function lgw_setup_sx125x.
It almost always failed to lock the PLL. Fiddling around with different variants of RAK831 reset in the startup.sh didn’t help much either. Also, the displayed version registers were almost always different.
My setup is a Raspberry Pi 3B, with converter board without GPS and the RAK831 board, using Raspbian lite Stretch 4.14.71-v7.

The solution proved to be inserting a delay of 500 ms at the beginning of lgw_setup_sx125x:

/* Get version to identify SX1255/57 silicon revision */
wait_ms(500);
MSG("INFO: SX125x #%d version register returned 0x%02x\n", rf_chain, sx125x_read(rf_chain, 0x07));

and another in the locking loop at the end of lgw_setup_sx125x:

/* start and PLL lock /
do {
if (cpt_attempts >= PLL_LOCK_MAX_ATTEMPTS) {
DEBUG_PRINTF("ERROR: SX125x #%d FAILED TO LOCK PLL\n", rf_chain);
return -1;
}
wait_ms(100);
sx125x_write(rf_chain, 0x00, 1); / enable Xtal oscillator */

After this, it almost always starts with only one attempt to lock the PLL. And the printed version registers are much more stable, too, although still not entirely consistent.
Further tests also proved, that with this modification, it was possible to dispose with the hw reset code in startup.sh. It was only necessary to reset the hw after a Raspi reboot. But better safe than sorry, and keep the reset code in startup.sh.

This issue documents a problem report that first was reported on www.thethingsnetwork.org/forums: Latest MultiTech Packet Forwarder Stops Sending Packets.

The brief form: after updating to V3.0.0-r5 from V2.x, we observe hangs of the packet router code. Easiest way to detect this is to look at the timestamp on /var/log/lora-pkt-fwd.log:

root@mtcdt:~# ls -lrt /var/log/lora-pkt-fwd.log
-rw-r--r--    1 root     root        384148 Jun 19 12:31 /var/log/lora-pkt-fwd.log
root@mtcdt:~# date
Mon Jun 19 12:53:10 CST 2017

(Note the difference in time.)

The forum thread may describe additional issues; this thread only documents those observed by me. I have seen symptoms like this on other gateways, but only finally caught things in the act yesterday.

Status of the packet forwarder (from ps au) was:

  516 ?        Sl    34:01 /opt/lora/mp_pkt_fwd -c /var/config/lora -l /var/log/

I believe that the Sl flags are significant.

Restarting the packet forwarder does not clear the problem.

root@mtcdt:~# /etc/init.d/ttn-pkt-forwarder restart
Stopping ttn-packet-forwarder: OK
Found MTAC-LORA-915 with MTAC-LORA-1.0 hardware
Starting ttn-packet-forwarder: OK
root@mtcdt:~#

The relevant portion of /var/log/lora-packet-fwd.log (after the above restart) was:

INFO: [main] Starting the concentrator
lgw_connect:532: INFO: no FPGA detected or version not supported (v103)
Note: success connecting the concentrator
ERROR: SPI ERROR DURING REGISTER BURST READ
INFO: tx_start_delay=1497 (1497.000000) - (1497, bw_delay=0.000000, notch_delay=0.000000)

INFO: End of upstream thread
ERROR: SPI ERROR DURING REGISTER WRITE

Rebooting the Conduit with init 6 solved the problem.

During this hang, no traffic was forwarded upstream.

Both observed failures were correlated with downlink (join) traffic. (This application otherwise does not use downlink traffic, and there are no other known applications on the gateway.)

Gateway version info:

root@mtcdt:~# uname -a
Linux mtcdt 3.12.27 #1 Thu May 5 18:53:23 CDT 2016 armv5tejl GNU/Linux

The desperation workaround is to have a daemon watching the timestamp on the log, and if it becomes older than one or two minutes, to reboot the Conduit.