EEVblog Electronics Community Forum

Electronics => Projects, Designs, and Technical Stuff => Topic started by: 741 on November 16, 2017, 11:16:46 am

Title: Why are dig pots "+1" bit?
Post by: 741 on November 16, 2017, 11:16:46 am
The MCP455 DS shows "257 Taps 8-bit". It states
"For an 8-bit device, there are 256 resistors in a string between terminal A and terminal B. The wiper can be set to tap onto any of these 256 resistors, thus providing 257 possible settings"

That is, with Q series 2-terminal devices  *--R--*--R--*--R--*--R--* there are (Q+1) nodes.

One node is the "wiper at zero" position. So, it makes sense that there are 2^N codes (not 2^N - 1).

But it still 'feels inefficient' when coding. It seems I need to pass in a 16-bit value or use an 8-bit value and ignore one possible setting or ... something.

Why do the manufacturers not use 255 resistors for example (yielding 256 'values').

Is it because when they lay out the resistors, it's neater to have a 'round number'?
Is it because the step size would be less intuitive?
Title: Re: Why are dig pots "+1" bit?
Post by: T3sl4co1l on November 16, 2017, 11:51:59 am
I don't remember if they actually use a 256-resistor string, or if they cheat it with a log series of matched resistors.

Consider the INL and DNL:
http://www.mouser.com/ds/2/268/DS-22096a-36447.pdf (http://www.mouser.com/ds/2/268/DS-22096a-36447.pdf)
Fig 2-6.

There are... the fuck... the horizontal axis has almost 13 divisions.  What retard plotted this?  Oh my god...

Anyway, please ignore the axis marks and grid, and visually subdivide it instead.  There are 31 peaks on the DNL curve.  That means DNL is zero at codes 0 and 256 (special case -- no resistors involved), and there are 32 segments inbetween, the edge of each one being marked with a peak.  DNL is differences, so the differences are small within each segment (a span of 8 codes), then it changes to another segment, which is slightly different, so the step size from code 0bxxxx0111 to 0bxxx1000 (say) is slightly different from the others.

Then if you look at the peaks every 2 or 4 or 8 or 16 segments, it doesn't look like there's much correlation there, so they probably do 32 ranges of 8-in-a-row.

This is supported by the INL, which goes down and up in this case.  In fact, it goes down after 8 peaks, then goes back up, then up again, then down.  It's probably more that they've got two or four spans of 16 segments each, and are arranging those resistors as needed to get the apparent terminal resistance correct.

So, the convenient lie, in the text -- that they call it a linear 256xR chain -- the reason they can get away with that is, they've done a couple runs of modest length (8 and 16, it seems) that are stacked (using several switches) in such a way that, within an adequate tolerance range, it's indistinguishable from exactly that.

The result is cost savings, because it doesn't take a huge area of silicon and resistors, and because it doesn't take 2^N - 1 laser trimming operations (not 2^N, because the initial tolerance sucks -- apparently, they found it worthwhile to match all the other resistors to one untrimmed reference, rather than just trimming all of them), but O(N) operations instead.  If there were 3 stages of 8-in-a-run for 11 bits total range, it would be 24 resistors and about as many trim operations and switches.  To meet 8 bits, they used a somewhat oddball 8-16-2 sequence, probably to keep nonlinearity down.

Speaking of linearity, it's worth doing this -- chopping it into stages instead of using a linear string -- for linearity sake too.  That many resistors would be much more prone to errors, like leakage current, and capacitance.  So the result is better all around.

And, of course, to take advantage of any division, you need a number with a lot of factors in it, preferably factors of 2.  Fortunately, 255 isn't prime (3 * 5 * 17), so it could indeed be implemented that way -- with 256 codes.  There would be a bit more decoder logic to solve for the odd multiples.  The method isn't very general, though: 2^N - 1 can be prime, in which case you're screwed.  Offhand, common values of N are okay: 8, 10, 12, 16 and 20-bit ranges all have tons of factors in them.  But now your decoder logic needs to solve for different factors for different ranges, which is kind of sucky I guess.

Tim
Title: Re: Why are dig pots "+1" bit?
Post by: TomS_ on November 17, 2017, 05:43:53 pm
One node is the "wiper at zero" position. So, it makes sense that there are 2^N codes (not 2^N - 1).

Unless I mis-understand what youre saying here, 2^N (or specifically 2^8) is 256 values, which is typically 0-255 or could be 1-256. 2^N-1 would be 0-254. So in this case its 2^N+1, which is just a pain in the ass if you want to store the value in an 8 bit integer....?  :wtf: