Products > Test Equipment
DIY scan card for Keysight 34970A
<< < (11/13) > >>
H.O:
When I got the 0x17E4 value I was reading the CJ temp via SCPI (I don't think you can do it via the front panel?).

I've done a 1 minute capture at power up and I don't see any calibration data. I've also configured a channel for T/C and as soon as you select Temperature the DAQ sends 0x1E1, 0x0FF (open all channels), then a 0x109/0x121 request/response, followed by the DAQ sending 0x169, 0x030, 0x001 which the card confirms with 0x121. After that nothing happens and I've let it sit idle for 5 minutes. A 34908A can't do TC but it's the exact same sequence when configuring a channel for temperature.

If the calibration is applied by the card CPU then surely we'd get the same displayed value for the same raw value but we don't so the calibration "must" be applied by the main CPU but there does not seem to be any transfer of that data. With the 34907A there's a lot of traffic at the configuration stage and some of it seems to be offset and gain calibration for the two DAC channels. Not so with the 34901A.

For the 34908A the 40 channels are numbered straight from 0x001 to 0x028. Commands to close/open channels are the same as for the 34901A.

EDIT: Still, that 0x169, 0x030, 0x001 is intereting, but the card just responds with 0x121. Perhaps the CJ compensation factors are lost and the FRAM has been re-initialised? But why would it try to read CJ calibration from a 34908A?
strawberry:
someone replaced with new EEPROM making card nonfunctional, if remember right
voltsandjolts:

--- Quote from: H.O on June 09, 2022, 05:59:54 pm ---I've done a 1 minute capture at power up and I don't see any calibration data.

--- End quote ---
I've just done the same. I agree, no cal data transfer there. Nor at time of reading first CJ temperature.


--- Quote ---If the calibration is applied by the card CPU then surely we'd get the same displayed value for the same raw value

--- End quote ---
Yes, and everything would make sense, just a weird scaling of values for hex to °C.
I'm going to check my result (0x17E4 == 16.464°C) again, in case I screwed up.

Do you have a couple more hex values and associated °C CJ reading from your unit?
Unfortunately I only have one 34972A here at the moment, no 34970A (there should be no difference 72/70A for this CJ stuff).
H.O:
0x13FE = 20.031°C  (low bank)
0x1404 = 19.996°C  (high bank)

Then, when repeated about two minutes later I get the EXACT same values as above. Wait another minute or two:
0x140E = 20.005°C
0x140E = 20.005°C

Yes, it actually did return the same value for both banks. Then, another couple of minutes:
0x1434 = 20.172°C
0x143E = 20.226°C

Then I warmed the card up with the heatgun:
0x477E = 77.375
0x3FA6 = 66.004

0x3AFC = 62.785
0x35EA = 55.437

0x2A80 = 43.629
0x296E = 41.805



voltsandjolts:

Edit:
We were typing at the same time,  I posted this some milliseconds after your post above :D
/Edit

OK, I found the culprit of the confusion:
When reading the CJ temperature, both bank1 and bank2 readings are sent by the card (16bits each).
But the dmm uses some kind of weighted average of the two readings, weighted toward the bank CJ you requested.
All our examples so far (of hex to °C) are null and void, because they were all influenced by what the other bank CJ reading was at the time.

By setting both CJ readings to the same value, I can see the scaling used by the dmm:
0x0000 = -7.109 °C
0x17e4 = 23.180 °C
0x7d00 = 124.289 °C
This scale is still odd, similar to the DS75 datasheet, but different ???
But that's my understanding at the moment.
You can't arrange your card to return exactly the same temperature hex for both CJ readings,....
...but my 0x17e4 reading of 23.180 is very close to what you got 23.0156 (your card must have been temperature equalised).
So, I think we are all good and we can assume the card applies the CJ calibration.


Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod