Hi all,
Many of you might know that Raspberry Pi Imager2 was released and it changes how customisation is done, so if you just download a OpenFlexure Raspbian image it may not allow you to customise.
Until we sort everything out, the recommendation will be to use the Imager 1.9.6. But I do think that moving onto Imager 2 will be a big improvement in how customisations are applied as you directly click through them.
The issue is we now need to explicitly explain in a separate file how our images can be customised, and where they are available. I have made a test file for this if anyone wants to help me test it.
The new way means you shouldn’t need to pre-download the image.
You should now only be able to select the Pi3 or the Pi4:
If you select Pi 4 you should get options to install either 2.11.0 or the new v3 pre-releases:
Selecting either should bring up sub-menus. For 2.11.0 you can select Full or Lite, for v3 pre-releases there will be a list of pre-releases but currently only alpha4 is listed.
How do people like this workflow? I think once we have v3 released we will ask to be added to the official distribution list.
1 Like
Just wanted to say that I have this in my “todo” pile to try next week, just haven’t gotten around to it yet. I hit the same roadblock recently, so I love that there’s a convenient solution.
2 Likes
I watched one of my team do this on a Mac.
It was simple and worked perfectly, installing v3.0.0-alpha4 for Pi4.
I flashed V3, got a verification failure. I’ll try it in the microscope and come back to the thread. Got three other SD cards to flash today, V2s and V3s, so plenty of testing to be done.
Edit: Yup, this one didn’t work. I’m on imager 2.0.3 though, switching to latest.
Edit2: write stalled for 60s, cancelled. Retrying
Verification failures are usually not about what is in the image, just whether the file read back from the card is the same as what was sent. That notifies card read/write errors rather than whether the intended software would work. Faulty cards or card readers are usually indicated as the cause.
I think I might be facing some issues with my hardware. Tried flashing everywhichway I could imagine, on different versions of imager, on different SD cards, not one connected up to the wifi. I’ll do some more debugging tomorrow. I can see the boot partition on the SD cards, they go through verification, but for some reason the customization isn’t applied to any of them - not “default” raspios with trixie, not OFM images from 2.0.6 using this method and on 1.9.5.
Edit: counterfeit SD cards…
We recently updated our advice on SD cards. It will be in the next release, but is currently on the development build with notes and part link.
The A1 or A2 class is important, and we see noticeable speed improvement for dealing with large scans with U3 or v30 designation. In the UK the lowest cost SD cards that satisfy that requirement seem to be the Raspberry Pi branded cards. Many other brands pair A1 or A2 with very fast read/write which makes them expensive, but the Pi hardware cannot match much faster than U3/v30 anyway.
Yeah, I went for an A1 Sandisk, the Ultra series which came well recommended for RPis. Issue is they’re fake. Some of them were binding in the slot of the RPi, one just couldn’t verify, etc. Couldn’t register on Sandisk’s website to purchase them (some bug with VAT numbers) so purchased them at a different spot, not straight from the manufacturer.
The packaging is really similar to “official” versions, obviously improved over the years (looked for “spot fake SD cards” vids on youtube). What really sold it, was them saying “watch the speed - originals have 140MB/s, while the fakes are 150”. I checked the speed, it says 140, but in the small print it keeps the 150MB error, which isn’t present on authentic versions.
Edit: see pic below for the fake, letters are bleeding through to the top. Probably SamsuNG? The funny part is, you have to look at it from a distance, or a thumbnail, it’s easier to see it in the photo that way.
Urg, that sucks. I wonder if we can do a disk test on the Pi as well (assuming the SD cards are good enough to actually install the image).
I’m installing all of my microscopes headless, so I don’t think it’d be possible to do much. I’ve sent them back for a refund and ordered straight from Sandisk this time. I don’t know if this is just this specific Pi, but ethernet doesn’t work on it either, even with a previous, working setup / original Pi card. One did install “properly” but without any of the custom info to connect wifi, so it was probably stuck on being unable to spool up because of the HQ camera.
Got the new cards, straight from the manufacturer. Setup an HQ microscope, it works and it worked perfectly instantly. I’ll later today / tomorrow assemble a V2-server based one. Would be cool to have the ability to choose V3-alpha + HQ without having to mess around with the configs in the future. I wonder if it’s possible to get options for other things too, like the stage class
Authentic cards pictured below for comparison
1 Like
These settings are for the future, but all being well will be things that you can set from within the software, not needing actual changes to the base code.
1 Like
Worth noting that these are very much in development features so the barrier to setting them ensure it is only developers playing with them and set expectations on how well they work.
The plan is eventually that the microscope will be on port 5000. A second management server will be served on a second port. The management server will have an interface for setting configuration, restarting the microscope server, performing upgrades, etc.
We are some way away from this, but rest assured the final plan will be that no one should need to SSH into a microscope and edit a settings file by hand.
2 Likes
V2 based server installed properly too, lite version. Printing something to put the sample on, and trying the scan in a minute
2 Likes
