| 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 |