Computing stuff tied to the physical world

Archive for November 2010


Meet the DC Motor Plug

In Hardware on Nov 30, 2010 at 00:01

Here’s a new I2C plug to drive two small DC motors. The DC Motor Plug has 2 H-bridges on board, which can drive each motor in forward or reverse. An additional 4 I/O pins are available, for limit switches, quadrature encoders, whatever:

Dsc 2310

Here is a test setup with a couple of (different) geared motors, driven from a 4x AA battery pack, plus the usual AA Power Board for the JeeNode itself (these could also have been combined):

Dsc 2309

All I/O is done via I2C, using the MCP23008 expander chip (same as used on the EP, LP, and OP plugs).

Here is a sample sketch called dcmotor_demo.pde which briefly drives each of the motors in both directions:

Screen Shot 2010 11 29 at 13.02.38

One notable detail about this plug is that it uses TC4424 chips which are in fact not DC motor drivers at all but MOSFET drivers… it turns out that these are also well suited for small DC motors, and should be able to handle up to 1.5A @ 4.5..18V.

A small bipolar stepper will probably also work, but I haven’t tried that yet. This board has a jumper to select between I2C addresses 0x26 and 0x27, so two of these can be daisy-chained on a single port.

Speed control should be possible using software PWM, but not at very high rates, since the I2C bus will be the limiting factor.

One use for this in the context of home automation would be to drive small highly-geared 12V motors to adjust the position and raising/lowering blinds.

Action!

Docs added to the café and kit in the shop, as usual.

,

Ethernet web client

In Hardware, Software on Nov 29, 2010 at 00:01

The Ether Card and the associated EtherCard library offer an easy way to connect a JeeNode to a LAN and internet. I consider this option useful enough to even want it within reach on a breadboard, so I designed the Bridge Board to support it as well. Here’s the setup, based on a JeeNode Experimenter’s Pack:

Dsc 2365

This is all it takes for an Ethernet-connected setup, and all JeeNode ports are still freely available for project use.

However, the EtherCard library only includes some examples for the web server approach, such as the EtherNode. What about using this setup to send requests out, and POSTing results to a remote web server?

Well, encouraged by a few great DNS-related patches to the code by Gérard Chevalier, who was also so kind to show me how he does DNS lookups and web requests, I’ve come up with two new example sketches:

  • The getStaticIP.pde sketch does just a HTTP get to a fixed IP address.
  • The getViaDNS.pde sketch looks up my server’s IP address by name, via a DNS lookup on startup.

Here is the code of getViaDNS:

Screen Shot 2010 11 27 at 15.38.35

Note that to make any kind of outgoing request outside your LAN, the IP address of the local LAN gateway has to be specified at setup time.

The dependency on the Ports library is due to the use of the MilliTimer class in this code. And because of that, the RF12 library also needs to be mentioned (it won’t increase the code size). Welcome to dependency hell…

Here is some sample output:

Screen Shot 2010 11 27 at 15.29.28

Even though this example is relatively short, I still find it quite awkward. The EtherCard library code really needs a major overhaul – far too much of the underlying mess is still being exposed for no good reason, IMO.

Furthermore, a massive code cleanup will be needed to overcome the current limitations of the EtherCard library: the need for a large RAM buffer, and the limitation that TCP requests and replies may only use a single ethernet frame (approx 1500 bytes).

But getting it working first was more important, and with these new examples you can now see how to implement outgoing TCP/IP requests (not just web/http, btw). Pachube, anyone?

,

Meet the new Room Board v2

In Hardware on Nov 28, 2010 at 00:01

For some time now, the Room Board kit has been outfitted with a new PIR sensor:

It’s nicely low-power, but unfortunately it has a pin-out which differs from the ELV model, even with 3 pins!

So I’ve decided to make a new Room Board v2, which drops support for the 8-pin ePir to allow the new PIR sensor to be mounted in two different ways.

Here’s the board, with a solder drop already applied for the SHT11 (much easier to solder it in that way):

Dsc 2345

Things have been moved around a bit, but the basic setup hasn’t changed. The 3 pins in the top left are still for the ELV PIR, and the 1-wire DS18B20 option is still there (with fixed pinout, yeay!).

Here is the board with SHT11 and LDR soldered on:

Dsc 2348

And here are the two ways to attach the new PIR sensor:

Dsc 2350 Dsc 2349

That second setup is the most compact, but also the most inconvenient one if you ever need to make changes or reach the headers. Note that the PIR pins were soldered in as far out as possible, and that the LDR was bent sideways a bit:

Dsc 2354

I would advise to use the first setup where possible.

Having said that, here’s a complete Room Node with the (relatively) “compact” layout:

Dsc 2355

Bit of a hodge-podge, but that’s what you get when everything is kept modular.


GLCD on battery power

In Hardware on Nov 27, 2010 at 00:01

I’m going to switch to a different type of graphic LCD once the next batch of Graphic Boards arrives. Instead of a white-on-black type, the new GLCD will be a blue-on-sort-of-blueish color:

Dsc 2356

The reason for this is that it is still quite readable without the backlight:

Dsc 2358

There is a solder jumper on the Graphics Board, to choose between powering the backlight continuously via PWR, or having it powered under software control, via the not-often-used IRQ pin. This not only lets you turn the backlight on and off, but even dim it under software control, because the IRQ pin supports PWM, i.e. analogWrite().

The above display draws about 280 µA without backlight right now, which means it will keep running for over a month on a single AA cell, using the AA Power Board. There are probably ways to reduce that current consumption further, as I’m not doing anything yet with the ST7565’s standby and other low-power modes.

And although it may not be practical for a permament display, this definitely is useful for something I’d like to have around and use on a regular basis. By sending it stuff to display over wireless, this setup can support what is quickly becoming my favorite mode of operation here at Jee Labs: no wires cluttering my desk!!!

,

Spectrum Analyzer

In AVR, Software on Nov 26, 2010 at 00:01

Intrigued by this post, I wanted to try the same thing with the Graphics Board.

So here goes:

Dsc 2330

A real-time Spectrum Analyzer, with due credit to “deif” on the Arduino forum for making Tom Roberts’ simple 8-bit FFT implementation available (three more people are credited in the source code). On the above display you can see a typical “power spectrum”, with one dominant frequency plus harmonics at fixed intervals.

The sketch can be found here:

Screen Shot 2010 11 23 at 00.14.25

This is almost the same code as the 100 KHz DSO sketch, just extended with FFT.

The LCD is refreshed at maximum speed. As you can see, the lag of the LCD itself is actually quite useful in this context. This did bring a bug to the surface: I’ve noticed that the speed-up I implemented for the ST7565 was slightly too fast for this chip. After running for a while, the display would just turn black and stop refreshing.

So I changed these two lines in ST7565::spiwrite() :

