It is not clear to me how this board is supposed to be powered. In the photos it appears to be powered with a USB-C cable. What is at the other end of this cable? I expect that a phone charger would suffice, but what about plugging it into the raspberry pi itself, assuming that the rpi power brick is beefy enough?
I wish to request that a bit of documentation about the Sangaboard is made available. Especially valuable would be current and voltage ratings, pinouts, schematics, and drawings.
Good point, I forgot the board changes how things are powered. The board is powered via USB-C at 5V and provides power to the Pi, so a single power supply can power the microscope. The motors are power-hungry so a 3A minimum power supply is required for reliable performance. The Pi’s and Sangaboard’s 5V lines are connected, so if the Pi is powered it will power the Sangaboard via the 5V pin which should also work if the power supply used can provide enough current, but it might go over the rated current of the micro USB connector if it’s Pi<4.
Schematics and KiCAD files are at Files · master · Filip Ayazi / sangaboard-rp2040 · GitLab
More documentation and instructions are in the works, but please do ask here if you have any questions.
Hi @letshin,
Below are all steps that I did in my installation of Sangaboard v0.5.1.
I have rPi 3B+, and after flashing Openflexure raspbian, I followed all steps from Serial Port setup in Raspberry Pi OS, including “Disabling the Serial Login Shell” and " Using the PL011 UART port" steps.
Then I followed the steps from @filip.ayazi GitLab
I got permission errors during the first step, so I had to grant group +w permission. I see that Filip already updated the README.md file 
After restarting and further (optional) updating the raspbian, everything works as it should.
In my case, both power lines work correctly, via the Sangaboard v0.5.1 or rPi 3B+.
While this will work it is very much not recommended because of the effect of possible failure modes.
It is fairly likely that something connected to the Sangaboard might take a lot of current, for example motor failures or the batches of motors that some people have that take a more current than normal.
Scenario 1: The power supply is plugged into the Sangaboard.
The Sangaboard itself is likely to be able to stand that current without catastrophic damage - the power wires to the outputs are designed for current. The user might notice and correct the fault. While in the high current condition the power supply might not be able to keep at 5V, the voltage might drop a bit. This would mean that the voltage fed through Sangaboard to the Pi drops which the Pi will flag up as low voltage but often will still manage for a time until the fault is corrected.
Result: For medium over-current everything is fine. For large overcurrent the Sangaboard is damaged and/or the Pi has an unexpected shutdown (voltage much too low) which might corrupt the SD card but is unlikely to cause damage to the actual Pi board.
Scenario 2: The power supply is plugged into the Pi.
A high current flows through the Pi power circuit to the GPIO pins. This is not designed as a high current path on the board and is fairly likely to damage the Pi. The Sangaboard itself is likely to be able to stand that current without catastrophic damage. While in the high current condition the power supply might not be able to keep at 5V, the voltage might drop a bit. This would mean that the voltage fed to the Pi drops which the Pi will flag up as low voltage, this might give the user time to spot the impending fault condition and avoid damage, but probably not.
Result: For medium over-current it is likely that the Pi will be permanently damaged, which is costly. For large overcurrent the Pi will certainly be permanently damaged and Sangaboard might be permanently damaged as well.
The high probability of high cost failures mean that this is not recommended.
This is a very good point. In addition to that, Sangaboard has a polyfuse on its USB power input which should be enough to protect it from damage in an overcurrent condition.
I’ve built the required changes into an SD image so that it’s easier to use until they are merged. The image includes the required serial changes, the modified pySangaboard module version and the Sangaboard software extension for controlling illumination and upgrading firmware.
Here are the full image and lite image. With these images, the boards should work out of the box (tested on a Pi 3, I’ll test it on a Pi 4 soon but it should work the same). Please consider these a temporary fix until the changes are reviewed and merged into the official distribution version and when that happens migrate to an official version to get the best experience.
The full image might be corrupted. The lite image worked just fine on a Pi 4 2GB.
Hi @filip.ayazi I have been in Python dependency hell for a couple of weeks trying to release a new OpenFlexure image. Did you persuade this to build using pi-gen, and/or managing dependencies with pipenv or have you done it some other way?
If you’ve got pipenv to re-lock dependencies without breaking, I would love to know how If you have used another solution, anyone using this image should be aware that it may not be compatible with updates in the future.
You shouldn’t need --user in the virtual environment - this probalby indicates the permissions are wrong. Could you try running:
cd /var/openflexure
sudo chmod -R g+w .
sudo chown -R openflexure-ws.openflexure-ws .
If you try to install sangaboard again (pip install --upgrade sangaboard) this should not encounter permissions problems.
Hi Richard,
I used the openflexure-pi-os repo and added an extra chroot step to stage2a. It took about a day of weird issues but it did build working images using the docker build method.
Extra script run on chroot (including the debug echos) was
#!/bin/bash -e
# Extras
source /var/openflexure/application/openflexure-microscope-server/.venv/bin/activate
/var/openflexure/application/openflexure-microscope-server/.venv/bin/pip3 install --upgrade pip
echo "Remove sangaboard"
/var/openflexure/application/openflexure-microscope-server/.venv/bin/pip3 uninstall -y sangaboard
echo "install dev sangaboard"
/var/openflexure/application/openflexure-microscope-server/.venv/bin/pip3 install -U git+https://gitlab.com/filipayazi/pysangaboard.git@sangaboardv5
echo "install pio"
/var/openflexure/application/openflexure-microscope-server/.venv/bin/pip3 install -U platformio
/var/openflexure/application/openflexure-microscope-server/.venv/bin/pip3 install -U semantic_version
mkdir -p /var/openflexure/extensions/microscope_extensions/
cd /var/openflexure/extensions/microscope_extensions/
echo "download extension"
git clone https://gitlab.com/filipayazi/sangaboard-extension.git
chown -R openflexure-ws:openflexure-ws /var/openflexure/extensions
Actually, now I look at it I also reverted the last commit which switched to using diffs and manually set config and cmdline files which meant I had to disable some config patches in stage2/01-sys-tweaks/00-patches/series.
The 0.5.1 board has been great.
When building the electronics_drawer.scad, function sanga_stand_height in lib_microscope_stand.scad needs to be changed from 12.5 to 15.5 to accommodate the header offset.
function sanga_stand_height(sanga_version=“v0.4”) = let(
extra_h = (sanga_version==“v0.4”) ? 15.5 : 27
) electronics_drawer_standoff_h() + extra_h;
Hopefully someone will commit a sanga_version==“v0.5” soon as I have not quite figure out gitlab.
Also need to adjust the side cutout on microscope_stand by a little bit (3mm looks nice) as the USB-C connection gets pressed down by the stand on an unmodified base.
@mmca there is a branch and merge request to modify the stand to fit the taller header which @filip.ayazi installed on his new Sangaboard. When I was building it I found that changing the Sangaboard height made the nut that attaches the drawer get in the way of fitting the Sangaboard. The merge request !319 makes quite a few changes to accommodate different versions of the motor controller. There is a link to view app on the merge request page that will take you to the full build of the instructions with the STLs of the proposed changes to the stand. This is not finalised or checked so you should only use it on the understanding that it may not work! If you do build it it would be really useful to have feedback on the merge request in the comments in Gitlab.
ok, I have finally (after a lot of days of frustration) sorted out the Python dependency mess and can properly include pysangaboard v0.3.3 in the next SD card image (that’s the version that will work with v5, though it doesn’t add any extra features). The improvements I’ve made to our packaging/dependency/testing infrastructures should mean that upgrading it in the future is easier.
The next SD card image will also remove the serial console and add enable_uart to config.txt. Are there any other changes you needed to make to get it working? I didn’t see a link but perhaps you forked the repo somewhere?
Is pio required for sangaboard support in the software, or just by the extension? I’m slightly wary about adding it as a dependency (because I’ve struggled to get it to install reliably in the past, and dependencies are a nightmare in the Raspberry Pi build as it is).
My plan for the next major release will fix a bunch of things, and hopefully make it way easier to include extensions that can be enabled or disabled as required. However, I would be a bit nervous including pio in the server virtual environment, because it may then break (or be broken by) the server’s use of pipenv e.g. during upgrades. Is there any way pio could be confined to its own environment? I think you only call it via command line anyway, so that shouldn’t be a massive change.
I think it would be good to include this, properly, in the next major release. Getting a separate environment with pio, and pre-cloning the extension, would also be feasible sooner - and it could then be enabled with just a symlink. However, I’m a little nervous about including more extensions that are enabled by default before we have a sensible way of managing and testing them.
@WilliamW Thank you, wish I had seen that earlier. I used 3mm as the adjustment but it looks like it should be 2.5mm. Will try the shifted side screw/nut holder in the next build.
I moved everything up 3mm and it worked fine, but the screw being moved looks like it will make placing the hat a little easier.
Excellent news! I also did the miniUART swap with dtoverlay=miniuart-bt in config.txt. I don’t have the changes cleanly anywhere unfortunately, I just hacked it together inside pi-gen for part of it as I was losing patience after some very bizarre issues, but the 2 changes you mentioned + the overlay should be all that is needed.
PlatformIO is only used to download a package, which I see more as a temporary hack when I wanted the image available ASAP. In fact, what might work is just downloading the openocd release directly from github, which can probably be done inside the extension itself without the need to have anything extra in the image (I’ll try to test it soon, but probably not this week).
Brilliant - I wasn’t totally sure whether the mini UART swap was required for Sangaboard v5 or not - it certainly is for v4, but v5 has rather more reliable serial timings, I think. I also need to think carefully about which Pi versions the uart swap is needed for. One article I read suggested that enabling the UART automatically swapped the UARTs (or even just disabled bluetooth) but that doesn’t match with my testing on Pi 4 so far.
Thanks for the explanation of PIO, that makes total sense - last time I tried to actually compile the firmware on a Pi, I couldn’t get everything that was needed for arm. If you just need that one utility, that explains why it works - and I agree, if you can just get it when it’s needed (or even better bundle it in) that would be perfect. I try to make as much as possible of the server (and client) work without an internet connection - so if I can pre-download openocd to the SD image, that sounds like a good option. I already pull in various utilities “just in case” so it would be very much in keeping with that.
The proper UART should be more reliable, but the mini also mostly worked (I did get some garbage once, but I think that was with a bad power supply). I think the miniUART is connected to those pins by default on all Pi versions, but Pi4 has a few more UARTs available, so we still need the swap. There’s some documentation on the UARTs on Pi here documentation/uart.adoc at develop · raspberrypi/documentation · GitHub
The only thing openocd is used for is for uploading the downloaded firmware for firmware upgrade in the extension so with the current set-up of the extension it still needs internet access, but it’s probably a good idea to add an option to manually upload a firmware file to the extension.
From @OpenFlexure on Twitter:
“We’re celebrating World Microscope Day by releasing the next version of our software, v2.11.0. Excitingly, it works with the newest version of the motor controller SD card image coming soon!”
I think this means that if you
ofm update
ofm upgrade
on the command line of your microscope, it will fetch the new server software. In the Microscope web app it should report the current version number in about and the Sangaboard v0.5 will work. I have not tested it yet myself.
Worth reiterating that this does not automatically add the lines to config.txt/cmdline.txt. I’ve built an OS image that should, just need to test it.