EDIT: Disregard this post. I am an idiot.

This definitely worked when I was testing it before the PR, but if I switch over to the tcp2msp branch now I get all timeouts in the configurator with BF 4.3 RC2 (which theoretically has your fix for the bigger CRSF MSP timeouts and buffer size)

Some pages will eventually load, but mostly it just gets stuck. When running on my home network instead of just in AP mode, I can't even usually get a real connection through the configurator, it times out during the handshake:

2022-01-14 @15:48:10 -- Serial port successfully opened with ID: 4
2022-01-14 @15:48:11 -- MultiWii API version: 1.44.0
2022-01-14 @15:48:14 -- Flight controller info, identifier: BTFL, version: 4.3.0
2022-01-14 @15:48:20 -- No configuration received within 10 seconds, communication failed
2022-01-14 @15:48:20 -- Serial port successfully closed

@CapnBry make sure you do not have -DDEBUG_LOG otherwise it causes problems with the link.
I had this problem and it took me hours before I realised my mistake!

@CapnBry make sure you do not have -DDEBUG_LOG otherwise it causes problems with the link. I had this problem and it took me hours before I realised my mistake!

Ah crepes, PK, you're right. I did build it with DEBUG_LOG on like a damn fool. Works perfectly like it did when I tried it before the PR. Thank you!

Ah sorry guys, yeah I should have mentioned! Betaflight does not like the debug output getting spit over serial.

Ah sorry guys, yeah I should have mentioned! Betaflight does not like the debug output getting spit over serial.

I wonder if on the RXes we could dual use the GPIO0 (boot pad) to be a soft serial for debug output.

Not a bad idea, I've also gotten debug via websockets to work, so that's another option.

Not a bad idea, I've also gotten debug via websockets to work, so that's another option.

I like the websockets, but the problem is that you can't really run wifi and the radio on the RX at the same time!
I think the wifi is just too hungry to allow the radio to work reliably.

Yeah, good point, but I don't think we tested that since you changed over to the async library. We should try it again.

Yeah, good point, but I don't think we tested that since you changed over to the async library. We should try it again.

Ah, true. Perhaps I'll give that go later then.

Can work with Inav?
The Speedybee app only connects to the port of their own device, right?

This doesn't support speedybee, and probably can't. Inav should work too, but there was some upstream changes needed in BF to fix MSP-CRSF encapsulation. Inav will probably be the same

@CapnBry make sure you do not have -DDEBUG_LOG otherwise it causes problems with the link. I had this problem and it took me hours before I realised my mistake!

I am a fool novice, how can I turn off DEBUG_LOG?

@CapnBry make sure you do not have -DDEBUG_LOG otherwise it causes problems with the link. I had this problem and it took me hours before I realised my mistake!

I am a fool novice, how can I turn off DEBUG_LOG?

If you are using configurator then I think it's off already.

Can this function also be achieved by connecting to the WIFI of the ELRS TX?

Can this function also be achieved by connecting to the WIFI of the ELRS TX?

No, that would require a whole lot more code to make happen, and the performance would be absolutely terrible. The configuration connection expects a pretty high bandwidth and low latency connection since it normally runs over serial. Running it over an extremely high latency link at ~5kbit throughput will cause Betaflight Configurator to timeout repeatedly and make a lot of redundant requests that will be discarded.

There would be a lot of work needed in BF Configurator to be even tolerant of a low bandwidth high latency connection. It is just a mountain of work for both projects, and the user experience is going to still be pretty awful due to the link speed limitations like trying to stream full resolution video over a dialup modem. There are plenty of ESP-based ELRS RX that will support this though, so it isn't too much to ask of the user to just spend $15 on a new RX if they want this feature instead of getting it for free on old R9 hardware + TX MSP passthrough and then complaining about how terribly it works.

Not yet, I waitìng for the new version, that be add labrary tcp

hmmm. I'm using 2.4.0 firmware version with betafpv nano rx and betaflight can't connect.

This feature will not be available until release 3.0

Is it available in any other branch so I can merge it in my own?

This code is merged into the master branch. If you are wishing to test, then you could flash master to both your TX module and an RX.

Is it available in any other branch so I can merge it in my own?

This code is merged into the master branch. If you are wishing to test, then you could flash master to both your TX module and an RX.

