Adding a GPS Receiver to the iC880A LoRaWAN concentrator

Hardware setup

The iC880A is a popular PCB for creating a multichannel LoRaWAN base station.  It is supplied with pads for the addition of a u-blox LEA-6T.  As well as adding the GPS receiver module several other components have to be added including a power supply, USB connector and associated passives / TVS protection diodes.

IMST iC880A prior to the GPS module and associated components being added.

IMST iC880A with ublox GPS soldered on and SAW-filter bypassed

However, following the instructions provided produces a system that enable communication with the GPS receiver but is unable to receive any satellite signal. This is due to a couple of problems, in order to debug these the Hardware Integration Manual for the LEA-6T is needed.

The first stage of the debugging was to identify that the active antenna connected to the SMA was not receiving power.  Whilst debugging this stage it was confirmed it was an aerial problem as when probing for DC voltage on the antenna connector the multi-meter probes were acting as antenna enabling signal to be received and a lock to be obtained.

 

LEA-6x antenna circuit design from https://www.u-blox.com/sites/default/files/products/documents/LEA-NEO-MAX-6_HIM_(UBX-14054794).pdf

The first problem is in the power supply circuit for the active antenna. R_BIAS (R959) is the recommended 10 Ohms, however, there also appears to be R958 connected to the V_ANT pin. R958 is a 0 Ohm resistor to ground meaning V_ANT is now tied to 0V and therefore unable to power the active antenna. Upon removal of R958, it was possible to observe 3V at the RF pin suitable for powering an LNA as part of the antenna. However, the antenna was still receiving satellite signals.

This led to the diagnosis of a further problem the instructions from IMST have a IC (U950) between RF_IN on the receiver and the SMA connector on the PCB.  This component is a SF1186K-3, which is a SAW Filter, which is designed to only pass the required frequency, thus improving noise rejection.  This, chip also blocks DC (Minimum 35dB rejection) meaning the antenna does not receive power.  As can be seen from the integration manual, the receiver does not require this filter, so it was remove and bypassed (visible in the bottom right of the second photo).  Having completed this modification the GPS receiver is now able to receive the satellite signal and get a position lock.  This was tested using the u-centre software available from u-blox connected via USB.

Finally the GPS serial output is connected to the Pi onboard serial port.  This can either be done using jumper leads.  For development we are using the Raspberry PI iC880A Lora Concentrator Gateway Shield, however, this doesn’t have these ports connected, so patch wire was used to connect the required pins.

Software Setup

Now the GPS is able to communicate both with the Pi and satellites a bit of software configuration is needed.  The Pi is now connected to UART1 of the GPS receiver needs configuration.  This can be done in u-centre, view -> configuration).   Before leaving a page you need to click send to actually tell the GPS unit about the change.

The first things is to enable NMEA output on the serial port connected to the Pi.  This is under the ‘PRT’ section. UART1 should be set to NMEA out @ baudrate 9600.

The GPS module is now sending lots of NMEA messages to the Pi, most of which are ignored by the LoRa gateway.  The only messages that the code parses match $G?RMC & $G?GGA.  All other messages can be turned off using the ‘MSG’ section of the configuration.

Having made the changes to the configuration these need to be made persistent.  Go to ‘CFG’, make sure “save current configuration” is selected and then click send.  These changes should now persist.

Make sure that the serial port is enabled on the Rapsberry Pi using raspi-config.  Do not enable a console on the serial port.

Finally change the local_config.json to enable the GPS receiver.  The configuration used on the node used for testing is

    "gateway_conf": {
    "gateway_ID": "B827EBFFFEXXXXXX",
    "servers": [
        {
            "server_address": "router.eu.thethings.network",
            "serv_port_up": 1700,
            "serv_port_down": 1700,
            "serv_enabled": true
        }
    ],
    "gps_tty_path": "/dev/serial0",
    "contact_email": "test@example.com",
    "description": "GPS-test-node",
    "fake_gps": false,
    "forward_crc_valid": true,
    "forward_crc_error": false,
    "forward_crc_disabled": true
    }
}

 

Testing

Due to the poor quality of GPS signal available in my office and in the (basement) electronics lab testing has had to wait until the weather has been good enough to spend some time outside.  This has meant waiting rather longer than hoped, but that’s the British weather for you! When suitable weather did arrive I took the gateway and a client device outside and setup on a picnic bench outside the office.  On starting the poly_pkt_fwd script there was the usual output stream with some additional lines shown below.

INFO: Validation thread activated.
WARNING: [gps] GPS out of sync, keeping previous time reference
WARNING: [gps] GPS out of sync, keeping previous time reference
INFO: [down] for server router.eu.thethings.network PULL_ACK received in 299 ms
INFO: [down] for server router.eu.thethings.network PULL_ACK received in 82 ms
INFO: [down] for server router.eu.thethings.network PULL_ACK received in 93 ms

##### 2017-08-01 17:06:10 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 0 (0 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
### [GPS] ###
# Valid gps time reference (age: 1 sec)
# System GPS coordinates: latitude 50.93680, longitude -1.40584, altitude 69 m
##### END #####

As can be seen at first start up the GPS receiver hadn’t yet got a decent lock so the forwarder ignore the data that it was receiving from the device and kept going with the time the device had from NTP. Shortly afterwards it can be seen that the GPS had achieved a lock and was being used as the time reference.

