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.

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.

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.