Screen Shot 2010 11 22 at 23.48.10

… to this, slightly slower but equivalent code:

Screen Shot 2010 11 22 at 23.48.43

I’ve also updated my version of the ST7565 ZIP file accordingly.

One more note about this code is that it uses most of the available RAM now: the 1 Kb buffer in the ST7565 library, plus two 256-char arrays to store 256 datapoints for running the FFT on.

With code such as this, it would actually be possible to get rid of the ST7565 buffer, since we’re re-constructing the entire display each time.

But for now, I’ll just leave it at this…

,

2-channel Logic Analyzer

In AVR, Hardware, Software on Nov 25, 2010 at 00:01

Let’s continue the tiny lab-instrument series ;)

Here’s a logic analyzer which takes 512 samples of 2 bits (DIO2 and AIO2):

Dsc 2318

The “trace” starts when either of the inputs changes. I’ve enabled the internal pull-ups, so in this example you can see that DIO2 has no signal. The AIO2 signal is from a JeeNode running the Arduino IDE’s built-in “ASCIItable” demo, which sends out a bunch of characters at 9600 baud (I took the signal from the USB-BUB connector).

Here is the glcdTracer.pde sketch which implements this:

Screen Shot 2010 11 20 at 17.24.06

Lots of trickery with bits. To keep memory use very low, I’m storing the 512 samples in a 128-byte buffer (512 x 2 bits = 128 x 8 bits). Low values are drawn as a pixel, high values are drawn as a little vertical line.

The code includes a minimal triggering mechanism, i.e. it waits for either of the input signals to change before collecting 512 samples.

Samples are collected at about 10 KHz, but this can easily be changed (up to ≈ 200 KHz with the current code).

Note that it would be possible to double the number of samples to 1024 and display them as 8 groups of 2 signals, but then you’ll have to really squeeze the output to fit it onto the 64×128 pixels on the display.

BTW, there’s some shadowing visible on the display – has to do with how the chip drives the GLCD, no doubt.

Soooo… now we also have a portable Logic Analyzer!


More box options

In Hardware on Nov 24, 2010 at 00:01

Here are a few more options for putting JeeNodes in a box which turn out to work really well:

Dsc 2316

Of course anything larger will fit as well, but I wanted to find out which boxes would be just enough for a JeeNode. As it turns out: several!

These boxes are all available from Conrad, which has an online shop in several European countries. I’m not going to stock them for two reasons: 1) there are just too many choices, and everyone has different needs and preferences, and 2) they won’t fit in an envelope. So to get them, you’ll have to order from Conrad yourself.

The good news is that all these boxes are very inexpensive.

Below is a summary of each one shown above, along with the Conrad order numbers and external dimensions.

#534347 – 85x56x25 mm

The smallest box of ’em all. The JeeNode PCB fits in any of the slots, but you need to make a small notch on the inside of the top cover:

Dsc 2311

#534346 – 85x56x39 mm

A taller version, same color and same perfect fit for a JeeNode (as with the previous box, the FTDI pins need to point up, not out). No need to adjust the cover on this one:

Dsc 2312

#530113 – 88x58x30 mm

This one is slightly larger on the outside, but the sides are slanted and the board only fits by slightly enlarging the plastic notches inside. There’s a small hole in one of the shells:

Dsc 2313

However, there’s also an optional PCB for it with copper islands on one side (#530126). Then the JeeNode can just sit on top as is:

Dsc 2317

#520861 – 90x60x51 mm

On the large side, and fairly high. The JeeNode won’t fit in tightly, so you’ll need to fasten it somehow. This box could almost include a 3x AA battery holder with switch, but to do so you’ll need to remove some plastic inside on all 4 stand-offs:

Dsc 2314

#528373 – 124x72x30 mm

This box is almost identical to the Jee Labs box, but it’s transparent, it has slightly smaller inner dimensions, and there are no slots to slide the Carrier Board into. You can either shorten the pcb a fraction of a millimeter or make some very shallow grooves on the inside of the box to hold the pcb in place:

Dsc 2315

This box also comes in BLUE (#528834), RED (#528347), and GREEN (#528360).

Don’t know about you, but I’m pretty sure I’ll find a good use for each of these little boxes around here…

, ,

100 KHz DSO

In AVR, Hardware, Software on Nov 23, 2010 at 00:01

You might have been wondering why I created the digital-to-analog converter a few days ago.

Well, because I needed a test signal… to build this thing:

Dsc 2307

You’re looking at a <cough> Digital Storage Scope </cough> with 100 KHz bandwidth :)

First of all: please don’t expect too much. There is no signal conditioning and no triggering whatsoever, and there are no external controls. This is simply a JeeNode plus a Graphics Board. It’s using the built-in ADC, with the conversion clock pushed quite a bit higher than what the Arduino’s analogRead() function will do. This speed comes at the cost of conversion accuracy, which isn’t so important since the Graphics Board display only has 6-bit vertical resolution anyway.

The screenshot shows a 1 KHz sine (from that Bleep! thing, obviously). As you can see, one cycle more-or-less covers the entire x-axis. So that’s about 128 samples per millisecond. This is not the maximum value, the ADC can also work twice as fast – i.e. with a division factor of 4 (ADPS2:0 = 2). This translates to 4 µs per sample.

Using the Nyquist–Shannon sampling theorem again, you can detect a frequency if you sample it at least twice per cycle, so that would have to be a cycle of at least 8 µs, i.e. over 100 KHz. Which is why I decided to call this thing a 100 KHz DSO :)

The code tries to get as many samples as possible into a little 128-byte buffer before doing the rest of the work. The graphics display has a fairly limited response time, so I’m refreshing the display at 5 Hz (it’s still visible up to 50 Hz, but only just…).

I find it pretty amazing what an MPU such as the ATmega can do these days, with just a few lines of C code. Here’s the entire glcdScope.pde sketch:

Screen Shot 2010 11 19 at 02.58.10

The rest of the code is in the same modified ST7565 library as used in the past few days.

There’s lots of room for expansion, this code uses less than 4 Kb.

So there you have it – a very crude, but functional, oscilloscope!

,

The obligatory clock…

In Software on Nov 22, 2010 at 00:01

Take a Graphics Board, a JeeNode (or JeeNode USB, or JeeSMD), some code, and you get this:

Dsc 2303

I guess it’s sort of the equivalent of “Hello World” for graphical displays by now.

This is my code for it:

Screen Shot 2010 11 21 at 17.38.44

It even includes a blinking colon! :)

There’s a separate header file with the ten bitmaps used for each digit.

Here is a copy of the modified ST7565 code I use.

