wfb-ng mavlink stream

[svpcom]

I have several questions about controversial decisions in the latest versions of openipc-fpv https://github.com/OpenIPC/firmware/blob/master/general/package/wifibroadcast-ng/files/wifibroadcast

1. Why separate stream for mavlink was dropped?
2. Why do you hardcode short GI (-G short) for video. It is very bad for multipath interference on long distances
3. Why uart speed 115200 was hardcoded?
4. No any unit tests for mavfwd are exists. For example it works in build from Aug 2024 but have a problems with current build (in my usecase).

Separate stream for mavlink is very important because you can use different FEC and packets type for uplink/downlink for example to allow realilable low-bandwidth control messages to drone and high-bandwidth but unrealiable control traffic.

P.S. Also a huge problem at least for me is absence of stable releases and even availability of old binary builds of camera firmware. Along with the fact that old firmware versions simply do not build (like all versions before December 2024 due to unavailability of some toolchains) this leads to huge problems for users who need some stability. Keeping everything in a monorepo IMHO is very bad, since it will never be stable. It is better to make independent modules (like majestic, wfb-ng, ruby, alink, etc, which have their own release cycle) as git submodules.

[flyrouter]

Good day

I have forwarded the link to your message to the FPV team and I think there will be more answers to your questions here in a while.

Unfortunately, I am not competent to comment on some points, my colleagues will answer more fully and correctly. However, I suspect that you are using a modified old configuration file or have not updated the system and therefore, when assembling, a search is performed for the old name of the toolchain, which does not exist.

As for binary assemblies, they are always published on the Dev channel with a lifespan of 6 months and they can always be taken there - https://openipc.org/our-channels

The firmware assembly system is and will remain the same in any case. Publishing individual releases in repositories by components is not acceptable in our case, since it depends on many settings of the overall system.

Regarding your questions:

1. I think our colleagues will answer here a little later. I personally cannot comment
2. Thank you, the information is valuable and I think the developers and testers will reconsider this parameter or will make it an important setting. I think there will also be a separate comment.
3. The speed of 115200 is taken as a unified default standard for all platforms. If you have any specific complaints or comments, please suggest them.
4. I think our colleagues will answer here a little later. I personally cannot comment

P.S. Also, please pay attention to the Builder repository, where you can create your own configuration for each device, each solution or project. Perhaps this will be interesting for you or you will want to create your own package.

Thank you.

[flyrouter]

I also made a transfer of some answers in a compressed form from other colleagues

1. Mostly because msposd is the new default and the tunnel replaces the previous separate pair.
2. This was chosen based on some testing but suggestions are being considered.
3. 115200 is the default for Sigmastar.
4. No one has and likely won't create any tests.

We hope that other participants will join the discussion.

[svpcom]

There is a problem with single speed of UART due to it async nature. It doesn't have a separate clock line and rely to internal oscillators of both side. Different boards have different base xtal frequency and uart clock produced from it via PLL. But it is not always possible to get exact clock freq. Due to this different pairs of FCs and cameras (or other SBCs) have different "best" common uart speed. For example for stm32f4x and Allwinner H3/H5 has best common clock 1.5M baud and using 115k produce a lot bit errors and corrupted mavlink packets

[tipoman9]

1. Why separate stream for mavlink was dropped?

Mavlink was mainly used to draw OSD over the video. Unfortunately the use case for this task is not standard either for the air-side, nor for the ground side. Recently we added support for OSD over msp-displayport , which is the same for all major FC controller softwares, that has many benefits.

• Allows for air side rendering, which greatly improves flexibility, since you can use any system that can render h265 as a ground station.
• Has built-in layout configurator in every FC softare
• Can be rendered both airside or ground side with advanced UI
• FC softwares seems to implement msp better and export more metrics over it than over mavlink
• Can use the "menu control system" via the Tx gimbals and config the air-unit with stick inputs.

MSP data, that contains basically the same info, like UAV attitude, speed, altitude, bearing to home, GPS and etc can be forwarded to the GS and rendered with nice UI, just like mavlink one. So we tried to send msp protocol over the same port as mavlink (14550), but it turned out that wfb-ng GS does some parsing on this channel and distorts it. So a new port was needed and this is where wfb-tunnel comes handy. And since the mavlink forwarding was done with simply another instance of wfb_tx, renamed as telemetry_tx, it was dropped in favour of tunneling to simplify support and to free some resources. Currently mavlink forwarding is fully supported, the main concern is that the user will need another UARTs , since he will most likely use the "first" one for msp in order to has OSD, and some cameras have only one uart. The tool that does the forwarding (mavfwd) is still included in the firmware and can be configured to output on port 14550, but the telemetry_tx binary (renamed copy of wfb_tx) should be manually created by the user. So, it is not many lines of script code needed to keep "legacy_mavlink" support for wfb_ng if the need for it arises. On the other hand, this can be added quite easily by the user as well

[tipoman9]

4. No any unit tests for mavfwd are exists. For example it works in build from Aug 2024 but have a problems with current build (in my usecase).

I just noticed that it is excluded from Goke/Hisilicon build now, I suppose there is not enough space after all drivers for 8812xx chipsets were included, but it can be manually added. It compiles and runs fine for me, just tested it.

[snokvist]

One possibility is to have a builder profile / image compatible with the wfb_ng protocols like provisioning and mavlink parsing, just like ruby have for its own eco system. Openipc have its own implementation of wfb_ng (and other additions like msposd favored over mavlink).

I would prefer to keep full compatibility with wfb_ng in openipc mainline but if its not possible, this would be the next best solution.

[Li-Tianming]

And since the mavlink forwarding was done with simply another instance of wfb_tx, renamed as telemetry_tx, it was dropped in favour of tunneling to simplify support and to free some resources. The tool that does the forwarding (mavfwd) is still included in the firmware and can be configured to output on port 14550, but the telemetry_tx binary (renamed copy of wfb_tx) should be manually created by the user.

That's help me alot. thanks.