Computing stuff tied to the physical world

Archive for May 2012


TK – Multimeter accuracy

In Hardware on May 31, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

Once you get into calibration stuff, it’s hard to stop. I recently bought this DMMCheck from voltagestandard.com:

DSC 3314

The nice thing about this unit is that it’s fully self-contained (with a 9V battery on the back) and that it has all the bits and pieces on board to check a multimeter’s (DC) voltage, (DC) current, and resistance measurements.

It comes with a calibration report – the voltage has been trimmed to exactly 5V, but the rest will have slightly different values due to component and temperature tolerances. Also, it was calibrated at 70°F (21.1°C):

DSC 3315

Here are my HP 34401A measurements, with only 15 minutes warm-up (it’s now about 23.5°C here at JeeLabs):

DSC 3316

DSC 3317

DSC 3319

DSC 3318

Very close – more than close enough to start checking the VC170 multimeter I described recently, for example:

DSC 3323

DSC 3322

DSC 3320

Easily within spec. Note that a VC170 only has 400 µA + 400 mA ranges, and 1 mA only shows 2 decimal points.

Here’s a higher-spec VC940, which I find unconvincing – I use it rarely anyway, due to its slow refresh rate:

DSC 3324

Here’s a very low end Extech MN15 – it performs worse than the VC170 and can only display values up to 1999:

DSC 3328 DSC 3325 DSC 3327

And finally, as flash from the past, a cheap analog multimeter – this one is probably over 30 years old:

DSC 3329

We’ve sure come a long way, from trying to guess the value while not mixing up all those scales!

This reaffirms my choice of using the VC170 for day-to-day use, with the high-end HP 34401A used for top accuracy and for long-running experiments (handheld multimeters always auto-shutdown much too quickly).

As you can see, the DMMCheck is an superb little tool to quickly do a sanity check of your multimeter(s). There’s now also a DMMCheck Plus with extra signals to check AC voltage + current, and even frequency + duty cycle.

If you take lots of measurements over the years, it’s well worth getting something like this to verify your DMM.

This all relates to a discipline called metrology (no, not “meteo”, but “metrics”) – i.e. the science of measurement.

Zero voltage diode

In Hardware on May 30, 2012 at 00:01

Two weeks ago, user @tmk commented on the weblog post about diodes with a pointer to a Zero Volt Diode.

Here’s the circuit, by Wilf Rigter:

200px NsmailCA

I couldn’t quite wrap my head around it, so I re-drew it in a different way – it’s still the same circuit:

JC s Grid page 15 copy

The key is that a MOSFET can switch a voltage with nearly no voltage drop, i.e. a signal on its gate can turn it from near-infinite to near-zero resistance. There’s no “bipolar junction” involved, therefore no 0.6V .. 0.8V threshold.

I’m not going to explain the circuit, but I’ve built it up and did some measurements to show its behavior:

DSC 3223

Since a supercap has all sorts of odd behavior w.r.t. deep discharge and such, I replaced it with a 6800 µF electrolytic cap for this experiment, in parallel with a 1 kΩ resistor to simulate a load of a few mA.

Instead of the solar panel, I’m using a 2.9V power supply, limited to supply at most 10 mA. In other words, when connected to the capacitor, it will reduce its voltage a bit while the charging current is high, and then end up as 2.9V once the capacitor has been fully charged up. This makes it similar to a solar cell with limited capacity.

Enough talking. Let’s see how this thing behaves, while tracking a number of voltage levels at the same time:

SCR70

There’s a lot to describe here:

  • the RED line is the voltage from the power supply, i.e. Vsolar
  • the YELLOW line is the voltage over the capacitor, i.e. Vcc
  • the GREEN line is the voltage between drain and source of the MOSFET
  • the BLUE line is the voltage on the gate of the MOSFET
  • all signals have their zero origin at 2 divisions from the bottom
  • power was turned on after 2 seconds from the left edge of the screen
  • power was turned off again about 5 seconds later

The RED line is actually the YELLOW line minus the GREEN line.

The first thing to note is really the whole point of this circuit: the voltage on the capacitor (YELLOW) rises up to 2.84V, while the input voltage (RED) reaches 2.90V, so there’s only a 0.06V voltage drop over that FET while it conducts. That’s a ten-fold improvement over a silicon diode, and three-fold over a Schottky diode.

I’m using a BC557 for the PNP transistor, a BC549 for the NPN transistor, and a VN2222 as MOSFET, just because I happened to have those lying around. That MOSFET in particular is not a great fit here, really.

The other peculiar thing about this circuit, is that the MOSFET is used for current flowing through it in the wrong direction, from drain to source! But most MOSFETs won’t mind, they really act a bit like (controllable) resistors.

The most interesting bit is the GREEN signal, i.e. the voltage over the MOSFET. At input levels under about 1.5V it does conduct, but with a substantial voltage drop – first from the built-in diode conducting, and then gradually the MOSFET turns on and its low resistance takes over, with a total voltage drop of some 30..60 mV.

When the input voltage is completely switched off, the MOSFET goes into high impedance mode within a fraction of a second, which can be deduced from the fact that the GREEN and YELLOW lines meet up and overlap.

Lastly, once the voltages drop below about 0.4V, the gate voltage on the MOSFET rises a bit, but this is not enough to turn it on, and also not very important since the whole circuit is now essentially “dead”.

Here’s the second event in greater detail, i.e. when the input voltage drops – or in this case, gets switched off:

SCR71

The MOSFET is switched off within milliseconds, with the cap now holding a higher voltage than the input.

The result of it all is that the capacitor soaks up almost all the voltage it can get, with no diode forward voltage drop involved. When the input voltage drops, the circuit disconnects it from the cap so it’ll retain its charge. Brilliant!

Update – Wanted to get a bit more info on-screen, so here’s another scope capture (oops, green is now yellow):

SCR16

It better displays the elegant “swirly” charge ramp, with an odd little 64 mV bump on the MOSFET when the cap is full (maybe that’s the power supply switching to constant voltage mode). Given that the cap voltage reaches 2.82V and is loaded down by a 1 kΩ resistor, we can deduce that the current through the MOSFET must be 2.82 mA at that point, and therefore that its resistance is 23 Ω in this circuit (64.57 mV / 2.82 mA, Ohm’s law again!).

,

It’s about survival

In AVR, Hardware, Software on May 29, 2012 at 00:01

When running off solar power, ya’ gotta deal with lack of (sun-) light…

As shown in a recent post, a 0.47F supercap appears to have enough energy storage to get through the night, at least when assuming that the day before was sunny and that the nights are not too long.

There are still a couple of issues to solve. One which I won’t go into yet, is that the current approach won’t start up properly when there is only a marginal power budget to begin with. That’s a hard problem – some other time!

But another tactic to alleviate this problem, is to try and sail through a low-power situation by reducing power consumption until (hopefully) more energy becomes available again, later on.

Here’s my first cut at implementing a “survival strategy”, using the radioBlip2 sketch:

Screen Shot 2012 05 15 at 14 00 12

It’s all in the comments, really: when power is low, try to avoid sending packets, since turning on the transmitter is by far the biggest power “hog”. And when power is really low, don’t even measure VCC – just slow down even more in maximally efficient sleep mode – I’ve set the times to 5 and 60 minutes. The 1-hour sleep being a last effort to get through a really rough night…

But I’ve also added some kamikaze logic: when running low, you don’t just want the sketch to go into sleep mode more and more and finally give up without having given any sign of life. So instead, when the sketch is about to decide whether it should send a packet again, it checks whether the voltage is really way too low after what was supposedly a long deep-sleep period. If so, and before power runs out completely, it will try to send out a packet anyway, in the knowledge that this might well be its last good deed. That way, the central node might have a chance to hear this final swan song…

The thresholds are just a first guess. Maybe there are better values, and maybe there is a better way to deal with the final just-about-to-die situation. But for now, I’ll just try this and see how it goes.

One last point worth mentioning: all the nodes running this sketch can use the same group and node ID, because they are transmit-only. There is never a need to address packets sent towards them. So the BLIP_ID inside the payload is a way to still disambiguate incoming packets and understand which exact node each one came from.

Re-using the same node ID is useful in larger setups, since the total number of IDs in a group is limited to 30.

I’ll do some tests with the above logic. Let’s hope this will keep nodes alive in long and dark winter days nights.


Re-thinking solar options

In AVR, Hardware, Musings on May 28, 2012 at 00:01

So will it ever be possible to run a JeeNode or JeeNode Micro off solar power?

Well, that depends on many things, really. First of all, it’s good to keep in mind that all the low-power techniques being refined right now also apply to battery consumption. If a 3x AA pack ends up running 5 or even 10 years without replacement, then one could ask whether far more elaborate schemes to try and get that supercap or mini-lithium cell to work are really worth the effort.

