Yes, and given there are only 1440 minutes in a day, some bit packing could bring this down to 1.5 bytes, using the other 4 bits for something else.
1 Like
You really donât need to transmit the time differences at all; just make them fixed offsets.
If there are multiple possible history schemes, use multiple ports for different packet types.
1 Like
Your are right @mark-stanley. 3 bytes for timestamp can be shortened to 2 bytes. With 2 bytes, I can send a position/timestamp up to 45 days before the current time. That should be enough for the balloon application.
1 Like
Fixed offsets will not directly work because there may have been no data stored from certain times. e.g. when its night time. The tracker is powered solely by the sun.
Therefore, if I use offsets of, for example, 24 hours, I may have data from 24 hours ago, 48 hours ago but not 72 hours ago. Note that the balloon is rapidly traveling across timezones.
However, with a little improvement, this can work. Instead of using fixed offsets, I can get the most recent position/time fixes to these offsets. For example, I can send the closest position/time fix to 24 hours ago, 48 hours ago, 72 hours ago etc. I just have to send the time delta between the recorded timestamp and 24 hours ago, 48 hours ago etc. It may just take 1.5 bytes to encode the time delta in minutes.
First of all, you should change that with some on-board power storage. But it also exposes that you can apparently tolerate huge gaps in your data, which really reduces how much you need to move - if you can tolerate overnight gaps, then it would seem you really only need a few points a day.
Therefore, if I use offsets of, for example, 24 hours, I may have data from 24 hours ago, 48 hours ago but not 72 hours ago. Note that the balloon is rapidly traveling across timezones.
You could certainly work out a sensible scheme; given a location and calendar, you know approximately when the sun is up. And youâve not moving that quickly that itâs going to have been more than a few hours different on previous days.
Should? It could be added, but as a decent supercap at 1F is 1.2g, thatâs adding 20% to the tracker weight so itâs not a trivial change.
1 Like
First of all, thatâs an interesting project 
I just have to send the time delta between the recorded timestamp and 24 hours ago, 48 hours ago etc
Alternately you can just send the deltas between each successive recorded timestamps:
For the first recording, you donât need to send anything because you can use the date/time from the metadata.
For each successive recording send just the delta between it and the previous one.
Using 10 bits would give you a flexible window of 1024 minutes between recordings (17h)
You will need to take a bit of care when rounding the numbers, so the errors do not accumulate, but itâs possible to keep the error below 1 min for each recording:
For i =1 to n calculate diff(i) = t(i) - t(0) - sum(diff(0âŚi-1))
This should cancel out the errors from the previous diffs!
You can extend this range further in two ways:
- add 1 more bit to get 34h
- you can shift out some unused values
For example, if it doesnât make sense to send too recent data (<4h) you can just subtract 4h from the diff end encode the result ⌠this way your range is effectively 4h-21h with just 10 bits
Another option is to use a âvariable precisionâ encoding/mapping.
This would work best with a scheme like you described, where you encode the diff to the beginning of 1 day ago, 2 days ago, 3 days ago etc.
You map each possible value of a byte to 256 âfixedâ minutes of a day, you can adjust the mapping table to map more values where you need more precision (sunrise, sunset), and have some larger jumps in the parts of the day that donât matter much (noon?, night).
Of course, you can use more than 8 bits if needed
You can apply the diff strategy to the other fields (lat/lng).
Only the first frame needs to record with 2 bytes precision, subsequent frames record just the diff with the previous one.
Depending on how fast these balloons go you might be able to use just 1 byte for the diffs.
A quick calculation at 10km altitude with 20m/s wind speed, you get 1728 km/day which is about 16 degrees of lat/lng
I think you could safely pack this in 1 byte (if -180/+180 fits ok in 2 bytes).
You might be able to pack together the time-lat-lng-alg diff in 4 bytes (11, 7, 7, 7 bits).
Thanks @danmana for the ideas.
What would happen if there is a 2-3 day gap in the data? If I restrict all the deltas to a certain size, e.g. 2 bytes, if the actual delta is greater than that, how to deal with that?
The naive solution is to make the size of the delta bigger(e.g. 2 bytes to 3 bytes) but then its size becomes too big to be useful.
A multi-day gaps in data is a possibility. If the balloon flies over the Arctic region, the sun does not come up very high during the winter time which means the balloon may not be powered for days and save positions to its non-volatile storage.
Its not possible to guarantee at least one position fix a day.
Medad
A 2 byte delta at the minute level is 45 days - 12 bits is 2.8 days, 14 bits is 11.3 days âŚ
Some sort of header with bit level flags to indicate which payload format / sequence is being used. At worst, you use bit flags to to indicate absolute or relative values.
Most of this just needs a really big envelope to sketch out a plan on. Plus beer. And snacks. And a kebab after.
Thatâs why Iâve been arguing for an exponential increase in the age of each measurement in a packet⌠Even if you want to use deltas and not mere position in the packet, an exponential scheme could still make sense - the staler it is, the less precision of the time really matters.