On Friday, March 22, 2019 at 10:13:51 AM UTC-7, JS wrote:
On Friday, March 22, 2019 at 12:44:48 AM UTC-7, Ramy wrote:
This sounds like an interesting possibility as the powerflarm core has a USB port. I’ll let Darryl analyze it...

Ramy

LXNav is waiting for FCC approval for the PowerMouse, which uses the new chip. Updates will probably come after that.
Jim

I think it would be great to see ADS-R and maybe TIS-B support in FLARM devices.

FLARM has two chips and associated software currently available to OEMs, the actual FLARM chip and a new 1090ES In chip. The new 1090ES In chip is different than what is used in PowerFLARM.

Unfortunately (and this confused me in the past as well) the LXNav PowerMouse does *not* use the new FLARM 1090ES In developed chip, it uses their own developed technology in conjunction with the FLARM chip. The LX Navigation Eagle *does* use the new FLARM 1090ES In and FLARM chips.

I say unfortunately as this may create differences in how these otherwise similar products operate. I guess we'll have to wait and see. Personally I would rather all this technology came from FLARM and all OEM products operate identically. LXNav clearly makes great products so maybe they'll pull this off OK, buy I am concerned that their decision to roll their own stuff here may not have been the best decision.

This stuff is not as simple as "just support xyz protocol", there are for example going to be devil is in the details of different $PFLAU and $PFLAA FLARM warnings being generated for ADS-B direct, ADS-R and TIS-B traffic. There are also operational things that can help improve ease of use and safety that I'd hope vendors implement (from understandable documentation about what TIS-B and ADS-R support there is and the implications of that to say the receiver detecting and warning if the own-ship 1090ES Out does not exist or is not transmitting the capability code for 1090ES In).

A FLARM device comes with more than usual ADS-B In traffic receiver capabilities, the precise traffic warmings, relatively low false alarm rate, ability to operate on tow or in a gaggle etc. The positional accuracy of ADS-R and TIS-B is less than ADS-B Direct, or FLARM and in the case of TIS-B the positional error is much more. So adding extra ADS-R and TIS-B data comes with some challenges, not insurmountable, but this likely needs to be done with a good technical understanding of both the FLARM traffic algorithms, and understanding of how ADS-R and TIS-B works in practice in the USA.

I hope vendors have been testing this stuff in a realistic simulated USA ADS-B/TIS-B/ADS-R environment before any USA product release, and that they explain implications of what what they implement for ADS-R and especially TIS-B (if supported) to users. (Don't forget for reliable operation both ADS-R and TIS-B require your aircraft to have TABS or 2020 Compliant ADS-B Out).

BTW technical aside... be careful when talking about "TIS-B" especially in more technical conversations with vendors. TIS-B can refer to the relay of SSR data from ground stations over ADS-B as implemented in the USA today (as I used it above). But to a more technical person TIS-B may also mean the general data message format used for both that FAA TIS-B and ADS-R services, for example if an engineer is reading the RTCA DO-260B standard they would implement support for the TIS-B message format to receive ADS-R data and might talk about that as "TIS-B support".