One fairly practical option would be a single rechargeable EneLoop AA battery, plus a really low-power boost circuit (perhaps I need to revisit this one again). The idea would be to just focus on ultra-low power consumption, and move the task of charging to a more central place. After all, once the solar panels on the roof of JeeLabs get installed (probably this summer), I might as well plug the charger into AC mains here and recharge those EneLoop batteries that way!

Another consideration is durability: if supercaps only last a few months before their capacity starts to drop, then what’s the point? Likewise, the 3.4 mAh Lithium cell I’ve been playing with is rated at “1000 cycles, draining no more than 10% of the capacity”. With luck, that would be about three years before the unit needs to be replaced. But again – if some sort of periodic replacement is involved anyway, then why even bother generating energy at the remote node?

I’m not giving up yet. My KS300 weather station (868 MHz OOK, FS20’ish protocol) has been running for over 3 years now, I’ve never replaced the 3x AA batteries it came with – here’s the last readout, a few hours ago:

     :41   KS300 ookRelay2 humi             77
     :41   KS300 ookRelay2 rain             469
     :41   KS300 ookRelay2 rnow             0
     :41   KS300 ookRelay2 temp             18.2
     :41   KS300 ookRelay2 wind             0

And the original radioBlip node is also running just fine after 631 days:

    1:32   RF12-868.5.3 radioBlip age       631
    1:32   RF12-868.5.3 radioBlip ping      852330

Even the JeeNode Micro running on a CR2023 coin cell is still going strong after 4 months:

    1:42   RF12-868.5.18 radioBlip age      139
    1:42   RF12-868.5.18 radioBlip ping     188449

So ultra-low power is definitely doable, even with an Arduino-compatible design.

No worries – I’ll keep pushing this in various directions, even if just for the heck of it…


Reverse diode current

In Hardware on May 27, 2012 at 00:01

After measuring the forward voltage drop over a diode, I should also have measured the reverse leakage current, i.e. how much current the diode lets through when it’s supposed to be blocking. I never did until now, because I couldn’t detect any current in a quick check I did a while back. Time to build a better setup – here’s what I used:

JC s Grid page 17

The voltmeter’s own 10 MΩ or so internal resistance will skew the readings by 10%, but that’s no big deal.

It turns out that the reverse leakage current is pretty small when applying 5V:

  • 1N4004 – a high power diode: 1.3 mV = 1.3 nA
  • 1N4148 – a low power diode: 3.4 mV = 3.4 nA
  • BAT34 – a Schottky diode: 50 mV = 50 nA

That’s nanoamps, i.e. milli-milli-milli-amps. The Schottky diode does indeed leak a tad more than the others. Here are the specs of that BAT34 diode – note that the reverse current could even be used as temperature sensor!

Screen Shot 2012 05 14 at 17 15 55

FWIW, I found a minuscule “RB751S” SMD Schottky diode, about 1 mm long, which does a bit better at 7.0 nA:

DSC 3221

It was quite a challenge to get some wires soldered onto it. I used the core of 30 AWG Kynar “wirewrap” wire:

DSC 3222

Anyway – the BAT34 is good enough: 50 nA leakage is acceptable while dealing with circuits which consume µA’s.

,

Through the night on a supercap!

In Hardware on May 26, 2012 at 00:01

Yeay! – The JeeNode made it through the night on a 0.47F supercap, for the first time ever at JeeLabs:

Screen Shot 2012 05 15 at 10 59 19

Sorry for the awkward / missing scale, here’s some context:

  • vertical is voltage: 50 = 2V, 100 = 3V, 150 = 4V, 200 = 5V
  • blue is VCC before sending, green is VCC after sending
  • graph runs from 11:45 yesterday to 10:45 the next morning, i.e. 23 hours
  • that’s two VCC measurements and one packet transmission every minute

The supercap had been charged by the solar cell for 3 days, no load. When connecting the JeeNode (BOD set to 1.8V, on-board 100 µF i.s.o. regulator, already running), I placed it in a cardboard box to block out the light:

  • the first upward blip is at 12:45, during 5 minutes of exposure to sunlight
  • then back into the box until 18:30, depleting the supercap for a few hours
  • after that, the node was kept in the light to try and charge up enough for the night
  • at 20:00, the charge had gone up to 4.42V and 3.86V, respectively
  • at around 6:30 the next morning, the lowest point was reached: 3.44V and 2.88V
  • from then on, the cell started charging again from the morning light (no direct sunlight yet)
  • looks like about 10% of the packets never arrived (probably mostly due to collisions)

At noon, the cap voltage had risen to 4.9V (note that the RFM12B is now operating above its official 3.8V max).

So there you have it: one packet per minute powered by solar energy, harvested indoor near a window.

Update – FWIW, this setup lasted a second day, but then it died again… we’re not done yet!


Different op-amps

In Hardware on May 25, 2012 at 00:01

One last experiment I wanted to do after the recent sine wave circuits, was to compare a few different op-amps.

I’m including the original one here as well – the LM358, running at ±13.6V:

SCR64

Here’s the LT1413, running at ±14.4V:

SCR65

And here’s the NE5532ANG, running at ±15.3V:

SCR66

In each case, the supply voltage was adjusted until the output sine wave was ±10 V, with all other components identical. Note the slight difference in oscillation frequency.

What’s also interesting, is the mean output voltage: it should be 0V with an ideal circuit. Looks like the NE5532ANG performs best – within 1%. It’s described as being an “Internally Compensated Dual Low Noise Operational Amplifier”. Second harmonic is at -51 dBm, i.e. 0.28% harmonic distortion – an excellent signal!

As a quick test with that last op-amp, I reduced the supply voltage to ±2.5V – the effect was a slightly higher frequency of 522 Hz, a much lower output of 2.14 Vpp, i.e. ±1.07V, but relatively far off-center: 240 mV. Harmonic distortion rises to 3.5% in this case. But that’s not surprising: the NE5532ANG is only specified down to ±3V, and it’s not a “rail-to-rail” op-amp, which means it cannot generate an output voltage too close to its supply voltage (with a ±5V supply, distortion drops back to 1.25%).

Lots of op-amps. Lots of trade-offs.

Ok enough op-amp chit-chat for now, I’ll stop :)

,

TK – Frequency Meter

In Hardware on May 24, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

Another post about frequencies – this time I’ve assembled a DFD4A from Almost All Digital Electronics:

DSC 3124

It’s a low-cost frequency counter which goes all the way up to 3 GHz. Here it’s measuring a 10 MHz signal from my Frequency Generator, while synchronized to the Rubidium frequency standard.

As you can see, it’s spot on – the last digit flips between 0 and 1 every so often, that’s all.

As with the Capacitance Meter I assembled recently, this kit comes with detailed build instructions. Except that this time I didn’t really want to build it, so I got the pre-built version instead, including the connectors and (fully) plastic enclosure. The front plate already has all the right cutouts, and a printed piece of paper (!) glued to the front. Works ok, but I suspect that it’ll get dirty over time.

The unit came with all the parts, I just had to solder a few components and wires in place after inserting all the switches and BNC connectors.

One thing missing was the 9V battery clip – but not to worry, I have a couple of those lying around anyway.

The reason to get this particular unit was its high frequency range of well over the 868 MHz and 2.4 GHz frequencies I may want to measure here at JeeLabs. The main difference with a professional unit is probably the fact that it doesn’t have many input signal options:

  • HF measures from 0 to 30 MHz, with 5 Vpp max into a high impedance input
  • UHF measures from 10 to 3000 MHz over a 50 Ω input (max 15 dBm)

No way to directly measure the 868 MHz output from an RFM12B, I suspect – i.e. it probably won’t be sensitive enough to measure 0 dBm.

The slow measurement mode continuously collects data for one second, so you get 1 Hz resolution on the HF range and 100 Hz resolution on the UHF range (since that’s essentially just a ÷ 100 prescaler).

The fast measurement mode runs 10 times per second, i.e. a gate time of 0.1s – so this gives 10 Hz resolution on HF and 1000 Hz (1 KHz) resolution on UHF.

It’s a bit odd that the display shows more significant digits than are being measured in all but FAST + HF mode, but no big deal – the current mode is clearly visible from the switch settings.

Knowing that the counter is very accurate (for now – it’ll no doubt gradually drift slightly), it’s time to find out how accurate the TG2511 AWG’s frequency is when not synchronized to the Rubidium standard:

DSC 3125

That’s only 0.4 ppm off and well within spec – excellent!

Virtuality vs Reality

In Musings on May 23, 2012 at 00:01

