FANET+

[Moshe Braner]

The latest versions of my SoftRF now have a combined FANET & FLARM mode.  But it is based on an arbitrary time-slicing scheme that may not cooperate very well with the FANET+ devices in common use by paragliders, such as SkyTraxx, XCtracer, and Oudie Omni.  I don't have access to any of those, and don't know how they time-slice in their own implementation of FANET+FLARM.  If anybody here has the chance to receive transmissions from those devices in SoftRF, please do the following test:

Install SoftRF version mb176 on a T-Beam or a T-Echo.  Set the debug_flags setting to "40".   Can turn off the GPS sentences in the output to make it less cluttered - set nmea_g and nmea2_g to 0.  Connect it to a computer (or phone/tablet) via USB.  Run some "terminal" software on the computer to capture the serial output appearing through the USB cable.  Once the SoftRF device has acquired GNSS fix, capture the output for a few minutes while the FANET+ device is transmitting in FANET+FLARM mode.  Make sure the lines such as "RX in prot 7, time slot 1, sec 1771255579(11) + 803 ms" are seen.  Do this for 3 different operational modes in SoftRF: single-protocol "Latest", single-protocol FANET, and Latest+FANET dual protocol mode.  Then send me the capture files.  And let me know whether the FANET+ device was on the ground or in flight.  (In-flight is best since they may transmit less often while on the ground, but that test would be harder to do.)  Thanks.

[Adam Mościcki]

any results Moshe ? spring is comming and time to paraglide with my T-ECHO.  hope FLARM+FANET will work.

PS.  are You planning to switch to dual protocol:  ADS-L  + FANET  ?

[Moshe Braner]

The FLARM+FANET mode works, although it may not be optimally timed.  Try it and see!  I can't really get the type of data I mentioned, so I hope some other people will do that.

[Ries van Twisk]

Moshe, is there anything where I check this? I have validated my timings and I can now measure them fairly accurately let me know what to look for.

Ries van Twisk

GATAS Conspicuity 

--
You received this message because you are subscribed to the Google Groups "SoftRF_community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softrf_communi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/softrf_community/fb9f493a-f663-41e5-89ce-b3e59a7e73a3n%40googlegroups.com.

[Moshe Braner]

Thanks Ries.  As I wrote in the beginning of this thread, the timing of received FANET/FANET+ messages can be recorded in my SoftRF like this:

"Install SoftRF version mb176 on a T-Beam or a T-Echo.  Set the debug_flags setting to "40".   Can turn off the GPS sentences in the output to make it less cluttered - set nmea_g and nmea2_g to 0.  Connect it to a computer (or phone/tablet) via USB.  Run some "terminal" software on the computer to capture the serial output appearing through the USB cable.  Once the SoftRF device has acquired GNSS fix, capture the output for a few minutes while the FANET+ device is transmitting in FANET+FLARM mode.  Make sure the lines such as "RX in prot 7, time slot 1, sec 1771255579(11) + 803 ms" are seen.  Do this for 3 different operational modes in SoftRF: single-protocol "Latest", single-protocol FANET, and Latest+FANET dual protocol mode.  Then send me the capture files.  And let me know whether the FANET+ device was on the ground or in flight.  (In-flight is best since they may transmit less often while on the ground, but that test would be harder to do.)"

Or perhaps your own software can do it.  Also there are several FANET or FANET+ commercial devices in use, their timing may differ, so let me know what you are using for the transmitter.  If you are receiving a mix of them from actual aircraft, if you capture the data, the trasmitter types may be deduced from the "ID" received.  In FANET packets the ID is 8 bits of a "vendor ID" and 16 more bits that are specific to the aircraft.  In my SoftRF those are combined into one 24-bit ID.