search

moshe-braner / SoftRF

:airplane: Multifunctional, compatible DIY general aviation proximity awareness system
GNU General Public License v3.0
18 stars 4 forks source link

Frequency hopping and time slots #13

Closed moshe-braner closed 5 months ago

moshe-braner commented 2 years ago

In version MB07 there is also new code to compute the frequency hopping and time slots for the "Legacy" (FLARM-compatible) protocol. (And also for OGNTP, which uses the same general scheme, but set up to use a different frequency than FLARM at any given moment.) The original SoftRF code is buggy (and incomprehensible).

The second time slot, 800 to 1200 ms after the seconds tick, spans the next second tick (PPS). The original SoftRF code switches to a new frequency at 1000 ms, due to passing the new Time (seconds UTC) to the frequency hashing function. This is incorrect. The full "Slot 1" uses the frequency based on the previous second's Time. The new Time is adopted later, at 1300 ms, during the 200 ms dead time between Slot 1 and Slot 0.

The new code also computes the slot & channel once for the 400 ms duration of the Slot, instead of over and over in the general loop. Variables keep track of when a new computation is later needed. The random time to transmit within each time slot is also computed at that time.

The exact time is computed in Time.cpp / Time_loop(), and the time slots and channels in RF.cpp / RF_loop().

moshe-braner commented 2 years ago

At this time the new time slots code is only used for the Legacy and OGNTP protocols. For other protocols (P3I, FANET, UAT) the original code is still in place. It will take more work to implement the new code in a more general way. And I need documentation of the frequency plans for these other protocols.

moshe-braner commented 2 years ago

Experiments with a Portable PowerFLARM doing the transmitting showed that some packets from the FLARM seemed to arrive between 800 and 850 ms after PPS, but on the channel they were supposed to be on before the 800ms mark (Slot 0). On the other hand no packets arrived between 400 and 450 (the early part of Slot 0), and some packets arrived between 200 and 250 (after the end of Slot 1). In other words, the timing seems to be off by about 50 ms. Since I cannot think of a way that my code (based on the PPS signal from the GPS module of the T-Beam) would be 50 ms too EARLY, I wonder if the FLARM is 50 ms LATE relative to the official time slots?

rvt commented 4 months ago

The other day I was looking into this and in my firmware I added analytics on on the rereceived dataset: This is what I get from SoftRF (the original version)

OGN measurement

Frequency   timeTenthMs
868200000   1111111111 11111111011 1100000000 000000000 0000000000 00000000000 0000000000 0000000000 0110111110 111101111
868400000   0000000000 00000000000 0000000000 000000000 0011111111 11111101111 1111111111 1000000000 0000000000 000000000

Each digital is 10ms in length You can see here that it does hop between the frequencies. Although my firmware is suppose to be accurate to 1ms (using pps from GPS) do allow for some delays and I need to valudate the accuracy. But I did notice some strangeness around 700ms where I always seem to have a gap.

moshe-braner commented 4 months ago

Yes of course the original SoftRF does frequency hopping. But it does it at the wrong times, according to Pawel. See my first comment above. This may not matter much in Europe, with just 2 frequencies. In North America we have 65 channels. Choosing the channel for those first 200 ms in each second based on the current, rather than the previous, second, ends up with the wrong channel. Thus 25% of the transmissions are on a wrong frequency and will not be received by a real FLARM.