Marc with AIR Avionics. To speed things up and to create transparency, I made an account here -- Hi everyone.
Before getting into detail, I will give you some insights into the technology used. The main data communication technology in use for all FLARM based traffic systems is RS232 (all besides our new AIR TRAFFIC. This one features a direct WiFi interface plus additional other interfaces like ARINC429). Every second, several datasets (normally over 30) are sent over this interface, e.g. GPS position, pressure altitude, and traffic targets (one dataset per target). There are two common failure modes we know of:
1) Checksum error: To preserve data integrity and to detect data integrity issues, checksums are used. If these checksums do not match the dataset's content, the dataset is to be considered as false.
2) Error in the data itself: Wrong data is transmitted. Traffic targets not producing warnings are encoded in RS232 datasets starting with $PFLAA. The error described by ToTheSky shows such a traffic dataset with a missing data field (differential altitude). We do not know where this comes from. We suspect an internal processing error in the ADS-B/FLARM receiver or another component down the signal processing chain.
Both failure modes are common, that means, they occur frequently. To put this into perspective, roughly 30 datasets are sent per second, every second. That is over 100,000 datasets an hour. First, due to RS232 signal integrity issues, wiring issues, EMI issues, checksum errors happen. This goes for all RS232 devices we know of (also certified devices), and this is what checksums are for. Secondly, sometimes, datasets contain errors with correct checksums, which means wrong data is transferred correctly. While this second failure mode, error in the dataset, is not good, I totally agree with that, it still happens. This as well is no specific to TRX devices, it happens with many FLARM and non-FLARM device types we know and, therefore, is to be considered as being common. Don't get me wrong: This is not at all good. Just because its common does not mean that its good. In our new AIR TRAFFIC, we have doubled down on data integrity and quality.
We propose a design that is tolerant towards a certain amount of failures. This is state of the industry and widely accepted as good practice. For example, the parsers (that's the piece of software decoding the RS232 data stream) in our avionics systems, omit datasets with invalid checksums and wrong data for a certain amount of time. The result is that the single failed dataset is not processed or shown to the flight crew, which results in its content, e.g. a traffic target, not being shown for one second, and then shown again after a new and valid dataset has been received.
in the software where we keep you safe?
This is not a valid argument. Providing a pop-up failure message because of a single 1-second event does not promote flight safety. It distracts the flight crew and consumes workload. It stops traffic data from being displayed which results in loss of traffic awareness. Moreover, you mix data quality with safety. Identifying a single dataset as false and ignoring it, results in a one-second data outage for this particular target. This is for sure not a good thing, but where is flight safety compromised?
Tim, I am disappointed about both the tone [...] of your answer.
Me, too.
If I were you, I would return the device I have purchased which is outputting erroneous data
It is not up to us to decide, what our customers want, is it? Badmouthing us or our products won't help either. I'd prefer to work together to find a solution that meets our customers' requirements.
My humble suggestion to resolve this:
SD directly acknowledges the warning popup window after correct data is received again. No flight crew action required. If wrong datasets persist, the window stays. Everybody gets it the way he wants, we all go flying.
Best wishes,
Marc