We have just released v3.0.0-beta1. We soon be going around the website and making a few updates, but we want our community here to know about it first.
Beta1 is a major milestone in the software overhaul, we now believe it is good enough for most of our users with a few caveats for specific use cases that we will work on before final release.
Release notes (since Alpha 5)
With this release, we move v3 from alpha to beta 1. This release has combined some essential back-end changes with improving the user experience, especially during calibration and scanning. It also sees the return of the Gallery and Full SD card images with a graphical interface directly from the Pi!
Some highlights of the release:
A new Gallery tab replaces the Scan List tab With significant improvements including a faster database driven back end, new views and filtering, and improvements to the viewer.
Building a “full” SD card image with a graphical OS
Huge improvements to scanning including increase seed, previews starting earlier, a view for settings mid-scan, and improvements to the stitching algorithm
A new camera API which makes it easier to add new cameras, and better defines the capturing and streaming modes for cameras
Continued improvement and modernisation of the webapp including library modernisation, improved logging tab, and a better mobile/touchscreen experience.
Global locking of the server to stop actions happening at the same time.
Fixed autofocus frame timing so autofocus no longer overshoots.
A new microscope management server on port 5001
OS migration from Debian Bookworm to Debian Trixie
If you want a full OS including a desktop:OpenFlexure Raspbian v3.0.0-beta1 Full, OR
If you want a lite image for remote control only:OpenFlexure Raspbian v3.0.0-beta1 Lite
Select your SD card from the list
give your microscope a name, and select Next
Leave the localisation settings as they are and click Next
Choose a user name and password then click Next
Optionally enter your Wifi details, but you can skip this (you may need to delete the SSID for it to let you click Next)
Turn Enable SSH on and click Use Password Authentication (Unless you understand SSH keys and how to manage them)
Finally click write and wait for it to finish
Should I switch to v3.0.0-beta-1
Probably! You perhaps try it on a new SD card rather than wipe your current working OS.
If you are using a v3.0.0-alpha - Certainly, yes
If you use v2 of the server (the release currently on the website) - Probably, unless
You use the nano/pico workaround for the motor board - We need to update the firmware for these, we are working on it. (With an older Sangaboard, you may be required to update the firmware)
You use a delta stage - There is currently no Delta Stage support, we are looking to add it soon
You need a specific extension - We have plans for a better extension experience, but currently it is not ready. Due to the almost total re-write of the software v2 extensions do not work
When will v3.0.0 be released
There are a number of things remaining before a full release including:
More users and user feedback is needed (installing beta1 and giving us feedback will help us a lot)
A strategy/mechanism for OS/Server upgrades (Help wanted!!)
A new extension framework
Delta stage and other motorboard support
A configuration interface for changing plugins and camera/moorboard/stage configuration
for the impatient, you can download and save the manifest, correct the path in the urls, and use “local manifest” option in the imager instead of manifest from URL. then it works. if you instead download the image and use that as a custom image, unfortunately the imager won’t apply the customizations.
in related nuisance, for some reason the appimage flavor of the 2.x releases of the imager doesn’t seem to work on my laptop. fortunately there is a .deb installer in the raspberry pi website, just in case anyone has a similar experience. the symptom was validation failure during the write phase, and nothing ever written to the sdcard.
I used the AppImage if imager2 for testing on Kubuntu 24.04. Did the deb version re-download the image? I wonder if they store data in a different place. It might be worth checking the hash of the downloaded file, may have been pure chance that there was a download issue?
the imager seems to use a local cache, does not download again if you have downloaded the same image previously. at least it didnt for me. unfortunately it took several iterations, different images, cards, user configurations (sudo etc) until i ended up on appimage as the culprit. popos fwiw. the sdcard was all zeros, no writes at all. permissions or sandboxing perhaps.
Outdated OS/Servers become a risk to the rest of the network, thus I think providing that capability through standard OS tooling - ie standard package management is going to be key, as it slots in with company’s policies, doesn’t complicate operating models, nor require additional skillsets.
The code base is open source, and people can/will support/maintain their own combinations of versions, therefore I would suggest focusing on the “head” of the development. I’ve had the fun of maintaining patching across a large 1000+ estate. I’d strongly advise automating everything with zero manual configuration or logins - drive it all out of the pipeline, providing tooling to make it easy for people to support their own builds. They have the option for going for the reliable build and that would be the suggested option. If their hardware is a ‘bane’ (ie the third party drivers are out of end of support or end of life) then they could freeze the process and maintain it at risk.
a) Ensure reliability
An automated version that follows the long term support Raspberry OS. The OS patching is then managed by RP and the server is part of that. Automated pipelines could regression test for the current patch level - that could be triggered on OS updates being detected. It’s unlikely that the server and OS will fail due to incompatibility however there is a chance (pillow for example).
Automated testing of hardware installs can be done by netbooting the boot loader for the dedicated RPI hardware onto a build server. This installs the OS with an XML installation script, runs apt update/upgrade on the standard Raspberry OS installation and upgrades the server packagers. If the devices are hard linked (ie IP cable) this can be quick and relatively painless to automate full install, configuration and executing test scripts to test the server itself (ie an automated web tester to test the UI and thus the server).
A little hardware investment could be extremely beneficial in addressing this. (I had an entire AWS organisation for pipeline testing the AWS cloud platform, along with the 10 live organisations!)
On policy point - the more packages added not in the OS distribution, the more likely it is to have a problem with dependency incompatibility. The same is true with hardware combinations and to a degree we have to trust the drivers here. A sense check of appropriate camera with the appropriate age hardware should help reduce the combinations - older RPi with a Cam v2 and a newer with a Cam V2 and an HQ.
b) Enable forward movement
You’ve already got the backstop providing reliability, a similar pipeline can be triggered to test new features and installation on the above, you’re coding up the automation and that will feed into the reliability build on release.
A forward movement pipeline build would be “the current front” of the build and patching, it will break things and that’s the idea.
c) Deprecation - this is an important one
It’s worth adding to the forward build pipeline a deprecation warning stage - for OS and for hardware. It allows people to see if there’s a problem coming their way, they can plan and make for changes.