I am confused by one aspect of the behaviour of the system, and that is the transmission of beacons. In the global_conf file the transmission of beacons is disabled. This is confirmed by the following line in the logs.

INFO: Beacon is disabled

However, it would appear that the device still tries to send a beacon.

NOTE: [down] beacon ready to send (frequency 0 Hz)
--- Beacon payload ---
0xEE - 0xFF - 0xC0 - 0x00 - 0x00 - 0x00 - 0x00 - 0x84
0x00 - 0x80 - 0xA1 - 0x91 - 0x59 - 0x38 - 0x0E - 0x1C
0x8C - 0x00 - 0x00 - 0x00 - 0x00 - 0x00 - 0x00 - 0x00
--- end of payload ---
WARNING: [down] beacon was scheduled but failed to TX

Further testing was carried out and it was identified that the PPS output of the u-blox module was not actually connected to the PPS line used by the transceiver (and available on the header). The failure of transmission was because the expected rising edge never arrived rather than anything with the actual transmission going wrong. On the iC880A PCB there is a test pad available by the timepulse output of the u-blox module. So it was a simple matter of linking the two together. Having done this it was tested again and it worked giving the following output when transmitting a beacon.

NOTE: [down] beacon ready to send (frequency 0 Hz)
--- Beacon payload ---
0xEE - 0xFF - 0xC0 - 0x00 - 0x00 - 0x00 - 0x00 - 0x84
0x00 - 0x80 - 0x62 - 0x94 - 0x59 - 0x38 - 0x0E - 0x1C
0x8C - 0x00 - 0x00 - 0x00 - 0x00 - 0x00 - 0x00 - 0x00
--- end of payload ---
NOTE: [down] beacon sent successfully

Although why it is transmitting a beacon with the flag set to false is still a mystery to me.

I’m lucky in that I have experience working with 0402 components which meant soldering on the passives was a feasbile proposition, and the uBlox module itself is a reasonable size for hand soldering. However, the SAW filter was beyond my abilities (many thanks to my colleague Graeme Bragg for his help with this.) so the fact it is not needed reduces the complexity of this modification considerably. Even so it’s not something I would recommend people without experience of hand soldering 0402 components tries. Which got us thinking there must be an easier way to add GPS receivers onto this iC880A concentrator boards. More to follow.


7 thoughts on “Adding a GPS Receiver to the iC880A LoRaWAN concentrator

  1. Hi,

    I contacted IMST support who emailed me the required document. I suggest you do the same as I’m not sure if they’d be happy with me sharing it.

  2. Hi Phil,
    I’ve contacted IMST as you recomm but no answer so far. Pls could you send me supporting documents? It helps me a lot.
    many thanks

    1. Hi Marek, as stated above I’m not sure if they are happy with me sharing the documents so am unable to forward them on to you.

  3. Hi Phil,
    I’ve finally got a schematic from IMST. I’m clear about active antenna problem (omitting SAW filter and some R and dummy C around it). But still have few more questions:

    1) Do you use the USB port on LEA only for programming in u-centre sw or also for sending NMEA MSGs (connected to RPI USB port)?

    2) Is GPS setting permanent even reset power supply?

    3) Have you deal with switching a TIMING mode in LEA? (has a better time accuracy)

    4) NMEA MSGs go via UART directly from LEA module (pin 3 Tx and 4 Rx) to RPI UART (pin 8+10, GPIO 14+15)?

    5) What about PPS signal? Since I’ve been using an external GPS module with iC880 and Raspberry, I connect the PPS signal from external GPS board to the pin19 iC880.

    IMTS send me for PPS following recomm:
    “For PPS purposes, there are 3 important resistors:
    * R100 (typically not fitted) connects LEA-6 TimePulse2 Output to SX1280 GPS PPS input
    * R101 (typically not fitted) connects LEA-6 TimePulse1 Output to SX1280 GPS PPS input
    * R306 (typically fitted by 100R) connects external PPS (module pin 19 or via typically not fitted U.FL connector) to SX1280 GPS PPS input

    Basically, all resistors can be fitted at the same time, but in this case you need to pay attention to avoid signal collisions. Thus we recommend to remove not required resistors and fit only one for your purposes.”

    1. Hi Marek,

      Glad to hear you’ve got the schematics and data needed from iMST, it sounds like you got more information from them than I did, although I never asked about the PPS issue – just worked around it.

      1) I used the USB port for programming only using u-centre. I have a board between the Pi and the iC880a which connects the GPS serial pins from to the hardware serial port on the Pi.

      2) I think I had to save the settings to non-volatile memory there was an option for it in u-centre.

      3) I’m afraid I can’t remember that one, I suspect if I knew about the timing mode I tried setting it.

      4) Yes NMEA messages go straight through the UART, there are options in u-centre to determine which type of messages get sent to which serial/ usb port.

      5) As I didn’t know about the resistor options I just used a bit of jumper wire between the ublox pin and pin 19 on the header. This also means the PPS goes to the Pi so can be used for ntp purposes. I think there’s options in u-centre to configure what you want the timepulse outputs to do as well. Once u-centre is connected it gives you a lot of control.

      Good luck, and I’d be interested to hear more about how you get on.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.