Wifi hotspot fallback

Contributions
1

Hello everyone,

First off, a huge thank you to the entire team and community for developing such an incredible open-source tool. We are quite new to OpenFlexure, still exploring and are consistently impressed by the project’s quality and vision.

We’ve noticed that the initial WiFi setup can be a bit of a hurdle, especially for users who aren’t familiar with Raspberry Pi. The current methods require either connecting a keyboard and monitor or manually editing files on the SD card before the first boot, or playing with the rasp flashing utility, but it’s hard to modify then for a random user.

To improve the out-of-the-box experience, I’d like to propose a new, much simpler approach for network configuration.

The Proposed Solution: A Fallback WiFi Hotspot
The idea is to implement a system that is now standard in most modern IoT devices, from smart plugs to 3D printers (we use this daily with our Klipper/RatOS-based printers).

The user experience would be as follows:

First Boot: The user assembles the microscope and powers it on for the first time.

Hotspot Creation: Since it has no network credentials, the microscope automatically creates its own temporary WiFi hotspot with an obvious name, like OpenFlexure-Setup.

Connect with a Phone: The user takes their smartphone or laptop, opens their WiFi settings, and connects to this OpenFlexure-Setup network.

Automatic Configuration Page: Upon connecting, a simple web page (a “captive portal”) automatically opens in their browser.

Configure: This page allows the user to:

Scan for local WiFi networks.

Select their lab or home network from the list.

Enter the password.

Done! Once submitted, the microscope saves the new credentials, disconnects the temporary hotspot, and seamlessly connects to the user’s chosen network.

This entire process would take less than a minute and requires no extra hardware or technical knowledge.

Key Benefits
We believe this would be a game-changing improvement for several reasons:

:sparkles: Drastically Improved User Experience: It makes the initial setup feel modern, polished, and incredibly user-friendly.

:laptop: True Headless Operation: It completely removes the need for a dedicated monitor, keyboard, or SD card reader after flashing the image.

:person::microscope: Increased Accessibility: It significantly lowers the technical barrier for new users. Scientists, students, and educators could get their microscope online without needing any command-line skills.

:counterclockwise_arrows_button: Easy Reconfiguration: If the microscope is moved to a new lab or location, this process would automatically trigger again, making it trivial to connect to a new WiFi network.

A Feasible Technical Path
This isn’t something that needs to be developed from scratch. This functionality can be implemented robustly on the Raspberry Pi using existing, well-maintained tools.

A solid approach would be to use NetworkManager to handle the dynamic switching between Access Point mode and Client mode. On top of that, a project like Balena’s wifi-connect is a nearly drop-in solution that provides the hotspot, the captive portal, and the logic for saving the configuration. Integrating it into the OpenFlexure image could be relatively straightforward.

We feel this feature would perfectly align with the OpenFlexure project’s goals of being accessible and easy to use.

What does the community think? Would a feature like this be valuable for your use case?

We’d be happy to contribute to testing or provide more feedback if this is a direction the project is interested in exploring.

Best regards,

Patrice

1 Like
2

Hi @Patrice. Making first use as easy as possible is important, but does tend to fall between the development of the hardware and build instructions, and development of the Microscope interface software.

Microscope operation is usually more reliable with a wired network connection, but wifi is much more convenient for many. I don’t know whether there are security implications of having a hotspot fallback as you suggest. It might be something to offer on a separate version of the OS build. You can set up wifi when burning the SD card with the OS customisation in the Raspberry Pi imager, but that would not work if SD cards are supplied with the OpenFlexure OS installed.

Having the fallback server whenever it loses connection could be a problem on slightly unstable networks.

3

Honestly, we have about 15 3D printers setup with this setup (RatOS) and never had any issue, they don’t even have a screen or any button whatsoever.

It has been a game changer, and still leaves the options to shut wifi off completely after initial setup.

1 Like
4

On the contrary, when we sell a 3D printer to one of our clients, they just have to switch it on, the self generated SSID appears and it takes 2 mn to set iy up on the local SSID.

1 Like
5

Sorry I was not clear - I meant that using the configuration in Raspberry Pi imager to set up wifi would not help if the image is written to the SD card by a supplier rather than the user.

I agree that many systems do use a fallback hotspot type of configuration, and it can work very well. I am just not sure what other considerations there are in implementing that securely and reliably.

6