This clock runs on the ATmega’s 16 MHz clock, which is only accurate to about 0.5% with a ceramic resonator. More importantly, this clock has no notion of real time – it just starts counting when turned on. The value it starts from uses a funky trick available in RTClib: it’s set to the compile time of the sketch … this is actually not a bad choice during development. But for real use, you’ll need to add an RTC Plug or some other means of obtaining the time (such as a DCF77 receiver, if you’re in Europe).

Anyway. At least now you can see that it really is a graphical display.


Bleep!

In AVR, Hardware, Software on Nov 21, 2010 at 00:01

Puzzle for you – what is this thing?

Dsc 2301

Maybe the demo sketch helps?

Screen Shot 2010 11 18 at 12.25.23

Answer: it’s an 8-bit digital-to-analog converter, using an R-2R ladder network (with 10 kΩ & 20 kΩ resistors).

The above toneGen.pde sketch generates a sine wave of approx 1 KHz:

Screen Shot 2010 11 18 at 12.25.17

There’s lots of ways to improve on this and turn it into a general-purpose function generator for example.

The interesting part is that all four ports are used for the required 8 I/O pins, and that due to the regularity of the pin assignment, they can all be set at once with very little code. The pin assignments for the DAC are:

  • bit 0 = AIO1
  • bit 1 = AIO2
  • bit 2 = AIO3
  • bit 3 = AIO4
  • bit 4 = DIO1
  • bit 5 = DIO2
  • bit 6 = DIO3
  • bit 7 = DIO4

The maximum attainable frequency is about 1.84 Khz with this software approach (1.95 KHz with the sine256 table placed in RAM), but that’s only if you use all 256 steps of the sine wave. The loop itself runs at about 1.84 * 256 = 470 KHz, so based on the Nyquist–Shannon sampling theorem, it should be possible to generate decent signals up to well over 200 KHz. The trick is to increment the “index” variable by larger values:

Screen Shot 2010 11 18 at 12.54.06

Here’s the corresponding output:

Screen Shot 2010 11 18 at 12.55.31

Still a pretty decent sine wave, so 16 resistors are all it takes to cover the entire audible frequency range.

By using fixed-point calculations for “fractional indexing”, you can get even more fine-grained control over the frequency of the generated signal. The following version generates an 8.01 KHz sine wave on my setup (note that “index” is now a 16 bit unsigned integer):

Screen Shot 2010 11 18 at 13.03.55

Update – I’ve changed the main loop to avoid the calling overhead of loop() itself. That increases the maximum attainable frequency by another 50%. Note that interrupts must be disabled to produce a clean tone.

, ,

Indoor temperature, etc.

In Hardware, Software on Nov 20, 2010 at 00:01

Here’s a fun little project…

A Graphics Board with a JeeSMD and two plugs: a Pressure Plug and a partially-populated Room Board.

The result is a geeky little indoor environmental monitoring station:

Dsc 2293

Couple of notes here:

  • I took the lazy way out and merely display the info as text, graphics would be so much nicer!
  • Both sensors can read the temperature, but as you can see, they don’t fully agree…
  • I added the FTDI hookup and used it to power this thing via an AA Power Board.
  • The AA board does double duty, as a little stand to hold this thing slanted upwards.

Adding FTDI was very useful in this case, since it also makes it possible to re-program the JeeSMD, which has no FTDI connector on board. All it needs is a 0.1 µF cap and the 6-pin header:

Dsc 2298

But there’s more to it than that, alas: to be able to upload to the JeeSMD, you need to hook up all the headers on the JeeSMD, i.e. also the PSI and the SPI/ISP headers. Adding those after the fact is very tricky, since you can’t reach the back of the Graphics Board pcb anymore if you soldered the LCD on permanently – as I did.

I had to solder the female headers slightly higher, to just barely reach the pins from the top with a very fine soldering iron tip (I use 0.4 mm). It worked, but as a result, the JeeSMD sits a bit higher on its pins than usual:

Dsc 2297

Here’s the indoor.pde sketch, also added to the Ports library:

Screen Shot 2010 11 17 at 22.47.37

Onwards!


Speedier graphics

In Software on Nov 19, 2010 at 00:01

The Graphics Board is going to enable a bunch of fun projects around here.

Unfortunately, the ST7565 library is a bit slow in one specific way – display updates. Since everything is buffered in RAM, most other operations are actually quite fast, but to get that data onto the gLCD takes time.

I had to find out how much time, of course. Here’s my test sketch:

Screen Shot 2010 11 17 at 19.45.42

All the loop does is send the same RAM buffer contents to the display, over and over again. The time it takes in microseconds is sent to the serial port, and the result is quite bad, actually:

  • 126 milliseconds, i.e. 8 refreshes per second, max!

The good news is that it’s a clear bottleneck, so chances are that it can be found and then hopefully also avoided. Sleuthing time!

The ST7565 core primitives, responsible for getting the data out to the display were coded as follows:

Screen Shot 2010 11 17 at 18.43.49

Guess what: the shiftOut() in the Arduino library is written with calls to digitalWrite(). That rings a bell.

Ah, yes, good OLD digitalWrite() again, eh? Of course …

So I rewrote this code using fixed pin numbers and direct port access:

Screen Shot 2010 11 17 at 18.45.18

And sure enough, it’s almost exactly TEN times faster:

  • 12.3 milliseconds, i.e. 80 refreshes per second.

Needless to say, I’m going to leave these changes in my copy of the ST7565 library – even though that means it’s no longer general purpose since the pin assignments are now hard-coded. A 10-fold performance increase of something which really needs to be snappy and responsive is non-negotiable for me.

Here is a copy of the ST7565 code I use.

Could this bottleneck have been avoided?

The ST7565 library was clearly written as general purpose library, so making it usable with any set of pin assignments makes a lot of sense. The price paid in this case, was a 10-fold drop in performance, plus a few extra bytes of RAM used in the ST7565 class.

I’ll revisit this topic some other time, to discuss the trade-offs and implications of compile-time vs run-time logic, as well as tricks such as: putting the pin choices in a header file, using #include for source files, pre-processing and code generation, and C++ templates.

For now, I’m just happy with the 80 Hz refresh rate :)

Update – I had to slow down the SPI clock a bit, because the display was not 100% reliable with the code shown above. The fix is in the ZIP file.


Thermo Plug mismatch

In Hardware on Nov 18, 2010 at 00:01

The Thermo Plug was recently updated as a kit with a thermocouple for use as Reflow Controller, for example.

It uses screw terminals to connect the K-type thermocouple, because that wire can’t be soldered – I tried, really hard! Besides, you don’t want to add too many weird amalgamated cold metal junctions in this setup, which is all about the tiny voltage potential between different metals.

The whole thermocouple works nicely, but I goofed a bit on the connector: the screw terminal I got for this plug is slightly too big to fit on there in the intended position:

Dsc 2289

Yuck … two solutions:

  • solder it on anyway, and just ignore that tower-of-pisa effect…
  • solder it on the other way, and insert the thermocouple wires from the board side