The worlds I dabble in at JeeLabs are twofold:

  • Software – a virtual world, artificially constructed, and limited only by imagination
  • Hardware – a real world, where electrons and atoms set the rules and the constraints

I’ve long been pondering about the difference between the two, and how I enjoy both, but in very different ways. And now I think I’ve figured out, at last, what makes each so much fun and why the mix is so interesting.

DSC 3208   DSC 3209

I’ve spent most of my professional life in the software world. This is the place which you can create and shape in whatever way you like. You set up your working environment, you pick and extend your tools, and you get to play with essentially super-natural powers where nearly everything goes.

No wonder people like me get hooked to it – this entire software world is one big addictive game!

The hardware world is very different. You don’t set the rules, you have to discover and obey them. Failure to do so leads to non-functional circuits, or even damage and disaster. You’re at the mercy of real constraints, and your powers are severly limited – by lack of knowledge, lack of instruments, lack of … control.

Get stuff working in either world can be exhilarating and deeply satisfying. Yes! I got it right! It works!

All of this appeals to an introvert technical geek like me, and all of this requires little human interaction, with all its complex / ambiguous / emotional aspects. It’s a competition between the mind and the software / hardware. There are infinitely many paths, careers, and explorations lying ahead. This is the domain of engineers and architects. This is where puzzles meet minds. I love it.

The key difference between software and hardware, when you approach it from this angle, is how things evolve over time: with software, there is no center of gravity – everything you do can become irrelevant or obsolete later on, when a different approach or design is selected. With hardware, no matter how elaborate or ingenious your design, it will have to deal with the realities of The World Out There.

So while after decades of software we still move from concept to concept, and from programming language to programming language, the hardware side more and more becomes a stable domain with fixed rules which we understand better and better, and take more and more advantage of.

In a nutshell: software drifts, hardware solidifies.

Old software becomes useless. Old hardware becomes used less. A very subtle difference!

The software I’ve built in the past becomes irrelevant as it gets superceded by new code and things are simply no longer done they way they used to be. There’s no way to keep using it, beyond a certain point.

Hardware might become too bulky or slow or power-consuming to keep using it, or it might mechanically wear out. But I can still hook up a 40-year old scope and it’ll serve me amazingly well. Even when measuring the latest chips or MOSFETs or LCDs or any other stuff that didn’t exist at the time.

Software suffers from bit rot – this happens especially when not used much. Hardware wears out, but only when used. If you put it away, it can essentially survive for decades and still work.

In practice, this has a huge impact on how things feel when you fool around – eh, I mean experiment – to try and to learn new things.

Software needs to be accompanied by documentation about its internals and it needs to be frequently used and revisited to keep it alive. Writing software is always about adding new cards to an existing house of cards – assuming I can remember what those cards were before. It’s all virtual, and it tends to fade and become stale if not actively managed.

Hardware, on the other hand, lives in a world which exists even when you don’t explore it. Each time I sit down at my electronics bench, I think “hm, what aspect of the real world shall I dive into this time?”.

I love ’em both, even though working on software feels totally different from working on hardware.


TD – LED flashlight

In Hardware, News on May 22, 2012 at 00:01

Welcome to the Tuesday Teardown series, about looking inside the technology around us.

Today’s episode will be a short one, it’ll become clear why halfway down this page…

This is a little bargain LED flashlight, nothing to it really:

DSC 3228

Three AAA (not AA) cells, a toggle button, 24 + 4 white LEDs, and that’s it. Press the button once, and the 4 LEDs on the side turn on, press again to light the 24 on the top, and again to turn it off.

Quite a bright light BTW. The 4 LEDs draw 190 mA, with 16 it rises to 270 mA. That’s perhaps 4 hours of use with 16 LEDs before the batteries run out.

The circuit is as ridiculously simple as can be – one 4.7 Ω resistor and a switch:

DSC 3229

That “metal” reflector is actually plastic with a chrome finish. The PCB is one-sided, no doubt to lower the cost:

DSC 3230

(it won’t take much bending to create a short with that top wire!)

Using Ohm’s law (V = I x R), we can deduce that the LED’s forward voltage is 4.5 – X = 0.190 x 4.7 – in other words, X = 4.5 – 0.190 x 4.7 = 3.6V. Note that the light intensity will vary considerably with battery voltage and that this lamp won’t work at all with 3 AAA EneLoop batteries which only supply 1.2V to 1.3V when fully charged.

The reason I’m opening up this trivial little gadget is not to marvel at the deep electronic engineering that went into it, but to show how custom plastics and a custom case makes something quite practical and nice to the touch. The top and bottom have a rubbery feel to them. The bottom has a little plastic hook in it, which can be folded out.

The bigger news today is a bit of a mess, unfortunately.

Last night I decided to upgrade the JeeLabs server from Mac OSX 10.7.3 to 10.7.4 – that update had been out for a few days, worked fine on two other machines here, so it seemed safe to apply the update to the server as well.

It failed.

This server is connected via wired Ethernet, and I usually only look at the GUI via a VNC-like “Screen Sharing” mechanism built into Mac OSX. It works well, because that connection is re-established even when the machine is in an exclusive “Updating…” mode, so you get to track progress even while the system is busy replacing some of its own bits and pieces. No screen needed, even though part of admin interface sometimes uses the GUI.

Last night, the server failed to come back online. Which is a major hassle, because then I have to move it to another spot to hook up a mouse, keyboard, and monitor to see what’s going on. Never happened before.

Trouble is (probably), that I turned the darn thing off forcefully. I knew that all the VM’s had been properly shut down, and I heard the characteristic reboot “pling”, so I thought it was waiting for a GUI response… or something.

Then the trouble started. Hooked it up, did a restart: no go. So I restarted it in recovery mode, and did a disk check/repair of all the disks. Guess what: the startup disk with all VM’s could not be repaired… whoops!

Time to kick my backup strategy in gear. I have two in place: local hourly Time Machine backups to a second drive, and daily backups for all VM’s to the cloud.

To make a very long night story short: the local hourly backups are fine, but they do not include the VM’s (whole-file backups of a VM disk every hour is not really practical). And the daily backups? Well, they are indeed all there – I can get any day in the past 3 months back, for any of the 4 VM’s. Awesome.

But Turnkey Linux does things a bit differently. Very clever in fact: it only backs up the minimum. The Linux Debian packages for example: these are not backed up, but re-installed from some other source. The rest is a well thought-out mix of full and incremental backups, and it all works just as expected.

Except that my VM’s are about two years old now, and no longer the latest base images used by Turnkey Linux. No problem, they say: you can get the latest, and then recover your own stuff on top of that.

So I spent about 6 hours trying to work out how to get my VM’s back up from the Amazon S3 storage. No joy. I can see all the files being restored, but the result is not a working VM. At some point, package installs & updates hang, with either udev restart problems or bootdisk image generation problems.

And now the crazy bit: the JeeLabs weblog + forum + café sites are all back up again (phew!). I restored from Time Machine to a freshly freed disk partition, and restarted the Mac – it’s alive! Right now, the server is running from the new disk partition, but with the 4 VM disk images still on the damaged partition. So apparently they did not get any damage, although the Mac file system structure on that disk seems to be hosed.

I’ll spend some time thinking about how to clean up this mess, and how to avoid it in the future. The good news is that I lost no data – just a lot of time and some hair. Yikes … this really was uncomfortably close to the edge!

The moral: test the backup strategy regularly. It can still break, even when not changing anything!

Update – All systems are “go” again.

Update 2 – Final diagnosis: one of the 2 internal disks was getting too hot, leading to intermittent failure, so it was hardware after all – unrelated to the 10.7.4 software. And it was probably all my fault, because I placed a (fairly warm) router on top of the Mac Mini. I’m going to replace the failed system drive with with an SSD.


Producing a beefier signal

In Hardware on May 21, 2012 at 00:01

Let’s move on, now that we have a clean sine wave. The goal is to produce a ±10V sine wave to use for constructing a Component Tester. The sine wave produced so far was merely ±65 mV.

I re-used the same circuit as yesterday, but with slightly different settings. First of all, I replaced the op-amp by an LM358, which can handle higher voltages. Next, I halved all the R’s to 5 kΩ and doubled all the C’s to 0.2 µF. This reduces the loading of the feedback loop – it shouldn’t really affect the frequency.

To increase the output voltage, I connected the oscillator output signal to a non-inverting op-amp circuit:

Screen Shot 2012 05 13 at 18 04 33

In a nutshell: this circuit tries to keep Ve as close to zero as possible at all times. IOW, the op-amp will constantly adjust its output so that the tap on the Rf:Rg voltage divider tracks the Vin voltage on the “+” input pin.

