Helium Based DIY GPS Vehicle Tracker With RYS8839 and RYLR993 and ESP32

I was recently testing the Reyax RYS8839 GPS module, and I wanted to combine it with the Reyax RYLR993 LoRa module, which has the capability to communicate via the Helium Network. This powerful combination allows us to create a device that not only pinpoints GPS locations but also transmits that data through the Helium Network directly to a Google spreadsheet—with absolutely no need for traditional internet or GSM connections.

I wanted to experiment with the Helium Network ever since I learned from a friend that Helium, already has coverage in my area. Curiosity piqued my interest: why wasn't this resource used more widely? I had to find out for myself, and thus this GPS tracker project was born. Everything is controlled by an ESP32 due to its reliable serial communication, as it outperformed the microcontroller unit (MCU) I usually work with.

Before we continue into the details of the project, I want to extend my gratitude to Reyax for providing the LoRa and GPS modules for this project. In addition, a shoutout to PCBWay, whose fast PCB manufacturing services and shared project section are invaluable to makers like me. They are supporting this project, and by checking out the links, you too can access their resources and even get a $5 welcoming bonus.

Read on to get all the details, and remember, your ideas and feedback are crucial for shaping future projects, so don't hesitate to drop a comment!

You can find the RYS8839 GPS module on the links below:

Website link: https://reyax.com/products/RYS8839

Amazon link: https://www.amazon.com/s?i=merchant-items&me=A2M9CC26G0VWTA

First Components srl link: info@first-components.com

https://first-components.com/en/rys8833

REYAX RYLR993_Lite module - https://reyax.com/products/RYLR993_Lite

https://first-components.com/en/rylr993_lite

You can support me and the channel by buying from the links below at no additional cost to you!

• ESP32 Development Board - https://s.click.aliexpress.com/e/_oFmrM7t
• NodeMCU Development Board - https://s.click.aliexpress.com/e/_oEKPd4X
• D1 Mini ESP8266 - https://s.click.aliexpress.com/e/_mtJeFHI
• Mini PC for Home Assistant - https://s.click.aliexpress.com/e/_msrHCog
• LILIGO LoRa Development board - https://s.click.aliexpress.com/e/_DeXZ7Zz
• ESP32 LoRaWAN Gateway - https://s.click.aliexpress.com/e/_DCP4OYB
• TTGO LoRa32 - https://s.click.aliexpress.com/e/_DlAGfrp
• Soldering Station - https://s.click.aliexpress.com/e/_EzQ4Aab
• Screwdriver Set - https://s.click.aliexpress.com/e/_DFvd9Jd
• Repair Toolkit - https://s.click.aliexpress.com/e/_DBnunr5
• Soldering Mat - https://s.click.aliexpress.com/e/_DchreR1
• Multimeter - https://s.click.aliexpress.com/e/_DkGtZpt
• Mini Breadboards - https://s.click.aliexpress.com/e/_DE16dRN

The greatest device strength is its ability to use the Helium Network to transmit GPS data without traditional internet connectivity. Here's how it works: At the heart of the system, you've got an ESP32, a robust microcontroller that's perfect for handling multiple types of serial communication. Initially, I tried a NodeMCU but I faced issues with the simultaneous serial communication required for both the GPS and LoRa modules, which led to the switch to the ESP32.

Upon booting up, the ESP32 initializes the process by attempting to join the Helium Network, which is the LoRa (Long Range) network in focus. Once successfully joined, the GPS module comes into play, initializing and starting to collect satellite data to derive a positional fix. We bring a level shifter into the equation to bridge the voltage gap between the GPS module, which operates at a low 1.8 volts, and the ESP32 which works at 3.3V. It adapts the voltage levels appropriately for seamless communication.

The GPS data is refreshed every 3 seconds, and I added logic within the ESP32 to check if there’s been significant movement—specifically more than 10 meters. If the device has moved beyond this threshold, it sends the new GPS data through the LoRa module over the Helium Network. At the other end, within the Helium Console, we have a decoding function that translates the bytes received from the LoRa transmission into readable latitude, longitude, and altitude data, which is then logged into a Google spreadsheet.

The data from the spreadsheet can then be used to generate paths and KML files to be shown on a map or analyzed in any other way.

The Helium Network is a pioneering approach to wireless communication, specially designed for Internet of Things (IoT) devices. Unlike conventional networks, which rely on a centralized infrastructure owned by major corporations, Helium is decentralized and built on blockchain technology. This means that the network is powered by a vast array of independent hotspots rather than centrally placed cell towers.

Operating on LoRaWAN (Long Range Wide Area Network), the Helium Network provides low power, long-range communication capabilities that are perfect for IoT devices that need to send small amounts of data over long distances. Because of its unique decentralized model, anyone can add a hotspot to extend the network's coverage and even earn cryptocurrency (Helium tokens) as a reward for contributing to the network's infrastructure.

The project is not sponsored in any way by Helium. I simply wanted to test it out myself given that it is already available in my area. It’s a cost-effective solution for many IoT applications, be it tracking devices, environmental monitoring, smart city systems, or agricultural sensors. Given its relatively low cost and ease of deployment, I'll use it more in future projects.

In this project, we've got two key modules: the RYS8839 GPS tracker module and the RYLR993 LoRa module. Wiring them together with the ESP32 requires a bit of finesse due to the different voltage levels they operate at.