No it's not on any other branch. All the changed files are in this PR, so you could try to put them into a 2.4 if you want to try it for yourself.

Is it available in any other branch so I can merge it in my own?

This code is merged into the master branch. If you are wishing to test, then you could flash master to both your TX module and an RX.

No it's not on any other branch. All the changed files are in this PR, so you could try to put them into a 2.4 if you want to try it for yourself.

Good to know. Thanks

But as I can see this PR is already marked as merged

But as I can see this PR is already marked as merged

Yes, to the master branch, which will become 3.0 when we are ready.

Yes, to the master branch, which will become 3.0 when we are ready.

So flashing rx with the master branch should make this feature available, right?

Yes, to the master branch, which will become 3.0 when we are ready.

So flashing rx with the master branch should make this feature available, right?

You need to flash TX also or TX won't talk to the RX. At least I think so, OTA protocol has had some updates for 3.0 and I think it breaks compatibility with 2.x

Yes, to the master branch, which will become 3.0 when we are ready.

So flashing rx with the master branch should make this feature available, right?

You need to flash TX also or TX won't talk to the RX. At least I think so, OTA protocol has had some updates for 3.0 and I think it breaks compatibility with 2.x

I guess TX is not needed in order this feature to work, but good to know it also have to be updated

Need some help! master branch can not for build

Great work! Hoping a mavlink2crsf (mavlink over expesslrs) version for ardupilot is coming.

What would be needed to get this also working with INAV?

Lost few hours intill I noticed that "Telemetry output" is not enabled in "Receiver tab" in Betaflight configurator in my ad-hoc setup...

What's the baud rate of this serial over wifi connection? I use it for INAV configuration on my big planes and it can be a little slow. But that may be just wifi interference with such small wifi antennas. I was thinking of trying Airport for configuring at the bench. But is Wifi still wayyyy faster than Airport? This PR appears to be the only official documentation of this feature. Maybe after this I'll commit something to the docs.

I use it for INAV configuration on my big planes and it can be a little slow.

This feature does not work with inav. Inav is missing mspV2 support in mspOverCrsf implementation. Inav configurator is sending mspv2 packets.

For inav you have to look at esp-link or bronebridge connected to msp uart.

What's the baud rate of this serial over wifi connection? I use it for INAV configuration on my big planes and it can be a little slow. But that may be just wifi interference with such small wifi antennas. I was thinking of trying Airport for configuring at the bench. But is Wifi still wayyyy faster than Airport? This PR appears to be the only official documentation of this feature. Maybe after this I'll commit something to the docs.

Slightly slower with eLRS than Crossifre and Tracer, so there was some modification recently in Betaflight to check the serial of the CRSF device - eLRS devices all have the serial EXPRESSLRS which can be used to tune throughput and avoid dropped MSP frames.
iNav should look at this - the RX uses mDNS to advertise itself so it's very friendly to autodetect on wifi

I was intrigued by this and noticed that the original comment says "Has also been tested to work with betaflight configurator on Andriod. [sic]" Can anyone shed some light on what Android app works with this? It works very well on my computer at home, but it would be great if could be used at the field with an Android app!

Can I flash firmware with it?

Can I flash firmware with it?

It's built in to all V3 firmwares

Can I flash firmware with it?

It's built in to all V3 firmwares

I mean Betaflight. Can I update betaflight using this? Via wifi?

Can I flash firmware with it?

It's built in to all V3 firmwares

I mean Betaflight. Can I update betaflight using this? Via wifi?

No, you cannot update betaflight firmware via the wifi connection.

Hi there, and sorry for reviving such an old PR...
I know we all hate MSP Jumbo frames, but I think there might be something wrong in the implementation. From the iNav docs it seems like in a V1 Jumbo frame, the length bytes are the indices 4 and 5, but in msp2crsf.cpp, line 120 bytes 5 and 6 are used. Similarly, here bytes 2 and 3 are used, as opposed to 1 and 2 (byte 0 is 255, followed by the actual length in bytes 1 and 2). Am I missing something here?

Am I missing something here?

Yes, MSP V1 Jumbo frames have the payload_size at index 3 set to 255, and the actual size is in the payload at index 5 & 6. Specified in the docs that you link to!

is in the payload

Ah I totally misread that, thanks. I always thought that the length is set to 255, and then it's immediately followed by the actual size (i.e. before the command).