Using Rf = 10 kΩ, and Rg = 470 Ω, its gain will be about 22x. The nice property of this circuit is that it has a very high input impedance, so there is virtually no current draw from the oscillator.

And sure enough, the output of this op-amp is a sine wave with many volts of output swing. Now it’s simply a matter of cranking up the supply voltages to ±13.6V and bingo, a ±10V sine wave:

SCR64

Very clean. Better even than the original circuit – the 2nd harmonic is now -49 dB w.r.t. to the base frequency. That’s just 0.35% of harmonic distortion – excellent!

That second op-amp came for free, since an LM358 DIP-8 package has two of them anyway. So the first op-amp is oscillating (at about 470 Hz) and the second op-amp brings the output level to ±10V.

It’s quite a mess on the mini-breadboard I used, but who cares – that’s what prototypes are for:

DSC 3215

One last check is needed to make sure that the LM358 is suitable. A component tester measures the effects of an unknown component in series with a 1 kΩ resistor. So in the worst case, with a simple wire as “unknown component”, the maximum current through that resistor will be ±10 mA. Luckily, according to the specs, an LM358 can supply at least 10 mA, and typically up to 20 mA on its output.

So that’s it: our Component Tester will need a ±13.6V supply, an LM358, and a few R’s and C’s. That supply voltage is not critical, as long as it’s stable – the output level could be adjusted to ±10V via a trimpot.

Welcome to the world of analog electronics!


A better sine wave

In Hardware on May 20, 2012 at 00:01

After the pretty bad sine wave trial of the last two days, it’s time to try another circuit:

Screen Shot 2012 05 13 at 15 55 30

This is a “Phase Shift Oscillator” from the same op-amp book as the other one. I used half a TLV2472.

This one is actually a bit simpler to explain: the op-amp is set up with 25..50x amplification, i.e almost a comparator (with 50x amplification, a 50 mV input above or below the 2.5V will drive the output to its limit). And indeed, the output signal of the op-amp looks somewhat like a heavily clipped sine wave:

SCR59

The 3 resistors and 3 capacitors create 3 RC “low-pass” filters in series, removing all the higher frequencies, i.e. harmonics. A fairly clean sine wave comes out at the end, as you can see here:

SCR58

The only problem is that the signal level has been reduced from a ±2.5 V level to ≈ ±65 mV, a 40-fold reduction!

So the op-amp itself has to amplify that level back up to produce the clipped ±2.5V signal again.

The frequency is determined by “phase shifts”. Each RC filter changes the phase of its input signal, and it will be by 60° at a certain frequency, so that 3 of them in series will then shift it by 180°. Since the signal is fed back to the “-” pin of the op-amp, that’s exactly the proper signal to generate the opposite output, i.e. shifted 180° out of 360°. This analog stuff gets complicated – don’t worry too much about it: just pick R and C values to get the right frequency, and make all of them the same.

I used 0.1 µF caps i.s.o. 10 nF caps, i.e. 10x larger than the original circuit. With these values, the oscillation in my setup turned out to occur at just about 440 Hz, i.e. a pure musical “A” tone!

I did have to increase the gain (1.5 MΩ / 55.2 kΩ = 27 in the above setup) to force oscillation. I changed RF to 1 MΩ and RG to 22 kΩ, for a gain of 47. This RG value is a bit low, it loads down the last RC section quite a bit.

What you’re seeing here is a classical example of a negative feedback loop, which ends up in a very stable state of oscillation. It oscillates because we’re delaying the feedback signal by about 2.27 ms through the RC chain. So the op-amp constantly overshoots around its mid-point (the 2.5V applied to the “+” input), but does so in a very controlled way. The amplitude can’t increase any further, since the op-amp is clipping at its limits already, and the amplification factor is large enough to keep boosting the swing up to that limit. You can see the startup ramp and stabilization when powering up:

SCR61

Here’s the FFT spectrum analysis of the generated sine wave:

SCR60

A clean signal compared to the previous experiment. The 2nd harmonic is ≈ 42 dB below the fundamental wave, the rest is even lower. Using this calculator, we can see that this represents about 0.8% harmonic distortion.

The only issue is that the signal is much weaker than the ±10V needed for a standard Component Tester.

But hey, let’s declare success for now – we’ve got a clean sine wave!


Generating a sine wave – part 2

In Hardware on May 19, 2012 at 00:01

After yesterday’s failed attempt to generate a clean since wave, I started experimenting a bit further. How could the Op-amp book be so wrong about the quadrature oscillator circuit?

The nice thing about op-amps in DIP-8 packages, is that most of them use the same pinout, so it’s very easy to swap them out and test different brands and types. The TLV2472 only supports up to 6V as power supply, most of the other ones go much higher – usually above 30V, i.e. ±15V.

Here’s the list of op-amp chips I tried (yeah, got quite a bunch of them in my lab, for various reasons):

  • TLV2474
  • LM358N
  • LM833N
  • NE5532ANG
  • OP2340
  • NJM14558D
  • MCP6023
  • LT1413

All of them had similar behavior, i.e. clipping at both limits of the voltage range, except for the LT1413:

SCR56

Still nowhere near a sine wave, BTW. But what’s more interesting, is the the voltage swing of this signal was just 4.5 Vpp, while the op-amp was being driven from a ±15V power supply in this particular case. So for some reason, it was “oscillating” at 1.25 KHz (about 8x higher than the other mode).

I have no idea what was going on. When trying to reproduce this a second time, I couldn’t get this behavior back. I suspect a loose connection, or perhaps some odd interaction due to the breadboard.

I’m not really interested in tracking down this issue, since it looks like this quadrature oscillator circuit is not suitable for a Component Tester – not without some sort of amplitude regulation anyway.

So there you have it – analog circuits also need to be debugged, as you can see!

Update – this issue has now been resolved, see the comments on yesterday’s weblog post.


Generating a sine wave

In Hardware on May 18, 2012 at 00:01

After the recent pretty disappointing results with a transformer-based Component Tester, I’d like to try and generate a ± 10 V sine wave at approximately 50 Hz in some other way. Using as few components as possible.

This is where we enter, eh, squarely into the analog electronics domain. Yes, we could generate it with an ATmega, but frankly that sounds like a bit of overkill, would require a fair amount of filtering to remove residual switching effects, and besides we’d still have to amplify it up to 10 Vpp.

Time to introduce some new circuitry!

One of the most incredible electronic building blocks invented in the second world-war era was the Operational Amplifier, or “op-amp” in short.

There’s way too much to say about this amazingly universal circuit, which even has its own schematic symbol:

180px Op amp symbol svg

A positive and negative power supply pin, a positive and a negative input, and an output pin. That’s it.

I’ve only just started exploring op-amps, really – one superb resource on the web comes in the form of a free eBook from 2002 on the Texas Instruments site, titled “Op Amps For Everyone”, by Ron Mancini.

In his chapter on Sine Wave Oscillator, he mentions a “Quadrature Oscillator” built from two op-amps:

Screen Shot 2012 04 18 at 01 08 17

It uses very few components. This one was dimensioned for about 1.6 KHz, so I started with capacitors ten times as large, i.e. 0.1 µF, to lower the oscillation frequency. Here’s the result, using a TLV2472 dual op-amp:

DSC 3056

Powered by a supply of ±2.5V (i.e. 0 / 2.5V / 5V), I see this result on the scope, when attached to the sine output:

SCR53

Yeah, right. Clipping like crazy, i.e. overshooting into the limiting 0V and 5V power lines. The FFT shows it’s not anywhere near a pure sine wave, even though the shape vaguely resembles one:

SCR54

A pure sine wave would have a single peak at the oscillating frequency.

Here’s the cosine output, again showing that it’s running way outside its linear range:

SCR52

So yeah, we’re generating a 160 Hz signal, but it’s no sine wave and it would be useless as Component Tester.

Oh well, it was still an interesting first trial!


TK – Frequency accuracy

In Hardware on May 17, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

(this is again a bit of a side excursion, about checking the quality of a measuring instrument)

I recently visited a friend who had to get his frequency meter’s calibration verified to a fairly high precision. Thinking of the Rubidium clock I got from eBay, he came up with the idea of using a transfer standard.

The thing with accuracy, is that you have to have an absolute reference to compare against. One option is to go to a “calibration lab” and have them test, adjust, and certify that your instrument has a certain accuracy. Awkward, expensive, and usually a bit over the top for “simple” hobby uses.

So the other way to do things, is to “transfer” the calibration in some way. Buy or build a device which can keep the desired property stable, calibrate it to some standard, move it to where the instrument needing calibration is located, and compare the two. Or vice versa: match to instrument, then compare with a standard.

