Is it worth reviving the PropScope OpenSource Project?

Hi, it's been awhile since I've posted anything. In fact due to technical issues with my old account I had to open another account.

I was involved in OBC's Propscope project way back when and was thinking of the software advances since that project was started. With Xamarin a cross platform project could be developed. I don't know Xamarin but as a software developer I know I could pick it up quickly.

I have all the documentation Parallax and Hanno put out for the project but sadly I don't have any of the pasm code that was posted on OBC's PropellerPowered site. I do believe somebody at least had code for interleave sampling of the ADC in the PropScope. With that site being long since shut down I was wondering if anyone on the forum had copies?

I also wonder with the PropScope being discontinued a long while ago and since most of the interest is now in the Propeller 2, there will be enough interest to make it worth attempting.

Comments

  • I think the problem here is that Hanno never documented the protocol used since it was also part of his commercial ViewPort.

    And Hanno seems to be awol, sadly. I do not have any copies but I tested it at that time and it was quite simple, almost useless, except for getting the basics done.

    I have a PropScope and use it very rarely, It is nice but quite slow. But a P2propScope might be a interesting product, since it would be faster and could work stand alone without a PC connected...

    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • PublisonPublison Posts: 10,689
    edited 2019-02-02 - 22:49:50
    Welcome back. I remember the name. I didn't follow the Propscope venture on Jeff's site, and never saved from there. That's not like me, the data horder. Guess it's lost to the ether. :neutral:
    Infernal Machine
  • There is a project on github that works with the propscope: https://github.com/rbehm-ibb/PropScope
    It needs more work to support all the features and also use more cogs to be able to sample at higher rates, but it's got all the code including PASM to talk to the ADC chip. It also includes an application to run on your PC (with full source) that talks the new protocol this project uses instead of Hanno's old one.

    That would be the place to start if you were to revive things. I would certainly like you to! I have 2 PropScopes, and Hanno's software is lacking in many ways, but the hardware is plenty fast and functional for a lot of use cases.
  • jmgjmg Posts: 13,108
    blittled2 wrote: »
    ...
    I also wonder with the PropScope being discontinued a long while ago and since most of the interest is now in the Propeller 2, there will be enough interest to make it worth attempting.

    The links and GUI can be (largely) common to P2 and PropScope, so it is probably quite a good time to revive something that can support either hardware.

    I have been doing some tests on FT232H, to see what bandwidths it can support in the various modes, with a view to faster data paths from P2.

    In Async FIFO mode, PC-> FT232H, I get peak rates of ~15MB/s, sustained averages of ~10MB/s, and if you stipulate 'no gaps' in the data stream, that is ~ 3MB/s
    I'd expect rates in the other direction to be largely similar.

    Sync FIFO can go faster still, but I'm not sure P2 can manage that.

    Even Async mode will need to consume a COG for the link, as the P2 Streamer lacks handshake abilities.
    I also tested Fast Serial modes, PC -> FT232H, and derived these rate equations
      Summary of FT232H Fast Serial PC bulk "U" sending tests : (use CLK out of FT232H to feed FSCLK )
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      FT232H fast Serial Speed equations model as                Calc             CTR             Deviations                                                               BYTES/Sec
      30MHz_30MBaud   => (30.00054M*5/14)*(256*14)/(255*14+15)  = 10711489     1-ans/10.71147M  = -1.855ppm 1-ans/10.71149M = 11.72ppb, ie mostly /14, appx 1:256 is /15   2.14229797 MB/s
      15MHz_15MBaud   => (15.000271M*5/13)*(512*13)/(511*13+14) = 5768468.343  1-ans/5.768466M  = 0.406ppm Mostly /13, appx 1:512 /14                                      1.153693 MB/s
      7.5MHz_7.5MBaud => (7.500135M*5/13)                       =  2884667.307    2.884667M     = looks like 7.5MHz can stream at /13, gapless.                             576.933 kB/s
    

    You can see the char frame time creeps a little with FSCLK MHz, 7.5MHz can manage always 13 Clocks, 15MHz is mostly 13, rarely 14, and 30MHz is mostly 14, rarely 15.
    This needs fewer pins than 245-FIFO mode, but can go quite a bit faster than ASYNC 12MBd limit.
  • If a P2 PropScope were made, I would very much like it to have extra RAM on board or at least the option to install extra RAM. For those very highest sample rates of the signal you can't feed the data out fast enough over serial link, so we'd want some local parallel RAM to dump to, then transfer from that back to the PC after the capture.

    For the existing PropScope it is limited to what it is already, and it can really only do the higher sample rates for a very short sample time that fits in the P1 internal memory. I think it can only reliable send 2Mbps over the serial, so you only get 200k bytes per second. which is only 160k 10 bit samples per second. The hardware setup is capable of 5Msps if using multiple cogs to read the ADC chip, but in that case you only get a very tiny fraction of a second worth of samples before it's filled available memory. It's still useful for capturing short bits of triggered stuff.
  • Yes @Roy Eltham,

    exactly my thoughts. the serial link to the PC is way to slow, especially if you capture more then 1 channel. But with 64 pins some fast external ram might be possible and still have serial,sd and maybe VGA and PS2 Mouse or Keyboard, maybe even HDMI, USB mouse/Keyboard. Or even both to connect it to older lab equipment.

    the short sampling time made the propscope quite - hmm - restricted when I needed it.

    Enjoy!
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • jmgjmg Posts: 13,108
    Roy Eltham wrote: »
    If a P2 PropScope were made, I would very much like it to have extra RAM on board or at least the option to install extra RAM. For those very highest sample rates of the signal you can't feed the data out fast enough over serial link, so we'd want some local parallel RAM to dump to, then transfer from that back to the PC after the capture.

    Yes, the SO-8 PSRAMs are quite cheap, LY68L6400SLIT is 59c/100 for 64Mb, so you might choose 2 or 3 of those, depending on the ADC chosen. That does ease serial link pressures.
    Chip has some sort of scope mode worked into the next P2 rev, which may allow for many channels of moderate sample rates, or a Selected premium ADC could give more sps, on fewer channels.

  • well with chips scope streamer mode one can fill up the HUB pretty quick, maybe two COGs to save that out fast enough to two external memories.

    interesting

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • With something like this: https://www.ftdichip.com/Products/ICs/FT600.html

    Probably wouldn't need any external RAM, just setup a stream of samples going out to that chip in parallel (16bit or 32bit wide fifo). Most basic setup would be a P2, a FT600, and whatever is needed to attach probes properly.
    Of course a more advanced model could include external high end ADC(s), but that's just going to make it cost a lot more.
  • jmgjmg Posts: 13,108
    Roy Eltham wrote: »
    With something like this: https://www.ftdichip.com/Products/ICs/FT600.html

    Probably wouldn't need any external RAM, just setup a stream of samples going out to that chip in parallel (16bit or 32bit wide fifo). Most basic setup would be a P2, a FT600, and whatever is needed to attach probes properly.
    Of course a more advanced model could include external high end ADC(s), but that's just going to make it cost a lot more.

    Yes, the FT6xx series are appealing, but the lack of streamer handshakes may bite here, as those parts really need the TXE_N to be responded to in 1 CLK (66MHz or 100MHz)
  • Roy Eltham wrote: »
    There is a project on github that works with the propscope: https://github.com/rbehm-ibb/PropScope
    It needs more work to support all the features and also use more cogs to be able to sample at higher rates, but it's got all the code including PASM to talk to the ADC chip. It also includes an application to run on your PC (with full source) that talks the new protocol this project uses instead of Hanno's old one.

    That would be the place to start if you were to revive things. I would certainly like you to! I have 2 PropScopes, and Hanno's software is lacking in many ways, but the hardware is plenty fast and functional for a lot of use cases.

    The new software is from me. Currently it only uses one COG to sample data and thus is limited to about 1Msamples/s. I have not yet found the time to extend it. I am using it heavily as it mostly fits my needs. If someone is willing to work on it I can support. he PC software is based on Qt and QCustomPlot to create the waveform display. I am using a new protocol to transfer the data to the PC. This could be extended for higher speed.
    The extension for higher sample rates (using several COGs) are currently something I have no time to implement (and no idea how to do it). Here help would be appreciated.

    Reinhardt
    --
    Reinhardt
Sign In or Register to comment.