BT Remote Is Alive!

The bluetooth remote is done, at least for the time being. The software and hardware both needed some changes.

My attempt to salvage the BlendMicro from the old circuit board was not successful. I was going to have to re-do the board. So I re-did it different. I put all the buttons and knobs onto the same board, and then attached the LCD on a riser, as before. Also, this time I added diodes on the power connection to protect from reverse voltage :P.

One of the issues I ran into here is that the screen could not be centered, due to the 0.1" spacing. I would have to account for this in my case design.

I did something slightly different than with the previous iteration. I mocked up the electronics in CAD, and then was able to reference the enclosure design to them. I would prefer being able to do things the other way around, but that requires being able to do a custom PCB layout, and I don't have the skill for that yet. Also, 123d design can't export sketches, so there's no way to reference component placement to the 3D model of the housing.

Fortunately, the encoder knob could be centered, so I was able to use this as a reference point for the entire design. It still took a couple of tries on the 3D printer before I had the dimensions correct. But once I did, I was able to reference the openings for the screen and buttons off of that. And that ended up being correct almost on the first try.

Once I was satisfied with the basic component placement, I wired up all the connections.

Once I was satisfied that it all worked, I made this test to check that my dimensions were correct.
 

It took a few iterations to get to the final case design. Once again, screw placement was the bug-bear of the whole project. I was trying to keep the over-all size down, but kept running out of room for screws. And 123d design doesn't make it easy to go back and change fundamental things like the under-lying dimensions, so I had to start almost from scratch 3 times before I got it right.

Here's the first printed version with mounting tabs on the sides.

I ended up not liking that the tabs on the sides. I re-did it with mounting tabs on the top and bottom. For some reason, I thought it made sense to offset the top tab. I changed my mind about that and moved it to the center.

Added a dollop of hot glue between the MCU and the screen for added rigidity and insulation.

Final design coming together.

Finishing touches with Sugru as a gasket material.

And yet I still have issues with the encoder knob and buttons being too close together. During my first road test, I had trouble skipping tracks without accidentally hitting the volume knob. I eventually figured out how to do it, but it takes some practice.

So, if I have to do it again, I need to space the buttons out more, or mount them sideways.

The other issue I ran into is that since Android has only 16 steps on its volume scale, I found that one step per encoder click was far too sensitive. So I had to scale the encoder input. But the whole thing now feels too sluggish, since I had the volume display update only in response to the round trip. This keeps the volume in sync with the display, but makes everything feel unresponsive.

In hind-sight, I guess what I can say about this is that an encoder wheel actually doesn't work very well as the volume controller. If android could adjust volume in finer increments, it would work a lot better. Another thought might be to make the encoder knob harder to turn so that it's harder to accidentally bump it. And also so that it takes more effort to move one step, one is unlikely to move it too quickly. But that might compromise the encoder's value as an input device for scrolling through menus (not yet implemented).

The encoder's button works good, though. And the rubber button pads actually feel pretty good, even with gloves on. So, I'm pretty happy with that.

I designed this mounting scheme shamelessly cribbed from an action camera I also own. The original intention was to have inter-operable components, but it turns out that the precision of my 3D printer and the quality of the materials I use are both factors, and so the mounting clip failed after a few weeks of use.

But there was another problem: vibrations. I figured something like this might  be a problem, so I had padded my handle-bar mounts with Sugru.

But the bars still transmit some very strong, high-frequency stuff at particular RPMS. In my case, very close to my cruising RPM. And the result was that the display would wig out. First, the contrast would get very dark, then the display would cut out all-together. Strange! But was it mechanical or electrical interference? I tested this by taking the display out of its clamp and holding it in my left hand while riding along at 5000RPM (I do NOT recommend doing this!) The problem did not re-appear. So my temporary solution was to work the mount a little bit so it wouldn't be clamped so tightly, which solved the problem with the display cutting out. But now the thing tends to fall out of the mount.

My original thought might be to cast something out of sillicone, but my experiments with molding silicone via 3D printed molds have been problematic. Basically, you can't separate the mold from the silicone. So that gives me an idea: don't even try to separate the silicone. Instead, embed the mount in the silicone.

The idea here is to isolate the remote and from the bars by a Silicone cushion. The cavity between the outer shell and the mounting plate will be filled with RTV, and then the plate carefully pressed in and the whole thing allowed to cure for a few days. I added some texture to the inside surfaces to help with adhesion, although my experience is that RTV will stick like nothing else.

I'll do another post on the my experience with mold making.

East Rising Display Project

I bought this display off of east rising back in the end of 2013. It took three months to arrive, and by the time it did, I had really not much use for it.

It's really quite a nice little piece of gear: 240x64 pixel resolution. It's about 6" wide. Nice and visible, even in direct sunlight. And only cost about $15 for the part.

http://www.buydisplay.com/default/serial-i2c-240x64-cog-monochrome-lcd-graphic-module-black-on-white

It was originally going to become a digital dashboard for my race car, but I've since given up on designing and building my own digital dash-board.

The interface to the display is a 30-pin flat-flex connector. It's probably the tiniest multi-pin connector that I've ever contemplated working with. The pins are 0.1mm wide, and the pitch is only 0.2mm. It's so tiny I can't directly photograph the pins with my smart phone.

