Why Bluetooth and not WiFi AP mode?

In my few days of testing, the Bluetooth comms between modules and phones is a nightmare… Disconnects, messages never appearing in app, repairing needed along with previous messages not buffered. Only benefit I see is lower power for battery use case… Otherwise its atrocious. With WiFi ap mode and an IP based app or better yet a web frontend we could have multiple phones/devices connecting to the mesh nodes, logging and calibration of basic sensors/battery voltage… IRC type chat agent, etc. BUT, that aside I am blown away with these radios, 2.6km NLOS and the garbage stub antennas still managed a connection!

You’re right that BLE doesn’t use very much power while Wifi uses a lot of power. Wifi clients also don’t really like being connected to more than one AP at a time.

That said, we support both :slight_smile:

Information on how to use the WiFi interface:

The web interface is a work in progress and is not yet supported, but you can take a look at the screen shots here:

1 Like

Yeah I saw that and it looks like a good start. I understand that phones and devices cannot connect to multiple simultaneous APs… “Without multiple WiFi radios” but maybe I’m missing the end goal of this project from the origins of “LoRa” long range, remote, solar powered soil/water/temp/weather stations needing max battery life to an alternative cell/internet long range and secure communication system where the benefits and simplicity of WiFi AP with web redirect for any phone or PC with a browser could utilize the system? Am I way off in my thoughts?

Hmm. Bluetooth seems mostly solid right now for most users. But I don’t doubt at all that you’ve found a bug. If you could lists the Android version, the phone model and the steps that happens when pairing is lost I’d be super happy to help find the cause.

Is it possible you are mostly seeing our sleeping behavior? Ie. The device leaves Bluetooth off most of the time, waking every few minutes to check for messages from the phone or waking instantly when a message arrives from the mesh.

(This limit applies only to esp32 based devices, nrf52s leave Bluetooth always awake)

I think the goal of minimizing power usage and as a result, extending the battery life is very admirable. If you’d like to change the settings, the python API will be the way to do that. In the future, those settings can also be edited through other methods – like from the android app or over wifi with the webui.

There’s two things I really enjoy in this project. I love hearing from people are all the perspectives of where and how this can be used. I also love the passion of people who volunteer their time and skills to make this work together.

@geeksville is very passionate about using BLE for his use cases while there are others like myself and you who are passionate about connectivity over WiFi. It’s great that this project allows for both to coexist. As with any open source project, contributors work on what they want.

I look forward to your feedback as we roll out the wifi features! There are updates every few weeks.

4 Likes

@Black6spdZ - I wonder if this was the problem you encountered?

Thanks, ill give new app a try. It should match firmware version 1.1.32?

Doesn’t need to (the version numbers go on slightly different tracks, but alpha device loads need the prerelease android app. So if you are using alpha device builds opt in to join the betatest on google play)

Got it, I’ll try this version out. Thanks again!

1 Like