Nobody Move. I've Got A BOM.

One of the most annoying things about getting a project ready for prototyping or production is compiling your parts list -- the dreaded BOM. You design a circuit using whatever parts/libraries are there in your PCB tool, sometimes with full knowledge that you need to substitute something that wasn't defined there 'cuz you're lazy and don't want to design a custom footprint/part/whatever...

Then, of course, you need to eventually compile the order for your prototype. I had no idea that SMD diodes, for instance, don't use the same footprint codes as SMD LEDs (light-emitting diodes). Who'd a thunk the light-emitting part made a difference? You must check these things very carefully when compiling your order.

For the SMD-impaired, like myself, here are some good pages discussing the mysterious world of packaging in that teensy world:

• Common Surface-Mount Packages
• The "right" 0805 footprint land pattern

Double, nay, triple check your BOM before you order.. I could have sworn I added those optoisolators to my order but whaddya know, they were missing. Back to the order page!

terrorist.

Then there's that voice in the back of your head: Aren't there some other parts you might need for other projects? Better order them too while you're at it. Maybe that's the geek equivalent to shoe-shopping. Sigh.

-Terrorist-

Ah, gotta love Senator Joe Lieberman. He wants blogs he doesn't like marked with a 'terrorist' tag. I'll just go ahead and add it to this blog and save him the trouble. That is all.

So Many RF Solutions, So Little Time

I've been a bit bummed out the past few days, due to the fact that I totally botched the addition of my HC-05 BT-serial module onto my current prototype (the Bluetooth module is supposed go to on the other side, not pictured), and I even managed to burn my thumb in the process. These Bluetooth modules don't exactly have a friendly footprint for the low-tech hobbyist with an old-fashioned soldering iron. I managed to short VCC to GND on the module and must have cracked some middle-layer traces on it, or just fried it, while trying to clean up my soldering job. One Bluetooth module, R.I.P. <sniff>




Researching parts for a project can be a real time-sink -- you can get bogged down trying to choose just the right part for so long that you don't get anything actually done on your design. It's worse if you have a short attention span like me. However, sometimes you see a part that just looks so much better you've just gotta stop what you're doing and re-design for it. Let's hope my judgement is right on this one..

On a whim I did some searching tonight to see what other RF modules might be out there. I knew of the very cheap and simple 433MHz car-remote style RF modules, which are simple regenerative radio thingies that use Manchester encoding, but their max data rate seems to be about 4KB/s which isn't high enough for my project's intended use (Manchester encoding requires at least twice the data rate of the endpoint due to its balanced 1-0 level requirements -- each 1 and 0 must be transmitted as two bits, either 1-0 or 0-1).

However, my inner geek is now extremely excited to get my hands on these babies: 2.4GHz (same band as Bluetooth) but with:

• raw SPI interface
• 126 RF channels
• 256kbps/1Mbps data rate
• full error detection/correction
• no crazy QFN pads. Simple 8-pin header.
• cheap modules available (half the price of HC-05 boards if you shop around)

Hot, sweaty spec pr0n here: nRF24L01+ datasheet

UPDATE: I saw some pages talking about the TI CC2500, another 2.4GHz transceiver and wondered if it had any clear advantages over the nRF part. Here's a PDF that compares the two (obviously from Nordic Semi, but the advantages seem clear on power saving and data rate.)

These look to be easier to work with for prototyping (.100" header, yay!), easier from a software standpoint (sigh, my dual-rate software UART code may be for naught) and, I hope, lower latency/jitter than Bluetooth devices. I've emailed Nordic Semi to see what they say about that... but if nothing else it'll make for a cheaper board, simpler firmware, and less burned thumbs for me :)

UPDATE: Nordic got back with a reply today, and it sounds like the nRF24L01+ can transmit 32 bytes of data, with an ACK even, in approx. 165us -- crazy fast. I was hoping for 10ms or so latency but with this device I might be able to get <1ms, far exceeding my requirements. The more I read the spec sheet the more I am impressed.

Upgrading the LCD of the Acer Aspire NAV50 (or eMachines NAV51) to WXGA

Netbooks are great -- they're small enough to carry around like a book, but can run a full OS for development-on-the-go, and are cheap -- I got my last one (of 3 -- the wife uses one, the other's a low-power server; strange I know but it works) for under $200 last year. It's an eMachines NAV51, which is just an off-brand Acer Aspire One Nav50 with one less USB port and a matte shell which means less fingerprint smudges.

Anyway.. one thing I didn't like about the low-tier netbooks is the 1024x600 max resolution. Websites these days assume a little more vertical resolution it seems, and Eclipse was darn hard to use without a lot of tweaking to get a useable editor area. I shopped around for netbooks with a WXGA 1366x768 LCD but they were all at least $500 CDN, which seems excessive considering the specs were otherwise identical to my trusty sub-$200 unit.

I stumbled on some stories of people upgrading certain 10.1" Dell netbooks to a 1366x768 WXGA screen, so off to eBay I went to look and sure enough, I found listings for LCD panels that were claimed to be drop-in replacements.. no specific mention of the Acer Aspire series though. I downloaded the NAV50 Service Manual (pdf) and sure enough, the screen pictured there looked identical.

In an evening, carefully following the service manual I was able to swap out the display. While the original WVGA in my netbook was generic, the one purchased from eBay was an LG model which I'd heard was good. The most hair-raising part was removing the keyboard: there aren't any screws so the keyboard is held in by plastic snap edges. Netbook keyboards are a sealed assembly with a thin tin-type metal backing, and the only way to remove it according to the manual is to put a thin credit card under the top edge, get your fingertips underneath, and just pull. I panicked a bit as the keyboard bent slightly coming out, but I straightened it out again against the table and prayed it would work fine once I replaced it (which it did, whew!).

So for a mere $70 additional investment, plus one evening's work, I have a netbook which would have cost $500 or more; the display is brighter, with only one dead pixel near the very top. The 1366x768 rez might not seem like a huge upgrade, but that little extra makes a big difference when browsing and programming -- I can use Eclipse in its default layout with a generous editor window.

Blatant Plug: The screen I ordered was listed with description "10.1"LCD SCREEN ACER Aspire One 532G AO532G WXGA HD" by seller "pcwithcom". Shipping was speedy and the screen was packed perfectly -- other sellers were charging much more in shipping, so I'd recommend these guys.

Using Li-Ion and Li-Po Batteries in Your Own Projects (without getting ripped off or blown up)

Those with whom I've been discussing circuit design lately have, it seems, been surprised to learn that there's a dead-easy way to use Li-Ion and Li-polymer ('Li-po') batteries in your own designs. Lithium-ion batteries give a nice 3.7V supply to any project and are available in a nice range of mAh capacities, ranging from small coin-cells, to AA- and AAA-imposters, to thin square or rectangular packs. The latter are used in all kinds of things like MP3 players, iPods, and little USB keychain picture-frames (if you see those at discount stores for under $2, grab as many as you can -- they're worth it just for the battery! -- but see the end of this post for more on that).

Lithium-ion cells, as I understand it, have some specific charging requirements which sounded scary to me at first, especially with stories of burning laptops, exploding white-hot batteries and the like.. but when handled properly are no worse than using alkaline or Ni-MH cells and they don't suffer from the memory problems for which the latter were infamous (apparently newer ones don't have memory problems -- I haven't really researched it myself).

From what I've read the short-list of Lithium rechargeable safety tips are:

• don't drop them (it breaks the internal short-circuit/overheat protection circuit);
• don't solder to them (search 'spot-welding coin cells' for the right way to attach pins yourself);
• don't charge them using Ni-MH or other types inappropriate for Lithium rechargeables.

Interestingly, the LIR series of rechargeable coin-cells, in addition to being drop-in replacements for their non-rechargeable brethren, also have the ability to deliver much higher current. The LIR2032 for instance is rated at about 70mAh peak supply current, while regular CR2032s are only able to supply about 0.2mA continuous drain(!?) [anyone know the absolute max rating? specs sheets I've found don't say], making them not really suitable for anything other than where you typically see them -- in blinky-light dollar-store gadgets and for CMOS backup. [Edit: hmm, I just noticed that the standard CR2032 apparently has a higher capacity than the LIR2032 according to the linked specs... I'd guess there's some general tradeoff going on here wrt. long endurance vs. high power...]

Anyway.. to the point -- Dallas-Maxim makes a pair of really convenient single-chip solutions, the MAX1551/1555, to charge any single-cell Lithium-ion or Lithium-polymer battery that is just so easy to use, there's no point in using alkaline or other batteries unless you have good reason to. These ICs take care of the whole charge cycle, and even have dual DC inputs, one for USB and the other for a DC power supply. The IC switches between whichever provides the best power at the moment -- or just ground one input if you're only using the other. Combine this IC with a USB-mini socket on your project, even if you're not using USB comms, and you have a dead-simple way to recharge your device. I personally prefer the MAX1555 variant as its CHG/ output hooked through a resistor to the battery's positive terminal VBUS gives a handy charge indicator:

Example Li-ion/Li-po charger using MAX1555 and USB-mini jack. Heck, leave out the caps if you're really cheap, it still works.

Design-in-progress w/MAX1555 and salvaged Li-po from a USB picture-keychain thingie, happily charging

[Blatant Plug: the board above uses all SMT parts save for the jumpers, which I wouldn't have attempted myself, but my colleague Chuck Rohs (the world's only lead-free engineer, HAR HAR) has a purely awesome PID controller for a souped-up toaster oven reflow station (that's just one application). Take a look at that board up close, the soldering job is bee-yootiful. You should buy his reflow oven kit :)]

Bargain Tip: search on eBay (or alibaba or other wholesaler if you are doing quantity) and you can find Li-polymer square packs in the 180mAh-600mAh range for $2 USD or under per cell. LIR2032 rechargeable coin-cells are also to be found online, again at prices $2 or less per unit if you shop around. Don't buy from anyone charging significantly more than this, you wouldn't believe the markup some online [US-based, sorry] retailers will charge on these things! Generally, if the website says they "specialize in batteries", they really are specializing in overcharging for batteries (har har, I made a pun). :)

A Dual-Rate UART Implemented in Software Using Atmel ATTiny MCUs

I've started designing a wireless interface using Bluetooth that, for technical reasons, requires the endpoints to communicate at a nonstandard baud rate. I found these neat-o Bluetooth-to-serial adapters on the net [look around, this is not the cheapest place, don't pay more than $8 USD or so for them and be sure to verify they have the HC-03 or HC-05 firmware that supports master -and- slave modes] that have a convenient AT-command set interface for configuration, so you can pair them up without any in-depth knowledge of Bluetooth, and a transparent mode that then acts like the modems of old... but they only support the standard rates you see with COM ports on PCs (9600/19200/38400 and so on). Bummer.

So.. it seemed to me that it should be possible to add a controller that, depending on the communication direction (this is a unidirectional link), would do an up- or down-conversion by sitting in between the BT interface and the target endpoint.

No hardware UART I've heard of supports a split data rate on the Tx and Rx lines, so a hardware UART or USART was not in the running. Software UART implementations from Atmel's app notes only do half-duplex while this required something that could shuffle data both ways in order to do the rate conversion.

For full-duplex software UARTs there is a handy library out there which includes one -- the Procyon AVRlib -- but it was written for AVR mega MCUs, and didn't have any facility for asymmetric baud rates. My application only needed a few pins so I wanted to use the ATTiny which has a somewhat different interrupt and timer register set as compared to the ATmega series. Moreover, the ATTiny25/45/85 have two independent hardware timers -- it looked perfectly feasible to implement a software UART that had asymmetric baud rates on the Tx and Rx sides, so why not roll my own software UART. Shouldn't be too hard, right?

Here's the general concept:

[A]----low-rate---->|SW-UART-Rx|---->|SW-UART-Tx|----high-rate---->|BT Master| >>>

and (for the other side)

>>> |BT Slave|----high-rate---->|SW-UART-Rx|---->|SW-UART-Tx|----low-rate---->[B]

As long as your endpoints [A] and [B] use a lower bitrate than whatever the Bluetooth-to-serial modules are configured for while in transparent mode, no special buffering of serial data should be required as [A] and [B] limit the total end-to-end bitrate to that of [A] and [B] themselves.

It took a bit of head-scratching with the oscilloscope attached but I managed to get a full-duplex software UART going on the ATTiny85, with no external hardware required. Symmetric or dual-bitrates are supported. I've tested the symmetric config at 38400 using puTTY and a USB-to-serial interface and all looks good so far. No real reason why the split rate shouldn't work, as each of Tx and Rx use their own unique timer...


I'll post code as soon as I have a spare moment.. gotta eat lunch now :p

[Update] Download source: attinyx5-dual-rate-swuart.zip

void blog_init(void)

Hi there, I'm Russ. I decided to start a blog, the lifespan and exact direction of which will be a mystery to even myself...

I'm a programmer with a degree in Computing Science, having spent much of the last 18 years or so stuck deep in the world of interrupt handlers, registers, device drivers and stack frames. Well, not so much these days.. but I still barely find my work takes me 'above' the worlds of C and C++, with detours into Python once in awhile, and almost never into Java/C# or any of that high-falutin' stuff :).

When I'm not at work I find my interests lie in synthesizers, music synthesis, and electronics relating thereto. I've decided to write about my recent excursions into the fields of hardware design and, well, whatever projects I'm working on and/or find interesting on teh tubez.

Though I am not an engineer of any sort, having come from the CompSci side of things, in my years I've learned a thing or two about electronics and circuit design (digital; the analog side I'm still picking up as I go along) through my work with embedded systems and RTOSes.

I have a short attention span. I can't help but think about new project ideas, but to be honest I kind of suck at getting them implemented, so this journal is a way of organizing and setting down ideas. If someone else learns something from my writings I would consider the whole exercise worth it. If any of you dear readers [do I hear crickets out there?] can help me learn something, that of course is also extremely welcome.

Again, I don't know the exact directions this will take, but I can give a good idea of what areas might be visited in future postings:

• Embedded controller projects (esp. Atmel AVR, hopefully ARM and even some FPGA eventually);
• Circuit board design;
• Postings about 'neat' components for the electronics hobbyist designer;
• Embedded software techniques, tips, opinions
• Music synthesis, MIDI, control surfaces and interfaces

A hosted blog seems like the best way to

1. get ideas 'out there' before I forget (short attention span remember?);
2. get ideas 'out there' so other people will pressure me to finish them :)
3. get ideas 'out there' while avoiding web-site-admin minutiae, which interferes with 1 and 2.

[Hmm, seems there is a theme there.]

So.. if you stumbled upon this area I hope you'll find some neat things to think about. Please comment on, ridicule, suggest, ....


-Russ