First build - Field Dissection Microscope

[Wacky]

Hello
I proudly present the first build of the Field Dissection Microscope :- )

Together with the OFM I built a few weeks ago I’m now ready to explore the microcosm… Thanks a lot for this wonderful projects!!

The build was quite straightforward.
For the bigger parts like base ring and riser I used a 0.6 mm nozzle. Just a little bit of sanding was required.
For the lens holder I used this M12 mount from thingiverse which fits perfectly well. The lens is a cheap standard 16 mm f/2.0 lens from amazon.

As a hobby astronomer I’m very impressed by the rack-and-pinion focus mechanism you created! I didn’t thought one can print such a thing. The only drawback is it’s missing endstop…

Here’s an example from a Bresser preparation slide: mouth parts of a honey bee

The picture is just slightly cropped.

Hope you like it :- )

[WilliamW]

Really nice build @Wacky How does the print time compare between the OFM and the field dissection microscope? The dissection version looks much bigger, but it has simpler shapes so might be quick to print with appropriate print settings.

[Wacky]

The OFM took about 35 hours to print. For the FDM (is this abbrevation acceptable?) my Voron 2.4 was busy for about 43 hours. 400 g filament was melted for the OFM, 1100 g for the FDM.

I usually use a 0.4 mm nozzle with 0.2 mm layer height at 100 mm/s print speed with 25 % gyroid infill. For precise parts like the OFM main body I reduce the speed to 60 - 70 mm/s. This resulted in a print time of about 16 hours.
For regions with threads I reduce the layer height to 0.1 mm. This doubles the print time but gives precise “cut” threads.

The FDM’s base ring was printed with a 0.6 mm nozzle. To maximize stability infill was set to 70 % with a rectilinear pattern. The print time was about 8.5 hours for this 350 g heavy part.
I also used these settings for the riser with about the same results. I had to extensively sand the lower edges of this part. These outlines don’t print well without supports. But finally assembled they are located on the rear side of the microscope and not a real problem.

To be safe I did use 2 thin supports on the inner part of the screen mount. Printed with a 0.4 mm nozzle it took about 13 hours to complete this component.

All parts with dovetails had to be sanded a bit and afterwards cleaned and lubricated. Their movement now is quite smooth.

The next steps will be evaluating the optics and trying to tinker an endstop for the focuser. I don’t want the camera and lens again to fall down into whatever will be examinated below ;- )

[Wacky]

Adding a physical limiter to the focus mechanism

When the top sides of the carriage and the pinion housing are on equal height, the carriage may travel down the dovetail for about 16 mm before it starts to get wobbly and gravity begins to strike.

I’ve added a physical limiter using an angled hook as it is used to hang up a picture on a wall.

First drill a hole near the top edges of the carriage, leaving enough space for the camera ribbon cable.

Scew in the hook. The carriage now looks like this:

Re-attach the cables and the clip and put the carriage back to the dovetail (the photo shows the parts without cables):

Take care that the hook cannot touch the components on the raspberry board! 21 mm is the maximum allowed height for the hook.

Now the carriage can no longer fall out.

As long as no sangaboard is involved with this microscope (hint!! :- ) this solution works perfectly well.

[j.stirling]

@Wacky

I proudly present the first build of the Field Dissection Microscope :- )

So awesome to see the first replication of this microscope. Thank you for posting, this really made my evening.

My collaborator in Panama will be building one soon, but there have been other delays to this work happening. It’s great to see the power of Open Source that thou beat him to it.

@Wacky

As a hobby astronomer I’m very impressed by the rack-and-pinion focus mechanism you created! I didn’t thought one can print such a thing. The only drawback is it’s missing endstop…

The gearing worked better than I though it might. The endstop is something I planned to do and never found time for. I like your hook end stop, I think at some point it would be good to integrate something into a print. To my eternal shame, my own microscope has the ribbon cable pinned acting as a physical limiter, nasty but got the job done.

@Wacky

Here’s an example from a Bresser preparation slide: mouth parts of a honey bee

[Wacky]

Some remarks about the software (Openflexure Pi OS and openflexure-connect)

The BOM suggests using a wireless keyboard with a built in trackpad. But this is not possible with the current configuration because bluetooth is broken. When trying to add a bluetooth device the list remains empty:

When I run the Pi 4B with the latest official Pi OS (Bookworm) there’s no problem connecting to bluetooth devices. Therefore the hardware seems ok. I also successfully tried with the latest Buster Raspi OS from 2021-05-28. Also with this version all available devices are visible. It even suggests connecting to our dishwasher on the lower floor :- )

It’s the same os with the same kernel as used by “Raspbian OpenFlexure”. I didn’t found the root cause of this error (yet, probably some incompatibility with the UART used by sangaboard), but it’s not a real problem. You could add a USB connected keyboard although being out in the field it isn’t very convenient to fiddle around with external devices, moreover when they are cabled…

Since the design uses a touch screen we already have a mouse. For the rare occasions when you have to enter text - like setting a filename for your saved captures - you just use a virtual keyboard on the touch screen (after all you use such a thing regularly on your smartphone ;- )
There are several of them, I use onboard.

To install it withyout a physical keyboard you have to remotely access you pi by using ssh. If you didn’t enable ssh access when flashing your sd card you can do it with the configuration app on the desktop:

Select the interfaces tab and enable ssh.

After connecting to your raspi just enter on the command line:

sudo apt install onboard

You can now start it from the raspi menu

Display configuration

The design uses a 7" monitor. These displays usually have a resolution of 1024 x 600. Unfortunately this specific resolution is not a selectable option in the screen configuration settings. If you select one of the available options like 1024 x 768 then the camera’s image on your screen is badly distorted. If you select 1920 x 1080 then the distorsion is minimized but text is too small and hardly readable. Furthermore the touch interface of the screen reacts very imprecise in this mode.

To configure this correctly you have to manually edit the file /boot/config.txt
You can do this again on the command line. If you are not comfortable with this you can also edit the file directly on the sd card while it is attached to your laptop.

Add these 3 lines to /boot/config.txt:

hdmi_cvt=1024 600 60 3 0 0 0
hdmi_group=2
hdmi_mode=88

Now your screen looks as it should.

One last enhancement. When you start OpenFlexureConnect you always get bored with the message on “what do you want to do” with the executable script.

To once and for all let it know that you want to execute the script you can set this “switch” in the settings of file manager. Open the file manager, go to menu → Edit → Preferences and put a checkmark at “Don’t ask…”

Now it won’t ask again :- )

[WilliamW]

I have always used wireless keyboards with a USB RF dongle, rather than Bluetooth. I have not yet got past the bad experiences with early implementations of Bluetooth peripherals which were rather temperamental.

Your solution to the execute question is really useful, I did not know that could be done!

[Wacky]

@WilliamW

I have always used wireless keyboards with a USB RF dongle

Ah, that’s why the BOM speaks of “wireless”, not Bluetooth (it helps if one can read).

@WilliamW

Your solution to the execute question is really useful, I did not know that could be done!

That’s why us system engineers were created, in a former life, long ago… ;- )

The comfort could even be enhanced if one could specify a target system to connect at OpenFlexure Client start. Then this could be set to autostart. This would be extremely useful on the Field Dissection Microscope. It would immediately show what it “sees”. Could this be done with this electron-based client?

You see, with every new user there are new requirements…

[WilliamW]

The instructions for the dissection microscope are not me, it is @j.stirling’s work.

The client is just a kind of wrapper for the web app. The point of Openflexure Connect is the discovery function to find what microscopes are available locally or on the network. If you know which microscope you want to connect to, you just point a web browser at <network name or IP address>:5000 . For a single microscope it is microscope:5000 or microscope.local:5000 by default. That would be the same whether you are working on the Pi that actually runs the microscope, or another computer on the same network. Whether the .local is present depends on some detail of the way the network that you are on is set up. With more than one microscope it is a little complicated as they somehow self-assign themselves to number 1, 2 etc. Then Openflexure Connect is particularly useful!

[Wacky]

@WilliamW

as they somehow self-assign themselves to number 1, 2 etc.

That’s a function of the DNS server in your network router. By default the hostname of Openflexure OS is set to “microscope”. As the DNS names must be unique these suffixes are added.

You can easily change this name using:

sudo raspi-config

select “System Options” → Hostname
After reboot the new name is set and recognized by all other network components.

[Wacky]

The final polish of the Field Dissection Microscope’s GUI:

automagically display the specimen

For this the web browser is launched at system startup in fullscreen mode, pointing to the local OFM server. This solution works with or without a network, independent of the actual name of your microscope.
Create a file with suffix “.desktop” in the directory “/etc/xdg/autostart”

sudo vi /etc/xdg/autostart/chromium.desktop

and enter the following lines:

[Desktop Entry]
Type=Application
Name=Chromium
Comment=Chromium Webbrowser
NoDisplay=false
Exec=chromium --disable-crash-reporter --start-fullscreen http://localhost:5000

After reboot your Field Dissection Microscope is fully functional without any manual handling.

To leave the fullscreen mode press “F11” on the keyboard or move your mouse to the top of the screen and click on the “X” (this “X” is only visible when there is no camera stream in front of it).

Edit: a word of caution
Before you implement this solution be sure to have started chromium manually and connected manually to localhost:5000 without being in fullscreen mode!
Otherwise you will not have a chance to skip or finish the welcome tour, which is hidden behind the web stream. This disables any other input on the web page.
After you could get rid of the welcome tour open the settings tab and disable “GPU preview”, but leave “Track window” enabled.

