Electronics > Repair
HP 3478A: How to read/write cal SRAM
<< < (29/41) > >>
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
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod