are you doing GIO and VIO calibration at nearly the same time as taking ADC data samples?
Remember the trails you plotted for every pin for VIO vs GIO calibration?
Some have a slope, but some are more point stable with respect to temperature
As part of my servo project I also did some experiments with ADCs and calibration. I use SINC2 filtering and 8192 clocks sampling period. I had some problems with the autocalibration that suffered from some offset variations from channel to channel. But there were no glitches and fairly low noise.
Hehe, sorry, no, I didn't explain my aim did I. There is only vague references so far. I'm explicitly aiming to see if there is a reliable way to measure the die temperature using the ADC's drift characteristics.
First thing I've noted is VIO level readings are more stable than GIO level readings so I've ignored GIO altogether.
EDIT: I guess, in the end, the biggest issue will simply be calibrating an absolute reference temperature. Each prop2 part I run this on will likely have a relatively large offset to other prop2s.
I also noticed that VIO was more stable than the GIO in the calibration readings
The VIO and GIO are somewhat correlated, and its the 'low' values which seem to have the most appropriate (more linear) temperature slopes ripe for exploit. So perhaps a strategy of choosing a pin with lowest or near lowest VIO calibration value then watching that pin for excursions could work
It doesn't appear sometimes. It was only when I was comparing all pins that I picked up there was a problem. I strongly advise you do add the de-glitching code.
I've just had a shot at sampling "fast" driven pins in place of VIO and GIO input sources in an attempt to remove differences in source select resistors. Chip mentioned to try that in the other topic ManAtWork linked to.
Comparing the two sources, they have the same varied DC levels numerically. Where a particular pin's GIO has as a relatively low reading, then so does that pin input when driven low with that pin's 20 ohm output drive. Likewise for VIO vs high output.
The measurement method is slow. I wait 250 microseconds with the ADC operating and smartpin in Sinc2 Filter mode. This provides a warm-up for the ADC hardware as per Chip's recommendations. Then take 20 consecutive samples, discarding the first four to fill the "diff" variables, and use the remaining 16 samples for that pin's reading. I'm operating at 10 MHz sysclock, for the moment, and each sample is 11585 clocks. So that's a measurement duration of 1.1585 x 16 = 18.536 ms for each source.
I conclude the source select resistors are not the reason for differences between pins.
PS: Also, the difference of VIO - GIO verses pin high - pin low also track each other well on a per pin basis.
So the min/max variations there is about 5% of full-scale for GIO and 4% of full-scale for VIO. That's a tad wild. And that's just one part at one temperature. Hence the obvious recognition of always needing to calibrate for instrumentation use.
I should build a binary for others to gather reports and post them here ...
Evanh, thanks. I've been looking at your comments in the doc, trying to fully understand the ramifications of this. It would seem just the MSBs would be bad, but is there more to it? I ask because I remember this coming up a while back, and there seemed to be more to it.
Just the 5 most significant bits (for a 27-bit to 32-bit translation). I had thought it was worse at the very start but that was quickly narrowed down, thanks to Ariba, to just a rollover problem affecting the extended bits only.
I've now even done a mock example on paper, just doing a regular spaced summing using 3-bit to 4-bit, and get the same effect of the extended bit toggling.
@evanh said:
Just the 5 most significant bits (for a 27-bit to 32-bit translation). I had thought it was worse at the very start but that was quickly narrowed down, thanks to Ariba, to just a rollover problem affecting the extended bits only.
I've now even done a mock example on paper, just doing a regular spaced summing using 3-bit to 4-bit, and get the same effect of the extended bit toggling.
Can't this whole thing be solved by ignoring the top 5 MSBs of the final result?
That's effectively what both options achieve - Removal of those extra bits so they won't mess up anything later. Ie: You don't want those extraneous bits present when further filtering, or scaling, or even a simple print.
If not documented, it'll catch a lot of people out. Sure had me for a while. It's actually a generic binary maths thing but just one I've not dealt with until now surprisingly.
Maybe the documenting around it could be written more that way. That here's two simple solutions to translating between circular integer word sizes.
Actually, in hindsight, I have dealt with this before but it was couched within some servo hardware where I had to derive the encoder count from its error counter. This was all in C also. The error counter was 13 bits wide and so I used a bunch of masking to handle the translation to 32-bit. Didn't even think how relevant that might be to other situations. EDIT: On the other hand, the error counter wasn't circular in nature, even if the encoder was.
It's not a smartpin problem at all. It's just the nature of circular maths arithmetic when mixing different word sizes. Ie: It's just in the software summing, the ADD and SUB.
Here's the 3-bit to 4-bit hand written paper version copied of the non-corrected software. It is simulating a fixed internal increase of 5 per decimation from the RDPIN:
It's amusing reading my evolving understanding. I wasn't fully on to real issue for quite some time. And even when I did get it completely I didn't post a clarification until now.
What I failed to do was print the suscessive components, as per above, in my early testing. I didn't know that RDPIN was producing a clean 27 bits. I guess I didn't know it was meant to be 27-bit either to be fair.
@evanh said:
It's amusing reading my evolving understanding. I wasn't fully on to real issue for quite some time. And even when I did get it completely I didn't post a clarification until now.
What I failed to do was print the suscessive components, as per above, in my early testing. I didn't know that RDPIN was producing a clean 27 bits. I guess I didn't know it was meant to be 27-bit either to be fair.
For the RDPIN, yes.
Not for the resulting post-diff'd sample. Read my simulated example above (I've fleshed it out a little more). It shows the resulting diff'd "sample" as containing extraneous high-order bits. It should be consecutive 5's but has sporadic 13's in there. If using an &7 to mask it, it would be all 5's.
PS: I've been trying to make it clear that it's just a word size conversion issue in the software. The extra instruction is needed as part of doing circular arithmetic and bridging between word sizes.
EDIT: Actually, it's not even about bridging. It's just managing circular arithmetic at a non-native word size. The other method of scaling with a SHL converts to native word size and therefore doesn't need further masking.
Cool. My editing in the Google Doc was looking messy anyway. Suggestion mode leaves a trail of overlapping edits. Best to prep it elsewhere then do a single paste.
Chip,
In your updating, please do make it clear that the RDPIN decimations are 27-bit wide. Not knowing that ahead of troubleshooting definitely slowed down diagnosing of this issue.
PS: This whole issue has a lot of commonality with motion control on rotary equipment. I did tons of this stuff more than a couple decades back. Certainly wasn't expecting this conclusion when I starting problem solving this - an ADC in a microcontroller.
Here's a little piece of BASIC code from the servo controller of the first two wrapping machines, last updated in 1998. I don't think I could do this now. I loved the work at the time but it was strenuous thinking all the time. There was very limited memory in the servo controller and all source was on board so comments had to be small. It was kind of cool because you could pop open a dumb terminal and edit the whole program with that. It tokenised upon RUN.
#fastpos : REM (Dropped to 0v)
REM Picture sync received
REM -----------------------------------------------------------------
IF !PicOset | (FASTPOS.1 - PicPls < PackEnc * .75) THEN RETURN
PackEnc = PackEnc + ((FP.1-PicPls+PackEnc*.5)%PackEnc-PackEnc*.5) * PicGn
IF PackEnc > PackMax THEN PackEnc = PackMax
PackR = PackEnc / InRev
cam1(2) = INT(PackEnc / FinSect)
PicPls = FASTPOS.1RETURN
What that is doing is dynamically recalibrating the nominal motion pack length, PackEnc, to match the measured distance between printed images on the wrapping, FASTPOS.1 - PicPls.
But to make that work as circular arithmetic requires to wrap (pun ) the measured distance to the existing pack length first. That's the modulo'd part, (..)%PackEnc. Just like masking a word size.
@evanh said:
Chip,
In your updating, please do make it clear that the RDPIN decimations are 27-bit wide. Not knowing that ahead of troubleshooting definitely slowed down diagnosing of this issue.
PS: This whole issue has a lot of commonality with motion control on rotary equipment. I did tons of this stuff more than a couple decades back. Certainly wasn't expecting this conclusion when I starting problem solving this - an ADC in a microcontroller.
Here's a little piece of BASIC code from the servo controller of the first two wrapping machines, last updated in 1998. I don't think I could do this now. I loved the work at the time but it was strenuous thinking all the time. There was very limited memory in the servo controller and all source was on board so comments had to be small. It was kind of cool because you could pop open a dumb terminal and edit the whole program with that. It tokenised upon RUN.
#fastpos : REM (Dropped to 0v)
REM Picture sync received
REM -----------------------------------------------------------------
IF !PicOset | (FASTPOS.1 - PicPls < PackEnc * .75) THEN RETURN
PackEnc = PackEnc + ((FP.1-PicPls+PackEnc*.5)%PackEnc-PackEnc*.5) * PicGn
IF PackEnc > PackMax THEN PackEnc = PackMax
PackR = PackEnc / InRev
cam1(2) = INT(PackEnc / FinSect)
PicPls = FASTPOS.1RETURN
What that is doing is dynamically recalibrating the nominal motion pack length, PackEnc, to match the measured distance between printed images on the wrapping, FASTPOS.1 - PicPls.
But to make that work as circular arithmetic requires to wrap (pun ) the measured distance to the existing pack length first. That's the modulo'd part, (..)%PackEnc. Just like masking a word size.
More detail on the SINCn would be appreciated...
I tried to use filtering modes but got nonsense...
Also, it's not clear whether or not one must retrieve a sample when in goes high.
You don't need to do this with the sampling SINC2 mode.
Maybe this is what I did wrong as I was just grabbing a value once per second...
@Rayman said:
More detail on the SINCn would be appreciated...
I tried to use filtering modes but got nonsense...
Also, it's not clear whether or not one must retrieve a sample when in goes high.
You don't need to do this with the sampling SINC2 mode.
Maybe this is what I did wrong as I was just grabbing a value once per second...
You need to handle each sample, otherwise you'll lose track of the ongoing measurements.
@Rayman said:
Can I take, say, 5 samples in a row and then just use the last one as the result?
No, the syncN filters need to process all 5 samples. You can store the 5 values in an array an process them all together after 5 samples, but the sync filters only work if every value is taken into account.
With Sync2 Sampling, the smartpin hardware does this for you, that's why you can read the ADC result whenever you want in this mode.
Comments
Remember the trails you plotted for every pin for VIO vs GIO calibration?
Some have a slope, but some are more point stable with respect to temperature
First thing I've noted is VIO level readings are more stable than GIO level readings so I've ignored GIO altogether.
EDIT: I guess, in the end, the biggest issue will simply be calibrating an absolute reference temperature. Each prop2 part I run this on will likely have a relatively large offset to other prop2s.
I also noticed that VIO was more stable than the GIO in the calibration readings
The VIO and GIO are somewhat correlated, and its the 'low' values which seem to have the most appropriate (more linear) temperature slopes ripe for exploit. So perhaps a strategy of choosing a pin with lowest or near lowest VIO calibration value then watching that pin for excursions could work
Comparing the two sources, they have the same varied DC levels numerically. Where a particular pin's GIO has as a relatively low reading, then so does that pin input when driven low with that pin's 20 ohm output drive. Likewise for VIO vs high output.
The measurement method is slow. I wait 250 microseconds with the ADC operating and smartpin in Sinc2 Filter mode. This provides a warm-up for the ADC hardware as per Chip's recommendations. Then take 20 consecutive samples, discarding the first four to fill the "diff" variables, and use the remaining 16 samples for that pin's reading. I'm operating at 10 MHz sysclock, for the moment, and each sample is 11585 clocks. So that's a measurement duration of 1.1585 x 16 = 18.536 ms for each source.
I conclude the source select resistors are not the reason for differences between pins.
PS: Also, the difference of VIO - GIO verses pin high - pin low also track each other well on a per pin basis.
Total smartpins = 64 1111111111111111111111111111111111111111111111111111111111111111 Rev B silicon. Sysclock 10.0000 MHz Sinc2-filtered Sinc2-filtered PIN pin low pin high GIO VIO ------------------------------------------------- P00 6142035 27885540 6090674 27950801 P01 5458869 27348489 5400775 27365451 P02 5273552 27433048 5236600 27456790 P03 6189832 28380066 6166334 28356052 P04 6203870 28093425 6178712 28107768 P05 6148515 28051689 6133104 28077391 P06 6174557 28237314 6162615 28226102 P07 6578140 28347982 6575421 28325400 P08 6611105 28668086 6605813 28647426 P09 5750487 27757971 5728135 27753544 P10 6224314 28482043 6185837 28499650 P11 5613531 27606855 5612429 27613500 P12 5788859 27741110 5838350 27685903 P13 6257255 28117335 6213640 28164760 P14 5881923 28008612 5880335 28037255 P15 5421120 27670129 5375159 27688079 P16 6415749 28352887 6352031 28317164 P17 6466884 28178692 6448147 28198719 P18 5585280 27632139 5567467 27624064 P19 6076829 28179265 6164480 28127087 P20 6204954 28302399 6179857 28330078 P21 5205974 27241737 5160754 27269773 P22 6120772 28316118 6074738 28288697 P23 5329749 27473193 5311630 27520487 P24 5153398 27326284 5109476 27318500 P25 5504514 27623546 5495829 27578640 P26 5662766 27881012 5636394 27882068 P27 5786535 27567829 5805058 27578443 P28 6870324 28668762 6860295 28654928 P29 5725359 27895102 5747010 27860190 P30 6172007 28169735 6181291 28175766 P31 6254414 28000645 6243634 27979439 P32 5921326 27933429 5890871 27925146 P33 5486545 27351672 5427591 27388197 P34 5822942 27907746 5799136 27928724 P35 5358255 27596923 5316434 27598711 P36 5657597 27696834 5679945 27685610 P37 5671452 27555290 5606952 27586792 P38 5619206 27822837 5649430 27800892 P39 6312615 28021793 6237612 28075028 P40 5665233 27534024 5658431 27513522 P41 5610010 27615702 5615519 27566359 P42 5925292 27820761 5896469 27851079 P43 5844487 28133435 5829831 28140200 P44 6293966 28394837 6255270 28403928 P45 6155626 28322529 6106238 28381965 P46 5437036 27512244 5387209 27468478 P47 6405709 28392870 6393274 28344056 P48 5711458 27703565 5699517 27753035 P49 6065627 28198225 6034380 28200829 P50 6338415 28090865 6289459 28126639 P51 5774707 27942914 5752440 27926301 P52 5902527 28052523 5893998 28021100 P53 5972431 28136139 5988334 28124655 P54 5649705 27924620 5601229 27901533 P55 5792624 27796270 5819284 27731016 P56 5745336 27846723 5744295 27865779 P57 5214628 27274456 5161293 27281442 P58 6135019 27832414 6090355 27830880 P59 5897501 28057974 5877131 28064822 P60 5968686 28005132 5958296 28019442 P61 5311972 27453301 5237735 27527931I should build a binary for others to gather reports and post them here ...
I've just added this info about 32-bit vs 27-bit summing rollover to the silicon document as a suggestion. It needs vetted for viewing/printing still.
[bah, testing wrong code]
Nothing to see this time
Evanh, thanks. I've been looking at your comments in the doc, trying to fully understand the ramifications of this. It would seem just the MSBs would be bad, but is there more to it? I ask because I remember this coming up a while back, and there seemed to be more to it.
Just the 5 most significant bits (for a 27-bit to 32-bit translation). I had thought it was worse at the very start but that was quickly narrowed down, thanks to Ariba, to just a rollover problem affecting the extended bits only.
I've now even done a mock example on paper, just doing a regular spaced summing using 3-bit to 4-bit, and get the same effect of the extended bit toggling.
Can't this whole thing be solved by ignoring the top 5 MSBs of the final result?
That's effectively what both options achieve - Removal of those extra bits so they won't mess up anything later. Ie: You don't want those extraneous bits present when further filtering, or scaling, or even a simple print.
If not documented, it'll catch a lot of people out. Sure had me for a while. It's actually a generic binary maths thing but just one I've not dealt with until now surprisingly.
Maybe the documenting around it could be written more that way. That here's two simple solutions to translating between circular integer word sizes.
Actually, in hindsight, I have dealt with this before but it was couched within some servo hardware where I had to derive the encoder count from its error counter. This was all in C also. The error counter was 13 bits wide and so I used a bunch of masking to handle the translation to 32-bit. Didn't even think how relevant that might be to other situations. EDIT: On the other hand, the error counter wasn't circular in nature, even if the encoder was.
I'm looking at my Verilog source code and I put in comments that those bits would always be zeroes. Weird.
Does this affect SINC2 conversion mode or just SINC2/SINC3 raw modes?
It's not a smartpin problem at all. It's just the nature of circular maths arithmetic when mixing different word sizes. Ie: It's just in the software summing, the ADD and SUB.
Here's the 3-bit to 4-bit hand written paper version copied of the non-corrected software. It is simulating a fixed internal increase of 5 per decimation from the RDPIN:
RDPIN x, pin SUB x, diff ADD diff, xRDPIN Sample Next diff 3-bit accum 4-bit diff 4-bit store ============================================ 0 + 0 = 0 0 - 0 = 0 0 + 0 = 0 5 + 0 = 5 5 - 0 = 5 5 + 0 = 5 5 + 5 = 2 2 - 5 = 13 13 + 5 = 2 5 + 2 = 7 7 - 2 = 5 5 + 2 = 7 5 + 7 = 4 4 - 7 = 13 13 + 7 = 4 5 + 4 = 1 1 - 4 = 13 13 + 4 = 1 5 + 1 = 6 6 - 1 = 5 5 + 1 = 6The middle "sample" is the resulting "x". It holds the apparent glitching ADC reading that still needs masked back to 3 bits.
Of note is the slightly surprising stored 4-bit copy of the decimation always fits in 3 bits. ie: The restoring addition cancels the glitch.
It's amusing reading my evolving understanding. I wasn't fully on to real issue for quite some time. And even when I did get it completely I didn't post a clarification until now.
What I failed to do was print the suscessive components, as per above, in my early testing. I didn't know that RDPIN was producing a clean 27 bits. I guess I didn't know it was meant to be 27-bit either to be fair.
So, the 5 MSBs really are zeros?
For the RDPIN, yes.
Not for the resulting post-diff'd sample. Read my simulated example above (I've fleshed it out a little more). It shows the resulting diff'd "sample" as containing extraneous high-order bits. It should be consecutive 5's but has sporadic 13's in there. If using an &7 to mask it, it would be all 5's.
PS: I've been trying to make it clear that it's just a word size conversion issue in the software. The extra instruction is needed as part of doing circular arithmetic and bridging between word sizes.
EDIT: Actually, it's not even about bridging. It's just managing circular arithmetic at a non-native word size. The other method of scaling with a SHL converts to native word size and therefore doesn't need further masking.
I understand now. Thanks for explaining this, Evanh. I think what we need is a table to show SHR and ZEROX values to be used to trim each sample size.
Cool. My editing in the Google Doc was looking messy anyway. Suggestion mode leaves a trail of overlapping edits. Best to prep it elsewhere then do a single paste.
Chip,
In your updating, please do make it clear that the RDPIN decimations are 27-bit wide. Not knowing that ahead of troubleshooting definitely slowed down diagnosing of this issue.
PS: This whole issue has a lot of commonality with motion control on rotary equipment. I did tons of this stuff more than a couple decades back. Certainly wasn't expecting this conclusion when I starting problem solving this - an ADC in a microcontroller.
Here's a little piece of BASIC code from the servo controller of the first two wrapping machines, last updated in 1998. I don't think I could do this now. I loved the work at the time but it was strenuous thinking all the time. There was very limited memory in the servo controller and all source was on board so comments had to be small. It was kind of cool because you could pop open a dumb terminal and edit the whole program with that. It tokenised upon RUN.
#fastpos : REM (Dropped to 0v) REM Picture sync received REM ----------------------------------------------------------------- IF !PicOset | (FASTPOS.1 - PicPls < PackEnc * .75) THEN RETURN PackEnc = PackEnc + ((FP.1-PicPls+PackEnc*.5)%PackEnc-PackEnc*.5) * PicGn IF PackEnc > PackMax THEN PackEnc = PackMax PackR = PackEnc / InRev cam1(2) = INT(PackEnc / FinSect) PicPls = FASTPOS.1 RETURNWhat that is doing is dynamically recalibrating the nominal motion pack length, PackEnc, to match the measured distance between printed images on the wrapping, FASTPOS.1 - PicPls.
But to make that work as circular arithmetic requires to wrap (pun
) the measured distance to the existing pack length first. That's the modulo'd part, (..)%PackEnc. Just like masking a word size.
Super! I will update the doc today.
More detail on the SINCn would be appreciated...
I tried to use filtering modes but got nonsense...
Also, it's not clear whether or not one must retrieve a sample when in goes high.
You don't need to do this with the sampling SINC2 mode.
Maybe this is what I did wrong as I was just grabbing a value once per second...
You need to handle each sample, otherwise you'll lose track of the ongoing measurements.
Can I take, say, 5 samples in a row and then just use the last one as the result?
No, the syncN filters need to process all 5 samples. You can store the 5 values in an array an process them all together after 5 samples, but the sync filters only work if every value is taken into account.
With Sync2 Sampling, the smartpin hardware does this for you, that's why you can read the ADC result whenever you want in this mode.
Andy
Ok, I see this is more complicated than I thought... Guess I need to look at the code examples...