Electronics > Repair
HP 3478A: How to read/write cal SRAM
djrm:
--- Quote from: Kleinstein on March 14, 2024, 06:17:18 pm ---Getting the error always at the same position is indeed a bit odd.
Are other tranfers (e.g. repeated status / version reading) also getting occasional tranfer errors ?
...
It can be worth looking at the signal levels with a scope.
--- End quote ---
In normal use I'm getting no errors, commands are returned without any visible errors.
I'll check the signal lines with my 'scope - not sure what I'm looking for but I'll maybee see an odd looking signal line or something.
D.
pqass:
--- Quote from: djrm on March 14, 2024, 06:01:19 pm ---... I tried sending 'W' 0x00 CRLF to see if I could get an individual byte back but never received anything at all.
--- End quote ---
For a rough/baremetal read of the cal data...
Connect your terminal emulator (GTKTerm, minicom, ...) to the AR488 com port (typically at 115200-8-N-1).
Type: "++ver", enter, to confirm that your AR488 is responding.
Type: "++addr N", enter, where N is the GPIB address of the 3478A.
Type: "++read", enter, to confirm a response from the meter.
Turn on log to file.
To read a cal byte (in a fresh bash shell) type:
"/usr/bin/echo -en "W\e\xHH\r++read\r" >>/dev/ttyUSB0"
Turn off logging in the terminal program.
The cal byte is the first character of every log file row; ignore remaining characters to end-of-line.
If needed, to write a cal byte (after turning the "cal enable" screw on meter faceplate), type:
"/usr/bin/echo -en "X\e\xHH\xVV\r++read\r" >>/dev/ttyUSB0"
Meaning of echo switches ("man echo" for more detail):
\e =ASCII escape char 1B hex (needed to tell AR488 that next byte is binary)
\xHH =HH is the hex of the character representing the address of the cal byte
\xVV =VV is the hex of the character representing the value of the cal byte
\r =ASCII carriage return 0D hex
ttyUSB0 =com port where AR488 is connected (replace as appropriate for your setup).
Creating a bash script to automate calling 256 echo lines above or scraping the first character from the log file is left as an exercise for the diligent student.
djrm:
--- Quote from: pqass on March 14, 2024, 07:25:13 pm ---Creating a bash script to automate calling 256 echo lines above or scraping the first character from the log file is left as an exercise for the diligent student.
--- End quote ---
Thanks, I'd been missing the escape on the address byte, I'll try again.
As for rewriting as a script, I'm not sure I'm up to that.
Just had a quick look at some signals on the 'scope. Some appear to be three state, others bit and byte pulses.
I'm not familiar with GPIB protocol, I wonder if pulseview knows about it ... it does :-)
edit, more importantly I had not been issuing any ++read commands to see the returned values!, doh
Kind regards, David.
djrm:
Sending read cal commands by hand results in the same sequence as seen by HP3478A.exe program, I wonder if this is a true copy of what I have in the cal. I would expect the meter to show an error though.
--- Code: ---@@@BICADLMELM : CkSum = (205 + 49) Checksum Fail.
@@@@BIADLALMF : CkSum = (214 + 41) Checksum OK.
M@@@@@ACCA@OG : CkSum = (247 + 21) Checksum Fail.
--- End code ---
--- Code: ---@+00.0007E-3
@+00.0007E-3
@+00.0005E-3
@+00.0004E-3
B+00.0004E-3
I+00.0007E-3
C+00.0007E-3
A+00.0004E-3
D+00.0004E-3
L+00.0006E-3
M+00.0004E-3
E+00.0007E-3
L+00.0009E-3
M+00.0009E-3
@+00.0008E-3
@+00.0013E-3
GPIB
@+00.0010E-3
@+00.0007E-3
B+00.0007E-3
I+00.0008E-3
A+00.0006E-3
D+00.0005E-3
L+00.0010E-3
A+00.0011E-3
L+00.0012E-3
M+00.0011E-3
F+00.0007E-3
M+00.0008E-3
@+00.0009E-3
@+00.0009E-3
@+00.0009E-3
@+00.0010E-3
GPIB
@+00.0011E-3
A+00.0008E-3
C+00.0005E-3
C+00.0010E-3
A+00.0009E-3
@+00.0011E-3
O+00.0009E-3
G+00.0008E-3
--- End code ---
with ++ver every 16 bytes
The scope trace looks clean and is reaching 0 and 5V ok
D.
pqass:
--- Quote from: djrm on March 14, 2024, 08:28:41 pm ---... I wonder if this is a true copy of what I have in the cal. I would expect the meter to show an error though.
--- End quote ---
If the meter boots with "SELF TEST OK" then the cal data in the battery-backed RAM is A-okay.
"M" to "N" is \x4D or \b01001101 to \x4E or \b01001110 which is 2 bits off.
"M" to "@" is \x4D or \b01001101 to \x40 or \b01000000 is 3 bits off! Very odd!
if you call "/usr/bin/echo -en "W\e\xHH\r++read\r" >>/dev/ttyUSB0" multiple times (at the problem addresses), does it consistantly give the same bad value? Or, does it occasionally give the correct value?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version