The latter is exactly what we ended up doing. First we created a little Arduino daughter board with a “VC-TCXO” on it: that’s a “Temperature Compensated Xtal Oscillator” which can be fine-tuned through a voltage. Here’s the setup, created and built by Rohan Judd:

DSC 3082

On the left, an SPI-controlled digital potmeter, on the right a VC-TCXO running at 10 MHz.

Via a sketch, the VC-TCXO was fine-tuned to produce exactly 10.000,000 MHz readout on the frequency counter we wanted to verify. This was done at about 18°C, but a quick test showed that this VC-TCXO was indeed accurately keeping its frequency, even when cooled down by more than 10°C.

I took this device back home with me, and set up my frequency generator to use the Rubidium clock as reference. So now I had two devices on my workbench at JeeLabs, both claiming to run at 10 MHz …

Evidently, they are bound to differ to some degree – the question was simply: by how much?

Remember Lissajous? By hooking up both signals to the oscilloscope, you can compare them in X-Y mode:

SCR26

Channel 1 (yellow) is the VC-TCXO signal, some sort of odd square wave – I didn’t pay any attention to proper HF wiring. Channel 2 (blue) is the sine wave generated by the frequency generator.

The resulting image is a bit messy, but the key is that when both frequencies match up exactly, then that image will stay the same. If they differ, then it will appear to rotate in 3D. It’s very easy to observe.

The last trick needed to make this work is simply to adjust the frequency generator until the image does indeed stop rotating. This is extra-ordinarily sensitive – the hard part is actually first finding the approximate setting!

After a bit of searching and tweaking, and after having let everything warm up for over an hour, I got this:

DSC 3080

IOW, the frequency I transferred back to JeeLabs with me was 9.999,999,963 MHz. We’re done!

To put it all into perspective: that highlighted digit is 0.1 ppb (billion!). So the frequency counter appears to be 3.7 ppb slow. Assuming that the transfer standard did not lose accuracy during the trip, and that my Rubidium clock is 100% accurate. Which it isn’t of course, but since its frequency is based on atomic resonance properties, I’m pretty confident that it’s indeed accurate to more than 0.1 ppb.

The real story here, though, is that such breath-taking accuracy is now within reach of any hobbyist!


First solar results

In AVR, Hardware on May 16, 2012 at 00:01

Some first results from trying to run a JeeNode off a 24 x 32 mm indoor solar cell…

In each of the cases described below, I’m using a JeeNode without regulator and with 100 µF cap hooked up, with fuses and settings as described in this post. The cap should have enough energy to cushion the dip from a small packet transmission. I’m using the latest radioBlip2 sketch, which now sends out the following 7-byte payload:

Screen Shot 2012 05 14 at 13 33 17

The benefit of this version, is that the sketch reports not just the battery level but also how far the battery level drops after sending out a packet once a minute. That value is sent out in the next packet, so it always lags.

To get started, I connect the JeeNode to a BUB, which charges the 100 µF cap to 5V (and runs the RFM12B slightly above spec). Then I disconnect and hook it up to the solar setup. This way I don’t have to deal with startup problems yet – which is an entirely different (and tricky) problem.

Yesterday’s elaborate setup didn’t get very far, unfortunately. Two different runs gave me just a few packets:

    L 09:16:01.571 usb-A600dVPp OK 17 1 0 0 0 1 209 0
    L 09:18:07.445 usb-A600dVPp OK 17 3 0 0 0 1 86 51
    L 09:19:10.308 usb-A600dVPp OK 17 4 0 0 0 1 86 50

    L 09:24:12.477 usb-A600dVPp OK 17 1 0 0 0 1 206 0
    L 09:25:15.707 usb-A600dVPp OK 17 2 0 0 0 1 86 210

Values are 20 mV steps, offset by 1V – the actual battery voltage is: 1 + 0.02 * X (where X is the reported value).

In the above runs, the battery is 86 (2.72V) before sending, and 50 (2.00V) after. That’s pretty close to the edge, I’m not sure why the drop is so large.

Another test with a 0.47 Farad supercap, charged for about 3 days to get the charge “deep” into the supercap, seems to fare a little better:

    L 09:43:06.943 usb-A600dVPp OK 17 19 0 0 0 1 210 52
    L 09:44:10.771 usb-A600dVPp OK 17 20 0 0 0 1 175 210
    L 09:45:14.549 usb-A600dVPp OK 17 21 0 0 0 1 175 146
    L 09:46:18.339 usb-A600dVPp OK 17 22 0 0 0 1 175 147
    L 09:47:22.100 usb-A600dVPp OK 17 23 0 0 0 1 175 147
    ...

That’s 4.50V and 3.94V before and after transmission, respectively. But a 0.47F supercap has a lot less energy in it than that 3.4 mAh Lithium cell used in the first tests above, so it’ll probably run down a lot faster.

After one hour, voltages drop to 4.28V and 3.72V. Two hours: 4.14V and 3.60V. Five hours: 3.92V and 3.36V. I’m not sure this will work, unless the node sends less at night perhaps or always restarts reliably the next day.

To be continued…

,

New solar setup

In Hardware on May 15, 2012 at 00:01

Time for another experiment, this time combining my small solar panel with the 3.4 mAh Lithium battery which seems to work so well. The circuit I’m going to try is as follows:

JC s Grid page 16

Here’s the construction, cozily attached to the back of the solar cell:

DSC 3128

Same solar cell, I think it can supply up to 4.5V @ 1 mA in full sunlight.

The tricky bit is that the rechargable lithium cell needs to be treated with care. For maximum life, it needs to be hooked up to a voltage source between 2.8V and 3.2V, and the charge current has to be limited.

Note that the 1 kΩ resistor is put in series with the battery not only to charge it, but also when taking charge out of it. Seems odd, but that’s the way the datasheet and examples show it. Then again, with a 10 µA current draw the voltage drop and losses are only about 10 mV. A diode bypass could be added later, if necessary.

The diode after the regulator has the nice effect of dropping the 3.3V output to an appropriate value, as well as blocking all reverse current flow. There is no further circuitry for the regulator, since I don’t really care what it does when there is too much or too little power coming from the solar cell. Let’s assume it’s stable without caps.

It all looks a bit wasteful, i.e. linearly regulating the incoming voltage straight down to 3.3V regardless of PV output levels and discarding the excess. But given that this little 3V @ 3.4 mAH battery has already supported a few days of running time when fully charged, maybe it’s still ok.

I’ll let this charge for a day or two.


Forward voltage drop on a diode

In Hardware on May 14, 2012 at 00:01

With all this tinkering with solar panels, little batteries, supercaps, etc, you often need to prevent current from leaking away. The usual approach is to insert a diode into the circuit.

Diodes conduct current in one direction and block the current in the opposite direction.

Well, that’s the theory anaway. In real life, diodes only conduct current once the voltage is above a certain level, and they tend to leak minute amounts of current when blocking the reverse voltage.

For ultra-low power use and the low voltage levels involved, you need to be careful about the type of diode used. A regular 1N4148 silicon diode has a forward drop of about 0.65V, quite a bit when supplies are 2..3V!

The Schottky diode has a much lower voltage drop. It’s usually specified as 0.3..0.4V, but it really depends on the amount of current passed through it.

To see the properties of the BAT43 Schottky diode I’ve been using, I created this simple test setup:

JC s Grid page 18

A 10 Hz “sawtooth” voltage is used to create a signal rising from -3V to +3V in a linear fashion, 10 times a second. This means that the current through the 100 kΩ resistor will go from -30 µA to +30 µA. We can then watch the voltage over the diode, and how it goes from a blocking to a conducting state:

SCR45

The yellow trace is the sawtooth signal applied to the circuit. The blue trace is the voltage over the diode. Note the difference in vertical scale.

You can see that with negative voltages, the diode just blocks. As it should. With positive voltages up to 1.2V, i.e. a current up to 12 µA, the voltage drop over the diode is under 0.15V, rising slowly to about 0.175V at 30 µA.

Changing the resistor to 10 kΩ to increase the current by a factor of 10, we get this:

SCR49

Same picture, different scale. At 300 µA, the voltage drop is now about 0.23V, and it’s fairly flat at that point.

For comparison, here’s a run-off-the-mill 1N4148 “standard” silicon diode:

SCR50

Again: different vertical scale. About 0.53V at 300 µA. More importantly, it’s already 0.4V at 60 µA.

So when losses matter at low voltages and low currents, it’s better to use Schottky diodes.


Watching it go down

In AVR, Hardware, Software on May 13, 2012 at 00:01

Now that there’s low-power vccRead() code to measure the current power supply voltage, we can finally get a bit more valuable info from the radioBlip sketch, which sends out one packet per minute.