One issue is that I believe EU regulations now prohibit hard-coded default passwords. I think that’s why the Raspberry Pi imaging tool now prompts you to add username/password when burning the SD card (and why we no longer have the hard-coded default password on our v3 alpha images). I guess a captive portal could work if it only permits the user to enter a secure SSID/password or join an existing network and then reboots with the new configuration - that is I think what you’re suggesting. It might take a little thought to combine that with the wired network - perhaps this is something we can revisit once we have a web interface for configuration/set-up.

My experiments with the built-in Raspberry Pi WiFi were mostly on older operating systems and older hardware: it was always quite painful, and never reliable enough that I wanted to recommend it to people as a way to use the microscope. I know @j.stirling uses WiFi via a travel router, rather than relying on the built-in module, and has found that to be a nice solution. If the built-in software and/or hardware have improved since I last tried it (and it sounds like perhaps they have) it might be something to look into again.

My major worry is that, by building in WiFi support, we’ll then be expected to troubleshoot when it doesn’t work. I’d be interested to see a version of the disk image, or (more easily) some relatively portable code that implements a captive portal as you suggest - but I think most of the core software team are focused on critical issues to get a v3 release out, so it might not be something we can implement quickly.

Perhaps you could open an issue here for further discussion:

1 Like
7

I can give my perspective as a user that built the microscope, without any previous Raspberry Pi experience. I do have extensive programming experience and messed around with some devops work in a previous life. A hotspot like this would’ve been a godsend.

For context, I setup the microscope without access to an SD card reader, monitor and keyboard, so fully headless setup. This is something that I’d expect would happen if I wanted to demo the device when visiting someone, to show them “it works on your system too”. Essentially as if they’d just bought the microscope and didn’t have someone to configure it for them right there, they “take it straight out of the box”.

I initially looked for any type of wifi connection with the default raspbian image. I didn’t find it, since it’s not enabled by default (and I got a pre-installed SD card with it disabled). I had to debug a bunch, then used a USB stick to which I flashed a new image and configured my own wifi credentials. Then had to SSH into the rpi, enable the remote graphical interface, to then take a photo from the microscope for the first time.

With OpenFlexure Connect and the OFM image, the process is simpler since I install a program and just need to worry about the connection. Ethernet didn’t work for some reason, maybe it was the terrible cable I used, but it just wouldn’t do anything. The other issue was raspberrypi.local / microscope.local didn’t work, I have to connect to an IP. When I got the wifi connected, it all worked fine for the short time that I used it, but I didn’t do any scans or ran it for longer.

So regarding the issues that were brought up in this thread:

  1. Security / fallback - just add a button on the body of the microscope, label it “reset wifi credentials”, “wifi hotspot configuration” etc. After initial setup, the microscope only connects to the wifi network it was supposed to connect to. If you want to change that, you hold that button for a few seconds and it goes into fallback mode. Fallback mode lasts for up to 2 - 3 minutes, during which you need to connect to it, which then lets you setup wifi access to your actual wifi network. This means you need physical access to the microscope to change the settings. By that point, a malicious actor could just bring an alan key, unscrew two screws, swap the SD card to their own image anyway. This also solves the unstable network problem, it just won’t connect anywhere else.

  2. Manufacturer setup and EU laws - flash in a random SSID, a random default password for each device, so the users need to set it up through “pairing” to the microscope. Not even the manufacturer will know it.

  3. Wired connections - on first connect, ask the user if they want to setup wifi or disable it. Pressing the pairing button would still result in the hotspot-setup being available when no ethernet connection is present. Possibly we could add in ssh and remote desktop enable - disable choice within some advanced settings too?

  4. Troubleshooting wifi - I don’t think this would impact any of the current user flow, only enable new possibilities. If the wifi hotspot wouldn’t work, a user could still use the Raspberry Pi Imager to flash in their own image with their own credentials. If in 3), we would’ve instead opted to ignore wifi completely unless the pairing button was pressed, then there’s no behavior change. It also would require the physical button, so it would only be a problem for the people, who would go for this very specific customization.

  5. Serviceability / user proofing - even without a dedicated button, we could have the maintenance person short out two inputs with a screwdriver to reset the wifi connection. Alternatively, just leave the button inside the electronics enclosure, so it won’t be an issue with young students pressing stuff during lessons and “bricking” it.

1 Like