

In an ideal world, we would have the PPS signal from the GPS trigger a transmission from within the Interrupt Service Routine (ISR). I decided against the added hardware complexity and managed it all in software, using the Pulse Per Second output from the GPS in an interrupt routine to trigger the transmission. Small real-time-clock modules are available for around £1, which we could add to the Feather, initialise with the time from the GPS, then use a tight loop to reference the time and get the transmission to take place. So I need to come up with a way to accurately time the transmissions to fit in, say, a 1/3 second (333ms) transmit window, to give 3*60=180 possible devices per radio channel (or 90 devices at 30 second refresh rate etc).įudging millisecond Time Division Multiple Access in Arduino IDE C We have a fantastically precise "Pulse Per Second" (PPS) output from the GPS that will synchronise the start of every second across all devices.īut I want more than 60 devices. In its most simple form, we could have 60 devices, and each one transmits on their designated second-past-the-minute. We know some rough figures - we want position updates about once per minute, we want to support > 100 devices per RF channel, and one LoRa 'packet' takes ~ 280ms on-air (See the other project log entry for how these values were calculated). The obvious way I can think of is just to assign each device a timeslot - a number of milliseconds past the minute that each device should transmit. I need a way of synchronising multiple tracker units so their transmissions do not overlap. Tight loop() can give 10 microsecond TDMA time slots whilst still fetching and parsing GPS data. GPS Pulse-Per-Second drives hardware interrupt.
#RPI TRACCAR SOFTWARE#
, and reports to traccar software via OSMAND HTTP protocol (all done on loopback interface)
#RPI TRACCAR CODE#
Python code receives position and battery reports via the LoRa radio (For the HopeRf RFM98 lora module you have to adapt the DIO and SPI port definitions - instructions here:

#RPI TRACCAR OFFLINE#
Offline openstreetmap tiles are created with software and saved to the Pi See here for rough instructions (basically overwrite any reference to servers with your Pi tilestache server - editing the traccar.war file in ubuntu File Roller (archive manager) works quite well)
#RPI TRACCAR MOD#
The off-the-shelf tracking portal can accept our offline tilestache maps quite easily (need to define the custom map source in the Config section AND configure the user accounts to use the custom map source), but the litvak.su traccar-web mod required some butchering.

or any URL would work when connected to the Pi AP)Īpache2 on Pi gives some flexibility in redirecting http requests to localhost to our auto-logon guest URL Running modified 'traccar-web' UI to allow auto-login as guest on mobile devices:ĭnsmasq on Raspberry pi acts as DNS and DHCP server for connected clients.ĭnsmasq also catches all HTTP requests and redirects to localhost - end users just connect to the hostpot then browse to any (non-https) web address - good for catchy marketing! (e.g. Tracker server software configuration at 16:36.This way no internet connection is needed at any point for tracking, logging or displaying positions on a map. The Raspberry pi is set up as a WiFi hotspot with DHCP and DNS, and serves the GPS map server to any connected devices (mobile phones, tablets) as a captive portal. mbtile format are created beforehand using and Openstreetmap data overlayed with GPX trails of race route if required, and then stored on the Pi SD card. Openstreetmap tiles or other custom map tiles are downloaded to the Pi ahead of time, and served on the Pi via installed on the Pi. Open-source GPS tracker software or receives the reconstructed GPS position reports and displays on webpage map interface.

Python code on the Pi adapted from receives LoRa telemetry, formats and fowards it over loopback connection to GPS tracker server running on the same device. HopeRF RFM98W modem on uputronics shield is mounted on a Raspberry Pi.
