Computing stuff tied to the physical world

Archive for February 2011

Something needs to change

In Musings on Feb 27, 2011 at 00:01

The previous post was about explaining which walls I have been hitting. Many thanks for your comments on that!

The task ahead is to move on! This must not become a blog about my ability to function (or not) in the context of JeeLabs. I’ve been doing a lot of thinking, and talking to people around here.

There’s a pattern. It goes as follows: I start on a big new challenge. Push really hard, get totally in the flow, and get lots of things done. This can last for days, or in the case of JeeLabs: several years. Until, gradually, other mechanisms start taking over, governed by obligations and expectations, essentially.

The reason this has worked so well with JeeLabs, is that the weblog was simply a report of what was happening anyway. A diary. Easy to do, and useful for me as well, to go back and review what I did. The shop just gave it more direction: making stuff happen was already a given, so making stuff which others can use as well was really just “low hanging fruit”. Easy to include, and very helpful to stay focused.

I think that over these past two years, I’ve unconsciously moved deeper and deeper into this pipeline. From doing it all as challenge and exploration, came the desire to describe it all more and more on the weblog. And from there it all evolved into making sure an increasing portion of this would end up as products in the shop.

It’s not quite the Peter Principle, but in a way, I’ve gradually drifted away from what this was all about: exploration, learning, and yes, also sharing. That’s why I started JeeLabs, and that’s what I want to continue doing with JeeLabs as much as ever.

I came across some interesting articles these past few days. Seth Godin talks about business needing to be of the right size. In my case, that means: sustainable. No more. No less. I’m confident that I can figure this one out.

Paul Graham talks about Maker’s vs. Manager’s schedules. Real life has a way of interfering with makers. Tinkering requires concentration, for all but the most trivial and obvious projects. This would explain exactly what happened here – as I kept ahead of the curve with weblog posts and shop items, all was well. I was in the flow and tinkering all day in the fascinating and endless world of physical computing. The emphasis was on the right stuff, and the rest followed effortlessly. Really. The weblog was oodles of fun, even with a daily post, and so was the shop, which is filled with interesting and new experiences about the world of atoms, production, and fulfillment.

I don’t want to list the projects here which I have already started up or new ones I would love to go into. It’s all fun, except that even just thinking about listing them drives home the fact that they are all out of reach for me!

Got to track inventories, order stuff, find second sources, juggle the cash flow, get stuff assembled and tested, deal with back-orders and new orders, handle sales / tech support emails, and more. Welcome to doing business, eh?

I’ll share a secret with you: I liked so much doing the daily weblog when it went well, that I’ve been pondering for the last week about how to resume this weblog on a daily basis. Conclusion, alas: it can’t be done. I need to be on a maker’s schedule again, to use Paul Graham’s terms. And both the weblog and the shop make that impossible.

Something needs to change.

No more daily weblog. Maybe after the summer, if I can get ahead of the curve again. Instead, I’d like to do a couple of regular columns – such as the Easy Electrons series, which I really want to keep going. Maybe a second series, but no promises yet. And posts on an irregular basis, when there is something substantial to report. I’m not going to water down the posts and write about trivialities. Nor am I going to just report about what others do elsewhere. You’ve got the same access to internet as I do. The JeeLabs weblog will remain about original content. For noise and fluff, I’m sure you have plenty of choices elsewhere.

The webshop is currently not in optimal shape. Too many out-of stock cases popping up all the time. I’m solving this by scaling up. Getting components by the thousands where needed, and getting products assembled by the hundreds where possible. I’m also going to do something painful: raise prices. I’m serious about JeeLabs. It is going to stay, and it needs to be run in a serious, sustainable manner. I can pour in my time and energy. But the figures have to add up, in a way which matches the scale at which JeeLabs operates. There are some economies of scale, but obviously not in the way DigiKey or Apple can operate :)

The shortages won’t go away overnight. I ordered 500 relays in January. Expected a first batch end of that month, only to be told a week ago that it was “pushed back” to the end of April. I came across a second source, so hopefully mid March I can provide relays anyway. ATmega shortages are over. Same for several other important items. I’ve got outstanding orders and agreements for hundreds of units for just about all items. I understand the risks and I’m learning the ropes. I just need to get better at it so it won’t take so much of my time in the long run.

Because in the end, JeeLabs is all about exploring and inventing. And, once those are back in the picture, sharing.

