question: multiple crystals or one?

I have not had this scenario, but I would have thought separate crystals would be better from a susceptibility point of view, since you can then avoid a long unfilterable trace. Can you use the built-in oscillators instead of the external crystal?

I have tried microprocessor control of gas igniters and they do indeed generate very nasty spikes. Main problem is likely to be conducted interference via the wires connected to the board. Suggest groundplane construction. Where safe, all incoming wires have TVS diode or MOV to groundplane, then RC or LC filter, all near board connector.

The built-ins are slower (8MHz vs 20MHz) and not as precise (5% vs

In my case, the furnace has an electrostatic filter in it. I.e. big spark generator.

Yup, I've got all that. 12MHz LCL low pass, dual schokty diodes for clamping, RC matrix for signal conditioning, in that order. The board is very space-constrained.

Here's the schematics for one of the zones:

The "SMD*" symbols are unassigned 0603 footprints so I can fiddle with the actual filter later, and/or reuse the board for other protocols.

And the board-so-far:

You can see the crystal resonators next to U100, U200, ... U500. U10 is the gumstix.

It looks to me like the mosfets could turn on at the same time and short out the +5V? Unless I've mixed up my drain and source.

I did some experimentation once, with different transient suppression arrangements, to find the "best" one. For big fat sparks direct to the I/O terminal, I found it was best to have a TVS diode directly at the terminal. This then limited the peak voltage to a reasonable level, so that an RC or LC filter could operate. If the TVS is after the filter, there is a risk that the spark can just jump over the filter component. If this did ever happen, I wonder if conducting it to +5V via the Schottky diode is a good idea? Perhaps OK given the powerplane construction.

Actually I don't see that happening for you, looks like any arc would go the central ground connection of the LCL filters.

You've got a lot of CPU's there! I would think you could have got away with an ARM7 for the whole thing... but then I don't know exactly what it all does!

Why would anything this slow need 6 uPs?

John

Unless *I* mixed them up. The idea is that the opamps and resistor divider guarantee that there's a dead zone in the middle. When the MCU line is high, the top mosfet pulls the line high. Then the MCU is low, the line is pulled low. When the MCU tri-states, neither mosfet should conduct, and the line is tri-stated.

Yup, it's a tri-state booster.

I'll see if I can fit one in.

Mostly I pick up inducted spikes, not direct sparks.

It's replacing the relay board that came with the furnace. The current board (also a replacement) has a PC on the floor running the show using busy loops, but it's (1) too sensitive to EMI, and (2) too slow. The 1wire bus is shared among 12 pushbuttons and 4 sensors, so the temperature polling is limited to a few times a minute, and it takes 1-2 seconds for it to notice that you pushed a button.

The new one has each 1wire bus controlled by an MCU, using timers. Each MCU knows what the protocol for the wires is (1wire, serial, PPP, etc) to talk to the thermostats, and mostly manages the timing, plus some preliminary calculations. The results go to the gumstix, which runs Linux, so the timing is less precise but it's a lot more flexible.

The r8c/26 is just a big I/O port with zero crossing logic (60Hz PLL) so that (1) the furnace can be reset to a known state ASAP when the system boots, and (2) because the ZC optos I looked at had a trigger voltage of 35v, and this is only a 24v system. Plus it can refresh the outputs more often to prevent latch changes due to EMI.

The r8c's are only a few dollars each, I'm basically using them as programmable peripherals.

Why not? ;-)

Like I said in my other email, I'm using them as programmable peripherals. They're cheap and small, which makes them efficient for managing line signalling. Also, the more logic I have between the outside world and the expensive gumstix, the better. I'd rather replace a $4 mcu than a $130 gumstix. Of course, I'd rather replace a

In the future, I'll put MCUs in the thermostats too (to poll the buttons and sensor, and drive the LCD), bringing the total to 9 uPs just to run the furnace :-)

Do you need crystal accuracy for the signalling? A resonator, or even better the built-in oscillator could do fine for many protocols.

You haven't necessarily gone overboard: TAPR recently announced a product (the FatPPS) that is a 74123 one-shot but costs $49 and comes with a manual filled with many many drawings :-).

Tim.

I think putting MCUs into the thermostats is sensible, as it follows the physical and real dimension lines of the problem you are solving. Thermostats exist physically separate from the furnace controller, itself. Dividing along those lines is following the natural problem lines.

That is NOT a necessary argument for putting a linux box and 6 MCUs into a furnace controller box. That's a separate question. Not being as familiar as you are with your application, it still doesn't sound like the approach I think I'd take. (But perhaps you are considering important lines of hot-replaceable modules though that doesn't seem the case when talking about sharing a clock module.) What _does_ make sense to me is that your choice to use the gumstix forced your choice of using at least one external MCU and that once you embraced that idea fully, making that more than one was like falling off a log. But this seems more a decision driven by choosing to use an operating system environment whioh then drove other necessities -- none of which were really driven by the core problem itself.

Jon

I'm using Panasonic's EFO-BM series (ok, they're resonators, doesn't change the EMI question), which are very small and have the load caps built-in. The whole thing is 160x120 thou, and only 72 cents each. Accuracy is 0.5%, not as good as the 5ppm crystals I use for ethernet, for example, but far better than the 5% for the built-in clock.

I'm just thinking that 5% (the built-in oscillator) may not be good enough for 1wire or RS-232. A 9600 baud link at 10080 baud? Or 9120 baud? The chip's bootloader even has - as part of the programming procedure - a calibration loop! You send it 16 NUL bytes and it adjusts its baud generator to match it, because it's usually off by too much by default.

