Shop OBEX P1 Docs P2 Docs Learn Events
Problem with SincN filtering in smartpins - Page 2 — Parallax Forums

Problem with SincN filtering in smartpins

2

Comments

  • 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.
  • evanhevanh Posts: 15,126
    edited 2020-11-13 18:18
    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.

  • Ok thats exciting I hope it can be made to work

    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
  • evanhevanh Posts: 15,126
    ManAtWork wrote: »
    But there were no glitches and fairly low noise.
    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.

  • evanhevanh Posts: 15,126
    edited 2020-11-14 03:23
    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.
    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  27527931
    
  • evanhevanh Posts: 15,126
    Graphed version of above:
    low-vs-gio.png
    high-vs-vio.png
    960 x 511 - 112K
    927 x 539 - 116K
  • evanhevanh Posts: 15,126
    edited 2020-11-18 06:50
    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 ...

  • evanhevanh Posts: 15,126
    edited 2021-05-10 03:53

    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.

  • evanhevanh Posts: 15,126
    edited 2021-05-10 07:25

    [bah, testing wrong code]
    Nothing to see this time :)

  • cgraceycgracey Posts: 14,133

    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.

  • evanhevanh Posts: 15,126
    edited 2021-05-10 23:14

    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.

  • cgraceycgracey Posts: 14,133

    @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?

  • evanhevanh Posts: 15,126
    edited 2021-05-11 00:28

    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.

  • evanhevanh Posts: 15,126
    edited 2021-05-11 01:06

    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.

  • cgraceycgracey Posts: 14,133

    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?

  • evanhevanh Posts: 15,126
    edited 2021-05-11 02:31

    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.

  • evanhevanh Posts: 15,126
    edited 2021-05-11 06:05

    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, x
    
        RDPIN          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 =  6
    

    The 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.

  • evanhevanh Posts: 15,126

    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.

  • cgraceycgracey Posts: 14,133

    @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.

    So, the 5 MSBs really are zeros?

  • evanhevanh Posts: 15,126
    edited 2021-05-11 12:22

    @cgracey said:
    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.

  • cgraceycgracey Posts: 14,133

    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.

  • evanhevanh Posts: 15,126

    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.

  • evanhevanh Posts: 15,126
    edited 2021-05-11 13:54

    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
    RETURN
    

    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.

  • cgraceycgracey Posts: 14,133

    @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.1
    RETURN
    

    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.

    Super! I will update the doc today.

  • RaymanRayman Posts: 13,805

    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...

  • cgraceycgracey Posts: 14,133

    @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.

  • RaymanRayman Posts: 13,805

    Can I take, say, 5 samples in a row and then just use the last one as the result?

  • AribaAriba Posts: 2,682

    @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.

    Andy

  • RaymanRayman Posts: 13,805

    Ok, I see this is more complicated than I thought... Guess I need to look at the code examples...

Sign In or Register to comment.