Hi,
I’m a software developer working in the cellular IoT space. My name is Matt. I’ve struck a deal with a reputable book publisher to write the first book on cellular connectivity in the IoT space. It’s a practical guide to the many challenges of establishing and maintaining cellular connectivity, especially for mobile systems moving in and between regions of poor connectivity. The book should be released in late 2024.
My company produces and sells SpotMyBus (see spotmybus.com), a system for tracking and managing fleets of school buses. Our customers are school districts and we serve districts in many states.
We designed and manufacture our own tracking device. It runs Linux (Ubuntu 20.04), and uses a hybrid keypad/text-to-speech user interface. When placed in “debug” mode, it calls out signal strength, MNO, and distance traveled since previous report every 10 seconds, while also calling out connections, disconnections, and connection progress (while trying to connect). It logs everything it speaks, and a whole lot more.
We also design and manufacture our own cellular modems. After designing a modem around a ublox module (SARA R410) that is unstable and unreliable, and getting absolutely no technical support (after having purchased a reel of modules) we threw in the towel on ublox and switched Quectel. We developed modems around their BG95/BG96/EG91 family of modules and have found their modules and support to be outstanding.
I have, for some time, wanted to be able to additionally report distance to connected cell tower. Theoretically, if I know the signal strength at Point A and the signal strength at Point B (and both points were registered on the same tower), and the distance between Point A and Point B, and the relationship between distance to tower and signal strength then I can calculate the distance from each of the points to the tower–assuming the tower and Point A and Point B are all points on a single line.
In practice, signal strength measurements frequently vary by 3 dBm (or more) from one reading to the next even when a device is stationary, so as a practical matter I that approach is not useful (I think).
Recently, I started poking around the Internet looking for exactly the kind of data provided by the OpenCellId project.
I downloaded the data for the US, massaged it a bit to discard fields I don’t need, reduce the records to 17 (binary) bytes per cell, and organize the data for quick disk-based lookups. The file is 85mb and fits on my tracker, so now it can do look-ups on-the-fly and call out distance-to-tower too (every 10 seconds).
I have a couple of questions:
- after reading various questions and comments regarding the “Range” values in the data, am I correct to understand that a Range of, say, 1000 means there is a 98% probability the actual cell tower location is inside a circle, centered on the estimated lat/lon, with a radius of 1000 meters?
Assuming–perhaps incorrectly–the answer to (1) is true:
- for many cells (~3 million), the Range values are “pretty small,” at 1000m, but for many the Range values are 10km or more. If the calculated distance from the tracker to the estimated cell location, is 1500 meters and the Range is 5000 meters, then all I really know is the tower is 0 - 6500 meters a way, and there is nothing useful to report.
Please note: I am not complaining. Rather, I am trying to understand the realities of using OpenCellId data, and thinking through approaches to improve Range values in the database.
Contributing Data
My trackers are on school buses. Half my customers are rural. It’s rural areas, I expect, where your data is most sparse and least precise. School buses go everywhere. Currently, my trackers log cell info every 10 seconds, but that is easily varied. My cellular modems use multi-SIMs which get access to ATT, T-Mobile and Verizon, so a single tracker can, theoretically, gather cell info for all three MNOs.
My trackers send location packets every 30 seconds which include some signal strength information. I am able to squeeze the packets into 18 bytes (payload) and use UDP to reduce packet overhead. The EG91 module has access to:
MCC
MNC
Radio Technology
TAC
Cell ID
RSSI
RSRP
RSRQ
SINR
srxlev (RX level value for Base Station)
Band
Bandwidth
I cannot send all of that data with each location packet, as it would greatly increase the packet size, but I could accumulate data on each tracker, analyze it periodically, and transfer a summary to one of our servers. The server could move the data to OpenCellId. For example, during a month, a tracker might collect many hundreds of samples for each cell it passes through. It could then perform the same sort of analysis OpenCellID performs on such data, and share the result for each cell, thereby reducing the the volume of data transferred by more than 99%.
I would be happy to discuss this matter if you folks are interested.
Regards,
Matt
1.757.277.4330
[email protected]