Onwards!

What’s going on

In News on Feb 21, 2011 at 00:01

If you’ve been following this weblog, then you may have noticed that things have been quiet around here…

There are a couple of reasons for this. The first one which triggered it all, was an unfortunate – but ordinary – flu, which swept me off my feet for a couple of days, and then sapped all my energy for a few more. I’m sorry about that, and I’m happy that this is all behind me now.

But there’s more to it than that.

In the beginning, I often had a queue of over a week of weblog posts pending and ready to go out on a daily basis. At that time, the weblog was working out exactly as planned: as a way to report on my adventures in the fascinating land of Physical Computing…

However, over 730 posts later, that buffer has been steadily decreasing, and I’ve often been forced to write a weblog post on the day before its publication. Sometimes this was ready only minutes before the deadline. No fun, and in the past month or two, this ended up happening more and more often. The reporting task became a recurring “what shall I write about today?” challenge. Somewhere along the way, the adventure got lost.

And finally, there’s the web shop, which has taken off much faster than I expected and anticipated. In a way, that’s good: a well-running shop means it provides funding for everything else – from keeping that shop going to being able to start new projects and work on fun stuff. Which is the point of JeeLabs after all.

Except… I’ve been swamped. It’s been a while since I’ve actually been able to “start new projects and work on fun stuff”. And some products added to the shop haven’t gotten the attention they need and deserve, such as writing more software examples and documentation to make things interesting, useful, and practical for everyone. Not to mention some stock problems (there are still a few right now).

One solution would be to “scale up”, i.e. to invest in larger amounts of stock and bring in more people to help with production, packaging, and sales. That’s probably what most people would do when presented with such an incredible “business opportunity”, right?

Ah, but there’s the rub… you see, my goal is not to create a large business and become the boss of something “big”.

Let me tell you a story I heard many years ago…

There’s this guy somewhere on a island, sitting under a tree. He takes a little branch, and patiently carves it into a magnificent little flute. He loves making his flutes, and does it all day long, day in day out. His family and friends enjoy what he’s doing, and everyone’s happy. Then, one day, a visitor comes along and sees him sitting there under his tree, amidst his branches and flutes. He walks over and says: “Wow, that’s amazing what you do. You ought to make lots of flutes, I think you could sell tons of them!”

The guy shrugs, and continues with his flute.

The visitor goes on: “Imagine how much money you could make, and how rich and famous you could become. Man, you could teach others to make these flutes, set up a factory, hire a workforce, and rake in the money! You’d be free to do anything you like. Wouldn’t that be incredible? Now tell me, if you were rich, what would you really like to do most of all?”

The guy looks up and says: “Me? Oh, nothing, just sit under a tree and make flutes.”

I’m not saying I’m exactly like that guy. But close. I want to spend my days exploring new things. And for a while, it’s been happening less and less.

Don’t get me wrong. I do want to share. I do want to encourage others to explore and learn more about all sorts of new and fun technologies. And I do want to continue with Open Source Hardware and Software. The mix of software, hardware, and electronics is absolutely fascinating and oh so worth sharing, and I love to be able to encourage people in those directions. But I don’t want to let the weblog or the shop run my life. My life is not about business, revenues, power, or even success. Heck, it probably wouldn’t be, even if I tried ;)

Dsc 1970

Just for the record: JeeLabs is not going away. On the contrary, I intend to find a way which makes sure that it will last and stay around for many years to come. I want to keep the weblog, as a source of unique posts with 100% original content. I want to keep the web shop going with kits and products which help anyone interested in Physical Computing to try things out, experiment, explore, and learn about it all.

But I need to take care of the inner fire and energy source which drives me. And that requires time to concentrate and the liberty to run off in lots of directions. I’m back into a bit of that right now, and it’s doing wonders for me.

There will be only a few more posts on the weblog this month. I’ll respond to emails and forum posts as before, and I’m committed to keep the shop running in a responsible way, with proper support and doing my best to maintain sufficient stock levels to keep everything listed available for people who want it. In fact, I expect this activity to increase, as more and more larger projects are starting up and several workshops are currently under way. But my focus will be on streamlining things, so I can recover that precious time I need for the longer term health of everything at JeeLabs, including myself.

Take care, and please don’t let the radio silence on this weblog affect your plans and activities. There are lots of old posts to go through which might interest you, just use the search box or go through any of the archived months at the bottom of this page.