The GPS module, which operates at a lower voltage of just 1.8 volts, can't be connected directly to the ESP32 because the latter typically communicates at 3.3 volts. To work around this, we use a level shifter (RYLS135) which serves as a voltage translator, bridging the communication between the ESP32 and the GPS module safely.

I have a tutorial on how you can make such a level shifter that you can check out.

The GPS module's TX and RX lines are linked through the level shifter to the ESP32's hardware serial ports, specifically to pins D22 and D23. This allows for a robust, stable serial data exchange between the GPS module and the ESP32.

The LoRa module, on the other hand, communicates at a baud rate different from the GPS module. The LoRa module is connected to the ESP32's pins D15 (TX of LoRa) and D4 (RX of LoRa), using what's known as a software serial—a method to allow serial communication on other GPIO pins through software emulation.

In addition to the data lines, there's a power connection. The ESP32 provides 3.3 volts output, which is used to power both the GPS module and the LoRa module. Despite the GPS module's 1.8V logic level for communication, it can still accept 3.3V as its supply voltage thanks to onboard voltage regulators.

Antennas are crucial for both of these modules to communicate effectively. For the GPS module to lock on to satellite signals and for the LoRa module to communicate over the Helium Network, each of them is outfitted with its respective antenna.

The 1.8V source comes from the level shifter module, which is powered by the Vin and GND pins on the ESP32 board. To have a stable voltage reference, all GND pins must be connected together in all of the boards.

The code at the heart of this project orchestrates the communication between the modules and the Helium Network.

First off, we initialize our ESP32's serial ports to listen for data from both the GPS module and the LoRa module. We use two different serial interfaces—one hardware serial for the high-speed communication with the GPS module and one software serial for the LoRa module due to its lower baud rate communication.

Once the device powers up, the ESP32 sends a 'join' command to the LoRa module to connect to the Helium Network. After a successful handshake with the network, we then wake up the GPS module and begin collecting satellite data for our position.

A piece of logic checks if there's been significant movement (greater than 10 meters from the last known position) before deciding to send a new set of GPS data via LoRa. We do this to conserve network data usage and only send meaningful updates. 

The actual data packets sent over LoRa are compact and adhere to the Cayenne Low Power Payload (Cayenne LPP) protocol, which is designed specifically for sending concise packets of sensor data across a LoRa network, making it highly suitable for our GPS data.

I go into much more detail about the code line by line in the project video so be sure to check it out.

The full code is available on my website article.

Once the GPS data is captured, processed, and sent by the LoRa module, it arrives at the Helium network's backend. Here, it undergoes decoding to extract the raw latitude, longitude, and altitude readings from the bytes received. That decoded data is then neatly piped into a Google spreadsheet using a custom integration, allowing for easy visualization and analysis.

The main piece here is the decoding function that converts the bytes sent by the device into strings that are then stored in the Google Spreadsheet. The function is entirely available on my website.

To put this GPS and LoRa tracking device to the test, I embarked on a practical road test. The setup was simple. I placed the GPS antenna on the dashboard and the tracker itself centrally above the console within the car. To my delight, the antenna proved to be powerful enough to work effectively from inside the vehicle—no need to mount it externally.

I powered up the entire system, and the ESP32 sprang into action, attempting to establish a connection with the Helium Network. After a few hiccups—and a demonstration of the retry logic baked into the code—the device successfully connected. With the Helium Network handshake out of the way, the GPS module began to actively fetch satellite data to determine my starting position.

During my drive, the device was constantly evaluating whether the movement exceeded the predefined 10-meter threshold. Whenever this condition was met, it sent an update over LoRa to the Helium Network, which was then logged into our data endpoint, the Google spreadsheet.

Monitoring the incoming data was crucial, so I kept an eye on the serial communication through the Arduino IDE. Some 'busy errors' initially emerged, indicating that I might be sending updates too fast for LoRa's duty cycle limitations. Adjusting on the fly, I implemented a fix by disabling the duty cycle checks, thus enabling continuous data flow once more.

As I navigated around the city, the tracker efficiently logged each key point. The varying distances between these points on the route painted a picture of my driving speed and stops, exemplified by the data during a wait at a traffic light and subsequent movement.

Once the test drive was complete and the data was safely stored in the Google sheet, I could then transform this raw data into a more visual form—a KML file. This file conveniently illustrated the path traveled during the testing phase on mapping software, providing a graphical representation of the journey and the effectiveness of the tracker.

The road test wasn't just a practical demonstration of how to track GPS coordinates; it was a real-world stress test of the entire system—from the reliability of the antenna inside a vehicle to the efficiency of the code in respecting network limitations and handling data transmission. It proved without a doubt that the GPS tracker coupled with the Helium Network was not only functional but also capable of capturing and transmitting valuable location data effectively.

In the spirit of constant improvement and innovation, there's always room to refine and expand. Moving forward, the next steps for this project could involve integrating the data into a live dashboard for real-time tracking, perhaps using a platform like Home Assistant. This would not only give a dynamic interface but could also enable automation based on location data

Moreover, feedback and ideas from the community are invaluable and could shape future iterations of this project. Suggestions for features, improvements, or even entirely new use cases could lead to further explorations and developments.

For those curious to try this out for themselves, I'll be providing the code on the related website article, where you can use it to potentially customize your version.

Stay tuned for more tech tinkering, experiments, and compelling projects in the future. Cheers, and happy building!

https://youtube.com/tastethecode