This is amazing.
So that clears up crosstalk or induced noise within the unit but- I wonder- (because I don't understand exactly what you've done!)- how does this effect a genuine noisy signal? and you want to see the noise?
This is amazing.
So that clears up crosstalk or induced noise within the unit but- I wonder- (because I don't understand exactly what you've done!)- how does this effect a genuine noisy signal? and you want to see the noise?
Dave
That noise would still be there. This just removes what the other signal is contributing.
Some mathematical musings: the 2-sample delay compensation is a simple 2nd-order digital filter, which is precisely what is needed because the problem is a 2nd-order one, namely the rate of change of the slope of the adjacent input. Unwanted effects are seen when there is a discontinuity in the slope. A 1-sample delay should be insufficient and a 3-sample one should not be any better than 2-sample.
A possible change to the software would be to fix the frequency and sweep the compensation scale to find the sweet spot, or sweep both at the same time.
Is there a simple way to see the raw signals in this display (non-windowed)? I know it would be noisier but it would be interesting to see the response reduce as the frequency is increased. Perhaps this window averaging might be causing the relatively slow displayed slew rate for square and sawtooth waveforms.
Is there a simple way to see the raw signals in this display (non-windowed)? I know it would be noisier but it would be interesting to see the response reduce as the frequency is increased. Perhaps this window averaging might be causing the relatively slow displayed slew rate for square and sawtooth waveforms.
The filter has 68 taps that the ADC bits must pass through. That's a bandwidth limiter, plus there's the roll-off of the analog front end of the ADC. I really want to redesign the ADC to give it more bits, make it independent of modes, and clean up the MUX problem. Just cutting away the PinB selection would solve the worst problem.
Ok. I can see the response reduce when I increase this line up towards 3 MHz. Square wave amplitude holds up for the longest, which makes sense if its output voltage remains at the extremities longer.
E.g
dds_freq = 3000_000.0 'nominal DDS frequency (without FM'ing)
The windowing/filter stuff really seems to impact the displayed slew rate.
At the original lower frequency I would have naively expected a waveform as something looking like Figure3 from this link below, but I guess all the extra front end processing does more than that.
Ok. I can see the response reduce when I increase this line up towards 3 MHz. Square wave amplitude holds up for the longest, which makes sense if its output voltage remains at the extremities longer.
E.g
dds_freq = 3000_000.0 'nominal DDS frequency (without FM'ing)
The windowing/filter stuff really seems to impact the displayed slew rate.
At the original lower frequency I would have naively expected a waveform as something looking like Figure3 from this link below, but I guess all the extra front end processing does more than that.
I've found a way to fix the ADC crosstalk problem by cutting a trace on metal layer 2 to eliminate PinB from getting into the ADC's input resistor array, where it mixes (accidentally) with PinA. This would be possible to work into the next wafers at minimal cost. It would also mean that you could not use the ADC on the adjacent pin, but only on the pin, itself. Probably, nobody would care about this. It's way more important that each pin's ADC can work independently, without coupling unwanted signal from its adjacent pin.
The bigger problem would be reworking our I/O test program that runs on ON's wafer prober, since it uses PinB-to-ADC mode. I'm looking into that now.
Does just using one pin in a pair solve this issue in the current silicon?
Also, is there any advantage to having the pair of pins tied to the same analog signal?
This doesn't sound like the kind of issue that is worth redoing the silicon, to me anyway...
Using just one pin, and making sure the other pin is QUIET, will do the job. Or, tying your analog signal to both pins, in which case you can get an extra bit of resolution.
If we do this, it may only be a $5k mask charge for either M2 or VIA2. It doesn't impact wafer delivery, as they are weeks away from processing the metal layers.
Price is right. But, I'd be afraid of doing a full scale production run with untested masks...
Will OnSemi verify that the change won't mess anything up?
Using just one pin, and making sure the other pin is QUIET, will do the job. Or, tying your analog signal to both pins, in which case you can get an extra bit of resolution.
If we do this, it may only be a $5k mask charge for either M2 or VIA2. It doesn't impact wafer delivery, as they are weeks away from processing the metal layers.
It's common for MCUs to have 'rules' around their ADC pins, around quietest pins/crosstalk etc, and some specify switching to IDLE during ADC conversion for lowest noise...
I'm with Rayman, not sure this is worth the risk/benefit.
Looking at this from ST makes me think it's a common problem...
Also, these two pins are likely to have coupling issues due to the traces leading away from MCU as well.
For that reason, you probably want to use only one of a pair of pins anyway..
Still a fan of being bold, and eliminating errata when it makes sense.
Okay, so how much of a predicted effect does this mask change have on the crosstalk? Will it eliminate it, or will there still be some crosstalk like it gets reduced by 25% but still there?
Because if there is still going to be some immediately noticeable crosstalk, and the solution is still a software fix, the mask change doesn't solve anything and is just extra time and money.
And risk. What onsemi can do on their end, is not throw away the old mask(s). Try a run with the new masks, change your test program, pass testing, ship.
Or fail, and if it's a bad or misaligned mask onsemi will fix it and try again. Or given some other unforeseen effect, you go back to the old mask.
Sounds like this could become a HUGE amount of time for many people in the chain to spend on something that can be solved in no time at all by simply using non-pairs, or even non-group pins, with the current mask. Not to mention opportunity cost, as you'll be distracted from Spin2/etc..
Did you find some really compelling reason to consider the mod ?
Otherwise, what you said above "Or, tying your analog signal to both pins, in which case you can get an extra bit of resolution.".....
That seems like a fine reason to keep your design as-is, and document that recommendation as a feature.
Seems like that's a good feature to me: Joined pairs for highest resolution, alternate pins for medium resolution, and adjoining pins for lower resolution.
Seems like that's a good feature to me: Joined pairs for highest resolution, alternate pins for medium resolution, and adjoining pins for lower resolution.
Seems like that's a good feature to me: Joined pairs for highest resolution, alternate pins for medium resolution, and adjoining pins for lower resolution.
Yes, agree.
This works for me too. And there is a software fix also.
But SETSCP/GETSCP work on a 4-pin block and if one pin in a pair is unused or both tied together it will be 2-channel, not 4-channel, and half the data will be wasted?
Aside from a single layer mask expense, I would just need to rewrite the test program to not use that pin B mode. I'm looking at that right now. It's really not that complicated, but makes the scope modes work like they're supposed to.
The risk of making this change is extremely low. It just takes some time for me to rewrite the test program.
What happens when you drive pairs of pins in differential mode? Do you get an added crosstalk on one pin and a subtracted crosstalk on the other? Remember, sigma delta conversion is notorious for out of band oscillations, like those period 7 "1011011" patterns that are so hard to suppress. But of course; if you could get an equal and opposite effect which cancels out around the problem "codes" then the achievable bandwidth goes up, I'm tempted to say - exponentially; maybe speaking figuratively or maybe not - because there is a type of "modulator" known as a "Weaver" modulator, that for example is used to make SSB signals by first modulating an audio signal with a 1.5 kilohertz pair of carriers, i.e. for SSB speech. Really, its just an analog implementation of the first stage of Cooley-Tukey FFT using ring modulators, but because it turns, let's say a 3kHz bandwidth audio signal into four 1.5 kHz bandwidth signals, you get the effect of doubling the A to D bandwidth if you follow the Weaver with a set of modulators instead of upconverting to an SSB carrier frequency. Or you can get 10 or 20 Mhz. bandwidth from a 5 to 10 Mhz. oscilloscope front end, or double that if you cascade a pair of Weaver filters. So if the is a silver lining among the clouds of grey, it is that if you have ever looked at the schematic of a 555, or 741 or an analog three terminal regulator, especially those three terminal regulators; because they have to use the ratio of a set or set of matched resistors to compare to junction intrinsic (Ebers-Moll equation again?) characteristic of two different junctions, so as to be able to use a bizarre arrangement of logarithmic convertors to compensate for temperature and produce a constant output voltage. Which means, likewise, if there is an exact - very precisely controlled amount of parasitic crosstalk that can be perfectly cancelled in software among the pins, then it is possible to exactly compensate for gain differences in the internal and external circuity, in addition to computing the cross-talk cancellation factor, which is also the "chopper" factor if you are doing instrumentation like EEG, EKG, etc., and you need near ZERO dc offset and near ZERO drift and as complete 1/f cancellation when you compare the summation of "count bits" on each of the pins with the filter outputs.
How much crosstalk is there between non-paired pins? There is likely still some from the pcb and package. Digital outputs have a low impedance and probably aren't a good representation of an analog source. Maybe 50 ohms from digital output to ADC, or use a reduced drive mode.
How much crosstalk is there between non-paired pins? There is likely still some from the pcb and package. Digital outputs have a low impedance and probably aren't a good representation of an analog source. Maybe 50 ohms from digital output to ADC, or use a reduced drive mode.
Very little between non-paired pins, but between paired pins, the crosstalk is at about -24dB, which is really high, about 4 bits down.
Comments
Thanks for suggesting a math solution. It wasn't occurring to me that something could be done in software. I was only thinking about hardware.
This technique is good enough for SCOPE mode, but for high-resolution conversions, some pin-use considerations are going to be necessary.
This is amazing.
So that clears up crosstalk or induced noise within the unit but- I wonder- (because I don't understand exactly what you've done!)- how does this effect a genuine noisy signal? and you want to see the noise?
Dave
That noise would still be there. This just removes what the other signal is contributing.
A possible change to the software would be to fix the frequency and sweep the compensation scale to find the sweet spot, or sweep both at the same time.
The filter has 68 taps that the ADC bits must pass through. That's a bandwidth limiter, plus there's the roll-off of the analog front end of the ADC. I really want to redesign the ADC to give it more bits, make it independent of modes, and clean up the MUX problem. Just cutting away the PinB selection would solve the worst problem.
E.g
dds_freq = 3000_000.0 'nominal DDS frequency (without FM'ing)
The windowing/filter stuff really seems to impact the displayed slew rate.
At the original lower frequency I would have naively expected a waveform as something looking like Figure3 from this link below, but I guess all the extra front end processing does more than that.
https://sound-au.com/articles/squarewave.htm
Figure 3 is what the ADC analog front end sees, but the 68-tap filter absolutely limits slew.
Its just nice that the scope mode does so much work for you.
The bigger problem would be reworking our I/O test program that runs on ON's wafer prober, since it uses PinB-to-ADC mode. I'm looking into that now.
Meanwhile, here is the fix:
Also, is there any advantage to having the pair of pins tied to the same analog signal?
This doesn't sound like the kind of issue that is worth redoing the silicon, to me anyway...
Using just one pin, and making sure the other pin is QUIET, will do the job. Or, tying your analog signal to both pins, in which case you can get an extra bit of resolution.
If we do this, it may only be a $5k mask charge for either M2 or VIA2. It doesn't impact wafer delivery, as they are weeks away from processing the metal layers.
Will OnSemi verify that the change won't mess anything up?
It's common for MCUs to have 'rules' around their ADC pins, around quietest pins/crosstalk etc, and some specify switching to IDLE during ADC conversion for lowest noise...
I'm with Rayman, not sure this is worth the risk/benefit.
Also, these two pins are likely to have coupling issues due to the traces leading away from MCU as well.
For that reason, you probably want to use only one of a pair of pins anyway..
Okay, so how much of a predicted effect does this mask change have on the crosstalk? Will it eliminate it, or will there still be some crosstalk like it gets reduced by 25% but still there?
Because if there is still going to be some immediately noticeable crosstalk, and the solution is still a software fix, the mask change doesn't solve anything and is just extra time and money.
And risk. What onsemi can do on their end, is not throw away the old mask(s). Try a run with the new masks, change your test program, pass testing, ship.
Or fail, and if it's a bad or misaligned mask onsemi will fix it and try again. Or given some other unforeseen effect, you go back to the old mask.
Did you find some really compelling reason to consider the mod ?
Otherwise, what you said above "Or, tying your analog signal to both pins, in which case you can get an extra bit of resolution.".....
That seems like a fine reason to keep your design as-is, and document that recommendation as a feature.
Seems like that's a good feature to me: Joined pairs for highest resolution, alternate pins for medium resolution, and adjoining pins for lower resolution.
This works for me too. And there is a software fix also.
The risk of making this change is extremely low. It just takes some time for me to rewrite the test program.
Very little between non-paired pins, but between paired pins, the crosstalk is at about -24dB, which is really high, about 4 bits down.