Here’s how that will look:

Dsc 2290

Slightly odd, but it’ll work just fine of course.

Note that the back side of this screw terminal has two holes, but they cannot be used to insert wires, because those will end up too high and wouldn’t be held tight by the screws:

Dsc 2291

I’ll look around for a slimmer form-factor 3.5 mm screw terminal. If I can’t find any, then I’ll plan a board revision – but for now, it’ll have to do.

With a small nod to Mr. Murphy…

, ,

Room Node display

In Software on Nov 17, 2010 at 00:01

Now that there’s a Graphics Board, I thought I’d make a little display with the last few readings from a couple of room nodes around here. Ironically, it’s just a 8×21 character text display for now – no graphics in sight:

Dsc 2281

The information consists of:

  • a packet sequence number (only 4-byte packets are treated as room nodes)
  • the node ID
  • the temperature in °C
  • the relative humidity in %
  • the measured light intensity (0..255)

New readings get added at the bottom, with older readings scrolling upwards.

Unfortunately, the ST7565 library doesn’t have a normal print() & println() API, so the first thing I did was to create a new wrapper class:

Screen Shot 2010 11 16 at 12.42.57

One quirk about this code is that since we’re using a RAM buffer, the ST7565 screen contents needs to be explicitly updated. I solved it by adding a poll() method which you need to call in the main loop. It’ll make sure that the display gets refreshed shortly after anything new has been “printed” (default is within 0.1 s).

Another thing this class does is to scroll the contents of the display one line up when the bottom is reached. It does this in a slightly lazy manner, i.e. the display is not scrolled immediately when a newline is sent to it but when the first character on the next line falls outside the display area – a subtle but important difference, because it lets you use println() calls and the display won’t constantly leave an empty line at the bottom.

Scroll support does require one change to the “ST7565.cpp” source code. This:

    static byte gLCDbuf[1024];

Has to be changed as follows, to make the RAM buffer accessible from other source files:

    byte gLCDbuf[1024];

(should be around line 42 in ST7565.cpp)

With that out of the way, here’s the glcdNode.pde sketch, which has been added to the RF12 library:

Screen Shot 2010 11 16 at 12.53.36

For debugging purposes, the same information shown on the display is also sent to the serial port:

Screen Shot 2010 11 15 at 02.24.28

Note that gldeNode is hard-coded to receive packets from net group 5 @ 868 MHz, as you can see in the call to rf12_initialize().

So now I have a battery-powered wireless gadget which lets me track what our house is trying to tell us!

Update – the ST7565 library needs to be changed a bit more, I now realize. Perhaps the easiest way to do so is to simply insert the following line somewhere near the top of ST7565.c:

    #define buffer gLCDbuf

That way, the buffer will have a more meaningful name when made global by the above-mentioned patch.

Update #2 – no more need for the ST7565 library, use the new GLCDlib instead. The glcdNode demo sketch has been adapted and moved over to it.

,

Assembling the Graphics Board

In Hardware on Nov 16, 2010 at 00:01

This is going to be a weblog post with lots of pictures…

The Graphics Board is easy to assemble, but there are two things to watch out for:

  • the polarity markings for two of the electrolytic 1µF caps are reversed
  • if you solder the display onto the board, then you can’t easily reach the back anymore

The former is a mini goof-up by yours truly, the latter is something to keep in mind when deciding which headers you are going to use (you can side-step the issue by mounting the display using headers, but that will increase the height of the entire stack).

Here goes. As usual, I’m going to proceed from low to high-profile components, because that lets you put the components in, flip the board over, and press on it to get the components soldered closely to the board.

First the 100 Ω backlight series resistor:

Dsc 2251 2

Note that there’s a solder jumper right above it. The default is to connect the middle pad with the leftmost pad marked “P”. This connects the backlight permanently to the PWR line. If you want to control the backlight through the IRQ signal, you can set the solder jumper to the “I” position instead (see the backlight() docs). This can be changed later if you change your mind.

Then 5 yellow decoupling caps. These are not polarized, but make sure you put them into the right holes:

Dsc 2249

Update: The latest kit version ships with ceramic capacitors replacing the electrolytic capacitors. This gives longer life and simplifies the construction detail since these capacitors are not polarised. See the Wiki for more detail

The next step needs some care, because these two electrolytic caps are marked the wrong way on the silkscreen – they should be placed as follows:

Dsc 2251

The proper way to connect these, is to put long lead on the right and on the bottom, respectively. Or, same thing: put the gray stripes of the plastic case insulation on the left and on the top.

Note: the two caps on the left will only just barely fit when a JeeNode v5 is added on later. If you use a JeeNode v4, it is probably better to place them flat on their side pointing left. When in doubt, make sure you check the mechanical layout before soldering these two leftmost caps!

The other two 1 µF caps go as indicated on the board, they will in fact be oriented exactly opposite to the caps right next to them:

Dsc 2252

More…

Read the rest of this entry »

,

Meet the Graphics Board

In Hardware on Nov 15, 2010 at 00:01

Sometimes, 2×16 characters (or perhaps a few more) just don’t cut it, when I’d like to present things graphically, or use larger fonts for some of the info. That’s when a “GLCD” would be handy, one which lets you set individual pixels, that is. I was pointed to a nice low-power 128×64 display recently, and decided to create a pcb for it – so here’s the new Graphics Board:

Dsc 2258

Due to the size of the board, it’s not a plug or an add-on to a JeeNode, but the other way around: you can take a JeeNode, JeeNode USB, or JeeSMD, and push it onto this board to power and drive the display.

Ports 1 and 4 are used for the diplay, but ports 2 and 3 are available, and brought out in such a way that plugs can easily be added on. To make a clock, add an RTC Plug. To add a few touch buttons, add a Proximity Plug. To create a fancy Reflow Controller, add a Thermo Plug. Or just use it as is and add a sketch to display messages received over wireless. Endless possibilities…

Here’s the display in action, it’s pretty bright when driven from 5V:

Dsc 2278

It can display up to 8 lines of 21 characters, but it’s also fully graphical of course. BTW, in real life the display looks much more white-on-black.

I particularly like this setup, using the AA Power Board to make this thing completely self-powered:

Dsc 2245

The backlight resistor is chosen such that on 3.3V, this display draws ≈ 6 mA, and on 5V it draws ≈ 19 mA. It will last a few days with an AA Power Board, but when the 100 Ω resistor is replaced by 270 Ω or even 470 Ω, you can get well over a week of battery life on a single AA (assuming the JN itself is sleeping most of the time) – at the cost of dimming the backlight to a fairly low level.

There is a solder jumper on the board which normally connects the backlight to the PWR line. By connecting it to the IRQ line instead, that pin can turn off the backlight under software control (or dim it, using PWM).