When I figure out how to best take this all forward, you’ll be the first to know.

PS. Thanks for all kind emails and encouragements. It makes a very real difference.

Easy Electrons – Pull Ups and Downs

In Hardware on Feb 13, 2011 at 00:01

Time for another installment of the Easy Electrons series. This one is about the why’s and how’s of pull-up and pull-down resistors.

There are many ways to generate digital output signals. They almost always work with “high” and “low” voltages – for suitable definitions of high and low. As it turns out, there are lots of tricks you can play with this.

The high-end solution is to use a “push-pull” driver with two transistors. Similar to the H-bridge circuit described in an earlier post. By switching either one of the transistors on, you get an output which can carry current in either high or low states (“sourced” to ground, or “drained” from the supply rail, respectively):

Screen Shot 2011 02 12 at 11.32.02

The CTRL A & B pins are set up in such a way that one transistor conducts, and the other blocks. When a PNP/NPN pair is used, tying them both together turns out to work exactly as needed. This is what an Atmega pin does in OUTPUT mode, essentially.

But you don’t really need such a setup in many cases. That upper transistor can also be replaced by a resistor:

Screen Shot 2011 02 12 at 22.40.17

Resistors are cheaper, but more importantly, resistors offer more flexibility. The effect is that when the only remaining lower transistor is conducting, then it draws the signal to ground, and when it is not, then the resistor pulls the now-floating signal to a high level. This works as long as you don’t draw too much current. A common value for such a “pull-up” resistor will be between 1 kΩ and 100 kΩ. In that last case, you can’t put a load of more than a few microamps on the circuit, but again: for signaling purposes that is often just fine.

Why is this useful?

Well, for one, the voltage levels can be different. It’s possible to control a 0..12V digital signal using just one transistor and a pull-up to… 12V. This is also perfect for 3.3V -> 5V conversion, for example, and it even works when the output voltage is lower than the signal input (which goes through a current-limiting resistor anyway).

Another nice property is that you can tie several such outputs together. The output signal will drop to 0 whenever any output is low, and stay at 1 when all the outputs are high. i.e. it acts as an implicit AND-gate. This makes such a circuit suitable for “bussing”, i.e. putting multiple devices on a single signal line. You still need to collaborate between the devices to make sure only one of them talks at any given time, but electrically they can all be tied together with no extra circuitry. An output which is high is in effect not participating in the state of the bus signal.

Third, the single-transistor can still drive larger currents, but only in the “0” state. So you can still use this to turn on a LED (+ resistor), as long as you tie the LED/resistor combo between output pin and the supply voltage, not between output pin and ground.

And fourth, perhaps not as important as the rest: shorting such an output to ground when it only has an active-low transistor cannot harm the circuit (unlike shorting it to the positive supply rail). All that happens is that the pull-up will be supplying a little bit of current as it ends up getting the full supply voltage.

Note that putting a positive voltage on the transistor base willl cause it to conduct, and than tying something between the output pin and the supply voltage will cause it to get power when the transistor is conducting current from the output pin to ground. So loosely speaking, a “high” input voltage leads to an energized output state, even though the effect is to pull the collector low.

A slight variation is to use one transistor and leave the resitor off altogether. This is called an “open-collector” (OC) output, for obvious reasons. Sometimes, that extra resistor is not needed, i.e. when all you care about is energizing a lamp / motor / LED, or not. Sometimes a pull-up is still required, but then a single one will be sufficient, even with multiple OC outputs tied together. This is a way to reduce the total component count a bit further.

The I2C bus is an example which uses the open-collector output plus pull-up resistor approach, to implement a bus with multiple devices, exchanging information between them in any direction.

On an ATmega, you can enable a pull-up resistor on any pin by setting the pin up as an input pin, while writing a “1” as if it were still an output pin. The result will activate a weak pull-up resistor of 20..50 kΩ. One side-effect is that the input pin will read as a clear “1” when nothing else is connected. A pull-up resistor is a bit like slanting the table, i.e. the signal tends to stay in the high state unless a certain amount of current pulls it low.

What about pull-downs?

Technically, all this pull-up trickery can also be done with pull-down resistors and transistors tied between supply and output pin, but it is less comoon to do so. Due to the way transistors work, such a “high-side” switch is easiest to implement with a PNP transistor – and these used to be less common and more expensive. Furthermore, a “high” input signal would now cause no output current to flow. So the sense of operations is inverted. Are these essential reasons to avoid such an approach? No. But the NPN low-side switch approach has become prevalent. It has become second nature to use NPN transistors, and to tie small loads directly between the output pin and the positive supply voltage.

