T
Terran Melconian
- Jan 1, 1970
- 0
Two of Fluke's models of multimeters, the 187 and 189, include serial
communications to transmit data to a computer. Partial information
about the protocol used can be found here, among other places:
http://www.cfa.harvard.edu/~thunter/manufacturers.html
However, the parts of the protocol documented by Fluke do not include
any ability to fetch from the 189 the saved logs. I wrote to Fluke
requesting additional information, but they could not provide it.
Thus, using the hint from the above web page that "QD 0" and "QD 2" were
two of the commands of interest, I have spent some time revere
engineering the protocol through extensive testing. The former provides
information on the immediate reading, and may not be worth using unless
you need information from the secondary display as well, as it is more
work to decode than "QM", which provides similar information. The
latter, however, is the only way of which I am aware to retrieve the
logs.
The understanding presented below is incomplete. In particular, it does
not address how to decode the information saying what mode the meter was
set on. Also, there are a couple of other commands I have not
investigated at all; since the documention mentions that the
Fluke-supplied software (which I did not buy, as I do not have a Windows
machine available anyway) can change settings like the logging interval
on the meter, one or more of them presumably pertains to those
operations. However, the understanding I now have is entirely adequate
for my purposes (the downloading of logs), and I do not expect to work
on it much more in the near future. I am therefore presenting it here
in the hopes that it will save someone else the time of undertaking the
same work, and that perhaps someone else will see fit to fill in the
holes.
One might say "Shame on Fluke" for not providing it in the first place,
and I could not argue, but sadly the fact that they were willing to
provide any information whatsoever, however incomplete, makes them more
helpful than some other companies I have tried to work with.
If you have any comments, reply here or email me (but note you will have
to demunge the address to do the latter)
=========================================================================
Fluke 189 protocol undocumented commands. See here for the documented
part and for the notes on the names of the other commands, which got me
started:
http://www.cfa.harvard.edu/~thunter/manufacturers.html
More information, maybe, if I've had time to write anything by the time
you read this, at http://www.consistent.org/fluke-189/
QD 0 response:
You transmit "QD 0\r". Fixed string of "0\rQD,", five bytes. All
locations will be taken AFTER this.
Location Bytes Meaning
0 4 Time stamp in units of 0.1s
4 4 Primary display value.
8 1 # places to shift decimal point in primary value
9 1 Units. -1 for milli, 1 for kilo, etc.
10 4 Secondary reading.
14 1 # places to shift decimal point in secondary value
15 1 Units as above.
16 4 Tertiary reading.
20 4 Repeat of timestamp
24 4 Repeat of primary reading
28 1 Repeat of primary scale
29 1 Repeat of primary unknown
30 12 Function unknown. Presumably knob setting, etc.
All numerical values are little-endian.
Values with 0x70 in the high byte indicate that the value is not in use
or that there is some kind of error. The low byte indicates what kind.
0x01 is for unused; other values indicate overflow, missing leads, etc.
Otherwise they are 2s complement numbers.
Units indicate the prefix. -3 is nano, -2 is micro, -1 is milli,
1 is kilo, 2 is mega, etc.
The only use I have ever seen for the tertiary reading is the log #
when in logging mode.
QD 2 response:
If there ARE NO logs, response of "5\r". Otherwise, fixed string of
"0\rQD,", five bytes. All locations will be taken AFTER this.
There is then an 18-byte header, which appears only once at the
beginning. I know little about it, but presumably it includes
information about the knob setting, etc.
Location Bytes Meaning
0 2 ?
2 4 Initial value
6 1 Decimal point location for initial value
7 1 Units, as in other places
8 2 Setting information, corresponding to QD0 bytes 30,31
10 2 ?, always 0x0258 that I can see
12 1 Mode information, corresponding to QD0 "mode"
13 5 ?, more unknown setting information as in QD0
The information about the setting is only partially understood.
Then there are 32 bytes of repeating information:
Location Bytes Meaning
0 4 Beginning timestamp for entry in units of 0.1s
4 1 Decimal point location
5 1 Units. -1 for milli, 1 for kilo, etc.
6 4 Minimum value for this time period
10 4 Maximum value for this time period
14 4 Actual value, sum of N
18 4 ?, always all 0 in my tests
22 4 Number of values which were summed
26 1 Status - 0x05 for normal, 0x85 for last entry, other
values for range changes or other oddities
27 1 ? - always 0x01 in my tests
28 4 Ending timestamp for this entry
Generally, the readings are taken equally distributed over the time
period, so the value will be an average. However, in cases of significant
changes part way through, I have seen the meter use some heuristic to
split it into separate entries sooner than the specified time period to
capture this. In the case of a sharp voltage increase, I saw the first
part (low value) have status 0x04, the short middle one with the fast
increase had 0x08, and the final one had 0x05. The value displayed on the
meter matched what I got by summing the actual values from the three and
then dividing that by the sum of the number of readings from the three.
communications to transmit data to a computer. Partial information
about the protocol used can be found here, among other places:
http://www.cfa.harvard.edu/~thunter/manufacturers.html
However, the parts of the protocol documented by Fluke do not include
any ability to fetch from the 189 the saved logs. I wrote to Fluke
requesting additional information, but they could not provide it.
Thus, using the hint from the above web page that "QD 0" and "QD 2" were
two of the commands of interest, I have spent some time revere
engineering the protocol through extensive testing. The former provides
information on the immediate reading, and may not be worth using unless
you need information from the secondary display as well, as it is more
work to decode than "QM", which provides similar information. The
latter, however, is the only way of which I am aware to retrieve the
logs.
The understanding presented below is incomplete. In particular, it does
not address how to decode the information saying what mode the meter was
set on. Also, there are a couple of other commands I have not
investigated at all; since the documention mentions that the
Fluke-supplied software (which I did not buy, as I do not have a Windows
machine available anyway) can change settings like the logging interval
on the meter, one or more of them presumably pertains to those
operations. However, the understanding I now have is entirely adequate
for my purposes (the downloading of logs), and I do not expect to work
on it much more in the near future. I am therefore presenting it here
in the hopes that it will save someone else the time of undertaking the
same work, and that perhaps someone else will see fit to fill in the
holes.
One might say "Shame on Fluke" for not providing it in the first place,
and I could not argue, but sadly the fact that they were willing to
provide any information whatsoever, however incomplete, makes them more
helpful than some other companies I have tried to work with.
If you have any comments, reply here or email me (but note you will have
to demunge the address to do the latter)
=========================================================================
Fluke 189 protocol undocumented commands. See here for the documented
part and for the notes on the names of the other commands, which got me
started:
http://www.cfa.harvard.edu/~thunter/manufacturers.html
More information, maybe, if I've had time to write anything by the time
you read this, at http://www.consistent.org/fluke-189/
QD 0 response:
You transmit "QD 0\r". Fixed string of "0\rQD,", five bytes. All
locations will be taken AFTER this.
Location Bytes Meaning
0 4 Time stamp in units of 0.1s
4 4 Primary display value.
8 1 # places to shift decimal point in primary value
9 1 Units. -1 for milli, 1 for kilo, etc.
10 4 Secondary reading.
14 1 # places to shift decimal point in secondary value
15 1 Units as above.
16 4 Tertiary reading.
20 4 Repeat of timestamp
24 4 Repeat of primary reading
28 1 Repeat of primary scale
29 1 Repeat of primary unknown
30 12 Function unknown. Presumably knob setting, etc.
All numerical values are little-endian.
Values with 0x70 in the high byte indicate that the value is not in use
or that there is some kind of error. The low byte indicates what kind.
0x01 is for unused; other values indicate overflow, missing leads, etc.
Otherwise they are 2s complement numbers.
Units indicate the prefix. -3 is nano, -2 is micro, -1 is milli,
1 is kilo, 2 is mega, etc.
The only use I have ever seen for the tertiary reading is the log #
when in logging mode.
QD 2 response:
If there ARE NO logs, response of "5\r". Otherwise, fixed string of
"0\rQD,", five bytes. All locations will be taken AFTER this.
There is then an 18-byte header, which appears only once at the
beginning. I know little about it, but presumably it includes
information about the knob setting, etc.
Location Bytes Meaning
0 2 ?
2 4 Initial value
6 1 Decimal point location for initial value
7 1 Units, as in other places
8 2 Setting information, corresponding to QD0 bytes 30,31
10 2 ?, always 0x0258 that I can see
12 1 Mode information, corresponding to QD0 "mode"
13 5 ?, more unknown setting information as in QD0
The information about the setting is only partially understood.
Then there are 32 bytes of repeating information:
Location Bytes Meaning
0 4 Beginning timestamp for entry in units of 0.1s
4 1 Decimal point location
5 1 Units. -1 for milli, 1 for kilo, etc.
6 4 Minimum value for this time period
10 4 Maximum value for this time period
14 4 Actual value, sum of N
18 4 ?, always all 0 in my tests
22 4 Number of values which were summed
26 1 Status - 0x05 for normal, 0x85 for last entry, other
values for range changes or other oddities
27 1 ? - always 0x01 in my tests
28 4 Ending timestamp for this entry
Generally, the readings are taken equally distributed over the time
period, so the value will be an average. However, in cases of significant
changes part way through, I have seen the meter use some heuristic to
split it into separate entries sooner than the specified time period to
capture this. In the case of a sharp voltage increase, I saw the first
part (low value) have status 0x04, the short middle one with the fast
increase had 0x08, and the final one had 0x05. The value displayed on the
meter matched what I got by summing the actual values from the three and
then dividing that by the sum of the number of readings from the three.
