I got round my first issue which was: How do I run AttoImage?? We may have lost our original config file, or at least the config file we are trying to launch AttoImage with (on the original XP computer) isn’t quite compatible with our BD Pathway 435. I tried to contact BD, but I doubt I will ever get a reply.
AttoImage (which controls the BDPathway) first opens a serial connection and sends the rd command to query what type of Pathway it’s dealing with. I remember our BDPathway 855 in Manchester was replying with “rdAtto_AAAS”, which interestingly is the answer AttoImage is expecting with the default (?) config file I am using. Instead, our BDPathway sends back “rdAtto_BD_EP”. Was that modified for our lab? I don’t know. However, AttoImage really doesn’t like this answer and shuts down soon after telling us about the “issue”.
My workaround is to put an “Arduino” microcontroller in the middle, which can analyse and modify any string sent back from the BDPathway to the listening PC. The idea of course is to swap the response containing “BD_EP” with one containing “AAAS” instead.
Since I didn’t really want to install any new device driver on the XP machine, I chose a microcontroller with (at least) two hardware serial ports, the STM32F103 blue pill. Also, it has plenty of oomph compared to an 8 bit ATmega, can be programmed with the Arduino IDE if one so wishes, and is very cheap.
I briefly considered stealing power from the RS232 port on the XP machine, but then I thought… Hey, the USB port delivers power but can only expose a serial connection, so why not use it?
Introducing… TCOD for “two controllers, one device”.
For now, TCOD has two different working modes which you can switch by issuing the `D command (for debug) from the USB side.
In normal mode, the blue pill redirects commands from either controllers to the device and sends the device’s answers to both controllers. Since the responses could come out of order, I wouldn’t advice trying to control a (any?) microscope that way, but who knows, as an acid test maybe? This could be very interesting!
In debug mode, you simply spy on the traffic between the XP machine (the other controller) and the BDPathway (the device) using any terminal software, like KiTTY or PuTTY.
where “>” denotes PC to device, and “<” device to PC.
Copy-paste into a text file and you have a nice set of commands and responses to analyse in Jupyter:
That’s all! I’ll continue to play with my setup until I break something I guess
For TCOD, I’m going to buy a nicer enclosure and some isolated RS232 <-> TTL modules because I’m not feeling confident about 3 mains powered machines connected to the same ground.
Also if I could do anything about it, I would have the blue pill expose two USB serial devices, one a “normal” serial communication device, and the other outputting debug info all the time.
If there is any interest in reverse engineering microscopes and writing device adapters for them, I’m happy to share my code and start a page on the micro-manager wiki