The ATmega has no built-in pull-down mechanism.

OOK fix

In Hardware on Feb 10, 2011 at 00:01

Here’s a great suggestion from Stefan Schulze (“kami” on the forum) for getting that wrong 433 MHz transmitter working with the OOK 433 Plug:

Img 5951

Sideways:

Img 5950

It requires some pin-bending, and you can attach an optional antenna, as he did.

I’m currently discussing option with the supplier to find a more “official” solution, but if you want to use the OOK plug right now, the above is definitely an option.

Thanks, Stefan!

Update – For everyone who received the OOK 433 Plug in its current form: I will send a solution out to everyone once it has been worked out. If you don’t need the TX side immediately, it might be an option to postpone soldering it until that solution is available.

Update #2 – Problem has been resolved, the OOK Plug is now supplied with the correct 3-pin transmitter.

Time-out

In Musings on Feb 9, 2011 at 00:01

Sorry, no post today. A cold and flu got the best of me.

OOK Murphy

In Hardware on Feb 8, 2011 at 00:01

Looks like there is a problem with the OOK 433 Plug

Here’s the transmitter I started out with:

Dsc 2455 2

Here’s the print layout I designed, based on that:

Screen Shot 2011 02 07 at 20.36.25

Everything worked fine. So I ordered larger quantities, to be ready for production. Here’s what I got in that new batch order:

Dsc 2455 3

Whoops… different unit!

Worse still, the original board had +, Gnd, Data as pins (as seen on the board layout), whereas the new boards have Data, Gnd, +, Antenna. It would be possible to cut the antenna pin off, but that’s not enough since the pinout is in fact reversed!

I’ve contacted the supplier. Let’s see how this goes. For the time being, I’m forced to take the OOK 433 Plug “off the shelf”. Sorry about that – please hang in there, also if you’ve already ordered this plug. Note that this only affects the 433 MHz transmitter – the 433 MHz receiver should work just fine.

Easy Electrons – MOSFETs, part 2

In Hardware on Feb 7, 2011 at 00:01

Yesterday was about MOSFETs and the heat they generate. Pretty impressive, those components which can control a 15A current with just a little bit of voltage.

Unfortunately, it’s not quite as simple as that. We have to check what happens with a lowly 3.3V applied to the gate. This can be found in the IRLZ34N datasheet:

Screen Shot 2011 02 06 at 20.43.00

This is an important graph for MOSFETs. Each line corresponds to a different voltage applied to the gate – this graph is in fact eight graphs in one.

You can see that they really do have some limits at lower voltages. At 3.3V, the IRLZ34N will not go much higher than 7A – quite a bit lower than the 30A maximum specs on the front page of the datasheet. Most MOSFETs are still at the end of their range when driven by a 3.3V microcontroller.

What this graph also shows, is the drain-to-source voltage at different current levels. This makes it very easy to estimate power consumption: at 3V and roughly 5.5A, that voltage will be 1V. In other words: 5.5W – quite manageable if the MOSFET is mounted on a suitable heat sink. But again: quite a bit lower current handling capacity than the 15A from yesterday. Note that we could drive it at a higher voltage by adding an extra stage in front, using either a BJT transistor or a MOSFET to get better current handling capacity.

As you can see, there is a very distinct switch-over point at each gate voltage level, where the MOSFET stops conducting more current. Under the switch-over point MOSFETs act essentially like a pure (low-value) resitor, but above that point they start acting more like a current limiter. This has major implications for power consumption, since the drain-to-source voltage will rise.

With this particular IRLZ34N, driving it at 3.3V, it is best not to push it beyond about 5..6A, and to use a heat sink when power consumption rises above say 1W (i.e. at 62°C/W, that makes the bare MOSFET rise 62° above ambient). Looking at the 3V line in the graph, I’d estimate that this MOSFET would work just fine without heat sink up to at least 2A, perhaps even 3A.

But what if we want to regulate the current? I.e. what if we want to use the MOSFET in an analog manner, and not just as on-off switch?

We could lower the gate voltage somehow, to force the current down. It won’t be a linear relationship, and I’m not even sure a MOSFET will conduct any current at all when the gate voltage is lower than 1 or 2V.

