Closed MedadRufus closed 3 years ago
Based on the lormac region spec, the minimum packet size does not appear to be 26 or 30 bytes. Actually, it is closer to 240 over US915 and similar for EU868 when using DR3.
When it comes to prioritising transmissions, I would use a combination of
Then I would transmit position for each day, then the second position for each day, third and so on. The first position for the day will be at midday, based on highest position of the sun. Then the next two positions will be the first and last position fixes for the day. The subsequent positions will be positions between First and midday packet, and between midday and final packet for the day.
I think in total, per day, we need to only store 5 positions.
Each packet should contain the info from one position per day from the last 4 days. Or the last 8 days, but alternate days. It appears that we are restricted to transmitting only 4 positions, in addition to the current one in each packet. Unless we use larger packet sizes, which I don't mind using. I will stick to the national regulations, but sticking to the TTN limit of 30s airtime per day is much harder.
I think the best way is to send a total of 8 archieved positions, one for each of the past 8 days along with the current fix.
Developing on the previous comment, each packet should transmit 8 archived positions, one for the 8 past days each, along with the current fix. For each past day, the position will be a random position from that day. i.e. the position can be from any time in the day.
Therefore, as the balloon comes back over Europe, with each transmission, we will get a more and more clear picture of where it was for the last 8 days.
We can use the GPS timestamps to tell the tracker the start and end of each day.
My estimate indicates that current position along with pressure/temp etc can fit in 70 bits. Each archived position that contains position and time fits in 40 bits. The proposed packet will therefore contain (70 + 40 * 8) bits which is 390 bits which fits in 49 bytes.
Be default, the tracker will transmit 8 archieved positions of the last 8 days. However, if we need to get info from even earlier than the past 8 days, e,g, 15 days ago, we can send a downlink to the tracker that will switch it to transmitting the 8 days before the specified day.
This option will be held in volatile memory, and will switch to default(data from last 8 days) after a reset.
Save a whole position fix+ time in eeprom as a fixed size (e.g. 6 bytes). To iterate through it, go from 6 bytes to the next 6 bytes etc. Allocate a few kb of eeprom for this use. Overwrite from start when this space is fully filled. Prefereably add a checksum at the end of each saved position to ensure uncorrupted data. Its important to make the space allocated to the data a multiple of the fixed size. e.g. if the size is 6 bytes, the space allocated should be n*6 bytes.
Perhaps, make a table holding the info about how many position fixes there are for each day, so that a random position fix can be retrieved efficiently.
Timestamp should be days since 1/1/2020 and hour, minute, second of day. Or, ITOW + week number
I was thinking about the compression of flight path data. What if we encode all the archived flight path in a polynomial, and send only the coefficients. With each new transmission, the polynomial would approximate the flight path better. This will cause a loss of accuracy, but give a big picture of the flight path.
Simplifying the whole thing, we get it to send the last 8 position randomly picked from the last n
positions. We can add additional options to send a downlink to the endnode to send more than 8 positions, pick from a larger pool of past positions and have a different offset position. i.e. instead of selecting from the last 20 positions, ignore the last 10 positions and pick from the 20 before that.
So in summary the options are:
All these can be specified from an downlink but will have a default.
TODO
TODO
[x] add number of resets to the sensor_t
[x] Add data received flag to it as well
[ ] Add options to configure playback params via and downlink(message from ground to tracker)
[x] Add option to save position every 30 minutes
[x] Prevent sending position two times over
[ ] Send one position from each day in the packet
[x] Implement Van Der Corput Sequence for sending down data
[x] Add in field in packet that sends number of coordinates saved in EEPROM
This is because, global LoRaWAN coverage is very poor and only on a few occasions do we hear from it. Tasks to carry out:
[x] encode 4 locations and their timestamps in a single 26 byte transmission
[x] save past locations to Non Volatile memory
[x] Tacktically send past info that contains the most info about the flight path. One option is the Van der Corput sequence.
[x] Compress the data such that it can be sent in 26 bytes. e.g. send timestamps as time deltas of the current time, and use other forms of compression.
[ ] Test if it successfully manages the overflow of eeprom
[ ] Ensure that the device will tx 120 byte long messages over US,AU and JP
[x] test next_LCG, even when all elements have been generated
[ ] Fix poor implementation of LCG