| Electronics > Repair |
| HP 3478A: How to read/write cal SRAM |
| << < (15/41) > >> |
| relmes:
--- Quote from: xbb on April 25, 2018, 11:31:24 pm ---Thanks for your script, I tested it with an Arduino and while the output looks ok, the checksum verification with fenugrec's tool fails. There are some more characters which require escaping (LF 10, Forward Slash 47 in my case), so I tried to just escape every character and the output now validates fine. However you need also to remove or comment out the line 232 from GPIB6.1.ino which prints "CR or LF inserted" when you escape the CR/NL chars --- End quote --- You are right. It needs to escape some other chars as well as GPOB6.1.ino processes a few chars specially. (Namely , ESC, LF, CR and +). You're method of just escaping all is a great idea. Thank you - if I can I'll edit my original post to highlight the issue. For completeness this is the patch for the GPIB6.1.ino file (swapping which goto loadchar line is commented - it needs to call loadchar just not print back to the serial): --- Code: ------ GPIB6.1.ino +++ GPIB6.1.new.ino @@ -226,8 +226,8 @@ case CR: case NL: - // if (isesc) goto loadchar; - if (isesc) { Serial.println("CR or LF inserted");goto loadchar; } + if (isesc) goto loadchar; + //if (isesc) { Serial.println("CR or LF inserted");goto loadchar; } *comp = NULL; // replace USBeos with null if (gotplus == 2) { // got a "++" at the beginnig: its a command! --- End code --- |
| sundance:
Any new insights on how the calibration SRAM data is encoded? (esp. the gain part) |
| fenugrec:
Just found something hidden in plain sight : the HP Journal, 1983-02 issue, has an article about the 3478A, which is presented as the "HP-IB version of the 3468". They mention a few things about cal : - offset is applied to raw ADC reading, *then* gain factor is applied. Makes sense since the calibration process makes you short/zero the reading first, then test full-scale. - They also say this about the checksums: --- Quote ---[...] the two constants for each function and range have parity bits associated with them so that the 3468A's microprocessor can locate single-bit errors and detect double-bit errs. The processor can correct a single-bit error in a cal constant and the instrument will remain calibrated. If the processor detects more than a single-bit error, the CAL annun is displayed and the error bits are set [...] --- End quote --- Interesting, but I wonder if at some point they removed parity-correction; either that or it's pretty well hidden in the disasm... |
| Miti:
I wonder what's the meter showing during calibration. Is it showing the raw numbers? If yes, maybe it's worth calibrating a range, 3V DC range for example, now that we know which is which, and see how the raw numbers correlate with the calibration constant. |
| fenugrec:
--- Quote from: Miti on November 14, 2018, 08:33:10 pm ---see how the raw numbers correlate with the calibration constant. --- End quote --- That won't be necessary ! Just finished figuring out the gain constants, with the help of partial MAME emulation. My cal dumper produces output like this for each range : --- Code: ---entry # offset gain? range 00 000368 3EDC5 30 mV DC --- End code --- The offset is BCD, we knew this. I thought the gain was an actual hex value, but not quite - it's a weird mix of signed hex digits and decimal scaling (...) I'll try to explain. 1) ADC gives a raw, 8-digit packed BCD reading (4 bytes). (ex.: 1021520, 1 021 520). This is sign-extended into 5 bytes. I'm not sure the lowest digit is significant or always 0. 2) Add offset : pregain = ADC + cal_offset * 10 == ADC + 3680 == 1 025 200 2.5) not sure exactly why , but it seems we add 50 here. Maybe for rounding ? 1 025 250 3) then we need the gain factor "gain_const". In the cal dump, it's printed as "3EDC5" and must be interpreted this way : --- Code: --- get digit_n as hex; if digit_n > 8, then factor_n = digit_n - 16 gain_const = 1 + (digit_1 / 100) + (digit_2 / 1000) + ... (digit_5 / 1E6); --- End code --- So for the example above "3EDC5", we have --- Code: ---gain_const = 1 + (3 / 100) + (-2 / 1000) + (-3 / 1E4) + (-4 / 1E5) + (5 / 1E6); gain_const = 1.027665 --- End code --- 4) display_raw = pregain * gain_const , so 1 053 614. Well, simulation gives 1 053 610, but rounding / trunction, so yeah. 5) display = display_raw / 10 and/or adjust decimal point. I lost track of the number of trailing 0's ! And, that's pretty much all there is to it. |
| Navigation |
| Message Index |
| Next page |
| Previous page |