But in general, it’s a bad idea. The reason is (again!) power consumption. Say we use the following circuit:

Screen Shot 2011 02 06 at 22.17.58

(the resistor is a pull-down, explained in a future post)

That’s a 12W incandescent light bulb, powered by 12V, and controlled by a MOSFET, in other words: it draws 1A when full on. Let’s say we want to dim the light by halving the current through it. The lamp acts like a resistor (it just get pushed so hot that it starts glowing, that’s all). So half the current is what you get when you apply half the voltage to it. In this case 6V.

Suppose we figured out exactly what gate voltage to apply to get a drain-to-source voltage over the MOSFET of 6V. That would essentially accomplish our goal: the lamp would be dimmed. Another way to look at this, is that we’re tweaking the gate voltage until the MOSFET acts like a 12 Ω resistor between drain and source. Then the lamp and the MOSFET both get half the voltage.

What about power? Well, the MOSFET will have to have 6V across it, as we just saw. At 0.5A, this means that it will have to burn 6 (V) x 0.5 (A) = 3 Watts of power.

This is totally counter-intuitive: when we switch a lamp full on, the MOSFET will consume less than 0.1 W (as gleaned from the graph), but to dim it, that same MOSFET would need a heat sink!

There is some logic in this, though, if you think about it. The 12V supply voltage is a given. So if we want to apply less voltage to the lamp, we have no other choice but to waste the excess energy. Which is exactly what the MOSFET (or BJT transistor for that matter) will do. So although we’re reducing the total power consumption in this circuit by halving the current, we’re forced to do so by wasting power – as non-visible light, i.e. heat.

Can we do better? Yes, fortunately, we can.

This is where “pulse-width modulation” (PWM) comes in. Instead of eating up the excess power, we can take advantage of the fact that incandescent lights are fairly sluggish in their response. What we do is pulse the power on and of in very rapid succession. So the lamp will constantly heat up and cool down, and the result is that it won’t be burning at full brightness.

Why is PWM so incredibly useful? Several reasons:

  • we don’t need a way to generate a regulated analog gate voltage, we can simply generate digital on-off pulses with no extra circuitry needed
  • the MOSFET is again being used as pure on-off switch, and remains maximally efficient – so we probably won’t need a heat sink
  • power is no longer wasted, it is now effectively throttled instead – in very short and rapid bursts

It turns out that PWM works in a lot more cases than just incandescent light bulbs. DC motors are also sluggish, so controlling their speed with PWM also works extremely well. And better still, even LEDs work well with PWM, even though they respond instantly – because it turns out that our own vision is sluggish too!

See also an earlier post about PWM on this daily weblog.

So there you go. MOSFETs are the workhorses of power control, due to their incredible properties, and PWM is the technique of choice when it comes to throttling power devices (lights, heaters, motors, and more).

Easy Electrons – MOSFETs (and heat)

In Hardware on Feb 6, 2011 at 00:01

To continue this Easy Electrons series, this time I will go a little bit into MOSFETs.

To me, MOSFETs rank high up there, next to operational amplifiers as one of the foundation components in electronic circuits which are extremely useful and practical. The most amazing detail is that MOSFETs only exist since a few decades – newbies when you consider the time scale of most electrical components.

In a way, a MOSFET is like a BJT transistor. Even the symbol for it looks similar (from Wikipedia):

80px Igfet n ch enh Labelled.svg

This “N-channel enhanced MOSFET” type is the most common one, and like the NPN transistor, current flows into the top (D = drain) and comes out the bottom (S = source), all controlled by a third pin (G = gate).

One key difference between a BJT transistor and a MOSFET, is that a BJT is driven by current, whereas a MOSFET is driven by voltage. You feed a (small) current into a transistor to make it conduct, whereas you apply a (small) voltage potential to make a MOSFET conduct. The gate of the MOSFET doesn’t conduct current – it just senses the voltage. Bit like a capacitor.

You could say that a transistor is like a water wheel: you have to keep churning the crank to keep the water flowing through it. Whereas a MOSFET is more like a flexible tube: you pinch (well, “un-pinch”) to control the flow, but that pinch doesn’t consume energy. You could use a small mechanical clamp to maintain the pressure and keep the flow going.

