According to Ali Express my additional 8 sources have made it to the US. The package likely will take some time to make it through customs, though.
-
Welcome back Guest! Did you know you can mentor other members here at H-M? If not, please check out our Relaunch of Hobby Machinist Mentoring Program!
Needing more than a spark test?
- Thread starter graham-xrf
- Start date
Analog's product selection web page has just become unusable for me. I have a Firefox type browser.
Even with all scripts enabled, the parametric product selection page was not letting me select options, like "number of bits".
The cores temperature monitors rock up from about 56C to a stonking hot 75C. The CPU usage shows all four cores are hitting 100%.
The browser pop-up says "A web page is slowing your system down" with options to "Force Quit", or "Wait".
The network shows a series of packets going up, and a lesser series coming down, even if I don't move anything.
I don't really know what is going on, but it looks like s_hitty programming somewhere?
Selection from the Mouser site is a second best work-around.
Even with all scripts enabled, the parametric product selection page was not letting me select options, like "number of bits".
The cores temperature monitors rock up from about 56C to a stonking hot 75C. The CPU usage shows all four cores are hitting 100%.
The browser pop-up says "A web page is slowing your system down" with options to "Force Quit", or "Wait".
The network shows a series of packets going up, and a lesser series coming down, even if I don't move anything.
I don't really know what is going on, but it looks like s_hitty programming somewhere?
Selection from the Mouser site is a second best work-around.
Worked recently for me, but then again I had a strange unexplained computer shutdown the other day. All while I had Firefox running with too many tabs. System monitor thought I had tons of memory. One of those tabs was a product selection table from ADI. Probably coincidence.Analog's product selection web page has just become unusable for me. I have a Firefox type browser.
Even with all scripts enabled, the parametric product selection page was not letting me select options, like "number of bits".
The cores temperature monitors rock up from about 56C to a stonking hot 75C. The CPU usage shows all four cores are hitting 100%.
The browser pop-up says "A web page is slowing your system down" with options to "Force Quit", or "Wait".
The network shows a series of packets going up, and a lesser series coming down, even if I don't move anything.
I don't really know what is going on, but it looks like s_hitty programming somewhere?
Selection from the Mouser site is a second best work-around.
OK - whatever that hangup is, "mostly "goes away" if one declines all cookies. A brief CPU flurry, and then it all settles down.
In general, I know Firefox, and most other browsers can be a system and memory hog, but that site is special.
Don't care! So long as it works again!
@homebrewed :
Hi Mark
When you get your USB isolator, could you have a little look at what it does.
I read things like "1500V isolation", and I get it that you can use opto-coupler chips, and the outputs can borrow power from the destination, but we want to know about the 5V.
Are they really little switcher PSUs as well?
The power requirements for the analogs are so little that I am considering a tiny, hopefully very low cost, high frequency charge pump or switcher, and a LDO low noise regulator like yours.
Hi Mark
When you get your USB isolator, could you have a little look at what it does.
I read things like "1500V isolation", and I get it that you can use opto-coupler chips, and the outputs can borrow power from the destination, but we want to know about the 5V.
Are they really little switcher PSUs as well?
The power requirements for the analogs are so little that I am considering a tiny, hopefully very low cost, high frequency charge pump or switcher, and a LDO low noise regulator like yours.
Yes it's an interesting question regarding the transfer of power across the isolator. Small switchers are cheap these days; and, given the form factor, that's a high probability.
A little more searching through the product description on Amazon indicates that the isolator can output up to 200mA @ 5V. So while it does cost a bit, it doesn't require an outboard power supply. At least not for the expected kind of usage.
As a data point, a Teensy 4.1 driving an ILI9341 display (running an ELS program) but not actually attached to a lathe or DRO, consumes about 170 mA from the 5V. The display is powered off 5V and regulated down to 3.3V on the ILI9341. Can't claim it is representative, but the program is running and the display menu is lit.
My replacement order from Digikey arrived today, a bit later than promised, but it did arrive. Have the components for the ADC board, and some fancy LTC op amps, the LTC6268-10 in MSOP-8 and the LTC6269-10 in MSOP-8 and LTC6269 in DFN10 to cobble up a front end. I found a SMD proto-board that I had been saving, but I have to measure the pin spacing on the art work. Even now, a decade later, it is tough to find SMD prototyping boards. It's hard to find much, never mind ones that are useful. Might just go straight to PCB, since its so much easier than dead bugging such tiny stuff. I have prototyped with adapters, but using a PCB is a lot better.
It seems that the original order was finally discovered. It appears to be in transit. May end up returning some of the material, since Digikey will end up charging me for it. (If I receive it, that is.)
My replacement order from Digikey arrived today, a bit later than promised, but it did arrive. Have the components for the ADC board, and some fancy LTC op amps, the LTC6268-10 in MSOP-8 and the LTC6269-10 in MSOP-8 and LTC6269 in DFN10 to cobble up a front end. I found a SMD proto-board that I had been saving, but I have to measure the pin spacing on the art work. Even now, a decade later, it is tough to find SMD prototyping boards. It's hard to find much, never mind ones that are useful. Might just go straight to PCB, since its so much easier than dead bugging such tiny stuff. I have prototyped with adapters, but using a PCB is a lot better.
It seems that the original order was finally discovered. It appears to be in transit. May end up returning some of the material, since Digikey will end up charging me for it. (If I receive it, that is.)
I have an update regarding my ADC board and driver. My test results are both encouraging and discouraging.
After thinking over the timing requirements and concerns regarding noise coming from the digital outputs banging around, I substantially changed the driver code. I'm still going with the T4.0 approach, but instead of driving the CNV\ and RD\ pins simultaneously, initially I just set RD\ LOW to read the data out from the last conversion. So the SAR stuff isn't running. At the end of the entire data acquisition I set RD\ HIGH and only then trigger the next conversion by pulsing CNV\ low for a bit over 10nS. Along with that, one important change was to implement a different approach to getting the necessary delays to make the ADC happy.
I've seen that changing various delays can radically change what's being read out from the ADC, so I did some extensive benchmarking of different approaches to getting repeatable delays and I only found a few that seemed useful for the purpose. The first, to get the fairly long ~45nS delays needed for the data outputs to settle, was answered by using the delayNanoseconds() function -- but the argument passed to the function is nowhere NEAR 45 (ns). It actually needs to be 27 ns. Probably due to setup and loop overhead in the delay routine. For the 10nS delay needed to make sure the ADC's conversion is properly triggered I found that adding a value to a volatile 32 bit unsigned integer is just about right. To foil any compiler optimization stuff I chose a value that is not a power of 2, but to be honest I haven't evaluated if the choice of the constant makes any difference.
Other folks who want to use delayNanoseconds() will likely want to do their own benchmarking for their particular requirements. I noticed some really odd behavior for small arguments -- in fact, in some cases the delay DECREASED when I increased the value of the argument. So just subtracting a fixed overhead value from the delay you want won't necessarily work. You have been warned.
After all that I fired up the driver code and got -- nothing. All zeroes. This was with grounding the input to the buffer amp. Well, H*ll. Out of desperation I connected the input to the ADC's Vref voltage. Whoa -- I got 65535! Exactly what one would expect. Well, now. Time to get out the signal generator and see what I get.
And here it is:
The signal generator was outputting about a 1V triangle wave for this. For further proof that the ADC baseline noise level is pretty low, I reduced the amplitude of the sig gen to 1mv p-p and I got this:
I think the signal generator's DAC isn't all that great, but it IS surprising to me that a 1mvp-p signal only spans 6 bits -- it should be closer to 27 bits. Maybe there's something else going here. Or maybe my cheap sig gen isn't all that accurate....something else to look at....
But now for the downer, and I'm sure you all noticed just now bumpy the larger-amplitude triangle wave looks. Well, that appears to be due to an assembly problem on my part. When I was soldering the ADC down I had a pretty difficult time and thought I had broken off one of the data pins. I was able to solder a wire from what (I thought) remained of the pin to the circuit board trace and called it a win -- but apparently the pin was NOT broken, but bent underneath the package. Where it shorted to an adjacent data pin. Now the funny bumps in the waveform make some sense
After looking at the situation very closely with my stereomicroscope, I don't think there is any way to rescue the board without completely removing the ADC chip and starting over again. If that's possible. I have a toaster oven I bought just for the purpose of soldering SMT parts (and heat treating metal) so that may work -- but some of the other stuff on the board may be toast. I'm thinking particularly of the headers, they don't seem to be particularly happy being exposed to molten-solder temperatures. But I do have several other boards. Probably the best thing to do is to order another ADC, just in case my rework attempt ends badly. And probably a few more headers.
The board I used for this only has one modification. I added a hefty jumper wire connecting the digital ground @C2 to the input ground pin. But I also made a special +5/Gnd connector that has a 10uF capacitor between the two, in an attempt to cut down on noise coming from the USB +5. None of the control signal lines have any series damping resistors -- if anything, that made things worse rather than better.
So Bruce may not find it necessary to do much, if any, modifications to the ADC board I sent him.
In retrospect what I _should_ have done was to pre-tin the ADC pads on the board, and do the same to the package pins. I've found that applying solder flux to the board and the package pins before tinning them has the happy effect of almost completely eliminating solder bridging (at least, when the flux is left on the board when they're soldered together). So using a relatively blunt solder tip (relative to a very small package pin) works out OK.
After thinking over the timing requirements and concerns regarding noise coming from the digital outputs banging around, I substantially changed the driver code. I'm still going with the T4.0 approach, but instead of driving the CNV\ and RD\ pins simultaneously, initially I just set RD\ LOW to read the data out from the last conversion. So the SAR stuff isn't running. At the end of the entire data acquisition I set RD\ HIGH and only then trigger the next conversion by pulsing CNV\ low for a bit over 10nS. Along with that, one important change was to implement a different approach to getting the necessary delays to make the ADC happy.
I've seen that changing various delays can radically change what's being read out from the ADC, so I did some extensive benchmarking of different approaches to getting repeatable delays and I only found a few that seemed useful for the purpose. The first, to get the fairly long ~45nS delays needed for the data outputs to settle, was answered by using the delayNanoseconds() function -- but the argument passed to the function is nowhere NEAR 45 (ns). It actually needs to be 27 ns. Probably due to setup and loop overhead in the delay routine. For the 10nS delay needed to make sure the ADC's conversion is properly triggered I found that adding a value to a volatile 32 bit unsigned integer is just about right. To foil any compiler optimization stuff I chose a value that is not a power of 2, but to be honest I haven't evaluated if the choice of the constant makes any difference.
Other folks who want to use delayNanoseconds() will likely want to do their own benchmarking for their particular requirements. I noticed some really odd behavior for small arguments -- in fact, in some cases the delay DECREASED when I increased the value of the argument. So just subtracting a fixed overhead value from the delay you want won't necessarily work. You have been warned
.After all that I fired up the driver code and got -- nothing. All zeroes. This was with grounding the input to the buffer amp. Well, H*ll. Out of desperation I connected the input to the ADC's Vref voltage. Whoa -- I got 65535! Exactly what one would expect. Well, now. Time to get out the signal generator and see what I get.
And here it is:
The signal generator was outputting about a 1V triangle wave for this. For further proof that the ADC baseline noise level is pretty low, I reduced the amplitude of the sig gen to 1mv p-p and I got this:
I think the signal generator's DAC isn't all that great, but it IS surprising to me that a 1mvp-p signal only spans 6 bits -- it should be closer to 27 bits. Maybe there's something else going here. Or maybe my cheap sig gen isn't all that accurate....something else to look at....
But now for the downer, and I'm sure you all noticed just now bumpy the larger-amplitude triangle wave looks. Well, that appears to be due to an assembly problem on my part. When I was soldering the ADC down I had a pretty difficult time and thought I had broken off one of the data pins. I was able to solder a wire from what (I thought) remained of the pin to the circuit board trace and called it a win -- but apparently the pin was NOT broken, but bent underneath the package. Where it shorted to an adjacent data pin. Now the funny bumps in the waveform make some sense
After looking at the situation very closely with my stereomicroscope, I don't think there is any way to rescue the board without completely removing the ADC chip and starting over again. If that's possible. I have a toaster oven I bought just for the purpose of soldering SMT parts (and heat treating metal) so that may work -- but some of the other stuff on the board may be toast. I'm thinking particularly of the headers, they don't seem to be particularly happy being exposed to molten-solder temperatures. But I do have several other boards. Probably the best thing to do is to order another ADC, just in case my rework attempt ends badly. And probably a few more headers.
The board I used for this only has one modification. I added a hefty jumper wire connecting the digital ground @C2 to the input ground pin. But I also made a special +5/Gnd connector that has a 10uF capacitor between the two, in an attempt to cut down on noise coming from the USB +5. None of the control signal lines have any series damping resistors -- if anything, that made things worse rather than better.
So Bruce may not find it necessary to do much, if any, modifications to the ADC board I sent him.
In retrospect what I _should_ have done was to pre-tin the ADC pads on the board, and do the same to the package pins. I've found that applying solder flux to the board and the package pins before tinning them has the happy effect of almost completely eliminating solder bridging (at least, when the flux is left on the board when they're soldered together). So using a relatively blunt solder tip (relative to a very small package pin) works out OK.
This is all getting good - except for the bent pin.
Getting all zeros when the input is shorted is, in concept, what is supposed to happen.
I practice, if all zeros happens, without at least some activity in the last two or three bits, that is cause to suspect something might not be all OK.
If all is well, you should sometimes see the LSB +/- 1 uncertainty.
A count of as low as 20 is more than 70dB down on a 2.5V reference, yet would be jangling the last five bits.
A count as low as (say) 5, (101), is 82dB down, and claimed SNR is 89dB, so a shorted input might give all zeros.
Except for the assembly mishap, I think you are doing great!
Re: The signal generator waveform. I am not sure about 27 bits. We only have 16.
1mV p-p out of a 2.5V reference is 2500 count, which requires 12 bits.
It can be tricky to deliver a signal generator signal in clean without also bringing in at least some unwanteds, and when it is reduced to only 1mV, they may start to show.
I still think you are acing this!
- except for the bent pin. Getting all zeros when the input is shorted is, in concept, what is supposed to happen.
I practice, if all zeros happens, without at least some activity in the last two or three bits, that is cause to suspect something might not be all OK.
If all is well, you should sometimes see the LSB +/- 1 uncertainty.
A count of as low as 20 is more than 70dB down on a 2.5V reference, yet would be jangling the last five bits.
A count as low as (say) 5, (101), is 82dB down, and claimed SNR is 89dB, so a shorted input might give all zeros.
Except for the assembly mishap, I think you are doing great!
Re: The signal generator waveform. I am not sure about 27 bits. We only have 16.
1mV p-p out of a 2.5V reference is 2500 count, which requires 12 bits.
It can be tricky to deliver a signal generator signal in clean without also bringing in at least some unwanteds, and when it is reduced to only 1mV, they may start to show.
I still think you are acing this!
Last edited: