-
Decided to repost this stuff from other forum. I was used to do extreme PC overclocking years ago, using
liquid nitrogen to cool computer CPUs and graphic cards GPUs to raise clock and speed margins
It's kinda fun, and involves a lot of stuff, which is outside of usual engineering scope. If
anyone interested here is link to LN2 gear review with practical bits.
This hobby required to have good thermometers, able to measure LN2 temps (-196c) and anything in between ambient.
Choosing and buying nice subzero thermometer is always not simple task, specially if you have lack of funds.
I was a student those years, so 100$ was a big deal that time. Advanced and precise reference meters cost insane, industrial have lack of range, cheapo devices less that 100$ are total crap for subzero. But some devices are real good and sometimes affordable, like Fluke 51, 52 and newer 51 II and 52 II meters. Some of them go from ebay with mere 200-300 USD.
I got that time few semi-broken Fluke 51 II thermometers, single-input one model.
Have some possibility and ideas how to improve it by modification to more expensive models with more features.
Let me tell full story here. Excuse my english, as this guide was written originally 4 years ago, and that's not my native language
I love soldering stuff and wrecking hardware. So disassembled mine 51 II (MSRP I guess 220$) and saw that everything inside, including keyboard and main PCB is EXACT same as in most advanced 54 II (370$) version. So Fluke engineers just designed top model and then make lower-priced models by limiting features and not soldering extra passives on PCB for second thermocouple channel. Smart move, I like this way. This mean that smart folks who don't mind loosing warranty can bring full features back :yepp: Only the enclosure of meter is different (51 II have no two extra holes in plastic for second thermocouple and lacks of three buttons (two for logging features and one T1-T2 switch), they are cutted from rubber stuff which closes contacts on film keyboard). But that easily can be drilled to make use of that.
Things could go bad if Fluke flashed unique firmware, limited in cheaper meters, because there is no way to get firmware from modern meter to reflash it unless your daddy is fluke engineer boss. So I tried everything on my own risk, to see what happen. So here high-quality pics of mine 51 II PCB.
Top:
Back:
As you see, it's PCB of Fluke 50 II series, marked 5X, so it's just same for all four meters, 51, 52 , 53 and 54.
Lets dig into details and components found onboard. Big chip in center - Texas instruments ASIC, i was lucky enough to get REV 101 meter with early boards, where original marking was present. This is 16bit MSP430P337I chip, with one-time-programmable firmware from Fluke. Most of Fluke portable tools are using TI chips, so no wonder here. Used chip have 16-bit cpu core, UART and SPI links, hardware 16x16 multiplier and LCD controller. Continue, by counterclockwise from the left we found amplifier LMV321M5 in SOT23-5 for current source to LED backlight. Then power supply - two National LP2980 DC-DCs (precision %0.5, 50mA output current , output voltage +2.8V), then DC-DC using switching capacitor tech LT1044, Xtal oscillator 12.5MHz for CPU.
Heart of meter - sigma-delta ADC LTC2400, with awesome 24-bit resolution, 4ppm tol and 0.5ppm bias with 110db snr. Maximum conversion speed - 6 Hz. Cost of just this chip, without anything else - approx 20-35$ on small amounts. Near it LT1097 - low-noise high precision amplifier with 50uV offset, thermerature drift 1uC per °C, CMRR 115dB, used as thermocouple voltage amplifier. Next three big chips - analog muxes, dual 4:1. I'm using similar 4051 in my Neutron project (ATE SMPS power supply tester) and other projects, so familiar with them. 8-leg chip near them TLC3702C - comparator, looks like used for detection of open sensor input.
Thermocouple contacts are connected by springs to gold-covered pads on special board, placed to collet pins into mainboard. All contacts are covered with gold, no oxidization will pass. For precise temperature measurement it's very essential to have constant and known temperature of cold junction, where thermocouple input connected to meter. So this connector board made from pure copper 1.3mm thick with thin insulation later and parts on one side. This amount of copper slug maintain temperature of all contacts same. Such board manufacturing is expensive, more expensive than 4 layer board for example.
On component side of this copper pcb was also two chips, one of which is ATMEL 25010AN - this is 1 kilobyte memory where calibration data stored. And near it custom chip from Linear Technology, according to logo, datasheet on which I could not find yet. But as for functional idea - i'm sure it's thermal sensor, to measure cold junction temperature of connected inputs.
Before we go I remind features and specs of Fluke 50 II series thermometers
51 II features:
Single channel thermocouple input, range -250°C to +1372°C (depends on TC type)
Accuracy +- .05% of reading + 0.3°C for Type K.
Power from 3 AA batteries
Nice LCD with green (ugly) backlight
Min, max, avg feature
Type K, Type T, Type J and Type E thermocouple support.
Time stamp feature (Relative time)
52 II features:
Everything as 51 II plus extra channel and T1-T2 diff mode
53 II features
Everything as 51 II but extra:
Datalogging feature up to 500 measurements
Infrared data port for comms to PC
Compatible with optional FlukeView Software (cost extra)
Extra thermocouple support - Type R, Type S and Type N
And most advanced 54 II features:
Everything as in 53 II and plus extra channel.
So basically we need to get photo of full featured 54 II PCB and make our 51 soldered same and hope that firmware in chip is universal for all models.
But even before that I already done conversion of logic of my 51 II to 54 II. It detected now as full-featured 54 II model, two inputs all extra stuff present in 54 II. But there was missing some passives on PCB, so second channels was not operable yet. It just told -0L, mean overrange.
Every feature from 54 II appers now
Types - all present here, KJTERSN (original 51 II and 52 II have only KJTE)
Interval feature for datalogging absent in original 51 II and 52 II meters
Also changed backlight from green to white and adjusted current source for more current for leds, so now it looks much much better than original ugly green dark BL. Four white color SMD-leds with size 1206 was soldered on wires with teflon insulation placed to side of plastic lightspreader on back LCD. I don't care much about battery life, so adjusted brightness of leds but raising current a bit. This was done by adjust to feedback of amplifier LMV321M5 (chip U9) by soldering R26 from 10k to 4.7k to feed more current to leds.
Recall to back PCB shot - we have meter mode straps.
These are resistors R50, R49, R51 and R52.
I made a pic with them
This is usual strap idea as present widely in digital electronics, including GFX, mobos, etc.
The idea is pure simple - using soldered resistors as switch.
For this engineers put two resistor patterns, each with one pad tied to one input pin of CPU/GPU/controller etc.
Other pad of one resistor tied to ground, other resistor - to VCC power. If we solder resistor to ground signal
- then input to chip will be zero, meaning logical zero visible to firmware.
If we solder resistor to power pad, then we have power connected to input, thus having logical one here.
Such pairs always have only ONE resistor at time, because soldering same two resistors to both of patterns
will get us resistive divider, with half of power voltage applied to input. This is wrong for digital electronic input.
So I've spotted these resistors and get clear idea what is it, having clear powers and grounds with two inputs.
Yes, it's 2-bit code present here
Here we have 100kOhm resistor - just to minimize current flow thru pin, because our meter is battery powered and this is critical to have as small power consumption as possible. But generally exact value is not important here, just with less resistance - more current can flow. With more resistance - input pin could be less immune to noise and get wrong state by accident. So i resoldered resistor to another place and figured out all possible modes.
Table of states:
ID[1:0]
00 - Fluke 51 II mode
01 - Fluke 52 II mode
10 - Fluke 53 II mode
11 - Fluke 54 II mode
So firmware is same, and operation mode just selected on manufacturing phase, by soldering resistors on proper place. Cool!
To this time slamms provided me photo of his 54 II, so I continue.
So this is what placed on 54 II as for logging features
I had no AT25320 chips that time, but we have SPI flash on any videocard Googled a bit of datasheets, and get idea, that they are same pinouts, little different in command protocol. So....
Soldered Videobios from GeForce 7900GTX to my fluke 51-2 @ 54-2, added debug wires to USB-UART bridge, and tested link with PC
Some junk from bios chip read by fluke lol notice 6K+ memory cell number. Native Fluke 54 support only 500 
I drilled plastic case of meter and instert round rubber spacers for extra keys, as you see on photo. Need better rubber blocks to make "native-look" buttons
Terminal software from USB-UART bridge chip between fluke and my ws got data with 9600 8N1 port settings.
So now time to add second channel. Knowing already that Q1, Q3, Q2 and Q4 on top was MOSFETs in SOT-89 package i found datasheet on original DN2540 ones. These are depletion mode mosfets, in contra to wide-used enhanched mode mosfets found everywhere on motherboards and gfx. Difference was that these fets closed with negative gate voltage, not zero. I reverse engineered schematic of this part:
Simulated it with SPICE modeling, got nothing but voltage follower here. Correct me if I'm wrong
Looks like they used as buffers here, to isolate channels when they are not needed to avoid errors in readout.
I didnt found original fets where to buy, so decided to go with another depletion-mode mosfets with smaller SOT-23-3 package. They are BSS139.
So back to soldering now.
To solder SOT23-3 on SOT-89 pattern i used piece of wire to connect dummy collector pad to central pad.
So after 10 min i did my homework like this:
Get notice C4 cap on right - it's tantalum capacitor, beware right polarity (marked line is positive here). 2.2uF 6V or so fit nicely in SMA package.
R8 and R10 are just similar as R7 and R9, 500kohm 1206 resistors with 5% tol.
R4, R5, R6 and R17 are gate resistors, all 100kohm 1206 with 5% tol.
R11 and R12 are 1% resistors for thermocouple input, 11.3kohm and 499 ohm. Take care to make them best tolerance possible.
And most important part here - Capacitors C23 and C20. There affect precision and channel crosstalk very significant, I found best results with 1nF 0805 and 1206 5% capacitors. My bad I could not find NP0 capacitors now , but original fluke ones (C22 C21 eg.) are NP0. NP0 dielectric type have zero temperature drift and much more precise as in term of capacity to more cheapo X7R type. NP0's usually much more grayish and ligher color as for appearence.
This additions to board let me use second channel nicely.
Later I tried just shoring drain and source pads on Q1, Q2 Q3 and Q4 patterns, without soldering gate resistors and transistors - second channel worked this way too!.
Here's sketchy LED backlight with white 1206 SMD leds hanging on wires.
For graphing Fluke have FlukeView Forms 3.5 application, i found it on web before.
Pretty sure, i have it somewhere on my storage, if anyone need it.
Testing datalogging.
CPU: Intel Celeron 356 at 6.5GHz with 1.92Vcc
Meter: Fluke 51 II modded, with two termocouples attached
T1 probe: mounted on edge of CPU IHS with grease and fixed tight by socket retention bracket.
T2 probe: mounted in copper container basement hole with grease
Logging interval betweek samples: 5 sec (can be any time down to 1sec).
LN2 pours at 5.41, 5.42, small pours till 5.50, then i meter off
then again log data from -190C.
Another 5-min graph, ambient temp outside of balcony. It was winter
-----
Also I did not like much spring type connectors on my fluke's, so modified one to
terminal blocks
But of course accuracy went little bit off, as therminal blocks heavy and add thermal gradients
Hope you enjoy reading -
Hope you enjoy reading
I saw your original conversion a while back and it is quite impressive. Thanks for taking the time to document and share it. -
I've just found a 52-II at a moderate price and I will probably try to convert it to 54-II if I can do that with a good looking (need to add 2 keys). I will add photos, and thanks for this post !
-
Thanks. I will try to do this mod on my F52 to have a 54. Changing conf without spi ram installed seems to prevent start-up. If it works, I will try serial connection with wires, and then solder missing IrDa components. As keyboard is complete (only the upper side is missing), it is possible to do modification with a good looking.
And as you told, the green backlight is...dark ! I don't know if actual models have same backligth, but it's unusable an incredible for that price (if new). -
It works !
The Fluke 52 is now a fluke 54.
Serial interface is made with FTDI230X usb adapter. Now, next step is to install the IrDa circuits, and replace the ugly backlight.
-
I've found ref of IrDa transceiver to sold on top of board (first photo) : HSDL-3201-001 (or 021) available from DigiKey. Other ref (Vishay for example, but not only) have different pinout, as if it was reversed.
This post doesn't seems to concern many people, but thanks for it, it was not useless !
Sorry for my english, I do my best... -
I have found this tutorial on multiple sites now and finally on one I post to! First let me say excellent work on figuring this out! I was going to do this mod myself but I found out before I did what Fluke changed with the new "B" update to the 51-54 II series digital thermometers. It seems they changed something in the IR to USB cable used to get the logged data out of the unit and onto the PC. Apparently there are two REV versions (1 and 2) of the Fluke USB FlukeView cable and the newer B series only works with the REV 2 of the USB cable. For me that was a big deal as I had already purchased the REV 2 IR to USB cable as that one is required to get data off of my Fluke 289 DMM. So in the end I just ended up buying a Fluke 54 II B and went about my business. But I am glad you took the time to post all this info around the net! Thank you!
-
I've soldered TIR1000 and HSDL-3201-001 (with 1uF near it) in Fluke, and made an IrDa/USB interface with another TIR1000 and HSDL-3201. As baudrate is 9600, we must generate 9600 x 16 = 153600 Hz clock for the TIR1000. I've made this clock with a small PIC10LF322, and I have a real clock between 153600 and 153800 Hz, the error is lower than 0.15% which is quite nice for the UART TIR1000. The processeur is unable to do something else when generating this frequency !
Then, the FlukeView software find the Fluke thermometer, can reset memory, synchronize date, but is unable to read memory, indicating memory empty
I've searched and found that all characters sent from USB to IrDa were received back by the IrDa transceiver, whatever was done on the transceiver to separate TX from RX on IR. And not disturbing for short requests. But during reading memory, when themometer was responding, there was collisions (if there are enough data) due to regular query from USB to verify if equipment is present (why ?), giving framing error on characters sent to USB at this moment.
So, I've used a second PIC10LF322 to prevent collisions and ensuring correct half duplex. Software is easy to do, a small arbiter gives priority to the first talking for a sufficient time, and data is copied from one side to other side only if allowed by the arbiter.
All could be done by a bigger processor or with other circuits, there are many solutions.
Now, all is fine !!!
-
I knew I read about it before
http://hackaday.com/2011/09/10/adding-fluke-54-ii-features-to-a-51-ii-thermometer/
Who is this guy TiN
-
As somebody asked me, here is part of schematic used to do an USB to IrDa converter working with FlukeView.
Signals TXD_FTDI and RXD_FTDI are routed to a FT230X, ore any equivalent circuit or MAX3232 (not tested) for RS232 / IrDa converter.
I used 2 processors because 1 was already on my board supporting the FT230X, and I've seen the need to prevent collisions while debuging. They are easy to connect in the SOT23-6 package. Of course, a single processor could be used, if you take care to guarantee a regular 16XCLK. The upper processor is used to generate the 16XCLK (153600Hz). Be sure that generated clock is correct, and compiler can give other result, as this is not the hex file ! The lower is used to prevent RX/TX collisions (see previous response)
As code was modified from another application, some lines are probably useless, or only for debug. An better writing is always possible.
Code for Half/Duplex processor
#define _LEGACY_HEADERS;
#define __PICC_
#include <htc.h>
__CONFIG (MCLRE_OFF & LVP_OFF & WDTE_OFF & CP_ON & FOSC_INTOSC); // LVP_OFF indispensable pour utiliser l'entrée 3 !!!
// Two bits bUser0 and bUser1 in system variable OS_Flags can be used for user purposes.
/****************************************************************************/
/****************************************************************************/
/****************************************************************************/
// GP0 : entree pour RX IrDa
// GP1 : sortie vers TX IrDa
// GP2 : sortie vers RX FTDI
// GP3 : entree vers TX FTDI
/****************************************************************************/
/* */
/****************************************************************************/
#define VAL_TEMPO 5
void main (void)
{
OSCCONbits.IRCF2 = 1; // oscillateur 16MHz
OSCCONbits.IRCF1 = 1;
OSCCONbits.IRCF0 = 1;
// Configuration des IO
// Validation des pullups
OPTION_REGbits.nWPUEN = 0; // Autorisation pullup
// Pas de pullup
WPUAbits.WPUA0 = 0;
WPUAbits.WPUA1 = 0;
WPUAbits.WPUA2 = 0;
WPUAbits.WPUA3 = 0;
// IO en numérique
ANSELA = 0;
// Dans le fichier pic10f322.h, il manque la définition des bits chemin : C:\Program Files\HI-TECH Software\PICC\9.83\include
TRISA = 0b1001; // GPIO1 et GPIO2 en sortie
unsigned char sens = 0; // 0 libre, 1 IrDa vers USB, 2 usb vers IrDa
unsigned char tempo = 0;
while(1) // ------------------------------------------------ BOUCLE GENERALE DE L'APPLICATION--------------------------
{
switch ( sens )
{
case 0 :
// Signal sur IrDa
if ( PORTA0 == 0 )
sens = 1;
// Signal sur USB
else if ( PORTA3 == 0 )
sens = 2;
else
// Sortie vers IrDa
LATA2 = 1;
// Sortie vers USB
LATA1 = 1;
break;
case 1 :
// Recopie RX venant de l'IrDa
LATA2 = PORTA0;
if ( PORTA0 == 0 )
// Initialisation temporisation
tempo = VAL_TEMPO;
else if ( tempo )
tempo--;
else
{
sens = 0;
LATA2 = 1;
}
break;
case 2 :
// Recopie TX venant de l'USB
LATA1 = PORTA3;
if ( PORTA3 == 0 )
// Initialisation temporisation
tempo = VAL_TEMPO;
else if ( tempo )
tempo--;
else
{
sens = 0;
LATA1 = 1;
}
break;
default :
sens = 0;
break;
}
}
}
Code for clock
#define _LEGACY_HEADERS;
#define __PICC_
#include <htc.h>
__CONFIG (MCLRE_OFF & LVP_OFF & WDTE_OFF & CP_ON & FOSC_INTOSC); // LVP_OFF indispensable pour utiliser l'entrée 3 !!!
// Two bits bUser0 and bUser1 in system variable OS_Flags can be used for user purposes.
/****************************************************************************/
/****************************************************************************/
/****************************************************************************/
// GP2 : sortie frequence
/****************************************************************************/
/* */
/****************************************************************************/
void main (void)
{
OSCCONbits.IRCF2 = 1; // oscillateur 16MHz
OSCCONbits.IRCF1 = 1;
OSCCONbits.IRCF0 = 1;
// Configuration des IO
// Validation des pullups
OPTION_REGbits.nWPUEN = 0; // Autorisation pullup
WPUAbits.WPUA0 = 1; // Pull-up
WPUAbits.WPUA1 = 1; // Pull-up
WPUAbits.WPUA2 = 0;
WPUAbits.WPUA3 = 0;
// IO en numérique
ANSELA = 0;
// Dans le fichier pic10f322.h, il manque la définition des bits chemin : C:\Program Files\HI-TECH Software\PICC\9.83\include
TRISA = 0b1011; // GPIO2 en sortie
unsigned char out;
// Cette boucle donne environ 153.75 kHz pour une cible à 153.60 kHz, soit 0.1% d'erreur !
while(1) // ------------------------------------------------ BOUCLE GENERALE DE L'APPLICATION--------------------------
{
if ( OSCCONbits.HFIOFS ) // Horloge stabilisee, en fait juste pour faire un test et trouver la bonne frequence
{
out += 1;
LATA2 = out;
LATA1 = out; // juste pour retarder sans que l'optimisation supprime l'instruction
}
}
}
-
I've soldered TIR1000 and HSDL-3201-001 (with 1uF near it) in Fluke, and made an IrDa/USB interface with another TIR1000 and HSDL-3201. As baudrate is 9600, we must generate 9600 x 16 = 153600 Hz clock for the TIR1000. I've made this clock with a small PIC10LF322, and I have a real clock between 153600 and 153800 Hz, the error is lower than 0.15% which is quite nice for the UART TIR1000. The processeur is unable to do something else when generating this frequency !
Then, the FlukeView software find the Fluke thermometer, can reset memory, synchronize date, but is unable to read memory, indicating memory empty
I've searched and found that all characters sent from USB to IrDa were received back by the IrDa transceiver, whatever was done on the transceiver to separate TX from RX on IR. And not disturbing for short requests. But during reading memory, when themometer was responding, there was collisions (if there are enough data) due to regular query from USB to verify if equipment is present (why ?), giving framing error on characters sent to USB at this moment.
So, I've used a second PIC10LF322 to prevent collisions and ensuring correct half duplex. Software is easy to do, a small arbiter gives priority to the first talking for a sufficient time, and data is copied from one side to other side only if allowed by the arbiter.
All could be done by a bigger processor or with other circuits, there are many solutions.
Now, all is fine !!!
I am having the same problem.
But I had not solder the TIR1000 on the board. I add a bluetooth module on it.
Now, I can reset memory, synchronize date in flukeview, but unable to read memory from the meter.
How to prevent collisions when bluetooth module is used ?
Please advice,
Thanks
===========
Update:
MSP430P337I datasheet attached.
-
Hm, that is neat idea. Let me try adding BT module and test that out! If only I can find time
-
TiN,
how did you make this excellent photos in first post (2014), what lighting equipment used by you?
Georg -
Hi Georg,
Simple LED flashlight and long exposure was used, just like with 99% of any other photos I post.
Perhaps you will find details in my new article, how to take photos of hardware more interesting. -
The PCB has changed.
Fluke 51-II pcb (top)
The EEPROM (U11, AT25640N) used for logging has been replaced. The IR-UART bridge (U12, TIR1000) has been replaced with transistors Q7, Q8 and a sprinkling of resistors (level shifters?). Test point J2 and J3 has been added. The analog network around the thermocouple connectors seems unchanged.
This means you still can add a second port, but you can no longer add logging and connecting to a PC.
Unless, of course, we find out what the new components are. Does anyone have a picture of a 53-II or 54-II with the above pcb? Thanks.
-
I know this thread has been dormant for a while, but I may be able to help with a few requests for information. I have both a fluke 54-II hardware revision 1.5 (latest version from what I can tell). Anyone still interested in a photo of the PCB? Also I have some info on interfacing with these meters without Fluke's software if anyone wants it.
-
Sure we are interested. Did you manage to get continuous logging, or data interface still only can use to read out meter's memory and not the realtime sensors?
-
Sorry about the delay. Here are some pics of the Fluke54-II PCB version 1.5. I notice that there's a "2012" etched towards the bottom-right. I will post info on the remote-specs soon. I can programatically access all functions that Fluke's own software can (flukeview forms). Unfortunately this method pulls all data from the fluke's internal memory. Further hacking would be needed to get real-time access to thermocouple data. This makes sense as the IR cable fits over where the thermocouples are plugged in; i.e. no-one expected to use the meter for real-time logging.
-
More PCB pics of the 54-II (2/3)
-
Final pic of 54-II pcb (3/3)
-
Ok. Here are the specs to talk to the meter... (1/2)
9600 Baud, parity: none, 8 bits, 1 stop bit.
Command responses:
0\r [30 0D] - command accepted
1\r [31 0D] - command not recognized
5\r [35 0D] - no data available in meter memory (after sending 'QD 1' command)
DS - Power cycles meter (won't go back to IR mode until toggled by user).
ID - Gives model number and software version in plain text.
Should respond something like: "FLUKE 54-II, V1.5"
RI - Resets the meter to factory specs **except** calibration values (clears internal memory, clears clock).
CD - Clear data (does the same as the Clear Memory function on meter).
QD 0 - queries the meter setup data. Returns binary data.
Binary data structure: <8 bit clock is set?><32 bit time><16 bits records in memory>
Bytes:
0 - record count byte 0
1 - record count byte 1 (record count int between 0 and 500; byte 0 + byte 1)
2 - time byte 0
3 - time byte 1
4 - time byte 2
5 - time byte 3
6 - clock set byte (0x00 = not set, 0x01 = set)
Time = number of seconds since 00:00 + (days since memory last cleared * 86400 seconds/day)
ST - Sets the time.
Example:
send - "st HHMMSS" to set time to HH hours, MM minutes, and SS seconds -
How to retrieve the actual data stored in the memory: (2/2)
QD 1 - qeries the data stored in the meter internal memory. Returns binary data.
Data are returned in 64 bit packets - either containing data or metadata (init packet). Every batch of measurements logged to the device creates an init packet (If I log 10 measurements then 2, I would expect 2 init packets and 12 data packets). Note: there is only enough memory to store 499 total 64 bit packets regardless of type (every set of measurements uses n+1 packets).
Init packet byte structure:
<1 bit Packet type (always 1 for init packet)><2 bits units><5 bits><8 bits TC type><1 bit><1 bit interval unit><13 bits interval int><16 bits offset 1><16 bits offset 2>
Bytes:
0 - Calibration offset integer for probe 2, byte 0
1 - Calibration offset integer for probe 2, byte 1
2 - Calibration offset integer for probe 1, byte 0
3 - Calibration offset integer for probe 1, byte 1
4 - Interval, byte 0
5 - Interval, byte 1
6 - Thermocouple type (ASCII char)
7 - Units (also packet type)
Calibration offset:
If units are F -
F = (<Cal Offset> / (10 * 1.5))
If units are C or K -
C / K = ((<Cal Offset> / (10 * 1.5)) * (9/5))
Interval:
The lower 13 bits of the interval bytes are an integer. The 14th bit (mask with 0x2000) is 0 if the interval units is set to seconds, 1 if set to minutes.
Units:
Two bits of the last byte sent (mask with 0x60).
00 = C
01 = F
10 = K
Data packet byte structure:
<1 bit packet type (always 0 for data packet)><31 bits time><16 bits T1 temp><16 bits T2 temp>
Bytes:
0 - Thermocouple probe 2 temperature int byte 0
1 - Thermocouple probe 2 temperature int byte 1
2 - Thermocouple probe 1 temperature int byte 0
3 - Thermocouple probe 1 temperature int byte 1
4 - Time int byte 0
5 - Time int byte 1
6 - Time int byte 2
7 - Time int byte 3 (also packet type)
Converting from Fluke's arbitrary units to real temps:
If units are F -
F = (<Fluke Temp> / (10 * 1.5)) - 459.67
If units are C -
C = ((<Fluke Temp> / (10 * 1.5)) * (5/9)) - 273.1
If units are K -
K = ((<Fluke Temp> / (10 * 1.5)) * (5/9))
Time int:
number of seconds since 00:00 + (days since memory last cleared * 86400 seconds/day)
(same as "QD 0" response) -
Just bought one of these from a local CashConverter. It's a 54-II, but was in pretty bad shape. (Missing rear battery cover missing, small cracks in case etc. I manage to get a good deal, but one of the channels (T1) was not working when I plugged a therocouple in. T2 was working, but would like both to be working well.
I took apart, and checked all the obvious. Turned out that one of the little wires from the thermocouple board to the main board was 'loose', i.e. the solder had become deteched or loose. It 'buzzed' out with a meter OK before and after resoldering. Assembled meter and it worked fine. Seems that the small resistance that can be present from a loose or poor connection and affect these meters.
Just thought I'd leave this as hope to others with similar meters, some thing to check as I have head a few of these with one channel not working properly.
I'm gonna try and find a battery cover now! -
I'm not sure if I have an extra battery cover or not. I will check and then say something to you.
EDIT: I was checking and only have the back cover were the batteries contacts are.