Issue: Having trouble using Bluetooth and GPS module.
Setup: RAK7244C purchased about a month ago from RAKWireless (WisGate Developer D4+ with Cellular module EG95-NA for North America) GPS antenna, Cell main and diversity antenna, and 915MHz LoRa antenna all installed (and confirmed to be working before changing things to get bluetooth to work).
Server: Built-in (with TTN active)
Details: In order to use bluetooth, we’ve changed /root/config.txt: changing dtoverlay from disable-bt to miniuart-bt, and separately enabled hciuart (which does allow bluetooth to work) but this appears to cause ttn-gateway to no longer be able to get valid GPS coordinates even after waiting several hours:
Dec 7 21:55:42 rak-gateway ttn-gateway[323]: # Invalid time reference (age: 1607378082 sec)
Dec 7 21:55:42 rak-gateway ttn-gateway[323]: # no valid GPS coordinates available yet
It will typically get valid GPS coordinates in the first couple of minutes when dtoverlay=disable-bt.
I’m having trouble finding which interface the Ublox Max7 module is actually connected over when dtoverlay=disable-bt (or miniuart-bt), as I get no output from cat /dev/ttyAMA0, while cat /dev/ttyS0 returns “Input/output error”. I understand there are some modifications made on the RAK2245 board made to allow connections to the cellular module to work when the system is ordered together (as a RAK7244C), but I can’t find what those modifications are exactly and which uart (or other comm port - i2c, SPI?) should be in use. I also see that some of the earlier builds of the LoRa/GPS module RAK2245 used an i2c port to connect the GPS to the pi but have instead switched to using a UART on newer builds.
Please let me know which comm channel of the Pi should be connected to the GPS module in this configuration, and any debugging steps that I can try to confirm whether or not they should still work after modifying the dtoverlay to allow bluetooth to work. Maybe there are some different or additional dtoverlays that I need to use in order to allow bluetooth and the GPS to work?
In my personal opinion, the limitations of the PI with regard to UARTs make this very difficult.
I could be wrong, but I suspect your path of least resistance might be to leave the pi’s bluetooth disabled, and instead pick up a cheap USB BLE dongle known to have good support in mainline Linux kernels.
Server: Built-in (with TTN active)
That’s confusing. You can only use one of the built in Chirpstack or TTN at a time. If you are using TTN, there’s not really any benefit in a GPS anyway (indeed, very few networks can really leverage one), so giving up the GPS might be an option, too.
In my humble opinion @cstratton might be right in this particular case. It is simply not worth the trouble over a cheap dongle. That is if it is not a must for some reason involving a particular project limitation.
Or swap things around, as the Bluetooth is well wired in to the Pi, use a half-decent GPS module on a USB lead that will present itself as the additional serial port we all know the Pi could really do with.
As for other GPS interfaces, one of the challenges with some of the U-Blox modules over SPI is that it is not entirely SPI compliant, so apart from any burden that may place on the concentrator’s interface, it’s an added complication. The code base we use for High Altitude Balloon trackers bit-bangs the SPI.
Thanks Chris and Nick,
For Server: What I really meant was that I’m using the stock firmware image that came with the RAK7244C, and I’m currently using the stock ttn-gateway application to see if the GPS is connected and working since it’s enabled by default and logging coordinates to the syslog (only when configured with dtoverlay=disable-bt).
You’re likely right that the easiest path would be to get a cheap bluetooth dongle and call this done. That being said - I’m trying to develop a relatively low power battery operated solution and adding a USB peripheral that already exists on board would be working slightly against my battery life (especially since I’m not using any other USB peripherals at the moment, and can turn the USB hub off for some significant power savings).
In order to really pull this off - I would like to better understand which PHYSICAL comm channels the RAK7244C is utilizing to communicate with
the GPS module on the RAK2245
the built in rpi bluetooth module
the cellular modem on the RAK2013
and the LoRa SX1301 module (which I’m pretty sure is unaffected by any uart configuration changes as it’s connected by SPI)
But I’m having trouble with this because I believe that the RAK2245 is physically modified (but I don’t know how) in order to make it work with the RAK2013 cellular modem as there is a note on the RAK7244C page: “Note that you can not add WisLink Cellular Pi HAT RAK2013 later and add it to WisGate Developer RAK7243/44 without modification of the RAK2245 board in the Gateway.”
You may be right that I could enable one of the additional uarts on the RPi 4, but first I need to understand which ones are actually in use to start, and which pins are physically connected over the rpi header, but I’m having trouble doing that especially because I don’t know which modifications were made to the RAK2245. Any troubleshooting steps that might be able to help clear that up that you could recommend? From digging around the forums here and elsewhere - I noticed that my /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/global_conf.json has gps_tty_path": "/dev/i2c-1" which I believe means that the ttn-gateway service is talking to the GPS module over the i2c-1 port of the RPi, but I’m not sure how to debug that to confirm it entirely. I ran i2cdetect -y 0 but did not return anything but ‘–’ on any address.
The documentation in the downloads section shows connections & schematics for both boards.
I’m not surprised that you find nothing on the I2C bus related to GPS because, as I made clear above, no one apart from the great DaveA has the chops to code such things on a Pi.
A Pi 4 based gateway with cellular modem is going to need some serious batteries. So I think saving power by not using a USB BLE dongle is a bit academic. But maybe it would be worth just doing that in the first instance, get the box (with it’s wheels) running and then refine …
Thanks Nick. You’re right that the effort I am going through now to save power consumption is largely academic. My entire project is academic in the sense that I am so far aiming for a proof of concept using off the shelf modules before generating a more custom integrated design. I’m confident that a USB BLE module would work, but I won’t have learned much before moving forward.
Do you know what the modifications are to the RAK2245 made when included in a RAK7244C assembly? I have not found any proposed modifications for this assembly in the downloads section so it’s hard to know what the physical truth is while I continue to iterate.
What I haven’t mentioned is that my next step will be to utilize an additional pi HAT that allows for periodic sleep and wake on the setup (to REALLY reduce battery consumption), and understanding which physical pins are in use in this setup (especially with the undocumented modifications on the RAK2245) will be important before attempting that.
I’ve got one so could potentially disassemble it. With a blank piece of paper and a couple of printouts I’m sure I could figure out the mods in terms of allowing the cellular & the gateway HAT to co-exist.
But your final reveal is just to bizarre to find the motivation to do it - a battery powered gateway that shuts down - how will your nodes know there’s no one to hear them transmitting?
This is sounding less and less like a job for a pi.
Probably you want to either use one of the compact OpenWrt platforms (eg, the old WisAP kit, now mostly seen in the form of the RAK7258) or even a real “embedded” type gateway solution based on a big MCU or ESP32 that will involve a fairly painful development process.
A gateway that “comes and goes” is also very disruptive to the operation of LoRaWAN network that includes other gateways, since adaptive data rate may no sooner adjust to leverage its presence, than it vanishes again, causing an hours to days of fallback with data loss before data flow from ADR nodes works via the surviving gateways.