Vertical Scale Error ?

[pjv]

Hi All;

I had complained (due to frustration unfortunately rather harshly) in the Sandbox forum about incorrect voltage readings on my prop scope, and have decided to shelve the unit until some better sofware opgrades come along.

Brad's comment about triggering caused me to think again about the scope, and I'm absolutely amazed that no one else has posted about experiencing the same gross error that I observed. In case it went unnoticed, I will repeat my observations here:

On applying a·2.5·V, 1 KHz positive signal on channel 1; at 5V vertival scale it displays correctly, and switching to 2V scale also, as with the 1 V scale. But switch to 0.5 V scale, the top line indicates just below the 1 volt graticule. And also at the 0.2 V scale. At the 100mV scale it reads just below 0.5 volts. Clearly some bad math is happening here.

I'm running 1.05h beta. If other's units don't exhibit these peculiarities, then could my install have been corrupted somehow?

I'd like to use the scope, but if I can't trust it,· I·can't use it. Does anyone else have similar findings??

Cheers,

Peter (pjv)


·

[Hanno]

Hi Peter,
I'm not monitoring the "Sandbox" forums- but I have thick german skin and am committed to solving PropScope problems as I'm made aware of them.

Your PropScope is actually working as designed- although maybe we need to make part of the documentation more obvious:
When you choose different vertical resolutions, the maximum +/- measurements that can be resolved changes. The PropScope software illustrates these maximum possible readings on screen- similar to other instruments. At .5V- the maximum reading is 1v, at .1V it's .5V.

So- when you input a 2.5V signal, they will be CLIPPED to the valid range.
Hanno

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer

[BradC]

Hanno said...

So- when you input a 2.5V signal, they will be CLIPPED to the valid range.

Is there a big red flashing notification saying "Input is being clipped" or does it just silently display incorrect readings?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Are you suggesting coconuts migrate?"

[Hanno]

Considering that the old USB Oscilloscope notified you that your signal was out of the -10..10v range by releasing its magic smoke, the fact that the PropScope indicates the valid measurement area on screen is an improvement. I'll add a "Input is being clipped" message in flashing red.
Hanno

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer

[BradC]

Hanno said...
Considering that the old USB Oscilloscope notified you that your signal was out of the -10..10v range by releasing its magic smoke, the fact that the PropScope indicates the valid measurement area on screen is an improvement. I'll add a "Input is being clipped" message in flashing red.

Personally I'm not fussed, I often _way_ overdrive the input range to give me more resolution around the zero cross point anyway (like I use very high sample rates to look at small portions of a waveform).

All the scopes I have here clearly demonstrate the waveform is out of range when the wave disappears off the top and bottom of the screen. Your software does not do that as you can scroll the screen window around and therefore you end up looking at a severely clipped waveform. For someone who does not know how the system works, this appears that there is something very wrong with the measurements.

I'd even go as far as removing the measurements from the measure window if its obvious the signal is being clipped (or make them red or something), or else it's just displaying garbage.

While I'm here.
Start PropScope software
View->Full Screen
Click the "Run" button to stop the scope.
Click the "Run" button to start the scope.
Entire screen goes white.
Have to hit "esc" to get back to normal mode.

Intermittently when I do this the scope locks up solid and I have to re-start the software to get any traces displayed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Are you suggesting coconuts migrate?"

[wastehl]

I have seen this exact problem with 1.04, and "bad" numbers in the measurement frame as well, fortunately, I had a handle on what the numbers should be and adjusted the scale accordingly. I was looking at waveform data, so this did not hold me up. It was perplexing for a while, however. An "out of range" indicator would be convenient. All in all, this is a good product. It performs as well as other USB scopes costing considerably more, even given some of the "quirks."

Any news on the 1.05 front?

Cheers,

Bill

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Propeller, Revolutionary Power...

[Paul M]

I recently bought the Propscope as I wished to support the propeller. I know that "one only gets what one pays for". However, I was a little bit dissappointed after spending £230. I know there is really only the base range Pico scope to compare and as I have not used it I shall try and not be too harsh.

Back to the topic, this got me also. Unfortunately, I was using the X10 probe settings and is this mode the dotted markers which indicate the max input range are not shown.

Whilst I am here, a list of other annoying "design features" in no particular order of annoyance

1.Changing the vertical scale seems to randomly change the position of the 0V axis. Sometimes the shift is so much that the entire valid measurement range dissappears.
2.Using <Tools> <Manage Probes> resets the Vertical scaling and the Timebase settings to some default value
3.Changing timebase setting seems to randomly shift the horizontal graph position.
4.Repositioning the Ch1 trace causes the Ch2 trace position to move also although it never shifts more than 1 division. However, shifting Ch2 trace has no effect on Ch1. This seems to be because Ch1 can be adjusted infinitely but Ch2 is limited to 1 division shifts; whichever is used it should be consistent.
5.the previous behaviour also has the effect that the label for 0V on Ch2 is not always displayed. This is very confusing. Ch1 0v is alway labelled
6.If one of the traces is completely shift off the screen, as in 1. above, and the other channel is on it is not possible to get the first trace back.
7.Saving the data to the clipboard or to a text file seems to save only 225 samples, which are the ones actually displayed. Since almost twice as much data is available it would make sense to save all of it. This would allow more resolution by using faster timebase and examining the data in for example Excel.
8.When the scope is waiting for a trigger and a trace is displayed (for example a burst from an IR receiver), changing the vertical scale alters the display but does not rescale the existing data correctly- again very confusing. Some changes of scale are OK e.g. 10V to 20V, but 10V to 5V gives garbage. This is obviously just maths as the same data is just being re-displayed. The same is true when changing the timebase.
9.It may just be my mouse, but when I move the vertical trigger point it always moves "faster and further" than the actual mouse pointer. This only happens with a X10 probe setting.
10.Manual could be a bit more explicit and detailed

Sorry for the long list(there are a few more but I shall leave these for another time). I realise that some of the above may be "by design" and I also know how difficult it is to write perfect software. I am, like PJV, rather surprised that so few people have had any problems - maybe there are only very few propscopes being used so far.
Despite my frustrations, I think the Propscope will be a worthwhile tool if Hanno can fix the problems, and from experience I am sure he will.

Cheers,

Paul

[Hanno]

Thanks Bill! There's a link to the 1.05 beta on one of these threads to get you going now- I'm still making steady progress on it and will put out an update soon- I just finished giving 7 presentations about the projects I'm working on and travelling with my kids- so PropScope progress is going a bit slower. Thanks for your patience.

Paul- thanks for your list of annoyances. Yes, I'm committed to resolving everything that makes sense and is achievable. I would put 4,5 in the "design" feature bucket- although I'll look at always labeling 0V for ch2- I chose the current way to make the display more pleasing. The rest are already, or will be fixed in v1.05.
Hanno

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer

[Hanno]

Thanks Bill! There's a link to the 1.05 beta on one of these threads to get you going now- I'm still making steady progress on it and will put out an update soon- I just finished giving 7 presentations about the projects I'm working on and travelling with my kids- so PropScope progress is going a bit slower. Thanks for your patience.

Paul- thanks for your list of annoyances. Yes, I'm committed to resolving everything that makes sense and is achievable. I would put 4,5 in the "design" feature bucket- although I'll look at always labeling 0V for ch2- I chose the current way to make the display more pleasing. The rest are already, or will be fixed in v1.05.
Hanno

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer

[pjv]

Hello Hanno;

If there is a list of things to be implemented, then I think that the horizontal timebase scale should have its zero at the trigger point, and cursors positive or negative relative to that.

Thanks,

Peter (pjv)