So here’s a new radioBlip2 sketch which combines both functions. To support more test nodes, I’m adding a byte to the payload for a unique node ID, as well as a byte with the measured voltage level:

Screen Shot 2012 05 09 at 18 28 02

As a quick test I used a JeeNode without regulator, running off an electrolytic 1000 µF cap, charged to 5V via a USB BUB, and then disconnected (this is running the RFM12B module beyond its 3.8V max specs, BTW):

DSC 3127

Here’s a dump of the received packets:

    L 16:56:32.032 usb-A600dVPp OK 17 1 0 0 0 1 209
    L 16:57:35.859 usb-A600dVPp OK 17 2 0 0 0 1 181
    L 16:58:39.543 usb-A600dVPp OK 17 3 0 0 0 1 155
    L 16:59:43.029 usb-A600dVPp OK 17 4 0 0 0 1 134
    L 17:00:46.323 usb-A600dVPp OK 17 5 0 0 0 1 115
    L 17:01:49.431 usb-A600dVPp OK 17 6 0 0 0 1 98
    L 17:02:52.314 usb-A600dVPp OK 17 7 0 0 0 1 82
    L 17:03:55.016 usb-A600dVPp OK 17 8 0 0 0 1 66
    L 17:04:57.526 usb-A600dVPp OK 17 9 0 0 0 1 50

Or, more graphically, as voltage – showing 8 minutes before the sketch runs out of juice:

Screen Shot 2012 05 09 at 19 06 19

This consumes only marginally more power than without the VCC measurements: the original radioBlip sketch lasted 1 minute longer under similar conditions, i.e. one extra packet transmission.


Improved VCC measurement

In AVR, Software on May 12, 2012 at 00:01

As shown in this post, it is possible to read out the approximate level of VCC by comparing the internal 1.1 V bandgap with the current VCC level.

But since this is about tracking battery voltage on an ultra-low power node, I wanted to tinker with it a bit further, to use as little energy as possible when making that actual supply voltage measurement. Here’s an improved bandgap sketch which adds a couple of low-power techniques:

Screen Shot 2012 05 09 at 15 42 39

First thing to note is that the ADC is now run in noise-canceling-reducing mode, i.e. a special sleep mode which turns off part of the chip to let the ADC work more accurately. With as nice side-effect that it also saves power.

The other change was to drop the 250 µs busy waiting, and use 4 ADC measurements to get a stable result.

The main delay was replaced by a call to loseSomeTime() of course – the JeeLib way of powering down.

Lastly, I changed the sketch to send out the measurement results over wireless, to get rid of the serial port activity which would skew the power consumption measurements.

Speaking of which, here is the power consumption during the call to vccRead() – my favorite graph :)

SCR41

As usual, the red line is the integral of the current, i.e. the cumulative energy consumption (about 2300 nC).

And as you can see, it takes about 550 µs @ 3.5 mA current draw to perform this battery level measurement. The first ADC measurement takes a bit longer (25 cycles i.s.o. 13), just like the ATmega datasheet says.

The total of 2300 nC corresponds to a mere 2.3 µA average current draw when performed once a second, so it looks like calling vccRead() could easily be done once a minute without draining the power source very much.

The final result is pretty accurate: 201 for 5V and 147 for a 4V battery. I’ve tried a few units, and they all are within a few counts of the expected value – the 4-fold ADC readout w/ noise reduction appears to be effective!

Update – The latest version of the bandgap sketch adds support for an adjustable number of ADC readouts.

Documentation Dilemma’s

In Musings on May 11, 2012 at 00:01

Let’s face it – some parts of the JeeNode / JeePlug documentation isn’t that great. Some of it is incomplete, too hard, missing, obsolete, or in some cases even just plain wrong.

I think that the fact that things are nevertheless workable is mostly because the “plug and play” side of things still tends to work – for most people and in most cases, anyway. You assemble the kits, solder the header, hook things up, plug it into USB, get the latest code, upload an example sketch, and yippie… success!

But many things can and do go wrong – electrically (soldering / breadboarding mistakes), mechanically (bad connections), and especially on the software side of things. Software on the host, but most often the problems are about the software “sketch” running on the JeeNode. You upload and nothing happens, or weird results come out.

Ok, so it doesn’t work. Now what?

There’s a chasm, and sooner or later everyone will have to cross it. That’s when you switch from following steps described on some web page or in some PDF document, to taking charge and making things do what you want, as opposed to replicating a pre-existing system.

To be honest, following instructions is boring – unless they describe steps which are new to you. Soldering for the first time, heck even just connecting something for the first time can be an exhilarating experience. Because it lets you explore new grounds. And because it lets you grow!

As far as I’m concerned, JeeLabs is all about personal growth. Yours, mine, anyone’s, anywhere. Within a very specific domain (Physical Computing), but still as a very broad goal. The somewhat worn-out phrase applies more than ever here: it’s better to teach someone how to fish (which can feed them for a lifetime) than to give them a fish (which only feeds them for a day).

IMO, this should also drive how documentation is set up: to get you going (quick start instructions) and to keep you going, hopefully forever (reference material and pointers to other relevant information). A small part of the documentation has to be about getting a first success experience (“don’t ask why, just do it!”), but the main focus should be on opening up the doors to infinitely many options and adventures. Concise and precise knowledge. Easy to find, to the point, and up to date.

Unfortunately, that’s where things start to become complicated.

I’m a fast reader. I tend to devour books (well, “skimming” is probably a more accurate description). But I don’t really think that thick books are what we need. Sure, they are convenient to cover a large field from A to Z. But they are reducing our options, and discourage creative patterns – What if I try X? What if I combine Y and Z? What if I don’t want to go a certain way, or don’t have exactly the right parts for that?

This weblog on the other hand, is mostly a stream-of-conscience – describing my adventures as I hop from one topic to the next, occasionally sticking to it for a while, and at times diving in to really try and push the envelope. But while it may be entertaining to follow along, that approach has led to over 1000 articles which are quite awkward as documentation – neither “getting started” nor “finding reference details” is very convenient. Worse still, older weblog posts are bound to be obsolete or even plain wrong by now – since a weblog is not (and should not be) about going back and changing them after publication.

I’ve been pondering for some time now about how to improve the documentation side of things. There is so much information out there, and there is so much JeeLabs-specific stuff to write about.

Write a book? Nah, too static, as I’ve tried to explain above.

Write an eBook? How would you track changes if it gets updated regularly? Re-read it all?

A website? That’s what I’ve been doing with the Café, which is really a wiki. While it has sections about software and hardware, I still find it quite tedious (and sluggish) for frequent use.

I’ve been wanting to invest a serious amount of time into a good approach, but unfortunately, that means deciding on such an approach first, and then putting in the blood, sweat, and tears.

My hunch is that a proper solution is not so far away. The weblog can remain the avant garde of what’s going on at JeeLabs, including announcing new stuff happening on the documentation side of things. Some form of web-based system may well be suited for all documentation and reference material. And the forum is excellent in its present role of asking around and being pointed to various resources.

Note that “reference material” is not just about text and images. There is so much information out there that pointers to other web pages are at least as important. Especially if the links are combined with a bit of info so you can decide whether to follow a link before being forced to surf around like a madman.

The trick is to decide on the right system for a live and growing knowledge base. The web is perfect for up-to-date info, and if there’s a way to generate decent PDFs from (parts of) it, then you can still take it off-line and read it all from A to Z on the couch. All I want, is a system which is effective – over a period of several years, preferably. I’m willing to invest quite a bit of energy in this. I love writing, after all.

Suggestions would be welcome – especially with examples of how other sites are doing this successfully.


TK – Voltage accuracy

In Hardware on May 10, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

(this is a bit of a side excursion, about checking the quality of a measuring instrument)

“Ah, but is it any good?” – that’s the inevitable question to ask when getting a precise instrument, right?

I’m referring to the 6.5 digit 34401A HP (now Agilent) multimeter I got my hands on, recently. This translates to: better than 1 ppm (part per million), i.e. 10,000 times more accurate than one percent!

This is the sort of thing the members of the volt-nuts mailing list ponder about, I would imagine.

In my case, with now over half a dozen ways to measure voltage here (numerous hand-held multimeters, mostly), I just wanted to know which one to trust most and to what extent.

The solution comes in the form of a transfer voltage standard – an item you can order, gets shipped to you, and which then gives a certain level of confidence that it will provide a fixed voltage reference. As it turns out, Geller Labs offer just such a thing at low cost – it’s called the SVR 2.0:

DSC 3078

Put 15V on its input (left), wait 30 min, and the output pins (right) will produce exactly 10.00000 Volt – magic!

Each board is “burned in” (kept turned on) for 200 hours and calibrated at the temperature you specify (I asked for 21°C). You even get the measured temperature coefficient at that spot (mine is 1.7 ppm/°C), so you can in fact predict the voltage it will generate at a slightly different temperature. Now that’s serious calibration!

My bench-top multimeter will indeed go down to 1 ppm in 6-digit mode, i.e. steps of 10 µV when measuring 10 V:

DSC 3079

And guess what – after a 30-minute warm-up (both the 34401A and the SVR), it’s spot on.

No last-digit jitter, nothing. A constant 10.000,00 readout. The current room temperature is 21.1°C, heh.

Think about it for a second: as hobbyist, you can order a precision second-hand instrument from eBay, Google around a bit to find a little voltage standard, have ’em shipped from different parts of the planet, get them here within two weeks, hook up some wires, wait 30 minutes, and they match to 0.000,1 % precision.

Given that this instrument is from the 90’s, I’m massively impressed. This 34401A HP thing rocks!

Voltage? Current? Resistance? Game over – for me, this is more than enough precision for serious use.


Not long enough

In Hardware on May 9, 2012 at 00:01

My second solar setup did not fare well:

DSC 3086

Started during the day, with the supercap charged up in bright daylight behind a window, it was able to power the JeeNode for about 16 hours – and then in the middle of the night it gave up:

    L 02:36:44.743 usb-A600dVPp OK 17 30 4 0 0
    L 02:37:48.074 usb-A600dVPp OK 17 31 4 0 0
    L 02:38:51.402 usb-A600dVPp OK 17 32 4 0 0
    L 02:39:54.725 usb-A600dVPp OK 17 33 4 0 0

Times are in UTC and we’re in the CEST time zone, so this was two hours later – i.e. around 4:30 AM.

I left it there for another few days, but unfortunately once dead this setup never recovers. The main reason for this is probably that the RFM12B starts up in a very power hungry mode (well, relatively speaking anyway) with a 0.6 mA current consumption – because it starts with the crystal oscillator enabled.

Maybe the self-leakage of the supercap was still too high, and would be (much) lower after a few days in the mostly-charged state, so I’m not ruling out using supercaps just yet. But as it stands, not getting through even a single night is not good enough – let alone being used in darker spots or on very dark winter days.

More experimentation needed!


TD – Soldering iron

In Hardware on May 8, 2012 at 00:01

Welcome to the Tuesday Teardown series, about looking inside the technology around us.

Today, I’m going to take a quick peek inside the soldering iron from Conrad, which was suggested as low-end soldering option for a first toes-in-the-water electronics toolkit:

Opening up the base is trivial, just remove 4 screws after taking off a couple of rubber caps:

DSC 3123

On the right: the AC mains feed, with 2 live/neutral wires and the green/yellow ground.

On the bottom: again 2 wires plus the green/yellow ground (as crucial safety feature).

First thing to remark is that there is no temperature sensor in the soldering iron. In other words, this is an adjustable unit, but it’s not temperature-controlled – the 150..450°C scale around the rotating knob is bogus.

Just removing the knob and a washer around the potmeter is enough to examine the board up close:

DSC 3121

A couple of resistors, caps, an inductor, and a little transformer – that’s all. Oh, and a little TRIAC in a TO-92 housing (just beneath the transformer). Here’s the other side:

DSC 3122

A plain single-sided low-cost PCB. No surprises here – this is a very low-cost unit, after all.

So how does it work? Well, it’s basically a simple dimmer. But instead of dimming an incandescent lightbulb, it dims the heater coil inside the iron. The way this works is that the start of each AC mains cycle gets switched off – and then only after a specific time does the TRIAC start conducting. The whole circuit is essentially an adjustable delayed pulse generator, synchronized to the AC mains zero crossings.

Here’s what it looks like on the scope (as measured via a differential probe for isolation):

SCR33

The entire AC mains cycle is 20 ms (50 Hz), half a cycle is therefore 10 ms, and in this mid-range setting, each half of the sine wave is switched on after about 5 ms, i.e. halfway into the sine, at the peak voltage in this case.

Does it work? Sure, turning the knob will definitely adjust the tip temperature – but not very directly. Instead of a feedback loop, we merely control the amount of power going into the iron, and assuming a fairly steady heat dissipation, the iron will then stabilize more or less around a specific temperature. Just like a lightbulb, such a circuit will “dim” a soldering iron just fine this way.

The only drawback is that it’s not tightly controlled. When using the iron and pushing it against a thick copper wire or a big copper surface, the iron will cool off. Real temperature control requires a feedback loop which senses this change and counteracts the effect by pushing more power in when needed.

For simple uses, the crude approach is fine, but if you plan to solder under lots of different conditions (through-hole, SMD’s, PCB ground planes, thick copper wires) then a more expensive type might be more convenient.


How low can it go?

In AVR, Hardware on May 7, 2012 at 00:01

While experimenting with various alternate power sources for a JeeNode, I was curious as to just how low it could go in terms of voltage and still function as a simple wireless transmit node.

Made the following mods to push things a bit more than usual:

  • adjusted the fuses to set the brownout level to 1.8V iso 2.7V (efuse: 0x06)
  • changed the RFM12B’s low-battery level to 2.2V iso 3.1V (rf12_control: 0xC040)
  • removed the voltage regulator from a JeeNode, and keep just the electrolytic cap
  • changed the radioBlip sketch to run at 8 MHz, i.e. 16 MHz clock % 2

This is the same setup as with the Tiny Lithium discharge setup described a few days ago, BTW.

Here’s the JeeNode-under-test (JUT?) – the cap I used here is again 100 µF:

DSC 3070

One pair of wires is from the power supply, the other from the multimeter.

And then it’s just a matter of hooking it up to a power supply and gradually lowering the supply voltage.

And the result is … 3.0, 2.9, 2.8, 2.7, 2.6, 2.5, 2.4, 2.3, 2.2, 2.1, 2.0, 1.9, 1.85 Volt still works!

Anything lower than that and the sketch stops sending out packets once a minute – but then again, that’s probably just the brownout detector of the ATmega kicking in!

To get it back up, I re-connected the power supply at 2.1 V and the node started its blips again… lower didn’t work, my hunch is that the RFM12B’s clock circuit needs that slightly higher voltage level to start oscillating.

Measuring capacitance

In Hardware on May 6, 2012 at 00:01

Capacitors are all about storing and releasing charge. The main difference with batteries is that this charge is stored directly as electrical energy, whereas a battery converts to / from chemical energy in some form.

In an ideal capacitor, charge and discharge follow an exponential curve. Charging takes place when connected to a fixed supply via a resistor, discharging is a matter of placing a resistor across the capacitor:

Rc circuit 07

(image copied from www.technologyuk.net)

The “time constant” is the level when the discharge reaches 36.8% or the charge reaches 63.2% of the original voltage. It can be calculated using the formula: T (seconds) = R (ohm) x C (farad).

This property makes it easy to measure the value of a capacitor: charge it up to a known voltage, then discharge it through a known resistor and measure the time it takes for the voltage to drop to 36.8% of the original voltage.

This is the approach taken by this capacitance meter kit by Radio Hobby Store:

DSC 3084

There is excellent documentation including very detailed assembly instructions, leading to this:

DSC 3085

And sure enough, it works as expected – measuring a 10 µF cap in this case.

The only two drawbacks I found is that it doesn’t measure caps larger than 50 µF, and that there is no on-off switch. With a tool like this, you tend to want to use it from time to time and put it away after use. Without the switch, you have to disconnect the battery each time – a bit awkward and inconvenient.

This meter is based on a pre-flashed PIC controller. There’s one button to calibrate its zero value, and a convenient “auto-zero” mechanism, which keeps adjusting for exactly 0 pF when no capacitor is connected.

Back from Istanbul

In Musings on May 5, 2012 at 00:01

Due to the wonders of automation, yours truly was able to sneak away for a few days without missing a beat on the weblog and webshop (but away from the forum) – with Liesbeth and me ending up on the other side of Europe:

Image

The “Blue Mosque”, and lots more fascinating / touristy things. A humbling experience for a Westerner like me.

With apologies for not responding immediately to all emails – I’ll catch up on this in the next few days.

Onwards!


Measuring VCC via the bandgap

In AVR, Hardware, Software on May 4, 2012 at 00:01

The ATmega’s (and ATtiny’s for that matter) all have a 10-bit ADC which can be used measure analog voltages. These ADC’s are ratiometric, meaning they measure relative to the analog reference voltage (usually VCC).

On a 5V Arduino, that means you can measure 0..5V as 0..1023, or roughly 5 mV per step.