[j.stirling]

Great, thanks. I will try to get this into the instructions soon. It is also something that may be useful for the standard microscope too.

[Wacky]

After fumbling with the software it’s now time to have a look at the optics and its performance.

As I wrote above I’m using a cheap lens with a focal lenght of 16 mm at f/2.0, according to the description on amazon. On the lens it says: 16 mm, 5MP, 1/2.5", IR. The M12 thread has a lenght of 12 mm with a backfocus of 4 mm.
The M12 mount which I printed has a thread with usable height of about 10 mm.

With this lens at the uppermost position of the focuser with minimum magnification I get a FOV of 36 mm x 27 mm with a flat object. The distance of the front of the lens to the object is 155 mm.

On the 7" display the object is shown in a picture 120 mm wide with a magnification of about 3.3x
resulting in a resolution of about 45 μm / pixel.

The maximum magnification with the lens unscrewed as far as possible can be achieved at a distance of about 30 mm. The FOV is about 6.1 x 4.6 mm resulting in a resolution of about 8 μm / pixel at a magnification of about 20x on the screen! About 50 % is in focus.

Of course all the above results regarding magnification and resolution are purely calculative and just for comparison to get an impression of the possibilities of this microscope.
All in all it’s not that bad considering the 10$ lens I used. I will try and find a better one, also with a bit longer focal lenght.

It’s a bit shaky to get correct focus, because you have to set it on the lens rather than using the focuser, especially with higher magnifications. I will have to better lubricate the moving parts.

[Wacky]

A few additional things I noticed during the last hours playing with my new toy, to have it all in one thread:

If you switch off the microscope by just disconnecting the power then chromium complains at the next start that you didn’t “shut down correctly”. Of course that’s true but who cares?
To have it stop complaining change one parameter in /etc/xdg/autostart/chromium.desktop:

old:

Exec=chromium --disable-crash-reporter --start-fullscreen http://localhost:5000

new:

Exec=chromium --disable-crash-reporter --start-fullscreen --app=http://localhost:5000

No more grumping…

The downside of this hack is that you don’t have chromium menu items visible in case you eventually leave the fullscreen mode. So you would have to reboot to enter the fullscreen mode again. But this normally shouldn’t occur, especially if you enable the following tip (then you can use F11 instead).

If you use onboard as virtual keyboard you can set it to be autostarted as well. Use this command:

sudo cp /usr/share/applications/onboard.desktop /etc/xdg/autostart/onboard.desktop

To have it always available: in
Preferences → General add a checkmark at “Show floating icon when Onboard is hidden”

and to show it above the fullscreen window of chromium: in
Preferences → Window add a checkmark at “Force window to top”

If you move the floating icon to the right side of the screen it doesn’t get in the way of the camera stream and the keyboard is available at your fingertip.

Meanwhile I also received the new illumination. It’s a USB powered gooseneck light with 6 white COB LEDs which can be adjusted in 3 brightness levels. The best thing is it’s only consuming 300 mW!

If you closely compare the screen and the sample below you may notice that the video stream is no longer upside-down.
Thanks to @j.stirling’s fix there’s no more confusion when placing an object.

[Wacky]

To verify that all of the above instructions are correct I reinstalled everything from scratch with a new sd card. Now I got the following error after autostart of chromium:

It seems that the local OFM server isn’t ready for the client yet, because when I reload the page with F5 everything is ok again. I have no idea why this didn’t occur before…

To fix this error the chromium browser has to wait a few seconds before it is started with a connection to the OFM server. This can be accomplished with the following change in the autostart entry.

Exec=bash -c “sleep 7 && chromium --disable-crash-reporter --start-fullscreen --app=http://localhost:5000”

The entire file /etc/xdg/autostart/chromium.desktop now should look like this:

[Desktop Entry]
Type=Application
Name=Chromium
Comment=Chromium Webbrowser
NoDisplay=false
Exec=bash -c “sleep 7 && chromium --disable-crash-reporter --start-fullscreen --app=http://localhost:5000”

[Wacky]

Some more tests to judge the resolution with the cheap lens (16mm, f/2.0).
The diameter of the circle is 4 mm. 1 div = 0.01 mm

Focuser in about middle position:

at maximum magnification:

For comparison the same object using the OFM with a 20x RMS objective (20/0.40, 160/0.17):

[WilliamW]

@Wacky

If you switch off the microscope by just disconnecting the power then chromium complains at the next start that you didn’t “shut down correctly”. Of course that’s true but who cares?

In a Raspberry Pi, the reliability of the SD card can be a weak link. That is the main place where shutting down nicely can make a difference. There is shutdown within the web app so you don’t need to leave your clean interface.