No. As I previously answered this question in other thread - it will be supported in AC-3.5.
Default scripts included in this release are tailored to work with Raspicam but you can modify them to suit your own needs. Wi-Fi broadcast feature doesn’t depend on any specific video camera. In fact it’s orthogonal. It just broadcasts data. We set up image with a kernel that is capable to do this. In theory, you can stream whatever you like.
wifibroadcast is included, does that mean that when I plug in my atheros card that I use with hostapd the bitrate will be modified on it, such as it is on Wifibroadcast? This would be undesirable in my case.
I may be wrong but I believe there were talks about having a built in access point, such as hostapd, so when you plug it in to a RPi 3 you can ssh into it without a monitor, keyboard, wireless router, etc. All you need is a laptop or other device, is this still going to be implemented?
Shouldn’t this feature such as the access point that allows easier configuration/implementation of the product be prioritized over adding wifibroadcast, which don’t get me wrong is a great feature to help expand the vision and capability of the Navio (hence the whole idea of having it piggy back on the RPi) but that doesn’t really help the product itself?
Same remark on my side : the “/etc/default/wbc” conf file does not exist (created from the doc information)
I get the following info on wbc service start
"Failed to start wbctxd.service: Unit wbctxd.service failed to load: No such file or directory."
Guillaume
I’m wondering if Wifibroadcast can work together with normal wifi (for ssh access)? For instance, if there are two wifi cards, or in the case of RPi3 with built in wifi.
Hello Yannis
Wifibroadcast changes your wifi device mode to “monitor” mode which sets a unidirectional link between your Rpi and GCS. To what I understood this is not possible to use both conventional wifi and wifibroadcast on the same device (indeed, basically the same “wlan” which would correponds to a single physical device)
If you want to use “conventional” wifi for telemetry or SSH you need another wifi device : the built-in RPi 3 chipset should work provided you have another wifi device dedicated to wifibroadcast
Be aware that range for the built-in RPi 3 wifi should in theory be quite poor as there is no external antenna --> I would not advice to use it for telemetry (but maybe this is something to be further tested…)
Guillaume
For sure monitor mode is not compatible with “normal” wifi mode, thus as you pointed out both cannot be active on the same device. My question was to whether using two devices a combination of WBC (monitor mode) and wifi would be possible. Perhaps by specifying the adapter to use to the wbctx script.
Re. telemetry, it is in fact possible to transmit telemetry (or, any other data for that matter) using a single WBC transmitter. AFAIK EZ-Wifibroadcast supports forwarding telemetry that is input in Pi’s serial port, for instance. I’m not sure if it is supported currently in the Emlid image, but eventually it would be great to see this as well, as it is a perfect fit since NAVIO telemetry is practically built-in.
We’ll think about some workaround. Maybe include two versions of the modules or something like that.
There are a couple of caveats regarding the implementation of the access point. We are thinking about it.
No doubt it would be handy, but access point is not the only way to set up ssh connection without the monitor\keyboard - you can simply add your WiFi network to a file on SD card or use an Ethernet cable.
Things are a little bit more complicated from our perspective. It would take an enormous amount of time to explain why are we doing X and not doing Y in particular, but in short and general we have a lot of stuff to consider that is only seen by the developers like: amount of effort required for implementation, how much maintenance we will have to carry afterwards, compatibility with other features, does anyone else already work on that feature etc.
We are always open for feature requests (but cannot promise their fulfillment). Yours is noted, thanks!
Sorry for the inconvenience as in the meantime I could solve my external I2C compass issue… which was coming from my RPi!!
I replaced my Navio 2 board --> still not working
I replaced my RPi3 with RPi2 --> working
I replaced my RPi3 with another RPi 3 --> working
After full cleaning of connections my “faulty” RPi3 worked again…
This is really strange behaviour as my “faulty” RPi 3 was perfectly answering mission planner. I am also surprised quality of connections can apparently variate from 1 RPi to the other (this might come from corrosion on the connectors due to exposition to humidity)
Wouldn’t we miss a safety check in the pre-arm code to test I2C connections are ok?
