| Electronics > Repair |
| HP 3478A: How to read/write cal SRAM |
| << < (23/41) > >> |
| lmester:
--- Quote from: fenugrec on January 25, 2020, 08:08:51 pm --- The reverse process is sortof like a long division I guess ? I think it goes something like this. Assume all offsets are 0 for simplicity. The meter has a raw ADC reading 'R', and it knows the expected calibrated value 'C'. * calculate error 'e = c - r' . Can be negative of course * shift raw value right, i.e. divide by 10. First iteration needs to start at a 1/100 division. let's call it 'sr = r * (1/100)' * how many times does 'sr' fit in 'e' ? * if it fits 0 to 7 times, then that encodes directly to digit 1. * if it fits -1 to -8 times, then "encode" that digit as (16 - <value>), so 0x0F for -1 to 0x08 for -8. * if it fits 8 or 9 times, problem : those digits indicated negative values, so we need to cheat: carry 10 to the digit to the left (by incrementing by 1 - careful if the digit was already 7, you'll need to do the same manoeuvre recursively), and set the current digit to (value - 10) i.e. -2 or -1. In other words, use the fact that 8 * sr = (10 * sr) + (-2 * sr) * if it fits -9 times, same idea : borrow 10 from digit on the left, adjust, and continue. * calculate new 'e' value for next loop, i.e. remainder. Right shift sr again and continue I think that should work, conceptually at least. Interesting consequence of the +7/-8 limit on digits : some gain values can be encoded in more than one way, for example 0001C and 00006 both correspond to a gain of 1.000006 . --- End quote --- Thank you for the info. I'm sorry, it seems that I still don't understand the procedure. I've ben trying to calculate the packed gain for .911112 packed =0x88888. I'm not getting correct results. I'm assuming that e is the gain value? e=.911112 Could you please go through the procedure using .911112? This would give me a better understanding of the process. |
| steve1515:
I've updated my release to correct for the decode error. If anyone wants to check it out and verify it would be appreciated. https://github.com/steve1515/hp3478a-calibration/releases https://github.com/steve1515/hp3478a-calibration I've also been thinking about how to convert from floating point back to a raw gain, and I'm not sure there is a good way. I see what fenugrec is saying... The meter just keeps the raw nibbles and uses them as is. No floating point calculations are done in the meter. Maybe it would be better to have the interface allow the user to adjust the raw gain values as 5 sliders or 5 numeric up-down boxes where the floating point value is displayed for reference as the value is changed. :-// |
| fenugrec:
--- Quote from: steve1515 on January 26, 2020, 10:03:38 pm ---I've also been thinking about how to convert from floating point back to a raw gain, and I'm not sure there is a good way. --- End quote --- Let me try again. Say the gain constant K is "0001C". The digits are : --- Code: ---k1 = 0 k2 = 0 k3 = 0 k4 = 1 k5 = 'C' = -4 --- End code --- As we know, 0-7 mean 0-7, but 8 to F are negatives, so 0x0C corresponds to -4. What is the meter calculating ? please read through this. scroll ! --- Code: ---R = raw ADC reading, delta = correction to apply C = corrected value : C = R + delta delta = R * ( (K1 * 0.01) + (K2 * 0.001) + (K3 * 0.0001) .... + (K5 * 0.000 001)) ###### all good ? in this case K1 to K3 are 0, so we can rewrite as delta = R * ((1 * 0.00001) + (-4 * 0.000 001)) and then of course, delta = R * (0.000006) ###### easy enough, I hope. This last value, 0.000006, I'll call it "k_factor" to distinguish it from the gain. So, delta = R * k_factor Remember from the beginning, C = R + delta C = R + R*k_factor C = R * (1 + k_factor) but we like to think about gain. What's gain ? C = R * gain so, gain = 1 + k_factor therefore "gain" in our example is 1.000006. ############ what's the opposite process ? Let's say for gain=1.049000 ? We want to determine the digits K1 to K5, such that k_factor = (K1 * 0.01) + (K2 * 0.001) + (K3 * 0.0001) + (K4 * 0.00001) + (K5 * 0.000 001) 1) finding k_factor : super easy. Of course this can give a negative number, since "gain" can be <1. k_factor = gain - 1 = 0.049000 2) how do you "solve" the equation to find K1 to K5 ? 2A) determine the desired k_factor = gain - 1 = 0.049000 2B) for digit K1, which corresponds to the position "0.04", can we solve (0.04 = K1 * 0.01) ? Of course. K1 = 4. 2C) for digit K2, corresponding to the position "0.009". Can we solve (0.009) = (K2 * 0.001) ? yes, but we have a problem : we would like K2 = 9, but we can only have K values between -8 and +7. What can we do ? 2D) well, 9 = (10 - 1). Serious math. what does that mean ? k_factor = (K1 * 0.01) + (K2 * 0.001) + ... k_factor = (4 * 0.01) + ((10 * 0.001) + (-1 * 0.001)) + ... k_factor = (4 * 0.01) + (0.01 + (-1 * 0.001)) + ... k_factor = (5 * 0.01) + (-1 * 0.001) + ... see what happened ? I incremented K1, and set K2 = -1. All's good, we've made the digits fall in the valid range -8.... +7 the digits are now K1 = 5 K2 = -1 2A3) : next digits are 0, thankfully. But it would be the same process. ##### note: if a carry/borrow operation causes a digit to fall outside the valid range, then another carry/borrow would have to be repeated with the next digit to the left. 2A5) we end up with a gain constant "5F000". --- End code --- |
| fenugrec:
I forgot to push to GH last time I worked on this. I added an "encode_gain" function and selftest (verifies that encode(gain) == expected_gain). The encode function isn't accessible from the CLI though; ran out of time to add that. Should be easy enough : sscanf(%d, &gain), bounds check, encode(gain). https://github.com/fenugrec/hp3478a_utils/commit/04584cd4eb7f9f741913e01591b73cf6db307348 |
| Miti:
Kirill added Prologix support to his adapter and it works with Lmester's program. https://www.eevblog.com/forum/projects/project-extending-hp3478a-functionality/new/#new A big thanks to both, Kirill and Lmester! |
| Navigation |
| Message Index |
| Next page |
| Previous page |