This also explains why a transistor won’t conduct if the base is left unconnected (no current coming in), whereas a MOSFET could be doing anything when its gate is left unconnected, depending on how much charge was left when last connected. Early MOSFETs were in fact incredibly sensitive to static electricity – just touching the gate with a finger would often destroy a MOSFET. Nowadays, they are ESD protected.

MOSFETs are perfect for controlling large currents via a microcontroller. Even the weakest output pins can drive them, as long as the voltage is high enough. In the past, MOSFET’s needed at leat 4.5 to 5V to make them conduct, but nowadays voltages in the 2.5..3V range are sufficient in these so-called “logic-level” MOSFETs.

I’ll take the MOSFET Plug as example. It has two MOSFETs tied directly to two ATmega output pins:

Screen Shot 2011 02 05 at 13.35.58

Let’s look at a manufacturer’s datasheet for that “IRLZ34N” MOSFET, because there’s a lot of useful information in there.

The IRLZ34N datasheet is a great example. Seven pages, full of details, facts, graphs, circuits, pinouts, drawings, etc. It’s worth getting used to reading datasheets. They are loaded with info. To me, datasheets are the user interface of electronics. Give me a part number, and I’ll grab the datasheet to understand what it can do.

Here’s the first part:

Screen Shot 2011 02 05 at 13.42.00

  • logic level – aha! it can probably work with 3.3V
  • VDSS – that must be the max switching voltage, 55V .. plenty!
  • RDS(on) – will come to that in a minute
  • ID – max current through the drain, a whopping 30 amps
  • 175°C – looks like it can witstand scorching hot temperatures

Ok, there’s your helicopter view of this component. What I’m interested in is: will it be able to switch my <insert-some-high-power-device-here> ?

Well, we’ve seen the max voltage and current specs. But what really matters is power consumption. Because that’s the heat that gets generated, and that’s usually what breaks things.

Power is voltage x current (E x I). The voltage in this case is the voltage across the MOSFET. But we don’t know that – not directly. What we do know is its “RDS(on)” – this is the resistance between drain and source when turned on. Heh, how obvious. And exactly the value we want. It’s a mere 0.035 Ω.

Ohm’s law says V = I x R, so the voltage across the device is the current through it times its resitance.

Combine these two and we get P = E x I = (I x R) x I = I x I x R. Power consumption is proportional to the square of the current. Aha – that explains why large currents can be so destructive!

Let’s try this. Let’s go all out and push 30 amps of current through the MOSFET. Its power consumption will be 30 x 30 x 0.035 = 31.5 Watt. That’s a fair bit of heat (small lightbulb).

But will it work?

To find out, we need to do a thermal calculation. What’s going to happen to those 31.5 Watt of power? Well, they will come out as heat, but how much heat?

Time to look at another bit of info on the datasheet:

Screen Shot 2011 02 05 at 13.57.09

Let’s take the last value first: R(theta)JA, or Junction-to-Ambient thermal resistance = 62°C/W. In other words, each watt of power at the junction (i.e. inside the MOSFET package) will leed to a whopping 62°C temperature rise when the component is suspended in “ambient”, i.e. free, air.

Hmmm: 31.5 x 62 = nearly 2000°C. Yikes, our MOSFET is going to evaporate!

What we need to do is mount this part on a massive heat sink to make sure those temperatures are never reached, by drawing the heat away and keeping the MOSFET (relatively) cool.

Fortunately, there are two other values. The way these work, is that they tell you how much “heat resistance” there is when it flows away from the junction where all the heat is being generated. And it’s really easy to work with:

  1. draw a picture of the MOSFET and how it’s mounted
  2. find out the heat resistance in each step
  3. add them up to get a combined °C/W value
  4. re-calculate 31.5 x <that-value>
  5. make sure it stays under the max temp you want stay under (175°C would be too hot for a plastic case, for example – or even for a printed circuit board)

I’ll use a quick example, just to see how far we can push our MOSFET. Let’s assume the MOSFET is mounted on a (very good) heat sink which has only 5°C/W. Then we add up: 2.2 (junction to case) + 0.5 (case to heat sink) + 5 (heat sink to air) = 8.7°C/w.

With 30A current, we get 30 x 8.7 = 261°C. Whoops, can’t be sustained without damage.

Ok, let’s aim a bit lower: 15 amps. Now the power consumption becomes: 15 x 15 x 0.035 = 7.9 Watt. Without heat sink: 7.9 x 62 = 490°C – still way too hot, but with heat sink we get 7.9 x 8.7 = 69°C.

