I finally received the PCB for this design. And in general it turned out okay. There were a couple of shortcoming in my design that will force me to to re-spin the PCB, so it’ll be a while before I can finish everything up. But having the PCB gives me the ability to debug my firmware and test the overall concept for this solar panel tracker.
In last week’s blog I talked about looking into using an accelerometer output as a user interface for the Disco Bike Light design. This week I took the next step of actually implementing a method of detecting taps with an accelerometer and using them as an on-off signal.
For a quick refresher, the Disco Bike Light is a design where I’ve decided to replace the guts of a Schwinn bike light with my own electronics. I wanted more color and more brightness. I put some constraints on myself for the design. One was that I couldn’t destroy the existing bike light in the process of making my new one. For on/off/color control I was left with few options…
Welcome to another edition of “Disco Bike Light: adventures in electronic design”. In last week’s blog I talked a little about the printed-circuit-board (PCB) design and the Lithium battery charging circuit. This week I’ll touch more on the circuit board, and a little bit on the user interface.
In last week’s exciting episode of “Disco Bike Light” I covered some of the issues I had with this electronic design. In summary, I’ve decided to convert my bike light to a multi-color kaleidoscope of mobile joy.
I’ve been working with some high power LEDs around here. I also ride my bike to work. The cheap bike lights I’ve owned kind of suck. In fact, some barely illuminate the road. And none of them flash groovy colors. Last week I bought a $20 Schwinn light (pictured above). I really like the shape of the light, and although it is an improvement over my last lamp, it’s still pretty tame in the light production department. So I’ve decided to pump up the lumens, taste the Technicolor rainbow, and build a disco bike light. And if I use the Schwinn body I can avoid some of the mechanical design effort.
The Schwinn bike light breaks down into several pieces. The main body is the black tube where I’ll need to fit my electronics. Normally it carries three AAA batteries (shown on the left). I’ve added a AA battery for size comparison, because that ends up mattering later on. There’s also a screw-in base that has the on/off/flasher circuit in it. It’s the part with the spring attached that presses against the negative terminal of the battery pack. This part is a little strange. It operates without the battery pack and provides an open, short, or 500ohm resistance from the case to spring (ground). I’m guessing there’s a microcontroller embedded in there, but I swore not to take it apart (I’ll need that light in the coming weeks). The last piece of the light is the aluminum LED holder. It’s a thin threaded inset that connects the single white LED to the positive battery terminal.
I want to use the same parts we have on our BM014 Super Bright RGB LED Module, because, well we have them in stock. I also want to be able to program color and brightness settings, so that means a microcontroller and user interface. I’ll also have to replace the 3-AAA batteries with something else. 1-AA Lithium Ion battery would provide a similar voltage, and give me some extra room for circuitry.
The first step in this design is realizing that I’ll need to fit the Lithium Ion battery, a circuit board, and USB connector into the main body of the light and onto a PCB (for charging and communicating with the microcontroller on board).
I turned to Sketchup 8 to do some simple modeling. If I mount the USB connector directly under the rear battery mount everything works well. To do this I would have to clip and sand the through-hole tabs on the battery mount (PN: BK-92-ND at Digi-Key). If there’s no room for it anywhere else I can go that route. The image below shows what I’m going on about.
The circuit board that fits inside the tube is pretty big, I calculate it at 0.725”x2.0”. So I think I’ll have room to move the USB connector. On the top side of the circuit board will be the battery mounts. On the other will be the USB-to-serial converter, a Lithium Ion charging circuit, and an LED drive circuit. I can rotate the USB connector and get it to fit further in from the battery clips. I would also have to notch the circuit board so a USB cable will fit into the USB connector. Maybe I can find some surface mount battery tabs?
Lastly, since the housing of the bike light is conductive, I’ll have to make sure the battery terminals can’t touch the sides of the enclosure. That’s tricky, but I have some ideas about how to do it with the PCB. I’ll discuss that in the next blog on this topic.
I used the chart control in Visual Studio 2010 (VS2010) last week on a consulting project. It was a useful means of using my serial communication software to create a visual display of the data being read. It is relatively easy to bind an array to a chart and display it on a form, so I thought I ‘d share that here.
This is the third installment/blog on the CR95HF, a near field communication IC manufactured by ST Micro. NFC is a short range RF communication protocol commonly used with smart cards for touch-less information exchange. New cell phones are being built with NFC hardware integrated making consumer applications more likely to be ubiquitous in the near future. Examples of applications might be vending machines or secure access systems. Here’s a Wikipedia summary of NFC.
I started work on a Near Field Communication (NFC) module. The design uses ST Micro’s CR95HF chip. The module above is the first shot prototype unit. This device uses a 13.56MHz RF carrier frequency and amplitude-shift keying . The CR95HF carrier frequency powers the loop antenna shown on the module above and the resulting field couples with a similar loop antenna on an NFC enabled card. The field coupling, like two loops of a transformer, powers the card. Powering up the card allows the CR95HF to transmit data to and from NFC cards. That’s the theory anyway.
They say no plan survives contact with the enemy. I think that pearl of wisdom applies to engineering. In my experience the enemy takes the form of everything with wires as well as software running on anything with wires.
It certainly applies to a project we’re currently working on. We can’t go into too much project detail, as the design is part of a contract we’ve been hired to complete. But we can cover some of the broad concepts that describe the battle we just survived.