Driver Kit Update & $400 AA Battery Accident

Broken MacBook Pro LCD

Driver Kit Update

It’s been a busy couple of weeks, both with my day job and working with suppliers to get the best price and quality on parts for the hybrid driver but I do have a driver kit update. I have finalized the supply chain and received all but the passive components and packaging materials. I expect everything to be here by the end of January. Once I have all the parts I’ll take the photographs for the plans, which will be available for free.
I also want to make a test rig for the hybrid driver ICs and the isolated DC to DC converters. They are critical components and cost a decent amount. I want to know that they are performing as expected before they go out in the kits or machines. I have a couple of ideas for building a simple but detailed and accurate Arduino based performance curve profiler similar to those used for testing transistors, diodes, and other electronic components. In the meantime, I’m getting back into the code using the two new driver boards I build from the spare components.

$400 AA Battery Accident

I dropped a harmless little AA on my desk while changing the batteries in my mouse. The battery bounced and rolled away, I didn’t think much about it. A few minutes later I noticed my screen took a hit… awesome. The outer glass isn’t even cracked. It was one of the substrate layers that broke and let out all the magic liquid crystals. Looking around for a replacement LCD for my MacBook Pro Retina, 15-inch, Mid 2014 it seems like $300-$390 is the price range, ouch! I saw some cheaper off brands but this is a beautiful Retina display, and I don’t want to change it out for some knockoff junk LCD.
I have been looking at the new MacBook Pros, but I genuinely don’t like them. The taskbar is a POS gimmick, and the keyboard feels like a toy. I switched to using MacBooks around 2009 when I got fed up with Windows interfering with my work. An [NTFS file system error] blue screen of death the night of a large network activation for AT&T Lightspeed/U-verse was the last straw. I went out and bought my first Mac the next day.
Yes, Mac hardware is costly, but it JUST WORKS! It is always something with Windows. I was tired losing valuable time fixing issues, updating, reinstalling, etc. The MacBooks I have used have ALWAYS worked rock solid. I run CleanMyMac to keep things tidy and a Time Machine at home which is the most intuitive and real world usable backup system ever, for a personal computer at least.
I didn’t mean for this to be a MacBook fanboy review or a windows roasting session, I still use windows too. Personal my favorite OS is Debian, maybe I’ll get a Linux computer. Probably not though, I just run VMware when I need it locally. Besides, I do love the integration between all my devices that Apple affords i.e., desktop, laptop, tablet, phone, TV, etc… It’s just that this is the first physical problem I’ve ever had with a Mac and honestly I’m sort of surprised how easy it broke considering how rough I’ve been on them over the years.
I’m going to order a screen today. I just tell myself, “Don’t worry, you can sell this Mac for about a grand when you upgrade!” Still, what a disappointing accident.

Bluetooth Telemetry Link

Bluetooth Telemetry

This Bluetooth serial link is nothing new. I had it working on the existing setup to send data from the ReactorForge control board to the Processing visualization program. The HC-06 Bluetooth module enabled me to see the live telemetry coming from the ReactorForge. That helps you to understand what is going on and tweak parameters such as the PID settings.

Consolidation of Development Process

I’m excited to get the entire development process in one operating system. Before, I was bouncing between macOS, Windows in VMWare Fusion on the Mac, and a separate Windows machine. It’s a long story, but this was partly due to the Windows-only compiler I used at the time. Other shortcuts I made early in the process just to get things working enough to get the induction heater to Daniel’s shop also helped put me in that spot.

Problems Connecting to the HC-06 Bluetooth Module on Mac

Getting the HC-06 Bluetooth to Serial module working on macOS wasn’t hard, but I did have one issue. The HC-06 seemed to just disconnect randomly after a minute or two of being connected. Then when I would try to reconnect to it, the port would be busy. I knew it wasn’t busy or open using lsof | grep HC-06 or whatever your’s is named, Reactor-Link in my case.

I fired up Windows in VMware Fusion and paired the HC-06 Bluetooth module. Then I opened a connection to it using a terminal program. I also began a screen session (terminal) on the Mac side with a USB to serial adapter. The USB serial adapter was connected to the HC-06 Bluetooth module to monitor it (and send data from it).

Anyway, this worked fine, and the HC-06 Bluetooth module never lost connection on the Windows side. I did notice that on the Windows side, the HC-06 Bluetooth module asked me for asked me for the pin number during the pairing process, but it did not ask on the Mac side. I removed the device from on the Mac side in the Bluetooth manager and re-Paired it. To my annoyance and relief, this fixed the disconnecting issue. Maybe I changed the pin in the past since the last time it had been connected to the Mac.

Bluetooth on macOS

So this is the simple test setup. The photos say it all I think.

Bluetooth Telemetry

Bluetooth Telemetry

Bluetooth HC-06.pdf

Libraries, Drivers, Etc.

With that working, I’m going to work on the libraries now. I’m looking at whether or not to get the existing libraries working in the new environment or use new libraries.  I’m leaning toward new libraries because there are quite a few compiler warnings and even some errors from the old ones. I’ll have to update function names and setup code, but I’d prefer to start with something cleaner and updated. I’m pushing it all to GitHub as I go!

Addition Terminal Jargon

The astute reader might notice that I am using the /dev/tty.* version of the device rather than the /dev/cu.* version. So, what’s the difference? TTY devices are for calling into UNIX systems, whereas CU (Call-Up) devices are for calling out from them (e.g., modems). We want to call-out, so /dev/cu.* is the correct device to use.

The technical difference is that /dev/tty.* devices will wait (or listen) for DCD (data-carrier-detect) e.g., someone calling in, before responding. /dev/cu.* devices do not assert DCD, so they will always connect (respond or succeed) immediately. Since neither the HC-06 Bluetooth module or the USB to serial adapter support DCD it’s not an issue. Still, following best practice, you should use the correct port.

So why did I use the wrong one in the photos? I switched to /dev/tty.* when I was having the connection issue and just forgot to switch back before documenting it.