This value is a relative value. It means 69°C above the ambient temparature. So in a 25°C room, the whole thing would become 94°C. Still very hot, but not a problem for the MOSFET!

In other words: take a MOSFET, mount it on a big heat sink, and you can see how a tiny little microcontroller could control a 15A light or a motor which has a 15A peak current. That’s what makes MOSFETS so magical…

Careful with heat sinks, though. To get it right, you really have to include all the paths to “ambient”. If you mount the heat sink in a big box (which can withstand 94°C), then the temperature inside will rise. And those 69°C we calculated will make the whole setup rise accordingly! – it doesn’t take much to get a “thermal runaway”: core heats up, ambient heats up, core heats up further, etc. Until disaster strikes. Not quite Tchernobyl, but hey… be careful.

Soooo… what started out as a MOSFET introduction, has turned into a power and heat calculation. As you can see, it’s not very complex. It’s not a bad idea to find out up front whether a power circuit will self-destruct or not. Now just add a 2x safety margin, and you should be OK. Or better still: build the circuit, and confirm that the results match these predictions, especially under stress and near design limits.

Ehm… I’ve swept a little detail under the rug:

Screen Shot 2011 02 05 at 14.22.04

These calculations assume that we’re driving the gate to 10V, but we’ll only be applying a feeble 3.3V or so. Whoopsy daisy. Let’s go into that tomorrow.

No time, yet

In Hardware, Software on Feb 5, 2011 at 00:01

Heh, I bet this isn’t about what you thought the title suggested :)

I’ve been spending a couple of hours today, trying to get a DCF77 time code receiver working on the new ookRelay2.pde sketch. There’s a dcf77demo.pde sketch in the Ports library, which actually does all the hard work of decoding that pulse train.

It’s fairly tricky code, and I tend to throw in lots of tricky hacks (silly me, I know):

Screen Shot 2011 02 04 at 23.31.52

To use this, dcf77poll() has to be called often in loop(), like so:

Screen Shot 2011 02 04 at 23.14.35

(lots of #ifdef’s in there now, to make the sketch more configurable)

The weird thing is that this all worked fine in the previous incarnation of the OOK relay.

This timing code is far less critical than the 433/868 MHz OOK decoding, by the way. Pulses come in once a second, and all it needs to do is disambiguate short and long pulses. Easy stuff for an ATmega.

Except today… well, I don’t know why, but I can’t make any sense out of what’s happening. Been debugging with a few prints to the serial port via LEDs, but no luck. I’ve switched prototype setups, redone it all from scratch, changed DCF77 receivers… nada. Worst of all, there’s no pattern.

It’s probably the wrong moon phase, or somethin’ – I’ll revisit this some other time (soon).

Out of the woods?

In Hardware on Feb 4, 2011 at 00:01

Great, got a new batch of of ATmega328p’s in today:

Dsc 2450

(that’s a mix of ATmega’s and DIP sockets, btw)

With five hundred more in transit this very moment. No more worries!

So that’s a the end of a couple of months of supplier-anxiety :)

Then again, JeeLink and JeeNode USB stocks are low again. I don’t have good estimates on when those will be back in good supply. Am chasing a couple of options right now… for the time being, I can only point to JeeNodes plus assembly service as workaround, I’m afraid.

You can never win 100% at this atoms game, it seems!

OOK relay, revisited

In Software on Feb 3, 2011 at 00:01

With the modded RFM12B receiving 868 MHz signals, and the new OOK 433 Plug doing the same for the 433 MHz band, the new OOK relay is coming in sight.

Just a lousy bit of code. Elementary – I thought…

Except it wasn’t. Software always seems to take a lot more time (and concentration) than hardware. Silly!

Still, I think I managed to collect all the pieces lying around here from earlier experiments in that area, and combine them into a new ookRelay2.pde sketch.

