I’ve just built my first gateway using a Raspberry Pi 3 and a ic880a board.
I want to connect a GPS module to the system as my ic880a doesn’t have the GPS chip installed.
I have connected a Ublox N8M module to the UART on RPi3 but the software doesn’t see it.
Has anyone managed to do something similar and got it working?
Do I need to configure anything manually to get this going?
I’m using resin.io to build and install the software so its not possible to do any ‘normal’ Linux commands on the RPi3.
When you click on your device in resin.io dashboard there is a terminal you can start in the left hand side options. How useful it is, I don’t know, but I suspect it will let you do whatever you need.
It’s important to separate the host OS which is a fairly bare system with just enough to start the resin.io agent, and the OS inside your container, which is by default some flavour of Debian, or whatever you specify in your Dockerfile. We currently use Yocto Linux as the framework to generate host OS. However, the operation of the host OS should be reasonably transparent for the users. What really matters is the OS within the container, called the “Base OS”. This OS shares the kernel of the Host, but otherwise has its own way of working and with resin.io the users can specify what Base OS their applications use by pointing to an existing Docker image, as long as that image is compatible with their target architecture, of course. The application container runs in privileged mode and has direct access to the hardware. In fact, it can even be used to inject modules into the kernel. Resin’s agent runs in a separate container, which allows us to continue running even if your application crashes, and in this way we can continue to pull new code.
I am guessing the terminal connects you to the Base OS, allowing you to obtain the GPS data from the serial port. I am guessing the Base OS can access all the pins through the Yocto Host OS.
The documentation of the ic880a SPI writes that an optional GPS module can be installed on that board. https://wireless-solutions.de/products/long-range-radio/ic880a
That line looks for a environment variable named GW_GPS_PORT (that might even be mentioned in the documentation). Just add another environment variable with the correct value to the resin settings and you are done.
Keep in mind the Raspberry Pi 3 has two serial ports and /dev/ttyAMA0 is connected to the bluetooth part by default, not to the serial port! (Check the resin forum for details on how to solve this)
The call to getenv( key, default) that you mention, gets the key from the environment setting GW_GPS_PORT. But if you did not configure that, then it uses the hard-coded serial.
When I read the source of the run.py that is mentioned, I see that this script reads configuration data and writes out a local configuration 'local_conf.json'. So when running it, line 170 prints that the file will be configured for a real gps, and lines 171-173 are configured in the json.
Also, it reads your configuration data from your TTN account on line 94, then on line 121 it checks the online configured gps position which is then printed on line 138-140. So that position is not read from your real GPS yet.
On line 303 the forwarder is started, and I guess this process will use the GPS device.
Yes - it all seems a bit ‘backwards’ to me. If you have GW_GPS set to true, the code shouldn’t go to the TTN account for configuration data but just wait for the GPS to supply it.
I have now moved the GPS module from the software UART1 to the hardware UART0. I thought that the software expected it to be there (as per RPi2B) but no luck.
I can’t find what mechanism the gateway software uses to actually read and use the GPS data. I have gpsd installed and it works fine.
If you check the output of the packet forwarder you should see it tries to open the tty specified to access the GPS. It does not use gpsd and if gpsd opens the tty the packet forwarder may not be able to. I would remove/disable gpsd and check the output produced at the start of the packet forwarder…
I will certainly try that - but before I installed gpsd, to check if the GPS module was actually working, the tty ports were free (only connected to the GPS module) and the packet forwarder couldn’t see/use the GPS module.
That means it won’t access the GPS. My updated container is looking for the GPS but something else is wrong so please bear with me for a day while I debug…
@marssystems
I’ve found an issue in the packet forwarder that requires fixing with regards to GPS. Hoping to find the time to fix it before the weekend.
