802.11b is a DSSS modulation protocol

I'm a totaly new beginner in everything with programming and protocols etc, but already two questions are dwelling in my mind:

1 All the existing and cracked protocols and not a single one able to connect to a computer via WiFi?
2 What is required from the Deviation software to make the Tx to a WiFi node in a 802.11b WLAN?

At the minimum, documentation on how to build a Wifi stack for one of the existing RF modules. And it would never fit on the 7E. Of course, having a reason for wanting it would also be nice.

There has been some work on getting a bluetooth connection working. That's probably preferable, as the major difference is shorter range and lower power. There are IP stacks that run over bluetooth, so anything you could do with WiFi you can do with bluetooth, but the interesting things have BT protocols that support them more efficiently. That can be done with the NRF24L01+ that can also be used for most of the RTF toy protocols.

Actually, with the advent of newer chip, ESP8266, it's perfectly possible. The modules are available and inexpensive, the only problem is physical connection to the Devo - not many free pins.

Why do you need it?

Ok, that's just cheating. The CPU in the ES8P266 compares well against the CPU in the transmitter. Building a version of the Multimodule or universal module around one of those would be interesting.

Better yet, splitting deviation between the STM32 in a 7E and one of these would probably be an easier path to a "ultimate" 7E than trying to replace the STM chip on a 7E. Depending on how much stuff you could push out to the 8266.

May be it is cheating, but dealing with the whole TCP/IP stack is boring, it's no longer close to the metal programming, it requires support from run-time system, so it's a job in itself. If there is a way to avoid all of this - I take this way.

The problem with offloading stuff to ESP8266 is quite narrow interface - not many pins are there. People do wonders with it, putting various programming languages on it etc, sure. But it needs to be explored can we put all the protocol work in it - does it have enough pins to control the other radios on one hand and be able to communicate with the mixer output from the main processor. And protocol work is not much, the most complicated pieces are in the GUI, as far as I understand, and it's hard to imagine another pretty thin and well defined interface between the main processor and this add-on than the protocol work.

It's certainly got enough pins to handle the other RF modules. That's what makes it interesting as an alternative for the MM/UM. That's just 3 shared data lines plus 1 CS line per module. It's got 9 GPIO pins, so no problems there.

I agree, the GUI is what really needs to move. Since the 7E only has one protocol loaded at a time, there's not much savings there. In theory, it could be done with one high-speed UART that passes input values to the ESP and gets back display updates. I'd have to check the specs to see if the SPI & serial ports share pins, but if not it would work fine - assuming the serial port is fast enough for the LCD updates.

How come it is necessary to add an extra module?

... epecially with something like that?

www.aliexpress.com/item/The-strongest-ve...1e-bf42-eb26b23a6942

they write something about 4M flash?

Perhaps this could really help the small CPUed Devos out of their mess!

aha! WiFi stack is referred to program code..?

Yes, "Wifi stack" is program code. It's called a "stack" because there are a bunch of layers that handle different aspects of things, each of which has a different standard and protocol. Which is how you can use internet protocols over a bluetooth connection - the bottom part of the stack is swapped out.

I'm particularly interested in why you'd want Wifi instead of bluetooth. Bluetooth has been suggested a number of times, and is actively being pursued. The advantages of wifi have a noticeable cost, and I can't think of any application would benefit from them.

I can imagine a couple, actually. Exchange with ESP chip is so simple you can implement OTA update in bootloader. Or you can exchange model files. And in general, WiFi works better and more reliably than Bluetooth.

But it is to be seen how so close proximity to another emitter of RF - working radio - influences WiFi and vice versa.

When talking on new modules an other contender could be RFM22B / SI4432, it is widely used in many projects cheap Rx is avaialble. For quad racing it gives a better penetration in buildings. For FPV it can give a long range. The moduels are avaulable indifferent power level en frequency bands.

Ultimate LRS, telemetry and RC link, for big range; www.itluxembourg.lu/site/
OpenLRS, openlrsng.org/
Oplink modems, as used embedded in Revo Openpilot github.com/TauLabs/TauLabs/wiki/User-Guide:-OPLink-Mini

well, I want to connect my 7E wireless to the computer, to run flight simulators primarily but possibly make updates also.
I noticed that the CYRF6936 is a DSSS modulation system and that the old WiFi protocol 802.11b is so too, in the same frequency spectrum. My thougt was that it would be possible make a protocol, and a matching driver, without having to make any fysical mods to the Tx.

DSSS is a generic term, there can be lots of such modulation schemes. Also, it's a separate problem to route your signal to the simulator even if you have network connectivity. Modern operating systems are not very modular, even if you have a connection at transport layer the application often can't use it.

Blue Tooth has other possibilities as well...What if someday we have a Android/IOS app to display telemetry and other info...If like me you sometimes mount your phone on your tx as a screen it would be interesting to be able to connect it to the tx via BT..Would be a nice step up from the lcd screen on the tx to a nice color screen on a high end smart phone..It would also be nice to be able to have 2 transmitter that can talk to each other via BT which would be nice in a trainer situation........no cord to deal with...Would be nice to add and edit model files without having to plug in the tx..With the voice build firmware we could add or change the voice files without removing the SD card the possibilities are huge...

Personally i would not want to have the ability to update firmware wirelessly do to the possibility of any lost packet would corrupt the install...needs to be usb only IMO..

@magic_marty everything you described is possible with WiFi, and something even without. Android/iOS app is more complicated than Web app which you can server from your WiFi equipped Devo, for instance. Trainer is technically possible now - someone described $10 wireless trainer based on FlySky receiver connected to PPM port, but even this can be done without extras - your Devo transmitter is a receiver also, so it's possible to listen to another stream in between transmissions. Update can be protected by checksum and made reliable. So they're not the opposites.

You can run IP over BT, and BT over IP, so there's really no difference in capabilities between the two. You could run your server on the devo and connect to it via IP over BT instead of IP over Wifi. And likewise, you could use the BT audio protocols over BT if you wanted to. This is why the question about applications are important - you want to chose the one that's has lower costs (whatever that means) for the applications you want to implement.

But even then, things get fuzzy. For instance, unless your web app provided by the Devo is going do most of the computation on the Devo, the JS that you run in the browser could also be run as part of an IOS or Android app. In fact, PB was working on a web-based config program using technology chosen specifically so he could turn it into an app.

Of course, once you've got a mobile or desktop app that works using BT file sharing, it should also work using an OTG cable - so you could use it on a Devo without having to put a network stack on it. That wouldn't be true of a web server based solution running on the Devo.

Do the protocols ( like DSM2/DSMX, DEVO etc.) based at the CYRF6936 differ in the DSSS modulation scheme between each other?
If memory capacity in the Tx is an issue for WiFi, perhaps WiFi compatibility is yet an other a reason to develop a memory expand mod?

The memory in question is internal FLASH in the mcu. I'm pretty sure the only way to expand that is to replace the MCU. This is really only an issue with the 7E, and dropping support for an unmodded 7E isn't really acceptable. So even though people have done this mod, and I plan on trying to make a build that supports it, it doesn't make the problem go away.

Besides, victzh has already a mod that works around that issue for all of them - just add a combined mcu/rf module so you can run the stack on the module. You could add that plus a multimodule to most systems with the only real difficulty being space inside the transmitter. Of course, memory on the 7E is so tight (as in, single-digit bytes to spare) that we probably can't support even that much of a mod. I know I've disabled most of my recent additions to the code to get things to fit.

Perhaps a very naive and stupid question (it is allowed because I am a newbee ...),
have any one tried to connect a Bluetooth dongle or a WiFi dongle to the Tx with an OTG USB cable?