It’s fairly elaborate and too long to show here, but I’ll pick out some pieces:

  • all the decoders live in the decoders.h file
  • since they all share common logic, each is derived from a common “DecodeOOK” class
  • the protocol for each decoder is the same: feed puse widths to nextPulse(), and it will return true whenever a valid packet has been decoded, then call getData() to get a pointer and byte count
  • the ookRelay2 sketch includes a variety of decoders, I hope we can improve/extend/add-more over time
  • there are two pulse sources: the 868 MHz receiver and the 433 MHz receiver
  • for each, a “DecoderInfo” table is defined with decoders to use for them
  • the runPulseDecoders() function does what the name says: evaluate each of the decoders in turn
  • when a decoder succeeds, data is added to an outgoing buffer (and optionally, printed to serial)
  • in this example, I send the accumulated data off to the RF12 wireless network, but Ethernet or any other transport mechanism could be used as well

With this out of the way, you can probably, eh… decode the following lines at the top op the ookrelay2 sketch:

Screen Shot 2011 02 02 at 23.30.36

And here’s the main loop, which is keeping things going:

Screen Shot 2011 02 02 at 23.31.24

The hard part is doing this efficiently with accurate timings, even though a lot of stuff is happening. That’s why there are two interrupt routines, which trigger on changes in 868 MHz and 433 MHz signals, respectively:

Screen Shot 2011 02 02 at 23.33.22

I’m still debugging, and I need to analyze just how much leeway there is to run all the decoders in parallel. Earlier today I had the 433 MHz reception going, but right now it seems this code is only picking up 868 MHz signals:

Screen Shot 2011 02 02 at 23.34.46

Oh well, it’s a start. Feel free to check out the code, which lives as example in the RF12 library.

Update – Bug fixed, now 433 MHz decoding works.

Meet the RFM12B Board

In Hardware on Feb 2, 2011 at 00:01

With the RFM12B becoming a nice low-cost option for low-volume wireless communication, and the RF12 library proving to be a solid software driver for it, it’s time to generalize a bit further…

Say hello to the new RFM12B Board:

Dsc 2448

This board adds a voltage regulator and 3.3V/5V level conversions, to be able to use the RFM12B on 5V systems such as the various Arduino’s out there, the RBBB, … anything you want, really.

There are 8 pins on this board, of which the 8th is a regulated 3.3V supply which can be used in other parts of the circuit – the voltage regulator will be able to supply at least 100 mA extra on that supply pin.

The other 7 pins are:

  • +5V
  • Ground
  • SPI clock (SCK) – Arduino digital 13
  • SPI data out (SDO) – Arduino digital 12
  • SPI data in (SDI) – Arduino digital 11
  • SPI select (SEL) – Arduino digital 10
  • IRQ – Arduino digital 2

Just hook each of those up to an Arduino, and you can use the RF12 library as is!

Sample output:

Screen Shot 2011 02 01 at 22.08.14

Look ma, just like a JeeNode or JeeLink!

With an 8-pin stacking header and a bit of bending, cutting, and soldering two wires (I used a jumper wire, cut in half), you can even stick this thing right onto an Arduino:

Dsc 2449

But of course using a normal solderless breadboard and some wire jumpers will work just as well.

Note that this board can also be tied to 3.3V systems – just use the bare PCB (and short out three solder jumpers), which then becomes a breakout board for the RFM12B. No need to mess with the 2.0 mm pin/pad distance on the RFM12B module itself.

Docs can be found in the Café, and the kit/pcb is now available in the shop, as usual.

SMD lab supplies

In Hardware on Feb 1, 2011 at 00:01

With SMD becoming more and more common, I really wanted to get a supply of different resistor values – a bit like this binder with through-hole components:

Dsc 2443

So I decided to get 100 of each of the E12 series, thus named because it has 12 values per order of magnitude – spread out in a logarithmic scale: 10, 12, 15, 18, 22, 27, 33, 39, 47, 56, 68, 82.

Here are all the values from 1 Ω to 10 MΩ:

Dsc 2439

Nothing fancy, but pretty low cost. And as a bonus: 0 Ω resistors! Don’t laugh, these can actually be quite handy as bridges over other traces. You could even use a single-sided PCB by adding a couple of these as “wire jumpers”!

Here’s the final result, as stored in the lab. I keep a set of 100 Ω, 1 kΩ, 10 kΩ, and 100 kΩ around for quick-and dirty uses, but this way all the usual values are available when I need ’em:

Dsc 2442

Each drawer has 3 compartments, with two values of the E12 series in each. So that’s two drawers per order-of-magnitude (“decade”), times 7, plus the extra 0 Ω and 10 MΩ. All that’s left, is to add a couple of labels on the drawers to quickly pick the right one.

Ready to do lots more experiments here at JeeLabs! :)