Id be interested to see this capability looked at.
But then you would have to implement a bare minimum IP stack on top of the wifi stack, have a way to handle IP configuration, possible gateway, plus security. And WiFi antennas are a bit more complicated than Bluetooth, as I understand it. May be if you could have a wifi module that handled most of it, it would be worth it.
What I’ve speculated about, though, is how fast can a Proffie pulse a LED, and if some form of visual light comms could be implemented. Regrettably neither LED modules nor NeoPixels have a return channel. So I abandoned that idea as worse than Bluetooth.
Wifi might be cool, but it’s neither easy, nor is it likely to make all of the things that the topic suggest possible. Let’s step through them:
- File Transfer. This is probably the easiest one. An ftp, tftp, smb or nfs server could easily be written to handle incoming and outgoing file transfers. I would probably use ftp since it’s pretty simple and less obscure than tftp.
- Firmware Upload. This is a more difficult, although there are several ways to implement it. However, almost regardless of what way is used, the wifi module is most likely going to have to be programmed specifically to support it. That means the wifi module itself would need to support arduino or similar for programming. An ESP32 wifi module could work for instance. I’m not sure if there are tool already available for doing this, or if we would just need to write our own.
- audio lag-free transmission. This is difficult. Unlike bluetooth, wifi doesn’t actually have a real-time communication channel, so the protocol has to have some amount of buffering and retransmission. The only standardized protocol I know of for sending audio over ip is RTP, but support for RTP is not commonplace, so we would probably need to implement both the sending and the receiving side, which makes it a lot of work.
At least for audio, I think a bluetooth 5.2 module would be better.
The new LC3-over-BLE mode should be excellent for low-latency audio.
Not a lot of receivers implement this yet though.
This may rapidly be consigned to the bin in the “Crazy Idea of the Day” file, but in order to get Bluetooth audio in sync, is it not possible to delay the blade lighting effects while transmitting/receiving Bluetooth audio? I don’t know what the latency is - but I’m guessing less than 100ms. Unlike a video of a person talking for instance, it seems to me there isn’t the need for 100 percent accurate sync in a lightsaber. The only effect that comes close is clash, but even then, I reckon you could get away with maybe 40ms discrepancy (one frame of video) before it becomes objectionable.
Or could you? I know people have experimented so they may have a different view.
But if it does have legs, could a line be added to a blade style that delays every light effect by a specified value?
Just an idea.
Something like a global time delay doesn’t sound impossible.
Maybe a #define BT_LATENCY NNN that would add NNN to the internal clock.
The trick would be to have audio NOT affected by it.
The problem is that BT audio has delays of at least 500ms. You could delay blade effects 500 ms to make it line up, but clashes would then happen half a second after you actually clash which would look silly.
Personally I feel that lightsaber should behave like a musical instrument, that means that lag should be as low as possible.
For Wireless audio, i think its best to forget the whole Bluetooth idea and go with 2.4/5G frequencies for lag free audio transmission. Something like this wireless transmitter/receiver i have modified and use on one of my demo sabers:
I just cut the sabers speaker +/- wires and fused a 1/4 female guitar jack on the end of the pommel, and plug one of these bad boys in, and i get lag free wireless audio transmission (up to about 75ft)
I’m still waiting for new the bluetooth 5.2 standard(s) to become widespread as they contain low-latency audio standards.
Ah, OK. I didn’t realise it was 500ms. Yes that is a lot, and would defnitely make for a compromised experience.
I believe an ESP32 would be a worthy research candidate for the next module. It contains both Bluetooth Low Energy and 2.4Ghz WiFi in a small form factor.
I’m not sure of the Proffieboards communication protocol, but if it can handle software SERIAL, then I think you’ve won half the battle. But I’m just thinking in terms of a web-interface for real-time settings modification; not sure about SD card compatibility.
I’ve bough a bunch of sparkfun micromod CPU modules to have a go at porting ProffieOS to more CPUs. ESP32 is is one of them. We’ll see how it goes.