I did the ofm upgrade and update and these are my results. I tried 3 different LEDs. The one with the red arrow gave me the best results on the other microscopes.
I am not getting even illumination regardless on how I position the condenser.
In this loop I started with a green image which does not get better after full calibration.
I also get the funny looking grid pattern
It can not be that tricky to get even illumination. I am puzzled.
I tried with a pi zero 2 and it kind of works. However, it is painfully slow to run the raspbian desktop
Oh dear, that does not look good. There was actually a similar thread last August Blurry green image - Request Help - OpenFlexure Forum which was after when we had the 2.10.0beta, so the old green problem from v2.9 should have gone away.
@r.w.bowman, could this be previous calibrations not being wiped properly? does disable flat-field correction wipe everything including exposure?
Looking at the gif, and the settings it shows, I think we are seeing saturation here, even with a very short shutter speed. That suggests you have extremely bright illumination - what optics are you using, and what LED? You must have found a really bright one I think! If you’re saturating the illumination, that will confuse a lot of things - could you use a dimmer LED, or perhaps diffuse it by sticking some white PTFE tape over the LED? If you deliberately misalign the condenser (e.g. by moving it upwards) do you see it improve? Also, is your illumination green, or white? If you’re calibrating with single colour illumination, it is very likely to get confused, @samuelmcdermott may be able to comment on how well the 2.10 calibration works for single colour illumination.
I think you may be right. This is probably a very bright LED. I will try to adjust the brightness using pulse weight modulation.
For those interested you can connect your LED to pin 4(5v) and the other to pin5 (GPIO 3)
run this code
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setup(3, GPIO.OUT) #this is set to GPIO3. change the number is you want another pin
P=GPIO.PWM(3,100)
P.start(50) #50% brightness. Adjust this number to increase or decrease the brightness.
Quick update…Did not work 
This approach makes the LED flicker creating horrible horizontal black bands. I will post a pic later.
@dgrosen I am not too familiar with the RPi PWM but the effect that you describe would happen if the PWM frequency is too low. The on and off time of the LED is long enough for it to be on for some lines and off for others during the camera frame capture. You should be able to set the PWM to quite a high frequency so that this does not happen. I don’t know where in the GPIO commands this is set. Searching seems to suggest that it is the 100 in P=GPIO.PWM(3,100) giving the frequency as 100Hz. That would certainly give the effect that you describe and needs to be higher. I don’t know how high the Pi will allow it to go. 1000 Hz would be better, 10000 or more is ideal.
I will try that. Hope I don’t create a time portal.
I found this article to generate software and hardware PWM. Somewhere I read that using C is much faster and does not create flickering.
The hardware PWM is likely to go to higher frequency, but I am struggling to find the maximums for the GPIO.PWM, which seems to be a software PWM. Hardware PWM libraries seem to be available for Python, not just C.
Hardware PWM is also more precise, but that is not so necessary for dimming and LED.
That is not useful, but really cool. Clearly needs to be even faster to work for dimming, which will need hardware PWM. From the top picture you will need to go to a pretty high frequency. Or you use the resistor dimmer from the other thread that you posted in.
The inconsistency of the software PWM is clearly seen in the images in ‘missed’ dark bars. It is interesting that there are no extra wide dark bars.
I am still experiencing several problems with my illumination. I changed to a diffused LED (the one in the middle). I get a more even illumination in the field compared to the one with the red arrow.
However, the calibration gives me a sky blue illumination. I dont know how to fix this. I decided to start with fresh installation followed but ofm update & ofm upgrade.
The warning could be the root of the problem, there might be an issue with the actual camera (or cable).
However that screenshot looks like the old server 2.9.x interface. Did the ofm upgrade maybe fail in some way?
Is all possible. I just purchased a couple of 8MP cameras to replace this one.
I am doing a new install after that.
That screenshot is not what I’d expect from a v2.10 server; the new calibration code should give you separate buttons for lens shading/flat field, exposure, and white balance as well as the existing auto calibrate button. I think something must have gone wrong with the update. Does it report 2.10 in the “about” tab? If you run sudo ofm update a couple more times, then re-run sudo ofm upgrade it may fix it, if there was a problem the first time.
I have seen the current SD image fail to update due to certificate checking problems, so I need to update the image as a matter of urgency.
I replaced the camera. Erased the SD card and put a new install. Run sudo off update and sudo off upgrade. I upgraded to a new Arducam Raspberry Pi Camera Module 8 MP, 1080P IMX219 and shows as disconnected. But the system does detect it.
Any idea how do I fix this?
The old 5MP works fine. The colors look fine too. But cannot set the illumination right with this one as stated above.
Arducam cameras are not something I’ve ever used. Typically, they use the same CSI ribbon cable as the official cameras, but they are not supported by the same drivers, because they offer a much wider range of sensors. The IMX219 shoudl be a special case, though; it is the same chip used in the official Raspberry Pi camera module v2. I think there’s an additional DRM chip required on the camera board to make it work with the Raspberry Pi GPU firmware though, which Arducam may not have.
A quick search brought up some arducam docs that suggest it should work with the picamera module that’s used internally by the OpenFlexure software.
A very useful quick test you can do is to open a console and run:
ofm stop
raspistill -t 0 -f
That should display the camera image full screen on the Raspberry Pi’s monitor. Hit <control> + C to close it. If that works, then the camera is talking to the right drivers, and the problem’s somewhere else.
Just to check, you’re using an OpenFlexure SD card and have not upgraded to Bullseye, right?
I learned this the hard way. Arducams are not fully compatible with RPi. Or at least it takes a lot of fiddling and playing to make them work. Very unreliable.
I bought 2 of them for US$22 as a bargain on Amazon. Even though the cameras are detected I get this error.
mmal: mmal_vc_component_enable: failed to enable component: ENOSPC
mmal: camera component couldn't be enabled
mmal: main: Failed to create camera component
mmal: Failed to run camera app. Please check for firmware updates
Not much documentation of this online Apparently, It can be caused by a million things including defective cameras. I also read that because of the current chip shortage there may a lot of counterfeit cameras sold online.
So I learned my lesson…you get what you play for.
Ah, that’s a shame - I could imagine that it’s the DRM chip that’s missing, though if their docs claim it should work, it would be a bit brazen of them not to include it! Anyway, at least you have an answer…
A post to link this thread to the solutions and lessons: New lessons learned -https://openflexure.discourse.group/t/new-lessons-learned/849