SoftRF Badge Edition only transmitting in second slot
nbonniere opened this issue · comments
Hardware
- Standalone
- Badge
- Prime Mark II
- Dongle
- SkyView EZ
- Uni
- Mini
- Academy
- Lego
- ES Edition
- Balkan
- Raspberry Edition
- UAV
- WebTop Serial
- WebTop USB
- UAT978 module
- Flight Recorder
< photo of your hardware > (required)
Firmware version
Firmware settings
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.
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.
To Reproduce
Select Legacy mode in North-America
Expected behavior
Transmit should happen twice a second, once in each slot.
- it is clearly stated in the description of the Badge Edition that every protocol implementation is limited to a reasonable minimum:
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
- the issue reporter has not provided any evidence that the transmitted packets have been received & accounted by either:
- genuine FLARM North-America device (proprietary hardware and firmware) and
- genuine 'OGN-Receiver' (closed source software)
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
- 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
- few tasks to improve ''Legacy' radio protocol are listed in the CONTRIBUTING file for many years
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
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