The display is based on the ST7565 chip and can be driven by Limor Fried’s great ST7565 LCD library. Note that this library uses a 1 Kb RAM buffer.

Here’s the glcd_demo.pde sketch which generates the above display:

Screen Shot 2010 11 14 at 17.20.36

I included logic to put the ATmega and radio into power down mode to let me measure the display’s current consumption. While active, they draw another 5..30 mA.

The Graphics Board is now in the café and the shop.

Update – Here is a copy of the ST7565 code I use.


Flippin’ bits – revisited

In Software on Nov 14, 2010 at 00:01

For one of the infinite number of projects here at Jee Labs, I wanted to know how fast you can toggle a pin. This has been covered before in a previous weblog post, but this time I’m going to actually measure the results.

I’m going to focus on sending out 8 pulses in a row, because my goal is to transfer one byte in or out of the system (i.e. software-based SPI).

Here’s the simplest possible way to do it:

Screen Shot 2010 11 14 at 02.13.56

Measured result = 124.60 KHz, i.e. ≈ 8 µs per bit.

Some of that is loop overhead, and one trick to avoid that is to “unroll” the loop:

Screen Shot 2010 11 13 at 18.19.02

Measured result = 129.14 KHz – no big difference?

The reason is that the Arduino library’s “digitalWrite()” is very slow. So let’s go back to the loop and use a faster mechanism:

Screen Shot 2010 11 14 at 02.17.19

Measured result = 1.72 MHz – whoa, 0.58 µS per bit!

Now let’s unroll that loop again:

Screen Shot 2010 11 13 at 18.25.30

Measured result = 3.03 MHz – yep, now the loop overhad makes a big difference…

Can we do better? Yes, we can (heh) – using the PIND trick to toggle an output:

Screen Shot 2010 11 14 at 02.18.30

Measured result = 2.16 MHz – that’s ≈ 0.46 µs per bit.

And now, at these speeds, loop unrolling makes an even bigger difference:

Screen Shot 2010 11 13 at 18.31.54

Measured result = 4.71 MHz!

That’s a bit odd though. The JeeNode is running at 16 MHz, and 4.71 MHz is not a very clear multiple or divisor of anything. How can a regular sequence of statements generate such an irregular frequency? The puzzle is solved by looking at the bigger picture with a scope:

Screen Shot 2010 11 13 at 18.59.09

(as you can see, my scope can’t sample 8 MHz square waves with good fidelity)

The scope measurement says it all: these are short bursts, because now the calling overhead of “loop()” is taking almost as much time as the 8 pulses.

If I unroll the loop further to contain several hundred “PIND = bit(4);” statements, the frequency readout increases to 7.82 MHz. IOW, each C statement takes one processor cycle!

Quite an amazing feat, the AVR MPUs are clearly RISC-class processors. And the gcc compiler is generating optimal code in this case.

So there you have it. A lowly JeeNode (or Arduino) can generate multi-megahertz signals on an I/O pin, just by writing a few lines of C code!

Note that these are limiting values. As soon as you start adding more logic to these loops – whether unrolled or not – the maximum attainable frequency will quickly drop. But still: not too shabby for them little chips!

Update – measurements were slightly off, because not all loops were 8 long. Fixed now, same conclusions.

Hand-made envelope

In Musings on Nov 13, 2010 at 00:01

Yesterday, I got a small cardboard box from India with some geared DC motors I’d like to experiment with. It came wrapped in this:

Dsc 2246

Quite sturdy and hard to remove, in fact. Note also the text on the declaration for customs: “Parts” – heh, yeah, that’s all they need to know :)

And it’s… hand-stitched!

Dsc 2247

Amazing. I now have this mental picture of someone with needle and thread, sitting in lotus position in the shipping department, in charge of wrapping up all the outgoing packages :)

I find these small glimpses of the cultural richness on our planet one of the most thrilling aspects of doing business these days. Long live human diversity!

,

Meet the Infrared Plug

In Hardware, Software on Nov 12, 2010 at 00:01

The new Infrared Plug needed a small adjustment to work, but now it’s working properly. Here’s my hand-soldered prototype:

Dsc 2243

Fits on any of the JeeNode ports, of course. The DIO pin controls the IR output, which is pulsed at 38 KHz (38.28 KHz on my unit, more than close enough). The light is generated with one or two IR LEDs. With one LED, the peak current is ≈ 50 mA (a bit high for the AA Power board) – with two LEDs, the current is ≈ 10 mA. That will no doubt have a lower range, but you could tape one of the LEDs onto a specific appliance, while still letting the other one shine into the room (or a second device).

The input is a 38 KHz detector, with its signal available on the AIO pin.

The “InfraredPlug class” in the Ports library makes it easy to interface to this plug, as described in recent posts.

I’ve also added an “ir_repeater.pde” demo sketch, which repeats any NEC command it receives three times, at 1-second intervals. When I press “Forward” on my Apple Remote, it’ll end up skipping 3 extra songs forward. Can’t quite think of a use for that, but it helped me flesh out the bugs:

Screen Shot 2010 11 11 at 18.16.58

There is a bit of logic in there to convert the incoming slot count to a bit pattern.

Sample output:

Screen Shot 2010 11 11 at 18.16.51

The Infrared Plug is now in the café and the shop.


Parallel port UltiMaker

In Hardware on Nov 11, 2010 at 00:01

I’m currently building the Mantis – a little CNC router designed specifically to help create custom PCB’s. Actually, mine will look more like this.

I’m not convinced yet that this thing will be able to do PCB isolation routing, but I’m willing to give it a try. It’d make it much simpler to do one-off’s, instead of having to live with this:

But I’m not quite willing to dedicate an Arduino Mega and the UltiMaker electronics that is offered as option in the workshop. If you’re interested in 3D printing: the UltiMaker is derived from the RepRap and the MakerBot CupCake, as described here.

So instead of following everyone using the MPU-based approach, I’m going to re-use my parallel-port laptop running the EMC2 software, and let the laptop do all the work, instead of yet another dedicated board. I can always switch to a microcontroller setup later if this machine is practical enough to use it frequently. And if it doesn’t work out, my investment will have been relatively low.

There’s also a second reason for doing it this way: I’d like to build my own electronics for this CNC/3D stuff one day. I think there are better ways to do this sort of thing, more modular, more extensible, and more flexible (why not Ethernet? why not closed-loop servos?). But it wouldn’t be realistic to think I can take on that challenge as well, with everything else also going on at Jee Labs. So for now, the parallel-port shortcut will have to do.

Driving CNC stepper motors from a parallel port is a proven (but by now somewhat outdated) concept. Either way, it all ends up doing the same thing: executing the CNC world’s de-facto standard G-Code scripts.

You still need stepper motors, and stepper motor drivers, since a parallel port can only send out feeble 5V signals.

