Sangaboard v0.5 now available

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.

1 Like

@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.

1 Like

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).

1 Like

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 :slight_smile: 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.

1 Like

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.

@mmca I have only now noticed the neat little display you have added to the stand on your microscope. What do you use that for?

It’s an i2c display that shows the IP address of the microscope.

I built this one for my daughter’s elementary school and they have a very restrictive wifi network topology.

So if they have the IP address it will still route to the microscope even if discovery doesn’t work across network segments.

3 Likes

Thank you, That is a neat idea.

Does someone know how the constant current driver work on the sangaboardv5? Can I just attach any LED no matter of the rated voltage because the current is limited?

Do you have some specifications @filip.ayazi?

The driver chip is TPS61060DRBR configured to give 0-100mA (5.1Ohm on the feedback), you can control the current through the Sangaboard extension. It should work for most LEDs, the only restriction is the forward voltage of the LED should be in the range of approximately 2.5-5 V (The chip is powered from 3.3V and there’s a diode in series to drop some extra voltage because it’s a boost converter and needs output voltage > input voltage). If the forward voltage of the LED is too low the current won’t be controllable until the output>input condition is satisfied (capped at around 100mA).

1 Like

By default I believe @filip.ayazi has the current set to 25mA if it is not altered using the Sangaboard extension.

1 Like

I’ve got a Sangaboard v0.5.2 that I bought with the illumination kit. And, I’m running the latest Raspbian Openflexure release on the Pi. But, I’m not currently getting any illumination.

There instructions in the documentation seem to suggest that the illumination board should be wired to the 5V/GND pins on the board and not the LED pins. But, the illumination kit came with a little slip of paper warning against this and the ofm-led repo also says not to connect directly to 5V, and instead to use the constant current pins (I presume the CC pins of the LED pin set). Does anyone know which pins should be used?

That same documentation also suggests that the firmware needs to be uploaded. I was hoping that this step might not be necessary for the Sangaboard v5. Is that step necessary? Is the latest release in the sangaboard-firmware gitlab appropriate? Is this done over the USB-C port to another machine? (The above discussion seems like the firmware can be upgraded from the Pi, but not sure about bootstrapping it).

I found the the extension for the sangaboard seems to exist and be installed on the Raspbian image, but I’m not really sure how to interact with it, or if there are any diagnostics I can run. Any help would be appreciated!

Hi @jyellick. The electronics part of the instructions are slightly muddled because there are several versions of electronics that will all work in different ways. The main Openflexure instructions detail using the led board that is illustrated in the instructions (that includes a constant current driver), or the work-around 5mm LED with a resistor. These take a 5V supply, as detailed in the instructions. For the motor control the only options until recently were to have a Sangaboard v0.3 made specially or to use the nano-workaround, and both of these need the firmware to be installed.

The Sangaboard v0.5 has some extra functions, and it is possible to buy it. The main Openflexure instructions have not fully caught up with that development. @filip.ayazi will have already installed the firmware if you got a Sangaboard v0.5 from him. Any instructions and illumination that came with the board should be correct for the parts that you have been sent. They may be different from the default parts in the standard instructions. In particular it sounds as though the illumination board that you have has not got a constant current circuit built in and so must use the constant current function that is available on the Sangaboard v0.5. The repo that you link for the LED is in Filip’s repository and is for illumination without a built-in driver. A photo would confirm that.

Hi,
please use the CC pins (red wire +, black -) on the Sangaboards. The boards should by default provide approximately 30mA of current to the LED via that pin. To make the current configurable via the Sangaboard this LED board does not have any built-in current regulation (like the version in the OFM documentation) so connecting it to 5V directly can burn out the LED.
The boards come with the firmware already uploaded so it should work out of the box, upgrading the firmware is just an option in case new features are added in the future (and firmware updates can be done via a button in the Sangaboard extension).

I assume you used the CC pins and it didn’t work? If you have the Sangaboard extension installed, can you please check what the CC LED power is set to (there should be a slider in the UI, it should be around 30%)?

Thanks

Thanks @filip.ayazi and @WilliamW things are working for me now!

Ultimately, it was a very simple mistake on my part. During assembly, I got fixated on the instructions showing the black on the right and the red on the left and I neglected to note the +/- in the reverse positions on the illumination board. So, when wiring to the CC pins, I had the polarity reversed which caused things not to work. The other bits that I thought I’d maybe messed up (the wrong pins, or wrong firmware) were simply red herrings.

As soon as I flipped the connector attached to the illumination PCB, things sprang to life, and there is now light!

For the sangaboard extension, I believe it’s present in the latest Openflexure Raspbian build? But, I’m not sure how to interact with it, is there any doc?

1 Like