Shop OBEX P1 Docs P2 Docs Learn Events
PropScope v2.0.0 Software Issues — Parallax Forums

PropScope v2.0.0 Software Issues

edited 2010-11-22 00:57 in Accessories
There is still an issue with the trigger time the trigger time crosshair does not reliably position the trigger event. The screen capture below accentuates it. The positive edge of the CH0 signal should be passing through the intersection of the trigger voltage and time crosshairs at (0.3 V, 2 us). Instead, the CH1 signal’s positive edge is a quarter of a time division off, at 1.75 us. Since folks going through Understanding Signals with the PropScope use this feature to prepare for measurements at a variety of timescales, it would be important to make sure this feature is stable.

A second issue with this screen capture is that there appears to be a delay of almost 0.5 μs between the function generator’s displayed output signal and the measured signal. This delay introduces errors into phase difference measurements that students would not encounter with the normal function generator and 2 channel scope setup. It also introduces uncertainties into the PropScope book’s RC decay and phase delay activities. Students making lab reports typically need to discuss sources of error, so if it cannot be corrected, it would be useful to have an error value that they can use. Is it constant or a function of time scale?

attachment.php?attachmentid=74606&stc=1&d=1287684158

Comments

  • Ken GraceyKen Gracey Posts: 7,392
    edited 2010-10-21 16:09
    I've alerted Hanno to this thread.
  • HannoHanno Posts: 1,130
    edited 2010-10-21 17:19
    I've fixed the issue- here's v2.01
    +Timing constants tweaked to improve alignment of screen and actual trigger
    Yes, there's a constant lag of 200-300nsec between the indicated DAC output and the actual measured input. It takes this long for the signal to make it's way from the Propeller through the circuitry, the ADC and back into the Propeller. If you use longer cables, this lag will be even longer- every foot will add a bit more than a nanosecond.
  • edited 2010-10-21 19:24
    2.0.1 looks excellent from 100 ns to 100 us, but it’s still off at 200 and 500 us.

    At larger time/div, it seems to have a tendency to drift a little further before correction than it does for smaller time divisions.

    Regarding the constant offset, I’ll include a statement in the book about round trip timing. Please let me know if you change your mind and decide to adjust for this constant in software.
  • Aristides AlvarezAristides Alvarez Posts: 486
    edited 2010-10-22 13:42
    Andy,

    Please keep posting the feedback in the forum thread so people testing the software and the book can keep track of the changes and the reasons behind each revision.

    Also, when you post anything regarding the software, please alert Hanno by email so he can follow up through the forum.
  • HannoHanno Posts: 1,130
    edited 2010-10-24 12:56
    I can not compensate for the round trip lag in software without significant changes. I'll have another look at the 200us and 500us settings- they looked fine when I tested them.
  • HannoHanno Posts: 1,130
    edited 2010-10-27 17:06
    Ok- v2.02- with pixel perfect timings and >1000 samples saved to csv/txt is up in the latest update post
  • edited 2010-10-27 17:57
    Yes, that's working really nice with the trigger crosshairs vs. trigger event on the 2nd time division. By the time you can get to the 19th, there's still a slight, visible difference, but probably not enough to raise any eyebrows.

    I did notice while trying the different time division settings that the mode switches from oscilloscope to datalogging at 100 ms/division, but the trigger setting does not switch from continuous to Off, and the trigger level and time controls remain visible. I'm not sure if this is intentional, but it could lead to some confusion.

    I have fielded some offline questions about datalogging vs. oscilloscope mode. I think it might actually be worth displaying a popup the that lets the user know what happened the first time it automatically makes this change. User could check "don't show this message again" followed by OK. Folks who follow the book will discover and understand the difference, (and they'll know to use Run/Stop) but it might take some people with prior oscilloscope experience who are not following the book by surprise.
  • pjvpjv Posts: 1,903
    edited 2010-11-20 13:31
    Hello Hanno;

    Since I am going to be travelling, I thought I would dig out my propscope and update the software.

    So, I find a significant improvement, but an unpleasant interface. Could we have some ability to turn off the annoying flickering of the channel values at the top of the screen? Especially for channels that are turned off. Or at least slow the update rate down.

    The most annoying thing for me is that the screen time scale does not zero about the trigger point. This makes time readings very non-intuitive, and a pain to make with any precision.

    Surely this can be rectified and be made like normal DSOs

    Cheers,

    Peter (pjv)
  • HannoHanno Posts: 1,130
    edited 2010-11-22 00:57
    Hi Peter,
    Glad to see you travelling with the PropScope- it fits in your pocket!

    The channel values don't flicker on my test systems- can you tell me about your setup? Clicking on the "dso" graph will fix the "cursor" to the point you click- that might help a bit.

    In addition to the absolute time, there are vertical cursors that you can position with the mouse. The software shows both the absolute position of the cursors and the difference between them. So, you could place one at the trigger point and one at the event you want to measure. I'll try to address both issues in the next revision.
    Hanno
Sign In or Register to comment.