To save some time, I decided to try something a bit whacky by re-purposing an UltiMaker electronics board to hook up its motor drivers to the parallel port:

Screen Shot 2010 11 10 at 17.49.08

Lots of stuff on there I won’t need: heater control, extruder control, PWM…

Here’s a minimal setup, using just 3 stepper drivers and a little JeePlug board sitting on top of some extra headers on this board:

Dsc 2242

I patched a 5V regulator (plus LED) on there to feed the logic levels of the Pololu stepper drivers, and left everything else off, basically. Only thing left to do is wire up 7 signals + ground between the parallel-port breakout board and the JeePlug.

And then figure out the software side of things…

,

IR packet decoding

In Software on Nov 10, 2010 at 00:01

The InfraredPlug class in the Ports library has been extended with a decoder which tries to recognize the incoming IR pulse trains. Remember that the data is returned as a list of on/off times, returned as multiple of the “slot size” given to the InfraredPort constructor on setup.

I merely added a new “decoder()” member:

Screen Shot 2010 11 09 at 12.16.09

It currently only recognizes the NEC protocol, which is what three of my remotes here use. The NEC packets have 32 bits of payload (or no bits at all in the case of a “repeat” packet).

Here’s is how the ir_recv.pde sketch calls this new decoder:

Screen Shot 2010 11 09 at 12.19.35

Sample output from three different buttons on three different remotes each:

Screen Shot 2010 11 09 at 12.52.03

The first remote (starting with 246) shows a “classical” NEC remote, where each second byte is the 1’s complement of the one before it.

The second remote (starting with 162) uses 1’s complement only on the command bytes at the end.

The third remote (starting with 119) is an Apple Remote which uses the extended NEC format, and presumably another way to check the validity of received packets.

Full details about the NEC and other protocols can be found on San Bergman’s page.

,

Almost, but not quite

In Hardware on Nov 9, 2010 at 00:01

There’s a new Infrared Plug in the works – it’s almost ready. The IR transmitter uses the venerable 555 chip:

Screen Shot 2010 11 08 at 20.36.42

I used the formulas from the datasheet to calculate the different resistor and capacitor values to arrive at 38 KHz, which is the most common IR frequency (and which most 36 and 40 KHz systems will pick up as well).

To check things out, I hooked the plug up for constant oscillation (DIO to +3V):

Dsc 2235

Despite using 1% parts for all the timing critical components, the output isn’t quite what it should be:

Screen Shot 2010 11 08 at 20.33.12

That’s 35.5 KHz … i.e. almost 10% off target!

(note that I measured the signal across the transistor – the IR current is actually the opposite, i.e. fast rise time)

I’ll have to tweak one of the resistors empirically (16.0 kΩ i.s.o 17.4 kΩ seems to fix it) and order some new SMD values. And then I need to check that the frequency across multiple plug builds will remain within bounds.

Not quite back to the drawing board (the PCB seems to be ok), but still: back to the soldering iron!


JeeNode Experimenter’s Pack

In AVR, Hardware on Nov 8, 2010 at 00:01

Neat – it looks like JeeNodes are starting to become popular for workshops!

I’m not really surprised: it’s more fun than an Arduino, IMO, because you get to learn the basics of electronics and soldering, and of course every JeeNode comes with wireless connectivity built-in. As I’ve said before, making things happen by wireless is a bit like magic…

FWIW, there are a couple of workshops scheduled for this month (“in-house”, i.e. for a specific audience, and I’m only indirectly involved), all are based on either a JeeNode or an RBBB. Both are well suited for solderless breadboards, which – if you ask me – is one of the greatest inventions ever for tinkering and learning electronics. Sure, soldering works best when the circuit is known and proven, but nothing beats a breadboard, some jumper wires, and a bunch of components and chips to try out things!

This gives me great satisfaction. No, not for the money side of it (it’s all discounted anyway), but because I find nothing more exciting than to see people try out new fun stuff and nurture their tech geek sides :)

Learning is great: if you’re young, it’ll make you wiser – if you’re old, it’ll make you younger … (and it’s fun!)

The big question is always: “what do I need to get started?” – and my answer is usually: “it depends on what kind of adventure you’re after”.

I’ve come up with a new “JeeNode Experimenter’s Pack” to create a baseline for the future. That way, it will be easier for me to set up and document my experiments, knowing that there is a common baseline on which to build. It’s also the logical step after this rubber-band concoction. It consists of the following key components:

Dsc 2221

In prose:

In addition, and only in combination with the rest of the Experimenter’s Pack, I’m throwing in a little 10×17 cm laser-cut wooden base and an LDR to get started with some sensor experiments:

Dsc 2220

The base turns the whole thing into a self-contained “project platform” for all sorts of experimentation. And the AA Power Board will supply 3.3V to make this setup portable and usable anywhere. The rest of the empty space is all yours. That’s where the fun happens :)

The AA Power Board is not just a gimmick, BTW: an AA battery will actually provide more power @ 3.3V than a 9V “block”! As someone pointed out recently, it’s also a great way to drain any half-used AA batteries you might still have lying around (who hasn’t?).

Here’s a recent example of use (which required a bit more power, so I hooked it up to a 12V supply):

Dsc 2215

It’s a little stepper motor tester (using an EasyDriver board). Nothing fancy, but it was a convenient way for me to try something like this out. That project board has now been cleared to make room for new experiments…

That’s the whole point, really – this self-contained setup is intended to provide a quick path for trying out new ideas. USB-connected or battery-powered, serial or wireless, local or remote, whatever.

Once it all works, you could:

  1. take the design and redo it as a more permanently soldered circuit
  2. design a pcb for it (which is what I did for the graphics board)
  3. put it all into a custom enclosure and keep using the setup
  4. stash it all away as is, for some other time
  5. put hot glue on it? (yikes!)

I’ve added this to the shop, as 1- and as 10-pack.


Isolation

In Hardware on Nov 7, 2010 at 00:01

There’s no escape… I have to get into mains voltage stuff and try some things out. All 220 volts of ’em!

I want to experiment with power measurement, power control, dimming, an such – but, ehm… preferably in a way which will let me live to tell the story! (how’s that for dedication to this weblog, eh?)

Now the thing about electricity is that it’s not the voltage that kills you, it’s the current – after all, if this weren’t the case, all the birds on high-voltage wires would be dropping dead out of the sky…

Current means: electricity going from A to B. And the problem with us human beings is that we are conductors – which isn’t too surprising, given that we’re mostly made of water anyway (the rest is hot air, I’m told).

So the first thing to do is to isolate myself from AC mains, by not allowing a ground path to carry any current. This can be accomplished with an “isolation transformer”, i.e. a transformer from 220V to 220V which – like any normal transformer – creates a galvanic isolation barrier:

Screen Shot 2010 11 06 at 20.25.22

