Category: Hardware

Poinsettia 2012

As the students here just started school, my poinsettia also returned to its "studies":



The lamp received some slight upgrades:

• The backup capacitor was upgraded from 4.7 mF to 1 F, now capable of a year's worth of timekeeping;
• Approximate sunrise/sunset time calculations. In the previous version, the PIC only knew the sunrise/sunset for dates between Oct 1 and Feb 28 (the program memory on this thing is extremely scarce!). Now the daylight data is sparsely stored, at one entry per 16 days. The sunrise/sunset points for the days in between are interpolated. Now it sports a full-year daylight calculations.
• The sun simulation is shifted somewhat ahead in the future — by 35 days, to be exact. As now we're approaching the autumn equinox, the lamp would illuminate as if it were about the end of October. The idea is to make the poinsettia blossom earlier - instead of the "natural" December-January, I'm aiming for November-December.

Whether the plant would get red by Christmas - keeping my fingers crossed - it's about to be tested :)

Posted in category Hardware -- 19 Sep 2012, 19:46, 0 comments

Battery Level Meter

One of the things I finished recently. 6+ months.
This time it's a small and compact measurement instrument. Not the "most useful thing on earth" though (but I guess that hardly surprises anyone).
I took a lot of photos during the development, so that I can represent an entertaining worklog of its development, from The Scratch to The Finished Product™.

The motivation

It's all because of a stupid point-and-shoot camera and its stupid firmware. The battery indicator has four ticks, whose meaning is really something like:

4 ticks: you're all set, go and shoot as much as you wish!
2 ticks: I'm about to die in a minute or so!
1 tick: GOOD B—....*turns off*

I imagined it would be convenient to have a small "battery level meter", with two wires sticking out of it. Connect them to a battery, and it displays voltage and capacity remaining, in percent. Piece of cake!

The whiteboard phase

It should be a small circuit board with a PIC, a 7-segment LED display, a voltage regulator converting any voltage->3.3V, and a resistor divider, so that the input voltage could be read. So, it's a battery meter which feeds on the battery under test. The readout would be then looked up in some table and the remaining capacity would be displayed. The plan was to support anything above 3.3V, which I eventually revised to 1.8V-9.3V (2÷7 cell AA/AAA NiMH, Li-Ion (1- or 2-cell); others can be added as well).

The prototype

