That would be a very important application of the Nano because clamp on ampmeters are extremely useful for troubleshooting many current demand situations. They are used to observe current waveforms in addition to DC values. They have become another valuable o’scope probe.
Maybe BenF would consider this possibility in the measurements function, with a new measurement value that converts the milli-volts to ampere values.
Just an extension of your idea…
ingra- how would he do the ranges- there are 3 common ranges 1mv=1amp 10mv=1amp =100mv=1amp, it wouldnt be usefull unless all three were implimented, i use the first one for starter relitive compression checks, the second one for alternator ripple measurements and diesel injectors… and the third is the most used for coil/injector/iac and such… i think you have a good idea, i guess the options would be 10amp(100mv=1A) 100amp(10mv=1A) 1000amp(1mv=1A) these would be your max current ranges in those ranges
After expending more thought on this matter, your idea of an attenuator might be the better approach for evaluating amp clamp waveforms. It could be handled as a configurable custom probe (in lieu of 1x and 10x) using user configuration parameters. This would also allow users to connect custom probes with alternate attenuation for voltage applications. If it can be done for one custom probe, then a couple of custom probes could also use the same structure.
A configuration pop-up that would allow the user to select input ratio choices of 1,2,3,5,10,100,1000 and then allow the user to select output ratio choices of 1,2,3,5,10,100,1000. Also allow the user to select the output choice of V or A. Now the input voltage would be scaled for this custom probe (using the user selected ratio), the vertical units could display V or A, and this custom probe could be saved with the configuration data.
BenF is much better at sorting out the menu organization and he most likely has a better idea. In summary, the custom probe concept would have many applications beyond amp clamps.
Improved support for non standard probes is probably a good idea, but it will be a challenge to implement this in a way that will be intuitive, logical and easy to use. Changing the user interface to use terms like Amp/Div, delta amps and amp trigger level seems awkward. Also we would not want to limit ourselves to amps, but also consider that custom probes may be used for pressure, energy, mass, force and what not. As it is now we can use any such probe as long as they output a voltage/frequency that fit within Nano hardware constraints, but then measurements may require a final conversion step (perhaps something for the XML analyzer).
A custom probe with user configurable gain/attenuation might work and I’ll keep that in mind for future upgrades.
Maybe this would be much simpler if the user just configured the ratio units required to reflect the desired units in volts, milli-volts, etc, and then calls the voltage units by another name such as amps, pressure, strain, or what-ever units. Then the Nano can stay with voltage units displayed. For example for 10mv = 100ma, then the user just selects a probe ratio of (1 input unit = 10 out units) probe ratio and the 10mv would convert to 100mv and the user would call that 100ma, or in other examples other 100m-Units.
Just another discussion of the feature.
Hello, I think brandonb aproach would be much simpler for an amp probe like the one on this video.
youtube.com/watch?v=gMq26dubD5I
thanks a lot for your great improvements.
It would be also be nice to have a possibility to save several calibration settings (like with the preferences, one as power on default and some ‘customized’). This wound help to re-calibrate the whole system of probe and oscilloscope for different probes.
Just updated my v1.1 DSO Nano to BenF 3.61. (Yeah I am slow…) Woah, what a difference!
Thank you very much for your work, your firmware rocks.
BenF,
Thanks a lot for all your work on this. I have few suggestions:
Faster refresh rate on Auto (and Norm) sync mode for higher TD (lower freq) because we can miss some changes. For example, you do not need to capture the whole buffer to display results on screen (you can use circular buffer, if you do not already use it and have last N records of any time).
It is not possible to see small interval changes on lower freq sample. If CPU allows, I would prefer to capture always on higher frequency, maybe always on 1 MHz. For each pixel on screen you can capture two dots: min and max value in appropriate time interval and display vertical line for each X (time dot on screen). On that way we can see if there are fast changes even on big TD (low freq). Then we can change the other parameters to capture that fast signal. Otherwise we do not know if these fast signals exist. This option reduces size of buffer to 2048, but it is still enough.
Scan "trigger’ option for faster TD, what CPU allows.
Currently there are different and strange results if we use Normal and Fast sampling. If 1-3 are made, then we do not need this option.
This is harder. Filters: Low, High and Mid. Probably this need few bytes of buffer for filtering. If we have, for example, high amplitude AC = 50Hz and some small signal of 1 kHz, it is hard to see that small signal. If we use High Pass filter f = 500Hz, we can see only that signal. Also if there are big high freq noise, we can reduce it with LP filter.
There could be other improvements (auto sync, FFT), but the 1 - 3 are the most important.
Regards,
Dejan
Hi BenF,
I was thinking more about my suggestions, and have another ideas.
Related to capturing always on higher possible frequency and MIN and MAX values, when I better think, it is better to capture three values:
To be able to save buffer memory, the normal average value can be stored with 8 bit, while DIFFERENCE of average value to Min and Max can be stored with 4 bit resolution per each (2x4 = 8 bit).
Because these 4 bit is very low resolution (only 16 values), and because these min and max will be usualy close to Average, the none linear converion is needed: Smaler distance need to be stored with bigger precision then other. For example, the table like this:
Diff Min/Max Value Diff stored in buffer
0 0
1 1
2 2
3 4
… …
7 7
8 8
< 10=8+2 8+1=9
< 12=8+4 8+2=10
< 16=8+8 8+3=11
< 24=8+16 8+4=12
< 40=8+32 8+5=13
< 72=8+64 8+6=14
= 136=8+128 8+7=15
There could be better non liner functions, but I guess this is simple to realize.
To simplify proggramimg, you can draw your lines as you alredy did, but before you draw line, the program displays the vertical line between min and max value with lower intesity color. There are other possibilitis to draw and fill lines between Mins and between Maxs with better look, but that is not important.
For auto option, if trigger is not found, while to wait 100ms for new display. Let’s display this as soon as possible, ot better, give the user posibilty to define that time.
If you need to extends your user interface with more options where some of them requires entering values (for previous option, fs for filters, …), I suggert to make routine for entring these numbers. I’ve put the picture what I’m using on my application which uses only 4 keys for user interface (Up/Down, Esc, Ok).
This option is not important and it is hard to implement, but it gives great look. If neded, it is possible to diplay full input resulution on smaler screen resolution using antialiasing lines which uses differnt color intesity. If somthing is between two pixels, but it more close to one, you can display an value with highr color intesity then on another. But the sum intesiy of all pixel need to be the same. Example from UBUNTU screen.
Regards,
Dejan
Vow! - That was quite a list of ideas and implementation details on your part.
Perhaps you could single in on your most desired enhancement and present a simple use case / example that I and others can comment on where you focus on the actual measurement and desired result rather than the implementation?
One of your ideas is to always sample at 1Mhz (the Nano maximum sample rate) for all T/Div’s. When we sample at 1MHz, time between 1st and last sample (for one capture cycle of 4098 points) is approximately 4ms. For a T/Div of 10ms, all we would see plotted then is a tiny waveform about 12 pixels wide. Surely this is not practical and so a compromise is needed.
Another idea of yours is to capture two points per on-screen pixel as opposed to one. With the current firmware and using fast buffer mode we capture 10 points per single pixel.
Visual perception is also an aspect to consider. Current refresh rate is 10Hz (300 points redrawn 10 times every second) and this is about as much as we humans can comprehend. If we increase refresh rate further, consecutive capture cycles will appear as if they blend together. If we need to capture a specific waveform detail we may be better off letting the DSO do the hard work (continues sampling) and then stop and show us (trigger) if and when an issue is found.
You’re also suggesting there are issues with using fast buffer mode and Normal trigger. Perhaps you could expand on this with some examples?
BenF;
The reason I ask is because many more users have function generators than variable DC voltage supplies. If we use an external calibrated o’scope to measure the input waveform amplitude, could we use something like Vpp?
Thanks
I would say any calibrated voltage source (AC or DC) close in amplitude/frequency to whatever you need the DSO calibrated for will do fine. Vavg may still be preferred since Vpp is a peak measurement that will include ripple if present. Personally I use a calibrated Fluke connected parallel with the Nano probe and so can use any available DC source (9V battery, car battery, lithium cell phone battery, USB port etc.).
Measurements are calculated from values in the capture/acquisition buffer with partial cycles excluded for AC waveforms.
BenF:
Sorry, but I have another question about the Nano. When the firmware detects a trigger condition during an acquisition, the trigger is always shown on a sample point. What happens if the trigger condition occurs between sample points. Does the firmware just interpolate that the trigger condition happened between two sample points, or does the firmware miss that trigger condition when it does not fall upon a sample point?
Thanks
An edge trigger condition is not satisfied from a single point, but as a transition across a lower and upper threshold as determined by trigger level, trigger sensitivity and trigger kind.
Let’s say we configure for a rising edge trigger and start with the waveform sitting well above trigger level. The waveform then drops below trigger level (or more precisely below the sensitivity band lower level) and now the first condition is satisfied. Eventually, the waveform will start to rise and once we reach or exceed trigger level (sensitivity band upper level), the second condition is satisfied and we have a successful trigger. That is a low to high transition crossing the sensitivity band (a rising edge). If the waveform starts out below trigger level, the same logic applies, but the first condition will be satisfied immediately.
Trigger position as marked on the DSO coincides with the sample point that satisfies the second condition.
BenF:
Thanks for that very thorough explanation. I had forgotten about trigger sensitivity because I usually keep that set to zero. Now I and others can completely understand the firmware trigger detection process.
Hi BenF,
I’m commenting “Sat May 07, 2011 2:52 am”.
First of all, thank you a lot for your time and improvements on this. I’m using DSO Nano occasionally for developing and servicing some machines with analog and digital signals less then 100 kHz. The small size of DSO nano makes it great.
I had two main problems (I’m using 3.61 version):
In most cases, I’m examining signals about 50 Hz (for example, controlling thyristors) and use TD ~ 5ms. The “Normal” and “Single” trigger mode work OK. But, before I use these modes, I wish to see the signal “in general” with AUTO mode. On this TD, the refresh rate is too slow (I didn’t measured, but lets say 0.2 - 0.5 sec), so I cannot see all signal changes and miss something.
There could be occasional high frequency components on low frequency changes. It is hard to see this high frequency change (at least you cannot set trigger for it).
My main suggestions are:
To increase refresh rate on auto mode for bigger TD, to be able to see what is going on with signal.
Always sampling at 1MHz. Unfortunately, you din’t understand my idea. Sorry for my bad English.
For example, let’s use TD=5ms. Currently, on Normal sampling mode you use fs=5kHz sampling and fill the buffer. You have 25 values per one time div. Because fs is only 5kHz, faster frequency changes (theoretically >= 2.5 kHz) looks very strange (or can be missed) and moved to low frequency. This is normal theoretical situation: if you sample 6kHz sine signal with 5kHz you will got 1kHz as result (I think?). Use my example in attachment and change the input frequency at filed B2 to: 100, 200, …, 1000, 2000, …, 6000 (the same as 1000).
My idea is following. For ONE pixel on screen (5ms / 25 = 20us), capture 20us / (1/1Mhz) = 200 samples. Calculate Average value, Min value and Max value for this set of 200 samples (you need just three variables), and put all three values in buffer and plot them on screen. You can use Average value as you did before to draw lines, while Min and Max value can draw vertical line with lower color intensity, or just plot two dots.
On that way we can DETECT and see high frequency changes amplitude even on low frequency signals. For example, if there is very small impulse with dt = 5us, we can miss it or display it occasionally. With min max values, we will always see this signal because we sample with dt = 1us (we will catch it 5 times).
For trigger modes, need to be option to catch only Average, or all three values. Or just use average value to simplify this.
This will reduce buffer size by factor 2 or 3 depending do you store Min and Max with 4 or 8 bits. Probably it is the bast just to store each value with 8 bits and simplify things and have real picture of signals, instead my idea I suggest in my second email (Min and Max with 4 bit none linear difference to average).
There could be option to enable or disable this mode.
–
Related to the Normal / Fast sampling modes, I have strange picture and the level of these signal are different. I expected that level on signal with high frequency can be higher (if it catch some high freq value), but I got opposite (I think, not sure now).
Anyway, with increasing refresh rate and sampling additional Min and Max values, we do not not need fast mode.
Thanks and regards,
Dejan
sine at 5kHz sampling.zip (38.2 KB)
For Open Office/Excel example: filed B1, not B2, sorry.
Benf,
Just few additional comments and ideas.
We need Average, Min and Max values per each t. You can use Average values as replacement for you old samples: for displaying waveform, triggers, saving, … The Min and Max can be used only for displaying high freq components with lower color intensity.
The nature of Average value is actually Low Pass filter, which is good and eliminates high freq noises. The Min and Max displays these high freq values. With current values we have these mixed and cannot see any of them on best way.
My idea for calculating Avg is simplest possible, and it is better then nothing. Theoretically, it is possible to make more quality Low pass filter (for this re sampling purpose) using formula c0v0 + c1v2 + c2v3 + … + cn vn, but this require memory for storing ci. I suggest to use my simplest possible approach suggestion.
Another ideas: in Normal and Single sync modes, we cannot see the signal until it is catched. It is possible to display always current signal changes, while triggered signal (and hold signal) could be displays with another color, for example red (actually light red for Avg value, and dark red for Min/Max). On this way we adjust trigger position and see signal while we are waiting on catching trigger.
The trigger mode is important option, so it has a sense to be separate menu, similar as TD, VD.
The Auto mode can be spitted in on two modes. Old Auto and new Auto which display new waveform immediately if trigger is not cached. It can be used in Normal and Single mode too for current “green” signal while holding signal is red.
Some links:
en.wikipedia.org/wiki/Circular_buffer
en.wikipedia.org/wiki/Xiaolin_Wu … _algorithm
en.wikipedia.org/wiki/Downsampling
Thanks,
Dejan
First of all, THANKS! This software is great!
In the FIT (auto scale) mode, it would be nice if it automatically adjusted the ground position such that the waveform is centered vertically. I tend to keep the ground position centered in the middle of the screen for bipolar signals (signals the swing both + and -). Then when I go to a digital signal (the output on the dso nano for instance) the displayed signal is asymmetric and compressed toward the top of the screen until I go and adjust the ground position. Quite often the peaks are off the top of screen as well when ground is not near the bottom.
Its not a big deal, but something that would save me from having to constantly re-adjust the ground position even when in FIT mode. I’d appreciate it if you could add it to the list of improvements.
Again … thanks for all the hard work.