AndrewPartridge wrote:Before I get too far into the design, I need to have requirements firmly established.

For me, I have a multi thermocouple input datalogger that handles BT, ET and time. It displays on the datalogger can save or can transfer live to my computer. Post roast I can see the rate changes with these inputs if I need to analyze. The rate meter helps me most during the roast. As the info. allows me to make quick changes without doing any calculations first. I assume this could be done with a computer hooked up live but I prefer to keep things simple and not have a computer in my roasting environment and with the rate meter makes this possible. I don't see any need for an alarm to say let me know if the roast has stalled or say has accelerated past my determined range. Keeping it simple and affordable seems better.
The only other issue is having to now use 2 BT thermocouples grouped together. One going to the datalogger and one to the meter. If the option to have only one BT thermocouple that could feed into the rate meter that then could also split to the other datalogger somehow.
For others with PIDs in their system I'm not sure what their wants might be.

farmroast wrote:The only other issue is having to now use 2 BT thermocouples grouped together. One going to the datalogger and one to the meter. If the option to have only one BT thermocouple that could feed into the rate meter that then could also split to the other datalogger somehow.

Ed -

Splitting the "feed" from the thermocouple can be done (I have mine set up that way now). As long as the input impedance (i.e. resistance) of both measuring devices (the rate meter and the digital thermometer) is fairly large, there is little loss in accuracy.

My setup works fine with one leg of the t/c feed going into the rate meter, and the other leg going into a PID controller. The input impedance on the rate meter is very, very high, so should not skew the readings on a second device reading the same signal.

Jim

I confirm what Jim has found, that a single thermocouple can be shared. This isn't true of any other kind of temperature sensor that I know of - just happens that thermocouples generate a voltage and a thermocouple input simply measures that voltage and presents a very high impedance to it. I can't imagine the MAX6675 will be any different.

So, are we decided on just one thermocouple input to the rate meter?

I'm happy to not bother with alarms and timers if you already have other equipment for that - those can always be added in later versions of the firmware anyway, if there is a call for them.

Cheers,

Andrew

Jim
What is the best way to take what I have and do the split?

Ed -

Probably your best bet is to build a splitter like that shown below. It might be better for you to switch all of the genders, though. I use extension cables, so this configuration works OK for me.

I'm thinking that you would want a female jack on the stem and two male plugs on the branches. Plug the sensor into the female jack, then the two male plugs go into your thermometer and your 80TK, respectively.

I don't know how much input impedance the 80TK offers. If you notice a change on instrument 2 when you plug in instrument 1, then splitting the signal won't be effective. But I'm guessing you will see little or no change when plugged to both instruments.

The wire must all be type K, and stranded would be better for this application.

Jim

Thanks Jim
I happen to have the parts on hand.
Ed

For those who want an analog solution, here are links to version 3 of the rise meter. This version accepts type K thermocouple input directly, so does not require the Fluke 80TK. It outputs 1mV per *F rise per minute.

Schematic: click here for PDF.

Board: click here for PDF.

This circuit has been breadboarded and works better on my Hottop than any previous versions. I've added a bunch of filtering. This has tamed the jumpy output quite a bit, but the derivative of a noisy t/c signal is anything but smooth.

I've uploaded the PCB to BatchPCB.com, but haven't ordered one yet. Price from BatchPCB is $15.37 per board (PCB only, no components), plus $10 setup per order. In the next week or so, I will probably order a board, and would be glad for anyone who wants to piggyback on my order.

Jim

Link to BatchPCB is here.

You can probably get away with using ordinary wire to make the splitter if the temperature is going to be uniform over the short distance that it will span.

From the Wikipedia article on thermocouples:

Law of intermediate materials
The algebraic sum of the thermoelectric forces in a circuit composed of any number of dissimilar materials is zero if all of the junctions are at a uniform temperature. So If a third metal is inserted in either wire and if the two new junctions are at the same temperature, there will be no net voltage generated by the new metal.

JimG wrote:I've uploaded the PCB to BatchPCB.com, but haven't ordered one yet. Price from BatchPCB is $15.37 per board (PCB only, no components), plus $10 setup per order. In the next week or so, I will probably order a board, and would be glad for anyone who wants to piggyback on my order.

Jim

Link to BatchPCB is here.

I would like a board

Randy

Jim,

regarding the jumpiness of thermocouple signals: could you email me a spreadsheet (or any other format file) with a series of raw time and temperature reading pairs from one of your roasts? - I want to be sure that the algorithm I plan to use to smooth the thermocouple readings will work properly on real life data. Thanks.

We can probably be quite sophisticated in the smoothing.

My current design, using a silicon temperature sensor, only looks at the temperature readings at the beginning and end of the averaging period (this is for faster rates - for slow moving environmental rates I use a different algorithm). Any noise in the temperature sensor output is effectively smoothed over the averaging period, but there is very little noise from a silicon sensor anyway (actually, if I could inject a little bit of dithering noise into the DS18B20's analogue section, I would, because it would help with the slow rate measurements).

But if the thermocouple signal is very noisy we could end up with a situation where we need such a long averaging period to smooth out the jumpiness that the very changes we are interested in get lost. To get around this we can take readings very frequently - the MAX6675 can do a conversion in 220ms - and estimate the real temperature at the beginning and end of the averaging period by using a number of samples for each of the beginning and end readings, discarding the outliers and averaging the rest. The number of samples to use depends on the spectrum of the noise, the sampling rate, and the desired averaging period.

Cheers,

Andrew