Category electronics

Crystal, PIC, and voltage regulator on a laser printout of the HMLiberator
(Click for full size image.)

The first batch of board-level parts for the HMLiberator came in today. It’s enough parts for three devices, with a few extra SMT parts thrown in just in case I drop them, sneeze, whatever.

That up above there is a laser printout of the latest board layout with the electronics filling a 37mm x 25mm area. I’m going to redo the pinout of the cables to make routing of traces more efficient, but that shouldn’t affect the other areas. Also, as you can see, the part footprints are good. So, barring any manufacturing problems, it should work out great.

I took some more macro photos (true macros) of other SMT parts received today, because I thought some people reading this might be interested to see them:

· Four size 1206 SMT .33μF 25V capacitors sitting on a dime. These are Mouser part 77-VJ12Y25V334K.
· One of the .33μF size 1206 capacitors sitting on the PCB printout.
· Surface mount parts in cut tape packaging.

After talking with jerronimo for a while on IRC about it, I think I’ve got a good idea about what I’d like my next project (after the HMLiberator) to be: a Nixie clock.

I’m thinking that it’ll be:

· Controlled by a PIC.
· Time / date / etc stored in a battery-backed PCF8583 (or so).
· Four Nixie tubes.
· Time / date / whatever will be set via serial terminal. PCB will include FT232BM for easy USB connection and footprints for DB9 connector, MAX232, etc.
· Other things may be possible via serial, including displaying one’s own data. This makes the clock also an external Nixie display for computers or embedded devices.
· Colon (:) in between pairs of digits can be turned on and off.
· Again, all open-source hardware and software. Probably done in mikroBasic since I’m getting to know it fairly well.
· I’ll make a few kits available to friends at cost, likely without enclosure.
· Maybe a bootloader so new firmware can be dumped on via serial port instead of ICSP?
· Possibly a way to control color-variable LEDs for illuminating base and / or tubes.

So, yeah. That’s a ways out, but I think that’s what I’ll work on next. :)

First Draft of the HMLiberator PCB

Having some time on conference calls this morning I went ahead and began laying out the first draft of the PCB for the HMLiberator. Well, there it is. It’s small. Really small. 54mm x 25mm, in fact, and I could probably cut it down to 50mm x 25mm if I feel like it.

A 300dpi version of the schematic is available here, if you’d like to see it.

I’ll let the design stew for a few more days while I work on the software (and other thing — especially laundry) and wait for the first order of parts (enough for three boards, $20 total) to come in. After validating that the parts match their footprints, and assuming I don’t run into any huge problems with the software, I’ll order a prototype run of boards.

Oh, I also ordered one of the OPPO DV-970HD DVD players from AV Science as well. It was US$149 with $10 shipping. I wasn’t expecting to pay the shipping, but at least I know it’ll go out today, a small company is getting the business, and the forums they run helped me learn about and decide on the player and TV.

So, some more information on the HMLiberator. For one, I’ve started writing the actual project page over on nuxx.net about the device itself. It can be seen here: HMLiberator

I’ve progressed quite far on the software, and if the changes I made today work, it will now also be able to send regular updates (every 500ms) if Polling Mode is enabled on the iPod (command: 0x00 0x26, response 0x00 0x27), all while continuing to process other things.

I still need to make it maintain internal state regarding current track playing, ensure that play/pause/stopped states are properly maintained, and a few other things. But, for now, I’m happy with the progress. I’m also glad to finally get some documentation about it online, even if it’s a bit scant.

Working on the HMLiberator

Oh, and as mentioned in the previous post, it works. Well, mostly. I had the Honda Music Link passing audio from the iPod and communicating with the HMLiberator, but then I ran into a bit of a snag. In the byte I was keying off of for a response (the checksum of the packets) I’ve run into a collision, so I now need to come up with a better way to selectively respond to commands from the HML.

I think I’ll try matching off of the actual command itself. This might not be too difficult, but either tomorrow or maybe over the weekend I’ll try and flesh out a good way to do that.

For now, though, I’m just happy that it’s proven to be possible to do what I want. :D

The EasyPIC4, iPod, Honda Music Link iPod Cable, and serial breakout cable,
all connected and ready for testing.
(Click for more photos of HMLiberator development.)

Well, it pretty much works. By “pretty much” I mean that the Honda Music Link talks to it, the HMLiberator replies, and things seem okay. I’m stuck at one point, where the Honda Music Link (HML) asks the iPod (really, the HMLiberator) for information about the two playlists it reports containing, and the HML doesn’t seem to like the answer. I think I screwed up at least one of the packets, so I’ll look into that tomorrow and do a bit more testing. The good news is that it all generally works and right now the problem is software related.

I’ll try and fix it tomorrow.

I uploaded a few more photos, which I’ll just mention here:

· Inside of one of the MiniDIN 8 connectors, with fingerprints for scale.
· Completed straight-through cable, to be split open for serial data testing.
· Cut open data cable, ready to tap into the serial TX and RX lines.
· Completed serial RX/TX tap, except I forgot to connect the ground line. Whoops! It works when grounded through the sniffer, though.
· My Honda Music Link sniffer. A level shifter, strip board, and some DB9 connectors.
· Detail of the top of the HML sniffer.
· Showing where the HML sniffer taps into the serial TX and RX lines which the HML uses to talk to an iPod.

This part is probably even less interesting to most people, so I’ll hide it behind a cut:

Continue reading: Click to see… →Continue reading: Click to see…

HMLiberator Schematic First Draft
(Click for 150dpi version.)

Well, there’s that. I think that’s the appropriate first draft of the schematic for the HMLiberator. All parts are SMT, including the SOT-8 voltage regulator and crystal. I’m still not sure how the cables running to the Honda Music Link and iPod will be terminated, but for now I’m thinking that the wires will simply be soldered into the board, then the body of the cable strapped down to the board for strain relief.

The whole board is intended to be considerably smaller than the Honda Music Link itself, capable of being strapped to the HML and sort-of piggyback on it. It will likely be cased in simple shrink-tubing, as being all SMT and low profile this shouldn’t be difficult to do at all.

The ICSP connector will be a right-angle .100″ connector on the dev board, and just holes on the production ones (if I do any production runs). I figure the right angle connector can be set in the holes and held in place during programming, and any purchaser who has the means to flash it themselves likely has the means to add the ICSP connector itself.

Now, to fix the FIFO problem and lay out the board. (Hopefully I’ll get both done by the end of the week.)

Oh, and if any of you can see any problems with that design, please let me know.

EasyPIC4 w/ PIC16F688 at 12MHz with
rigged connection from hardware UART to on-board level shifter.

After some jiggery to get the PIC16F688 sample I received today talking to the built-in level shifter on the EasyPIC4 I had no problem getting the basic software for the HMLiberator running and responding to commands. It’s currently running at 12MHz, but as soon as I get some 20MHz crystals it’ll run there. This will give a baud rate just about 0.16% skewed from the specified 9600 baud rate, and I think that’s close enough.

I still have one problem to sort out before I try plugging it into the car, and that’s with the receive FIFO. With it set at the default of 40 bytes I can get five commands sent and responded to, and then the sixth just fails. As I was testing with a seven-byte command (and 7×5 = 35, just below 40), I think I’m hitting point where the FIFO wraps around (or something — I don’t understand it well enough yet). The incoming commands are of varying size, so I’m not really sure how to work around this yet.

At least I know where the problem lies. Once that is sorted (or whatever) I’ll plug the thing into the car and see what it does. If that goes well, which I expect it will after some basic software changes, I’ll finish up the v1.0 circuit / board design and order a run of boards and make up a first batch of five or so.