Electronics > Repair
HP 3478A: How to read/write cal SRAM
<< < (12/41) > >>
Miti:
Ahh, I missed that but my theory stays. For the first 5 entries the first 6 nibbles are all around zero if, as you said, 999... meas negative and the last 5 nibbles are all around  2Dxxx so one may be the offset and the other the gain. I expect the offset to be pretty close to zero.
It becomes Interesting, I may play with the numbers over the weekend.
Miti:
OK, so I couldn't wait until the weekend and today after work I played with my "lab rat" again and check    this    out!

Cal entry #    Range
1                  30 mV DC
2                  300 mV DC
3                  3 V DC
4                  30 V DC
5                  300 V DC
6                  Not used. It doesn't even show "UNCALIBRATED" if altered, you can put your name there.
7                  All AC Volts ranges
8                  30 Ohm 2W, 4W
9                  300 Ohm 2W, 4W
10                3 KOhm 2W, 4W
11                30 KOhm 2W, 4W
12                300 KOhm 2W, 4W
13                3 MOhm 2W, 4W
14                30 MOhm 2W, 4W
15                300 mA DC
16                3A DC
17                Not used
18                300 mA and 3A AC
19                Not used

I also experimented with the constants for the 30V range. I used a 9V battery to see changes. I've attached the results. The first 6 nibbles are the offset, the next 5 are a kind of a gain and the last 2 the checksum. The checksum is an 8 bits constant made of the last two nibbles. If you add the checksum with all the nibbles in that entry, you get 255. The "gain" doesn't really do what I expected so it needs more thinking but the offset is bang on. The 999 thing is like the zero level is at 1000000 but you only see the last 6 digits. So for a positive  value of 136 you just add 136 to 1000000 and the constant is 000136. For -136, you subtract from 1000000, so  the constant is 999864. I know, it doesn't make sens... at least to me. Maybe it's a bingo moment for a software guy.
As you can see, the calibration constants are common for 2W and 4W Ohm ranges. That's why the manual says that you should calibrate in the mode that you are using it.

Checksum example:
@@@A@IADOD@MM -> hex 0 0 0 1 0 9 1 4 F 4 0 D D  Checksum = 0xDD       1+9+1+4+F+4+DD = 0xFF
fenugrec:

--- Quote from: Miti on March 28, 2018, 01:06:22 am ---OK, so I couldn't wait until the weekend and today after work I played with my "lab rat" again and check    this    out!

--- End quote ---
Awesome !! And you did a pretty thorough job, thanks for that.


--- Quote ---Cal entry #    Range
...
17                Not used
18                300 mA and 3A AC
19                Not used...

--- End quote ---
hehe I did a double take on the unused entries but simply because you started your numbering at 1, where I used 0 !



--- Quote --- I also experimented with the constants for the 30V range. I used a 9V battery to see changes. I've attached the results. The gain doesn't really do what I expected so it needs more thinking
--- End quote ---
Interesting - I'll see if I can find some hints in the firmware.


--- Quote ---The 999 thing is like the zero level is at 1000000 but you only see the last 6 digits. [...]
--- End quote ---

makes sense. As I thought, this is 6 digit BCD, right, so adding 999 999 + 1 , rolls over to 0.
Miti:
So you say the calculations are done in BCD? Looks stupid out of fashion to me...but hey...it works. :-+
fenugrec:

--- Quote from: Miti on March 28, 2018, 01:54:16 am ---So you say the calculations are done in BCD? Looks stupid to me...

--- End quote ---

Hehe, say not stupid, but rather out of fashion. Think of the advantage : numbers are already in a format ready to be displayed, or sent over GPIB as text with minimal work. Looking at firmware disassembly it's very obvious it wasn't easy to fit all this in an 8kB ROM and get decent performance !

Pros :
- add 0x30 to each digit and you have ASCII !
- adding and subtracting is not much harder than on multi-byte base2 on these CPUs because they have special flags and opcodes to help with BCD ops
- no overhead required to convert between base 10 and 16 - save on code size but also speed (5.6Mhz clock , but throughput is IIRC closer to 1MHz)

Cons :
- mult / div probably require more code in BCD, this is beyond my experience
- ADC readings are most likely plain base2, so at least one bin-to-bcd conversion is required
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