Not exactly a puzzle, but puzzling

[Robert Swan]

This may not be the appropriate newsgroup for this; I'll post it to
another group if anyone has a better suggestion. Still, it might rate
as a diverting problem for those sad individuals who think like I do.

By way of background, I recently bought a Rigol digital oscilloscope.
It is able to save waveforms in a .wfm file (different from
Tektronix's .wfm). I have this format sufficiently decoded to get
what I need from it, but I thought the way they stored the probe
attenuation value was very peculiar:

Code Probe
Hex = Decimal Attenuation
3f80 16256 x1
40a0 16544 x5
4120 16672 x10
4248 16968 x50
42c8 17096 x100
4471 17530 x1000

So what led them to this strange encoding? Why not just encode it as
the attenuation value itself?

After dusting off my rather rusty memories of regression analysis, I
came up with:

atten = round(10^(0.00235494566320616*code - 38.214998330573))

as the closest approximation I could easily get. It gets pretty close
too, but is hardly the picture of clarity. If, instead of base 10,
you use base 2 logs you get the tantalising:

atten = round(2^(code/128 - 127))

which looks nice and computerish -- but it isn't nearly close enough.

For my programming purposes, a simple lookup table does the trick.
I'd just like to know the thinking behind this scheme. Theories,
anyone?

Have fun,

Robert.
--
Robert Swan | No, not the antarctic adventurer.
swan...@gmail.com | No, not the Canberra porn monger.
| Yes, that's right, the boring one.

[Alan Curry]

In article <acc3v6-...@rswan.netspace.net.au>,

Robert Swan <rob...@athlonx2.gville> wrote:
>This may not be the appropriate newsgroup for this; I'll post it to
>another group if anyone has a better suggestion. Still, it might rate
>as a diverting problem for those sad individuals who think like I do.
>
>By way of background, I recently bought a Rigol digital oscilloscope.
>It is able to save waveforms in a .wfm file (different from
>Tektronix's .wfm). I have this format sufficiently decoded to get
>what I need from it, but I thought the way they stored the probe
>attenuation value was very peculiar:
>
> Code Probe
>Hex = Decimal Attenuation
>3f80 16256 x1
>40a0 16544 x5
>4120 16672 x10
>4248 16968 x50
>42c8 17096 x100
>4471 17530 x1000

You have an error in the last line. 17530 is 447a, not 4471. And I bet that
447a is the correct value, because:

Each of those hex codes is the first 2 bytes of a 4-byte IEEE 754 floating
point representation of the probe attenuation number. The last 2 bytes of the
float are 0 for all of the listed numbers.

--
Alan Curry

[swan...@gmail.com]

In article <hfn880$lmq$1...@aioe.org>, Alan Curry <pac...@kosh.dhis.org> wrote:
>In article <acc3v6-...@rswan.netspace.net.au>,
>Robert Swan <rob...@athlonx2.gville> wrote:
>> Code Probe
>>Hex = Decimal Attenuation
>>3f80 16256 x1
>>40a0 16544 x5
>>4120 16672 x10
>>4248 16968 x50
>>42c8 17096 x100
>>4471 17530 x1000
>
>You have an error in the last line. 17530 is 447a, not 4471. And I bet that
>447a is the correct value, because:

Yep. Silly transcription error. Sorry about that.

>Each of those hex codes is the first 2 bytes of a 4-byte IEEE 754 floating
>point representation of the probe attenuation number. The last 2 bytes of the
>float are 0 for all of the listed numbers.

And right again. There were "unknown" slots both before and after
these two bytes that changed with the attenuation. I thought I'd
tried both possibilities for float encoding, but no, clearly not.
Excellent, I'll be able to get rid of the lookup table.

>Alan Curry

Full marks, plus a bonus for correcting the question! And thanks.

[Matthew Russotto]

In article <acc3v6-...@rswan.netspace.net.au>,
Robert Swan <rob...@athlonx2.gville> wrote:

>By way of background, I recently bought a Rigol digital oscilloscope.
>It is able to save waveforms in a .wfm file (different from
>Tektronix's .wfm). I have this format sufficiently decoded to get
>what I need from it, but I thought the way they stored the probe
>attenuation value was very peculiar:
>
> Code Probe
>Hex = Decimal Attenuation
>3f80 16256 x1
>40a0 16544 x5
>4120 16672 x10
>4248 16968 x50
>42c8 17096 x100
>4471 17530 x1000
>
>So what led them to this strange encoding? Why not just encode it as
>the attenuation value itself?

I'm guessing that's the value actually used by some hardware
register. Why the hardware uses those values would be a deeper
question; it's almost logarithmic.
--
The problem with socialism is there's always
someone with less ability and more need.