Yes but you can do the whole thing with the $4 MCU :)

I never said anything about necessary. It's partly for fun. When people see how many PCs I have in my office, I can look at them and say "Dude, this is nothing. I have 9 computers running my furnace."

The core problem was "I need something smarter than bi-metal switches running my $1000 central air conditioner motor". We burned out the first one pretty quickly, due to short on-off-on cycles.

The only restriction I'm giving myself is that the board must fit in the existing enclosure, even though it would be easy to just bolt a new one on. It's more challenging that way. Everything else is flexible.

The first pass was to put a PC there, with the minimum logic needed to interface with the furnace. Unfortunately, a 200MHz pentium talking to a furnace with a long ribbon cable just isn't a good solution, for various reasons. See

I originally planned board #2 to have a single M32C running everything. It has enough peripherals in it to manage all the line signalling in hardware (it's got 11 or so timers and 5 serial ports). I prototyped a ram/ethernet board for the m32c to prove out those circuits, but decided to go with a gumstix as it vastly simplifies the programming - I can reuse the linux stuff running on the PC.

Plus, running linux gives me a web server (statistics and control), the ability to live update the software via ssh, etc. The control software is more complex than a regular furnace, and I have more features planned (proactive heat/cool based on weather forecasts, weather forecasts shown on the thermostats' LCDs, etc).

Also, I work for Red Hat, so having a furnace that runs Linux is a prestige thing ;-) My furnace currently runs Fedora Core 4:

dj@envy pts/0 ~ $ ssh furnace Last login: Mon Dec 11 22:04:41 2006 from delorie.com [root@furnace ~]# /furnace/sw/console

/ MBR 69.90 F 43.1 % OPEN 16:30:27 / DNS 72.56 F 36.7 % OPEN 16:30:31 / UPS 70.36 F 41.1 % OPEN 16:30:19 / EXT 40.63 F 90.5 % 16:30:23 / ---- ---- --- ----- winter 16:30:16 16:30:32

That's just cool.

The latest furnace applet calculates how much money I've spent for oil this year so far, compared to last year, based on how many hours the furnace was running, relative to average outside temperature.

And it turns out the hard part is the EMI anyway! The multi-uP setup was trivial compared to the I/O circuitry.

I've read all the others, but here's my take:

If the stuff is relatively slow [which it is], then a single high drive buffer should not be significantly enough affected by local EMI and it would be a whole lot cheaper than all those resonators / crystals.

I'd go with a single oscillator and a driver (if it needed one), for price, board objects and not having to worry about loading caps.

Cheers

PeteS

You'd fit right in at General Motors ;-)

...Jim Thompson

Aha I see what you are doing there now. In fact looking at I think I once "invented" a similar looking thing as one half of a h-bridge motor driver, using bipolar transistors instead of fets!

Still not 100% sure what happens during the transition though.

Don't bother then, I don't see it will make much difference in that case. My problem was big bad ESD events: literally sparks going to the input.

Ok, now I'm worried. From the pdf, top circuit...

When P1_4 is higher than 2.235V, U102-6 is higher than U102-7, so U102-1 is low. U102-4 is higher than U102-5, so U102-2 is low. Now, a low on T100-G turns it ON and a low on T101-G turns it OFF, so SMD100 sees a HIGH.

When P1_4 is lower than 1.065V, U102-7 is higher than U102-6, so U102-1 is high, so T100 is OFF. U102-5 is higher than U102-4, so U102-2 is high, and T101 is ON, so SMD100 sees a LOW.

When P1_4 floats, R100/R103 pull it to 1.65v. U102-7 is 2.235V, so -7 is higher than -6, so U102 is HIGH and T100 is OFF. U102-5 is 1.065V so -5 is less than -4, so U102-2 is LOW and T101 is OFF. Thus, SMD100 is not connected to anything.

No problems with the wiring (whew).

Yes, at high switching speeds there may be a nanosecond where they're both on (the comparators switch in under 0.7ns, and they're push-pull, so a 1-2ns rise time is enough to avoid most of the overlap). Regular CMOS IC's do this too; that's part of where the switching spikes come into play, and one reason why higher clock speeds means more power consumed.

Hmm, I probably should add a bypass cap right at the mosfets, yes?

Actually, I looked at H-bridge chips before doing my own.

Then my work is done... :)

Yes, the "wiring" looked OK to me too I was just not sure about that transition. I made a motor driver that blew itself up like this. Several times...

Wow, that's pretty fast (remember the FETs will appear to have a bigger effective gate capacitance due to the miller feedback). If they are 2N7002 type things with high on resistance I shouldn't think they will notice. But I know some of the modern FETS have on resistance measured in milliohms, and high gate capacitance that slows them down. Perhaps they will end up half-on, taking just enough current to pull down the supply to the gate threshold, till they ignite!

I don't think it will make much difference with a powerplane construction. The impedance will already be lower than that of a cap. Wouldn't do any harm though, or perhaps a small series resistance

• cap.

You're right, it was uS, not nS. Now I know why you're worried.

So... An RC filter on the GPIO pin to slow it down to match the comparator's speed?

I certainly hope you have no CO or fire issues, or ever want to sell the house. The furnace is one thing I do *not* mess with. Forgetting the above, I like warm when it's furnace season (hot showers are good even in the summer).