GT06 protocol "compression"?
Can you provide some context on why you need it?
Disclaimer: I haven't purchased or implemented anything yet... just reading and thinking about system design.
Generally this would be to reduce the amount of data transmitted over time and reduce cellular billing costs. I guess it doesn't need to be related to GT06 per se, as it could be implemented in other protocols.
How are you planning to implement it on the device side? Do you have access to the firmware?
I was hoping something like this was already implemented in an existing device, and would just be a configuration option.
But if not, and there was an open source tracker, perhaps I would tinker with it.
Any guess what % reduction would be attainable in theory? If only the "necessary" data was transmitted? Also seems no reason to transmit N/S E/W for vehicles that will never cross hemispheres.
There are some devices that do have some compression options. Don't remember off the top of my head, but you can probably look through the code to find which protocols support it.
For open source device you can use this:
https://www.traccar.org/freematics/
But I'm still not sure why you would need this extreme compression. The amount of data used by devices is pretty small as is.
@Cory
I wonder how much data you think a tracker actually uses per month?
Simple trackers that sent Link keep message every 7 minutes and report the position every 10 minutes consume less then 30 mb of data per month.
Thats about 30 dollarcent per month for data cost.
Thanks Anton!
@Track-trace,
I was thinking about live position updates for things like buses, and especially if the updates were something like every 10 seconds. Updates once a minute or every 30 seconds would probably be adequate, but more finely grained data can be interesting.
Well if you want more frequent updates then you still need the date and time, direction for validity etc..
Easiest way would be to look at lowcost simcard providers
I agree low cost sim would be the easiest. I am thinking about protocol engineering.
Regarding the date, why would you need to resend it every 15 seconds? If you have minutes and seconds, you would be protected against all but malicious reordering or spoofing. It's not ever a new date 15 seconds later unless we less than 15 seconds before midnight :)
You could probably save a few bytes and bits here and there, but why? Premature optimization is an anti-pattern in engineering.
Good reminder on premature optimization.
Perhaps I'll revisit this once I have my own system up and running.
It might be so that data costs keep falling, and the small amounts transmitted make further optimization an unnecessary complexity.
But it could also be so that people will increasingly want to track larger number of things at shorter time intervals - 1 hz or less - and transmission costs may continue to be meaningful.
Thanks for the ideas.
Are there any methods to trim the number of bytes sent? For instance, during regular position updates, there seems to be no need to repeatedly send the date, the hours part of the timestamp, or the first few digits of lat and long.