Got myself an Andonstar 2 megapixel USB microscope about a year ago, mainly just for testing it out, and having it readily available when some repair project demanded it. The microscope is actually pretty nice given its ca USD 60 price point, with decent picture quality, a sturdy stand (even though it’s somewhat of a pain adjusting it) and a built-in adjustable light source.
To be honest it hasn’t been used much (it did come in handy during the repair of the BK Precision LCR meter though).. but this is in part due to the lack of good OS X software for use with generic USB microscopes. Over the past year I have tried some video software, and still have a few on the try-these-out-list.
Lots of OS upgrades lately, Windows went to Windows 10 and Apple to El Capitan. I am usually pretty ok upgrading to Apple’s latest OSs a week or two after their release – they are usually of good quality.
As VirtualBox (“VBox”) also came out with their version 5 release, it was time to upgrade the Windows 8.1 virtual machine (“VM”) running in VBox, with OS X as host.
Turns out this is (of course..) not as easy as one would think – but still possible.
Here we will walk through the steps of
Extending the Windows 8.1 virtual disk in VBox
Forcing the Windows 10 installer to run, even though its hardware compatibility checker says the VBox machine is not compatible with Windows 10
Installing the VBox Guest Additions in the Windows 10 VM.
Before doing any of those steps, you might want to upgrade to OS X El Capitan, and to latest Virtual Box (5.x as of this writing).
The previous post listed some of my favourite OS apps, but there are a few more that also make everyday life easier. When thinking about it, the apps below are just as useful and important as the ones in the previous post. The apps are:
Being fairly multilingual – I use Macs, Windows and Linux boxes daily – OS X has during the last 4-5 years been the main platform for daily work. And as much as I like the way OS X has developed over the years (including the fact that it’s free once you have bought a Mac!), even the sun has spots.
So let’s see how we can make a good OS X system truly awesome.
In this first of several posts we’ll look at these tools:
Turns out that OS X Yosemite on Mac Mini does not support standard Wake-On-Lan (“WOL”), at least not when using the built-in Ethernet port.
Which is strange – but when trying to make the media server attached to the household’s TV a bit more energy efficient, I just couldn’t get that Mac Mini to come out of sleep using a WOL magic packet. Others out there report the same thing, so it’s not an isolated issue for me. Just to rule out issues with the WOL client used, I tried waking Windows and Linux machines from sleep – worked flawlessly. Weird.
Node-RED is a truly awesome framework for visually building data flows. There is a lot of focus on wiring together hardware devices and Internet of Things, but there are also plenty of modules for connecting to email, social media, various online services etc.
After using it during some months I can confirm that stability is absolutely fine, don’t think I have had a single issue with the setup due to Node-RED itself.
Version 0.10.1 came out a week or so ago (early Feb 2015) and brought things like better partitioning of flows in the form of subflows, improved Raspberry Pi support, binary MQTT payloads to name just a few of the improvements.
I am running Node-RED on an always-on Mac, running latest OS X. This machine is very stable but for various reasons I do need to restart it every now and then. It would then be very nice to have Node-RED start automatically at boot. That’s somewhat complex to do, but having an app starting at login is trivial – let’s do that instead. I am always logged into this computer anyway, so it won’t be a problem.
Apple tried to be smart with OS X Mavericks, developing their own FTDI drivers. Just too bad they don’t seem to work.
I have been getting nothing but “avrdude: stk500_recv(): programmer is not responding” errors when trying to upload sketches to various Arduino compatible boards.
In the end, the only thing that worked was programming the boards using a dedicated programmer (in my case an USBasp).
Some digging around forums and Apple’s support site, the following steps has solved the issue on all the OS X machines where I have tried it. In short, you need to replace Apple’s drivers with the ones from FTDI.
Open a terminal
sudo mv AppleUSBFTDI.kext AppleUSBFTDI.disabled
sudo touch /System/Library/Extensions
Install FTDI’s virtual COM port drivers from http://www.ftdichip.com/Drivers/VCP.htm. In version 2.2.18 this package contains two executable files, I have had success with the one named FTDIUSBSerialDriver_10_4_10_5_10_6_10_7
Restart again (might not be needed, good practise though after installing drivers)
Voila – The Arduino IDE can now upload sketches to all boards I have tried, both with the old/legacy bootloader and Optiboot.
For some reason i cannot get the easy-to-use tools out there for burning ISOs to work… Command line to the rescue:
First, make sure Homebrew is installed. It is strictly not needed for the burning-to-thumb-drive process, but will enable the progress indicators, which are quite nice to have for long running tasks. Now install Pipe Viewer from Homebrew:
$ brew install pv
Now we need to figure out the device name of our USB drive. In a terminal window (you are using iTerm2 – right? Infinitely better than OS X built in Terminal app):
$ diskutil list
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 250.1 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *320.1 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_HFS SSD backup 180.0 GB disk1s2
3: Apple_HFS Temp 139.6 GB disk1s3
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_HFS Macken_Ext Backup 999.9 GB disk2s2
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *8.0 GB disk3
1: DOS_FAT_32 WHEEZY 8.0 GB disk3s1
/dev/disk3 is the USB thumb drive. I previously had another Wheezy image on it, thus its name.
Now unmount it:
$ diskutil unmountDisk /dev/disk3
Unmount of all volumes on disk3 was successful
A severely cracked 13″ Macbook Air display came my way some time back. The LCD panel was obviously damaged, but it would be interesting to see what makes such a great display tick, and maybe parts of it could still be used? I believe the display came from a Late 2010 Macbook Air (which would indicate an A1369 type construction), but can’t be sure. Anyway – ideas included
Keeping the back lighting (assuming it works) and camera, mounting the whole display on a flexible arm next to the work bench. Given the high intensity of the back lighting, it could then (maybe) provide ambient lighting AND video recording of whatever was being worked on. Maybe with a LED light and camera on a separate flexible arms.
If the LED backlighting drivers were toast, there should still be some nice white LEDs in there for scavenging.
Same thing for the camera, I believe it to be a 640×480 pixel device, nothing too exiting but could still be useful.
Turns out it’s not entirely easy to disassemble these displays. They are sealed together with very strong tape. Heating the bezel helps a lot, but it’s still a fair amount of work – and given the delicate components beneath the bezel, you might want to think twice before doing this on a laptop you care about.. Some good instructions found here, btw. Results so far:
Prying the bezel open…
…before applying heat with a hot-air SMD rework station (regular heat gun would probably also work, if you are careful):
Voila! Bezel is free:
Now the tricky part. The cable from the cable is a thin wire with some kind of textile cover, for strengths I assume. It goes through the hinges and there is no way (as far as I can tell) to get the cable through there, without cutting off the (very small) connector that normally connects to the computers Left I/O (a.k.a. LIO) board. Cut.
Now the whole camera assembly can be removed. It also includes the ambient light sensor, which communicates over I2C. Unknown protocol for that one though – one for the future to investigate..
Very tiny 6-pin connector, normally going to the LIO board. Camera module exposed in the top part of the screen. Held in place with 2 small screws.
These things are small – fingers included for scale reference.
With six wires in the cable it’s pretty clear that 4 are for USB (+5V, Gnd, Data+, Data-) and 2 for I2C. That cable is however crazy small – it’s about 2 mm diameter. Once the outer layer is off, you see 6 even thinner cables. 2 are black, 4 transparent. Which ones are which?
Google is your friend. Turns out there are schematics to be found if you Google long enough. Turns out you need schematics for the LIO board though, in order to get the pinout of the camera/ALS cable, and it’s nowhere to be found for the A1369. Did find a schematic for the A1370 model though (same computer but 11″ screen), with a bit of luck that cable is the same between models.
The 2 black ones are prime candidates for +5V and Gnd. Cutting away the insulation revealed that the cables are shielded, with a center wire that is barely visible to the eye. It took several attempts before I had separated the wires from the sheilding, and then done the same with the other 4 wires. Soldering these onto an old USB cable was then easy (but ugly!!):
Still, it doesn’t work. The camera is not recognised on an iMac with latest OSX, nor on a Windows 8 laptop. Happened to have a Raspberry Pi lying on the work bench, tried it too with same result: nothing.
But wait… doing a “tail -f /var/log/messages” on the RPi showed that it DID recognise the camera, but that the camera wanted more power than a non-powered USB hub could provide! Placing the camera into the RPi’s regular USB port made it appear nicely when doing a “lsusb” command.
Still, it didn’t work when I connected the camera to the Windows or iMac machines – strange.
Also, the RPi loose contact with the camera after a while – no idea why. Could maybe be a bad USB cable (it’s from an old mouse using USB 1.1 – maybe that’s a problem??), or is there too much noise introduced by the ugly splicing of cables that I’ve done? No idea… More investigation needed. Anyway, the camera enumerates with USB id 05ac:850a, which indeed is an Apple FaceTime camera – nice!
If you spend any time at all at the command prompt in OSX or other Linux-ish systems, tmux is a must. Basically it gives you persistent shell sessions, once using it you’ll wonder how you ever got by without it…
For OSX the easiest way to get tmux is via (the also excellent) Homebrew. After installing Homebrew, just do a
brew install tmux
from a OSX prompt (you ARE using iTerm2, right? …Rather than OSX’s rather horrible built-in Terminal app…?)
Add to the mix the nice Bash replacement Fish, which gives you all sorts of command line goodness (color coding, auto-completion, …). Very nice!