Trouble is, these transformers are relatively expensive. One reason for this could be that you want to get a fair amount of power across, so these are hefty units with a lot of copper, iron, etc. in them!

Fortunately, there’s a simpler way to accomplish exactly the same using two back-to-back normal transformers:

Screen Shot 2010 11 06 at 20.26.38

The first one is a normal step-down transformer, producing 10.5V – and then we simply take a second one of the same type, and connect it the “wrong” way around.

There will be losses, so the output voltage won’t be exactly 220V, but I’m fine with that. In fact, it’s a nice test to see what a mains circuit will do with a somewhat lower voltage.

I’m going to use a pair of beefy 300W transformers I have lying around here, which will let me test some control and measurement options up to at least 250 Watts or so. Here are the main ingredients, which I’ll put in a wooden box with slots for natural convection. This dual wine bottle unit looks like a good fit:

Dsc 2212

(I told you they were hefty tranformers – each of them weighs several kilo’s!)

What this gives me, is an isolated source of mains-like AC voltage. It is still just as lethal when touching both power lines. The only safety this adds, is that touching a single high-voltage output wire is now harmless.

The other benefit is that an accidental short will limit the amount of current that can flow through this setup, thus also limiting heat and damage somewhat. But 300W of power is still a huge amount, so I have no illusions that things won’t break. It’s mostly to prevent fires and burnt-out cabling.

Evidently, this thing needs a switch with indicator light, and fuses: a 5 Amp fuse on the input, and a 4 Amp resettable fuse on the output (lowest I could find):

Dsc 2213

Scary stuff. I could set up a pair of much lower-amperage transformers for loads up to 25 Watt or so, but it’d still be potentially lethal, so that would only lead to a false sense of security.

The low-voltage / high-amp intermediate circuit does provide an option to insert a fast-acting fuse. A 100 mA fuse @ 10.5 VAC would translate to 5 mA @ 220 VAC, which is no longer lethal, but I’m not willing to “prove” that! Trouble is that such a setup would blow its fuse with anything over 1 Watt of power, even if only a power-up spike.

Here’s the whole contraption (not wired up yet) – with thanks to Ikea for the “front panel”:

Dsc 2214

I’ll finish this isolation setup for some experiments, but it won’t alleviate much of my fear. Unfortunately, there’s simply no other way to get going…

,

Better panels

In Hardware on Nov 6, 2010 at 00:01

While we’re on the subject of PCB panels…

All new plug panels are now made with a mix of V-scoring and routed slots:

Dsc 2194

The vertical lines are “V-scores” – small sharp cuts on both sides of the boards which makes it easy to break off the board at that point. Adds a few strips of waste, but the result is much cleaner.

The reason for this is that the sides come out better (and much more accurate) when routed, but you don’t want to route all four sides, because then you have to leave little break-off tabs to hold the boards. The problem is that these tend to break off with a very rough edge, requiring extra cutting or sanding to clean up.

Progress!


Smooth sailing

In Hardware on Nov 5, 2010 at 00:01

I’ve just completed three pcb panel reflows, based on my Reflow Timer progress. Here’s a panel of Pressure Plugs:

Dsc 2210

Perfect reflow, on all three panels. There is a small problem with a cold spot in the grill, but that’s a known (and predictable) issue with a specific spot on the panel. Nothing a soldering iron touch-up can’t fix.

Oh, and isn’t blue + gold just gorgeous? – I see that it’s being picked up / imitated by others as well, such as for the “USB BUB” and the “LCD Plug” – well, sort of… ;)

Here’s one of the (unretouched) corresponding reflow graphs:

Screen Shot 2010 11 04 at 18.27.00

A perfect profile on every run, as far as I can tell!

Note that the initial overshoot in the WARMUP phase is not very important. The key is to start off somewhere between 80° and 100°, with a fairly flat curve. How that point is reached turns out to vary a lot – but from then on, all reflow graphs I’ve seen so far look more or less the same. Which is all that matters.

The only improvement remaining, is to find a way to automatically come up with decent P, I, and D factors (I’m currently using 150, 5, and 700, respectively). I’m hoping that a calibration run which applies a step change will be able to solve this. The idea is to start at some temperature (below 40°C), then turn on the heater full blast until it reaches 120°C, then measure the slope at that point as well as the maximum temperature reached after the heater has been turned off. The slope says something about the heater power, the overshoot says something about the amount of “pent-up” heat stored between heater and thermocouple, i.e. the “thermal mass” of the system.

I’m delighted with my new setup, because it no longer needs to be chaperoned – I just turn the Reflow Timer on and walk away to start populating the next board. IOW, this reflow process is now a no-brainer and a time saver!

Onwards! :)

,

Reflow Timer software

In Software on Nov 4, 2010 at 00:01

Another episode in the reflow controller story…

Here is yesterday’s graph again, but manually annotated this time:

Annotated Reflow

Actually, I went ahead and extended the code to add those axis labels in there. I was concerned that they would overlap and distract from the graph data itself, but after seeing this… it clearly improves readability.

The trick is to get the PID control factors right, and these will be different for each setup. Right now, I just picked a couple of values which seem to be working ok on my particular grill. I’ve extended the JeeNode sketch to allow adjusting these values via a serial USB connection:

    <N> P       P factor (x1000)
    <N> I       I factor (x1000)
    <N> D       D factor (x1000)
    <N> L       I limit (x1000)

The PID calculation is:

    (Pfactor*Pval + Ifactor*Ival - Dfactor*Dval) / 1000

In other words, these factors are specified as a multiple of 0.001.

The result is brought into a range of 0..100. This in turn is used to determine when, how often, and how long to turn on the heater in the grill/oven/skillet.

The reflow profile parameters are also adjustable from the serial link:

    <N> o       ON temperature (°C), default 70
    <N> w       minimum time in WARMUP phase (sec), default 60
    <N> p       temperature at end of PREHEAT phase (°C), default 140
    <N> s       temperature at end of SOAK phase (°C), default 170
    <N> m       maximum REFLOW temperature (°C), default 250
    <N> r       minimum time in REFLOW phase (sec), default 15
    <N> c       temperature at end of COOL phase (°C), default 150
    <N> f       temperature at end of FINAL phase (°C), default 50

Once the FINAL phase ends, the JeeNode will power itself down.

A few more parameters:

    <N> l       lower calibration temperature limit (°C), default 40
    <N> u       upper calibration temperature limit (°C), default 120
    <N> d       stable duration (sec), default 5
    <N> t       stable trigger gap (°C), default 25
    <N> a       number of temperature averages to take, default 250

Some parameters for reporting, which happens once per second:

    <N> i       wireless node ID (sending disabled if 0), default 8
    <N> b       wireless frequency (4=433, 8=868, 9=915), default 8
    <N> g       wireless net group, default 5
    <N> e       enable (1) or disable (0) serial reports, default 0