The challenge: to make a break-out board so that we could interface this display to the 3.3v our micro-controller of choice. In my case, this will eventually be a Teensy 3.1.

I recently found myself with some time on my hands, and so I went down to visit my friend, Mike, who can basically do anything. But even he agreed that making a break-out for this connector would be a challenge. For something this tiny, a PCB would have to be etched. And we were concerned that this pitch might be too small for DIY etching techniques, especially the photo-resist method. Mike had some scrap copper-clad lying around, so we decided to try the laser-paint method.

Mike knocked out the PCB layout in Eagle in a couple of hours. Then, with a rock-steady hand, he covered it with some Krylon enamel and left it to dry, after cleaning the surface with alcohol. Meanwhile, we converted the layout into something we could send to the laser cutter. By the time we had finished that, the paint was dry and we were ready to try laser-etching the layout.

One caveat here is that the orientation of the layout in the laser cutter matters. Unfortunately, the laser cutter's ability to etch fine raster details is not symmetric between the X and Y axis. The direction that the laser carriage moves along has a more limited resolution, because the laser can only turn off and on so quickly. So we oriented the thin traces going town that axis. It might have been interesting to try it going the other way, but we didn't quite have enough time.

We did some trial runs on the laser cutter with some regular white printer paper. It took a few tries to get the settings right on the drawing with auto-cad. There's a little confusion about white being black, and black being white. If you're not careful, the printer tries to use a stipple pattern when you want a solid color. Anyways, we did two boards, at two different intensities. They both "came out", but the one at the default power level came out the best in terms of having thicker traces. We realized right away that we had made the long traces too thin, and because of the limited raster resolution on the laser cutter, the fine curve of the traces was interrupted in places.

We decided to etch both boards anyways, without attempting to touch up the traces before-hand. This is as much about pushing the limits of the technique as it was about getting the job done.

What you can see is that the pad area for the flat-flex connector etched cleanly on both boards. The traces, on the other hand ,were a little thin and broken in places as we expected. But it at least looks workable.

We then proceeded to develop a CNC program to route our copper-clad boards into panels, and to drill out the through-hole pins for the in-line headers we planned to add next. This was done with bob-cad, and the resulting program was routed on a proper CNC mill. It's nice when you have the proper tooling at your disposal.

The challenge of soldering was divided between us, but I let Mike takle the delicate job of hand-soldering the surface-mount flat-flex. Once he got it lined up, he was able to drag-solder the pins and got it right on the first try.

I did the power connector (my first time ever trying to do a surface-mount job). It turned out to be easier than I had expected. A little more difficult was top-side soldering the the in-line headers onto the PCB. In hindsight, it would probably have been better to flip it over, but you live and learn.

Now I could finally prototype an interface. There were two challenges here: the first is that, while the documentation was comprehensive, it did take some time to comprehend. The controller, a U1608, is quite capable. It contains an internal charge pump, which is capable of driving the LCD segments, but you do need to add some external capacitors. This we did, but powering the display on resulted in a whole lot of nothing.

Based on reading the documentation, it seems that the charge pump isn't activated until you send the "ENABLE" command to the controller

The controller can operate in 3-wire SPI, 4-wire SPI, 4-bit parallel, or 8-bit parallel. And these latter two can be done in either an "8080" style bus or a "6800" style bus. The distinction was not entirely clear to me, but in the end I finally figured it out and decided to go with 6800 8-bit parallel to start off with. The 8-bit mode is easier to get going, if you have enough pins for it. I will probably drop it down to 4-bit to save pins in the future. But you want to stick with parallel so that you can read back from display memory, rather than having to buffer all 240x64 pixels.

After a bit of fiddling, I was able to get the display to respond to the ENABLE command. I was worried that perhaps the display would appear too faint with the default contrast settings. But it turned out we had the opposite problem, and the display wasn't quite legible until I was able to turn the contrast down in software. The data sheet has detailed info on how to tune the contrast circuitry, but I decided to forego this for the time being. Probably I should have measured voltage bias, but at this point, I was just happy to have something working.

The next task was to figure how how to write arbitrary pixels to the display. This is done by writing directly to the display's internal memory through the bus. The display contains two registers Page Address, and Column address, which determine which byte in display memory will be written too, but this will auto-increment by default. So if you just write bytes in sequence, you'll eventually write to the whole display. But there were some gotchas.

The biggest one is that while the Column Addresses map directly to each of the 240 horizontal pixels, the Page Address space starts off screen. It turns out that Page Address 4 is the first visible page address. One thing to understand about monochrome displays is that while they are byte-addressable, each byte is used to represent 8 pixels.

In any case, once I had worked out the starting addresses, I decided to write a program to cover the screen in that 1-bit gray pattern which is beloved of the Nintendo Game Boy and the original Macintosh.

The next task would be to write an Adafruit-GFX driver for the chip -- assuming it needs it. It's possible that the KS1608 display they sell is actually compatible with this display at the software-level, in which case it would save me a lot of trouble. I'll have to go over the command set to be sure. If not, it would not be hard to port this display to the Adafruit-GFX library.

Tripod Mount

I've been looking on Thingiverse for a proper 1/4-20 tripod mount, and not finding one. So I finally got around to making one now. It's based on an old tripod I inherited. Might use it on the race car or make a few more to use as general-purpose mounts for motorcycle farkles. The thingiverse page is here: http://www.thingiverse.com/thing:1016340