Send 9 locations in each transmission: Current location and 8 other past locations

[MedadRufus]

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

[MedadRufus]

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.

[MedadRufus]

When it comes to prioritising transmissions, I would use a combination of

1. Coverage maps, mainly over Europe
2. Listening for downlinks(messages from gateways to end node) to detect if the tracker is being heard as inputs to determine what has to be transmitted.
3. Try to send up a message to the tracker telling it what info has been received and what has not been received; where we are missing info in the timeline. The tracker can delete the times when it has already be listened and not transmit them down again.

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.

[MedadRufus]

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.

[MedadRufus]

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.

[MedadRufus]

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.

[MedadRufus]

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.

[MedadRufus]

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.

[MedadRufus]

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.

[MedadRufus]

Timestamp should be days since 1/1/2020 and hour, minute, second of day. Or, ITOW + week number

[MedadRufus]

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.

[MedadRufus]

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:

1. number of positions to send in a single packet
2. how many positions to select from
3. offset of positions

All these can be specified from an downlink but will have a default.

[MedadRufus]

TODO

• [x] integrate the string builder into the main program
• [x] fill the string builder with info
• [x] get time since epoch from GPS. need to test in hardware.
• [x] Ensure it never sends null values from eeprom(when it has yet to be populated)
• [x] Consider saving every 30 minutes. Each day has 5-10 hours of sunlight. Max is 20 positions per day. EEPROM can store 650 positions which works out to 32 days of storage.
• [x] Save position to eeprom ONLY when there has been nothing saved for the last 30min. Make it mcu reset tolerent.
• [x] Ensure that no positions are resent. Only resend after all unsent positions have been transmitted. Ensure its mcu reset tolerent.

[MedadRufus]

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

[MedadRufus]

• [x] verify save eeprom fcnt

[MedadRufus]

• [x] Implement Van Der Corput Sequence for sending down data

• [x] Add in field in packet that sends number of coordinates saved in EEPROM