What followed was an implementation of that basic idea on a breadboard. The 3.3V voltage regulator was unavailable in a non-SMD form, so I had to solder appendages to it (as I've written earlier):



Initially, I envisioned it with a 2-digit display:



However, that part actually didn't even have a decimal point. Fractional numbers need to be printed as "3_6" instead of "3.6", and this is cumbersome (requires scrolling). So I replaced it with a 4-digit one, which I quickly transferred to a breakout board:

.

Isn't it an evil-looking monster? Like the tripods from "War of the Worlds", but having a lot more legs, and thus far more blood-thirsty, hehe (ò_ó)

In the soldering chaos that ensued, I grew quite dissatisfied with the way I was storing and organizing my electronic components. It was a box-filled-with-dozens-of-plastic-bags setup, and I moved to something a bit more civilized:



Anyway, here's that centipede beast mounted on the breadboard:

.

At this point I decided to implement an important additional feature of the tool: a discharge function (initially, just for memory effect treatment, but later it got extended quite a bit):



Right to left, we have a big resistor that handles the discharge, along with the switching transistor (it could've been a smaller part; I just have a thing for TO-220s), and finally, a pot for user input (the user selects the desired ending voltage, and the discharge current. So the discharger is not just a stupid resistor, connected across the battery).

Shortly after I (overoptimistically) "froze" the design and moved it out of the breadboard. These are the two parts of the sandwich, ready to be assembled:



The sandwich itself:

..

This would be the last thing I do on a perfboard, I swear:

The enclosure

With the hardware almost ready, I looked for a similarly-sized plastic box in the shop.

.

The one I settled on could've won any design competition. Bottom-up. It's basically a severely uninspired, dull and apathetic box: sporting an ugly color, ugly texture, sharp and ugly edges, and it gives off an awfull smell when melted (I'm still using the cutting metod from the previous post).

I couldn't leave it like this, so a rasp joined in:


... then some sandpaper, and a test of the marker:


In preparation for painting:


Painting - first layer:


Second layer:


Well... you get the drill:


Btw, the drying intervals between any two layers is no less than two hours :)

So, three layers later, I decided to try how the handwriting upon the painted plastic would look like. A white marker, which works well on that kind of a surface is surprisingly hard to find, and the only one I managed to get turned out being very thick:



It was okay-ish on the front face:


...but the other side was incredibly ugly...


... because I wanted to put some detailed instructions on that side, in a neat table...
So it became clear that I can't do this, this should be the job of the printing professionals, with the labels printed by a machine.

The extension

In the meantime, I did some work on the software. Having the discharge function up and running, I decided to throw in a voltage logger, and transfer-to-PC capability (the transfer is done using the PICKit2 - it has an UART tool mode). So I can get the exact discharge curves, and an approximate capacity measurement in mAh. In the end, it turned out to be a functional battery analysis tool - for example, here are some discharge curves:

Nokia BL-5C:


4xAA Eneloops (the label says 1800 mAh minimum, 2000 mAh typical).


Here's a comparison between the Nokia battery and a Canon dSLR battery (the latter has two cells, so its voltage is divided by two in the graph):


The software grew up signigicantly, to the point it did not fit in the program memory anymore. I decided it would be just better to replace the PIC chip with a bigger one (16F690->16F1829).

The finalization

Back to the enclosure thing. There are a few possible ways to paint labels on a small, dark, plastic box: screen printing, laser engraving, offset printing...
Fortunately for me, a kind person that does this sort of stuff stepped in and offered me to do a screen printing of the box for me. However, I was curious enough to try the laser engraving as well (while waiting for the screen-printed version to become ready). So, I ended up in a laser engraving studio with two boxes to be printed on. One was the red-painted one, only sanded down and repainted clean from scratch; the other one was a new box without any surface treatment.

We first tried the laser on the painted one (I hoped it would turn out good, even though the guys weren't so optimistic). Indeed, the laser only does a temperature-induced displacement of the paint, and it is very sensitive to the paint thickness. The back side came out somewhat acceptable:



The other one was not so well, though:


The unpainted box came out a lot better, using the laser in low-power mode only:
..

There's a room for improvement in terms of contrast, but otherwise it's great, the fine detais are very crisp.

The other one is the one from the professionalist (Lubo):
.

The finalists (before adding varnish)


After the varnishing:


I'm not kidding. It's just that the engraving disappeared (quietly, quickly and irreversibly) on the first varnish spraying. Have you ever played with Paint/Photoshop/GIMP and tried the rubber tool? Well, the feeling was just like it :)

The label is absolutely unintelligible now:


And here's the improvised spraying station:
.

In the end: two scrapped boxes, and one surviving one, done entirely by a professional. Making enclosures sucks!

It's time for the last changes on the sandwich:


While it looks like someone took a bite, it's really a broken off edge, which otherwise interfered with the box and the sandwich wouldn't fit. I also replaced the push button with a taller one.

Time to put it into the box for the last time:
.

The finished product

..
.

I have:

• A pocket voltmeter;
• Battery capacity checker, using calibrated discharge curves of the batteries I'm interested in;
• Quick and safe discharger of NiMH batteries;
• Possibility to analyze batteries (capacity, discharge curves, etc.);

You can see it in action here:

Also, a local copy (H.264)

The future

I'm going to buy a huge arsenal of batteries next week, of all brands I'm able to find (AAAs, AAs, 9-volts). Then check them and find out which one gives off most mAh for the bucks :)

If anyone has an idea of anything further to be tested with the unit, don't hesitate to put it in the comments!

Posted in category Hardware -- 17 Apr 2012, 13:06, 9 comments

Geiger counter + iPad

Two months ago, I purchased a geiger counter kit from MightyOhm. The assembly was easy, and the tool works perfectly at its intended purpose. However, I wanted to export the radiation data to a higher-level device, e.g. an Android phone, thus making the geiger counter purely a "sensor", that the higher-level device uses. This enables you to get exact radioactivity readings (in µSv if you wish). Also, you can accumulate data for a longer time window, enabling you to detect if one place is just slightly more radioactive than another (which is very hard, if not impossible, to do by ear). You can also get GPS-matched logging, graphing and whatnot.

So the first idea was to solder a small bluetooth module to the free pins of the microcontroller. However, I subsequently went into a different direction, prompted by an iOS app I saw on the internet - Geiger Bot. It supports any geiger counter it is able to "hear", either from the built-in mic, or by using the microphone input. So I decided to use the PULSE output header of the geiger counter kit and connect it with an "audio" cable to the higher-level device's audio port. It turns out that the headphone socket of the iPhone/iPad is really a 4-connector TRRS one, so while it accepts standard 3.5mm stereo jacks, it can also take a 4-connector one like the one below:



The other end of the cable is an ordinary RCA ("cinch") connector, since I don't need more than one channel. The figure also shows what the connections should be like.

Then I removed the PULSE header from the geiger kit's PCB and soldered two wires, that lead to the female RCA socket:



From left to right, the PULSE header's pads are V+ (3 V), signal, and ground.

The pulses from the geiger counter are a bit high, they have to be converted to around 0.1V, using a 30:1 voltage divider. The schematic:


(This explanation is courtesy of comment I found somewhere around the Geiger bot's webpage)

I installed the RCA socket into a hole I drilled in the transparent plastic. As I don't own a dremel, the drilling was done in the following way: take a paperclip and unfold it into a "L"-like shape. Then heat the short part to a candle flame, until it glows red. While it's hot, quickly press it to the plastic, melting a small hole in it. The hole is later enlared by putting a small screwdriver inside it and rotating it until it widens the hole enough. The hole will probably still be too small when you're done with that screwdriver, so next you get a larger one, etc. In the end you get a very beautiful, round hole, and nobody would even suspect the medieval method you've used :)

Anyways - the RCA socket is now installed, you need to wire up that resistor divider, and the "audio interface" is ready:





You don't need to build a special connector cable; you can find a TRRS-to-3-RCA cable in most camera stores, as they're usually used for the TV out function of digital cameras.

Then we connect the devices, fire up the Geiger bot, and we have a high-level Geiger counter, with all the featues you could've wanted!
Here's it in action:



Youtube


I'm testing it with the same rock as in the previous video.

Just a quick note, if you're dealing with radioactive sources like the one in the video: it seems that Geiger bot is only optimized for low radiation levels, and the default settings impose a limit of around 50-60 CPS and don't detect higher levels. This is more than enough for background radiation sources, but that stone actually emits around 250 CPS (and the geiger counter can actually supply up to 10 000)! So, you have to go in settings, and select Custom GM Tube..., and then Audio IO settings and decrease the RMS window/delay windows to the minimum. These settings allow it to show the actual radiation of this piece.

Now, the only downside is that I still want to have this on my phone, and I don't have or want an iPhone. So I'm thinking about porting this app to Android (probably somewhat simplified, I'm not promising a complete port!).

Posted in category Hardware -- 23 Mar 2012, 13:03, 0 comments

Programmed gardening, v. 2.0

Take a programmer, add some electronics, and a poor houseplant. What would you get?

Yes.
Flower abuse.
Or, "Gardening meets Programming, ver. 2.0".

As the previous attempt to make the poinsettia blossom didn't succeed, it was time to approach it more gently.

First, let me tell you (in my defence) that it isn't just me who's messing with the poor plant. Its development basically halted long ago, and its stealthy attempts to slip through a little new leaf or appendage would be faced with inevitable trimming, as my mother would trim it anytime she sees anything above the 20cm height-line. You know, riots need to be put down as early as possible :)
However, this summer I changed places, and the flower was now within my guardianship, so I let it grow. And gosh, it did :)
Well, that meant that the Thing's black box had to be upgraded. I also had some difficulty installing the crane in the new appartment.