And finally, the parameters which control the FS20 remote switch:

    <N> H       house code to use for FS20, default 4660
    <N> h       device ID to use for FS20, default 1

All PID factors and other parameters are stored in EEPROM, so they will remain in effect until changed.

To get a summary of all the current settings, type a question mark: “?”.

To reset all parameters to their “factory” defaults, type an exclamation mark: “!”.

The code for the “reflowTimer.pde” sketch is here The current code size is ≈ 14 Kb. I’ll probably be tweaking it a bit further in the coming days.

One thing I’d like to try adding to the current sketch is an easy way to self-calibrate and come up with a workable set of P/I/D factors, so that it can be used with a variety of electrical grills, toasters, skillets, ovens, barbecues, whatever – under the motto: if it can melt solder, we should try it!

The JeeMon script is here and is about 150 lines of code. If you save it as “application.tcl” next to JeeMon, it will automatically be picked up when JeeMon is launched. The code is still work-in-progress at this point: you will have to manually edit the “device” variable to refer to your attached JeeNode/JeeLink running RF12demo – you can also set it to a COM port (Windows) or tty device (Linux/Mac). Likewise, the “nodeID” variable should be set to match the current setting in the Reflow Timer sketch (“i” parameter):

    variable device   usb-A900ad5m    ;# which JeeNode/JeeLink to attach to
    variable nodeID   8               ;# which node ID to listen to

The frequency band + netgroup of the JeeNode/JeeLink are assumed to have been previously set in RF12demo.

Note that the script is an optional GUI front-end – you can launch it anytime, or you can ignore this whole JeeMon thing, since the sketch does not depend on it. It’ll drive the reflow process with or without the GUI.

If you try this out, or have suggestions about how to improve things, please let me know.

Update – I’ve adjusted the info above to match the latest code changes.

, ,

Meet the Reflow Timer

In Hardware, Software on Nov 3, 2010 at 00:01

Now we’re cookin’ – here’s the complete reflow configuration I am setting up for use at Jee Labs:

Dsc 2201

Yes, it’s a Project On Foam again!

As before, I’m using a 700 Watt low-end toaster/grill. It can heat about the area of a 10×16 cm pcb and it’s really small and practical for me. I removed the teflon-coated hot plates, and placed a thin aluminum sheet in there, to respond more quickly to heat changes. A small oven or a skillet could probably also be used.

The power is controlled by an FS20 remote switch (available from Conrad or ELV, both in Europe). This is very convenient, since JeeNodes can control this thing through the RFM12B without any further hardware. The big advantage: no need to mess around with 220V AC mains – it’s RF-isolated!

The LCD display makes this thing independent of a PC/Mac. And the battery pack makes it a fully stand-alone solution. The JeeNode (and LCD / radio) will shut off once the temperature drops below 50 °C. This whole setup draws about 30 mA, so with a run time of 10-minutes, four AA batteries will last hundreds of runs, i.e. plenty!

The Thermo Plug and Blink Plug have both been extended in the shop as pre-assembled unit and kit, respectively, including a thermouple which can be used up to 350 °C. I’ve also added a 4-cell battery holder.

Here’s how to operate this thing:

  • set up everything, place the board inside the grill, and close the lid
  • press the GREEN button, the green LED goes on
  • wait for the BEEP, then carefully open the lid
  • wait until the green LED turns off, i.e. the temperature drops under 150 °C
  • done!

This is an example of what happens during a run:

Screen Shot 2010 11 02 at 13.10.19

Tomorrow, I’ll comment on this graph and the JeeMon app that produced it.

,

Reflow profiles, again

In Software on Nov 2, 2010 at 00:01

Now that the thermocouple readout is working properly, things are moving again with the reflow controller.

What we need to do is set up a reflow temperature “profile” which drives the whole process. First the top level code which controls the whole shebang:

Screen Shot 2010 11 01 at 12.10.38

I’ve left out the reporting part, but basically we need to respond to button presses and go through the whole profile once activated. The reflow profile logic is handled by “setPhaseAndTemp()” function:

Screen Shot 2010 11 01 at 12.12.33

As you can see, it is a simple state machine which moves from one phase to the next according to current temperature and timing conditions. The parameters I’m currently using are as follows:

Screen Shot 2010 11 01 at 12.19.36

Each phase has slightly different conditions, and criteria with which it decides to move on to the next phase.

I’ve added a “warmup” phase at the start for two reasons: 1) to always start off on the main part of the reflow profile from a fairly well-defined temperature, and 2) to implement a drying period which removes any humidity present in the chips, since some chips seem to be sensitive to that. That does somewhat lengthen the whole cycle, because there is a lot of overshoot at low temperatures.

Tomorrow, I’ll describe the complete setup and show you how it performs.

, ,

Conquering the thermocouple

In Hardware, Software on Nov 1, 2010 at 00:01

(No Halloween stuff on this side of the pond – I’ll defer to Seth Godin for some comments on that…)

A while back, I had to shelve my experiments with the reflow controller, because I couldn’t get a reliable temperature reading from the Thermo Plug when using a thermcouple.

Or rather, sometimes it worked, sometimes it didn’t: the physical computerer’s equivalent of a nightmare!

The thermocouple circuit is very sensitive to ground currents, apparently. The effect was that my setup would work fine on batteries, but jump all over the place when attached to the USB port. Not very convenient for development, obviously.

It still has some unexplained behavior, but I’ve been able to narrow it down, so there are two new pieces of good news: 1) it only works badly while data is being transferred over the USB port, and 2) with some averaging, the readout is actually rock solid, both on batteries and on USB. I still see a difference in readout when data is transferred over USB, but since this is a JeeNode, I can work around that in the final version: go wireless!.

Here’s the readout code which produces good readings – all remaining jitter is now in 1/10’s of degrees Celsius:

Screen Shot 2010 10 31 at 18.48.10

The output is in 1/100’s of °C, because I’m trying to avoid floating point math in this sketch.

And here is the measuring side of my new reflow setup:

Dsc 2200

The thermocouple is taped to the thin aluminium insert in the grill using heat-resistant Kapton tape. When I turn on the heater, I now see a clear rise in temperature within seconds – perfect!

Note that I’m using a 4x AA pack i.s.o. 3x AA, because the AD597 needs at least 2V more on its supply line than the highest output voltage it is going to report. With 4x 1.2V (worst case, i.e. near-empty eneloops), the range will be at least 4.8 – 2 / 0.010 = 280°C, i.e. plenty!

And indeed, I’ve verified that at 250°, it reports valid temperatures on the attached LCD Plug w/ display.

The other plug you see in the lower left is a Blink Plug, with two pushbuttons and two LEDs.

Let’s see if this time around we can get the whole thing going properly!