lyusupov / SoftRF

:airplane: Multi-functional, compatible DIY general aviation proximity awareness system
GNU General Public License v3.0
792 stars 215 forks source link

SoftRF Badge Edition only transmitting in second slot #142

Closed nbonniere closed 1 year ago

nbonniere commented 1 year ago

Hardware

< photo of your hardware > (required) Badge_Picture

Firmware version

Screenshot_20230606-192324

Firmware settings

Screenshot_20230606-192346

Describe the bug

The OGN receiver in North-America sees very few packets from the Badge Edition. The OGN receiver in North-America hops 65 channels and so does the Badge, but the Badge only transmits in the second slot and the OGN receiver only tunes to the first slot. Therefore only very few packets are received, and that happens when the OGN receiver second adjacent channel happens to be the correct one. See below a graphical display of both slots with dots for packets received only in second slot.

Legacy_Rx_Capture

With a Flarm device, packets are sent twice per second, once in the first slot and once in the second slot. A dot in each graph for each packet.

Legacy_Rx_Capture_Good

To Reproduce

Select Legacy mode in North-America

Expected behavior

Transmit should happen twice a second, once in each slot.

lyusupov commented 1 year ago

1) it is clearly stated in the description of the Badge Edition that every protocol implementation is limited to a reasonable minimum:

image

100% compliance of the SoftRF to the (undisclosed) 'FLARM Air V6' radio protocol have never been stated by the SoftRF officials.

Resolution 1: not applicable


2) the issue reporter has not provided any evidence that the transmitted packets have been received & accounted by either:

Instead, he is trying to convince somebody with screenshots of some 'Flarm Rx' software. Nobody knows, what the software it is. Nobody knows it's purpose, quality and degree of compliance to the FLARM radio protocol specs. We can see no official FLARM logo on the screenshots - so we assume that it is a 'hand made' software utility of questionable quality.

We can not treat the issuer supplied information as a valid evidence.

Resolution 2: invalid


3) SoftRF HQ and R&D deps are located in Eurasia, while the reporter is from North America. We have no a genuine 'FLARM North America' device to reproduce the issue in SoftRF lab by ourself.

Resolution 3: unable to reproduce


4) few tasks to improve ''Legacy' radio protocol are listed in the CONTRIBUTING file for many years

image

We are looking for volunteers from Australia, South and North America who can devote their time, process these tasks and provide ready-to-use output into SoftRF project.

We expect that no any improvements of the 'Legacy' radio protocol for these world regions will appear till then.

Resolution 4: deferred

nbonniere commented 1 year ago

I have tested this issue with a Flarm units (powerFlarm and PowerMouse) and my OGN receivers CNV4b and CNF3a that have been on-line for years. I tried many times to help, but you reject it all the time, except for issue 139, where you believed me. I have done extensive legacy protocol analysis and made many suggestions that you initially rejected, but eventually implemented such as the packet parity bit location, and others. After much analysis and testing, I have made the legacy protocol work much better with extrapolation (very well tested and confirmed). See my fork: https://github.com/nbonniere/SoftRF/blob/master/software/firmware/source/SoftRF/src/protocol/radio/Legacy.cpp Instead of just rejecting suggestions, for issue 143, you need to replace: host_name += String((SoC->getChipId() & 0xFFFFFF), HEX); by string formatting as %06X as is used is other parts of the code such as: snprintf(id_text, sizeof(id_text), "ID: %06X", id); For issue 144, just document that the SoftRF baud rate is 38400 (SoftRF.h).

define STD_OUT_BR 38400