In the end, I followed another approach: let's just keep the flower in shade, and illuminate it by other means, 10 hours a day.

1. I needed to provide a light source, which would be suitable for photosynthesis. Luckily, NASA had already researched that (f.e.), and they recommend using LEDs for that purpose, for efficiency and resource reasons. LEDs produce very little heat, thus the lighting won't incur any additional evaporation. The optimal light color is also known, this patent recommends red, orange and blue LEDs, in proportions of 12:6:1.

2. I bought some ultra-bright LEDs. Calculating the actual number of LEDs turned out to be a fairly complex deal, as one gets quickly submerged in the miriad of photometric units: lumens, lux, candelas, Watts per steradian... After double-checking my calculations with some other people, I placed 17 red, 8 yellow and two blue LEDs, each having 10000mcd of brightness. The aimed for around 2000 lux at peak, which was achieved (as checked with a dSLR-used-as-a-light-meter).

3. I prototyped on a breadboard:
.

4. And later moved it on a perfboard:


5. I analized some graphs of the sun's brightness when measured around sunrise. The light intensity shoots up no less than 1000 times (more like 10k in fact). I did some PWM to implement smooth "warming" of my artificial sun (see the video below). I only managed getting ~1000:1 contrast, and the initial part of the "sunrise" sequence is a bit buggy. I also programmed the yellow diodes to be lagging 20 minutes behind the red ones, and similarly for the blue ones, which are offset by an hour. The intent of this was simulating the different light color of the sun around sunrise/sunset. Not very convincing though, to be fair.

6. I cannibalized an old lamp:


and got some screws and plates out of a Meccano set:


... and here I ran a test blink on my strange "lamp":
.

7. Timekeeping is done with a specialized date/time chip - DS132 - and a quartz resonator. The sunrise/sunset times are correct year-round; they correspond to the actual times in San Antonio, Texas (used this one-year online calculator). These could be calculated algorithmically, but since the PIC is not exactly fit for floating-point math, sines/cosines, etc., I found it better to keep all the sunrise/sunset data in a static array, in a delta-compressed manner.
DS1302 continues to keep accurate time even after a power failure, as it supports backup power. This would normally be a battery, but I chose to just place a big electrolytic cap, which the DS1302 would charge while the main power is OK:


4700µF is more than enough, it can keep the clock alive for a bit more than a day.

8. Finally, I placed the poinsettia in a dark corner, with the "lamp" hanged around 30 cm above it (there has to be some space between them, as the light beam of these LEDs is quite narrow - so the space is needed to get more even illumination on the whole plant).
Finally, it's time to plug the power adapter in the socket, and the lamp follows the programmed daylight cycle, each day on...

.
.

And here's the sunrise, captured on video: Youtube.

The whole thing ("project: Daylight" I call it) wastes around a watt. The LEDs don't heat up at all.

The plant doesn't show signs of impendent blossom. It's been hooked up for around a month and a half now.
If flowers were capable of commiting suicide, this one would've been long gone.

Things learned:

• A whole project written in C. Not a single line of assembly for this one, just C, using the Hi-tech compiler. Well, this time I can't account for every last byte of the memory, but as long as the memory still suffices - it's not a problem¹.
• Inter-chip communication, the DS1302 specifically. What I did could classify as writing a driver, albeit a very simple one. Anyhow, a lot of unknown areas, related to hardware communcation, did clear up to me.
• Thinking photometrically: the lux, lumen, candela, and the geometric meaning of all these.
• Non-volatile memory (EEPROM) in projects like this. The PIC has it built-in, and thanks to that, I realized some kind of a zero-button user interface. I wanted to have two functions available: the normal one, and a test "blinker" function. This would have required either a button, or a DIP-switch. Well, the smarter way to convey our intention to the hardware, using only the On/Off switch can be something like that:

1. Turn the switch On.
2. Quickly turn it off again.
3. Turn it on. If the time between 1) and 2) was less than a second, enter in the test function mode, otherwise continue normally. Here's where the non-volatile memory comes into play. At bootup, the software quickly raises some flag in the EEPROM, and a second later turns it down again (if we're still alive). The next power-up can see whether the flag was cleared and decide accordingly.

• The compiler is your friend. Not long ago, I was a big fan of filling my sources with that cute magic-number arrays, which have been conveniently computed by some throwaway script. Well, I'm now for moving as much as possible inside the C/C++ code, wherever practical. The compiler can compute a lot of things all by himself, at compile time. So, no more magic numbers - but code/macros and the like - which derive the said magic numbers. For example: the DS1302 needs power, otherwise it loses track of time and thinks its Jan 1st, 2000. This may happen when placing it initially, or when moving it to the circuit board, or even by mistake. Well, I could've prepped a special build, which initializes it with the correct date/time, but that would be too hacky, as it doesn't leave a track how the DS1302 was ever initialized in the final code. Instead, one can use the __DATE__/__TIME__ pseudovars, which the C compiler is so nice to provide, and derive the correct dates/times from them. Thus, initialization is just a rapid recompile/program/run succession, and, more importantly, code is easier to maintain.
• MPLabX under Linux. Not the greatest IDE on Earth, but it gets work done.

---
¹ That kind of thinking is, of course, completely flawed, and leads to abominations. You could end up writing in C# if you stick to it for too long :)

Posted in category Hardware -- 30 Jan 2012, 03:53, 1 comment

PIC 3 RC2

I was in the lets-solder-something-just-for-the-heck-of-it mood so I grabbed the soldering iron. The results: my box mover now has a capacitor-based redundant power supply, implemented on a separate perfboard:




I haven't tested it thoroughly, but it easily survives at least half an hour without mains power. Nanotechnologies rock (I mean, 1F caps are surely awesome)!.

The original mission is probably about to fail: the plant has not shown any signs of turning red anytime soon. I'm going to tease it for another month, though.

Unrelated: want to know when you should celebrate the 10000th day since you were born? Check this out!

Posted in category Hardware -- 27 Jan 2011, 00:24, 0 comments

Tube sound

Hey guys, happy new year to all of you!

I got recently into the audio hardware mood and did some testing at home - I have a couple of unused car audio speakers, and I went to check out whether it was worthy to assemble a DIY audio system, based on them. Basic PC usage, that is. After all, any audio geek out there would tell you that the speaker size is a key factor of the sound quality - good sound requires bigger speakers. Well, what I have here are 6.5" speakers, compared to the 3.5"-4.5" that are commonly available in consumer desktop PC speakers.

Well, after some testing, I concluded that the car audio speakers are inferior. So, if you want a decent sound, you should start with a pair of specialized, high-quality speakers - the ones used in cars are not good.

During testing, I tried what would happen if I put a small light bulb in series with the speaker:

DEMO

Enjoy the "warm", "tube" sound :)
What you won't hear from the youtube clip is that the bulb acts as an active component of the system, it is not just a blinking coolness! Remember that a resistor (the wire in this case) becomes more resistive as the temperature increases, so when the bulb shines bright after a powerful bass-kick, its increased resistance attenuates the sound a bit (not much, but it's quite noticeable). So, in short, it acts like a slow-acting audio compressor. Combined with the thermal inertia effects, I was truly amazed by the amount of functionality that can be achieved by a simple hot wire!

Posted in category Hardware -- 8 Jan 2011, 20:57, 0 comments

Older posts >>