On a 3.3V JeeNode, the measurements are from 0 to 3.3V, or roughly 3.3 mV per step.

There’s no point connecting VCC to an analog input and trying to measure it that way, because no matter what you do, the ADC readout will be 1023.

So can we figure out what voltage we’re running at? This would be very useful when running off batteries.

Well, there is also a “bandgap reference” in each ATmega/ATtiny, which is essentially a 1.1V voltage reference. If we read out that value relative to our VCC, then a little math will do the trick:

  • suppose we read out an ADC value “x” which represents 1.1V
  • with 5V as VCC, that value would be around 1100 / 5000 * 1023 = 225
  • whereas with 3.3V as VCC, we’d expect a reading of 1100 / 3300 * 1023 = 341
  • more generally, 1100 / VCC * 1023 = x
  • solving for VCC, we get VCC = 1100 / x * 1023

So all we have to do is measure that 1.1V bandgap reference voltage and we can deduce what VCC was!

Unfortunately, the Arduino’s analogRead() doesn’t support this, so I’ve set up this bandgap demo sketch:

Screen Shot 2012 04 22 at 21 44 43

Sample output, when run on a JeeNode SMD in this case:

Screen Shot 2012 04 22 at 21 47 20

There’s a delay in the vccRead() code, which helps stabilize the measurement. Here’s what happens with vccRead(10) – i.e. 10 µs delay instead of the default 250 µs:

Screen Shot 2012 04 22 at 21 51 15

Quite different values as you can see…

And here’s the result on an RBBB with older ATmega168 chip, running at 5V:

Screen Shot 2012 04 22 at 21 53 44

I don’t know whether the 168’s bandgap accuracy is lower, but as you can see these figures are about 10% off (the supply voltage was measured to be 5.12 V on my VC170 multimeter). IOW, the bandgap accuracy is not great – as stated in the datasheet, which specifies 1.0 .. 1.2V @ 25°C when VCC is 2.7V. Note also that the bandgap reference needs 70 µs to start up, so it may not immediately be usable when coming out of a power-down state.

Still, this could be an excellent way to predict low-battery conditions before an ATmega or ATtiny starts to run out of steam.


TK – Equivalent Series Resistance

In Hardware on May 3, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

Equivalent Series Resistance, or ESR, is the resistance of a capacitor. Huh? Let me explain…

A perfect capacitor has a specific capacitance, no resistance, and no inductance. Think of a capacitor as a set of parallel plates, close to each other, but isolated. When you apply a voltage, electrons flow in on one side and electrons flow out on the other side until the voltage (potential difference) across the plates “pushes back” enough to prevent more electrons from flowing. Then the flow stops.

It’s a bit of a twisted analogy, but that’s basically what happens. A capacitor acts like a teeny weeny battery.

But no real capacitor is perfect, of course. One of the properties of a capacitor is that it has an inner resistance, which can be modeled as a resistor in series with a perfect capacitor. Hence the term “ESR”.

Resistance messes up things. For any current that flows, it eats up some of that energy, creating a voltage potential and more importantly: generating waste heat inside the capacitor.

ESR is something you don’t want in hefty power supplies, where big electrolytic capacitors are used to smooth out the ripple voltage coming from rectified AC, as provided by a transformer for example. With large power supplies, these currents going in and out of the capacitor lead to self-heating. This warms up the electrolyte in the caps, which in turn can dramatically reduce their lifetimes. Caps tend to age over time, and will occasionally break down. So to fix old electronic devices: check the big caps first!

Measuring ESR isn’t trivial. You have to charge and discharge the cap, and watch the effects of the inner resistance. And you have to cover a fairly large capacitance range.

This ESR70 instrument from Peak Instruments does just that, and also measures the capacitance value:

DSC 3055

It’s protected against large voltages, in case the capacitor under test happens to still have a charge in it (a cap is a tiny battery, remember?). The clips are gold-plated to lower the contact resistance – and removable, nice touch!

In this example, I used a 47 µF 25V electrolytic capacitor, and it ended up being slightly less than 47 µF and having an ESR of 0.6 Ω as you can see.

It this cap were used in a 1A power supply to filter the ripple from a transformer, then its ESR could generate up to 0.6 W of heat – which would most likely destroy this little capacitor in no time.

Fortunately, big caps have a much lower ESR. It measured 0 (i.e. < 0.01 Ω) with a 6800 µF unit, for example.

As with last week’s unit, this is not an indispensable instrument. But very convenient for what it does.

Tiny Lithium – packet test

In AVR, Hardware on May 2, 2012 at 00:01

This post continues where the Tiny Lithium discharge post left off…

To summarize: a tiny ML614 rechargable Lithium cell of a mere 3.4 mAh is used to power a JeeNode running the radioBlip sketch, which is going to send out one small packet per minute (the period is actually slightly longer).

I charged the battery overnight from a 3.0V power supply and through a 1 kΩ resistor, as described in the datasheet. As expected, the battery voltage without load is now indeed 2.97V

The test is really simple, but it’s going to take a little while: connect, see packets come in, with a counter being increased for each packet, and then just wait for the whole thing to stop sending. Here we go:

DSC 3072

The range will need to be good, since packets have to cross a reinforced concrete floor to reach my receiver.

Here’s the log of packets I got (the first packet seems to have been missed):

L 12:08:51.628 usb-A600dVPp OK 17 2 0 0 0
L 12:09:54.592 usb-A600dVPp OK 17 3 0 0 0
L 12:10:57.556 usb-A600dVPp OK 17 4 0 0 0
...
L 23:58:57.898 usb-A600dVPp OK 17 167 2 0 0
L 00:00:00.777 usb-A600dVPp OK 17 168 2 0 0
...
L 23:59:32.169 usb-A600dVPp OK 17 6 8 0 0
L 00:00:34.988 usb-A600dVPp OK 17 7 8 0 0
...
L 23:58:57.821 usb-A600dVPp OK 17 101 13 0 0
L 00:00:00.609 usb-A600dVPp OK 17 102 13 0 0
...
L 23:59:01.058 usb-A600dVPp OK 17 197 18 0 0
L 00:00:03.818 usb-A600dVPp OK 17 198 18 0 0
...
L 23:58:45.821 usb-A600dVPp OK 17 37 24 0 0
L 00:00:51.318 usb-A600dVPp OK 17 39 24 0 0
...
L 13:18:55.865 usb-A600dVPp OK 17 34 27 0 0
L 13:19:58.670 usb-A600dVPp OK 17 35 27 0 0
L 13:21:01.474 usb-A600dVPp OK 17 36 27 0 0
L 13:33:35.035 usb-A600dVPp OK 17 48 27 0 0
L 13:37:46.210 usb-A600dVPp OK 17 52 27 0 0
L 13:43:00.171 usb-A600dVPp OK 17 57 27 0 0
L 13:56:36.450 usb-A600dVPp OK 17 70 27 0 0
L 13:57:39.232 usb-A600dVPp OK 17 71 27 0 0
L 14:06:01.520 usb-A600dVPp OK 17 79 27 0 0
L 14:20:40.504 usb-A600dVPp OK 17 93 27 0 0
 …silence…

As you can see, this “battery” packs enough energy to send out 27 x 256 + 93 = 7005 packets – of which 398 were not properly received (mostly in the last days). IOW, it was still sending after 5 days!

The node kept going even though several of the last packets were not received – so transmit power probably dropped off quite a bit, but the sketch was still running properly until the very end.

Note: once moved to measure the supply voltage (still about 2.5V), packets started coming in again – perhaps because of improved reception from the new location, or a slight warm-up of the battery.

This little cell just doesn’t want to give up!

Indoor solar energy

In Hardware on May 1, 2012 at 00:01

The amount of solar energy available indoor is very limited… a very small fraction of outside, I’m sure.

Still, this unit has been running in the house here for a few years now, and not near a window either:

DSC 3074

It’s a attractive goal: gadgets which you buy (or build) once and then use essentially forever!

We don’t use the alarm clock mode of this thing, so the beeper never goes off, but it does listen for the DCF77 clock standard transmitter in Germany once a day to stay in sync. It’s also slightly glow-in-the-dark, so this clock remains readable at night.

The fact that this clock works so well tells me that, with proper care, we should be able to run simple nodes inside the house with a solar cell of perhaps a few square centimeters, just like this clock.

And, whether battery- or supercap-powered, that’s precisely what I’d like to get going…

As with the AC-mains connected ultra-low power supply, I suspect that reliable startup will be the hardest part. Such an energy source will have very little spare energy and charge up very slowly, so when the JeeNode comes out of power-up (or brownout) reset, it’ll have to be careful to not cut off the hand that is feeding it, so to speak.