PropScope?

Rayman

I have a design in mind for a Prop based USB oscope.· I think it could do up to 100 MSPS (running the Prop at 100 MHz).·

I have a feeling that Hanno is way ahead of me though...

Cluso99

I think so. But see my article if you want to play with the prop.

Data Logger Object 80MHz (samples pins @ 50nS or 12.5nS) - like Dscope http://forums.parallax.com/forums/default.aspx?f=25&m=268880

Paul Baker

We are way ahead of you, Hanno and Parallax have teamed up to create the next generation oscilloscope, named (you guessed it) PropScope. We're on the second prototype and the subcircuits appear to be working for the most part. There are some issues concerning manufacturability and there are some aspects which need work for the board to achieve the target feature set. It will be clocked at 80MHz because we didn't want to base the design on a potentially hard to get item (6.25 MHz crystal), and to reduce the cost of other components (high speed = high $$$). The target sample rate is 20Msps/channel, but the frequency response of the input needs further refinement to get a flatband response from 0 to 10 MHz (the Nyquist frequency of the system). I am no longer heading the project (I'm more of an internal consultant now) so I can't give you an ETA, but it will most likely be sometime next quarter.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 11/7/2008 6:47:55 PM GMT

Rayman

Well, I'm up for a challenge! I'm aiming toward two 50 MSPS channels that can be interleaved for 100 MSPS on one channel. I think one can always custom order (in quantity) whatever freqency crystal you want. But, it would work equally well at 80 MHz too.

Looking at an analog bandwith of 200-400 MHz. This way, I can do undersampling to re-construct very high frequencies.

Triggering at full speed is the most difficult obstacle I see... There's going to need to be some sacrificing there.

Post Edited (Rayman) : 11/7/2008 7:32:36 PM GMT

Phil Pilgrim (PhiPi)

Rayman,

If you succeed, you'll have a very snazzy device, indeed! But you have to realize that Parallax's objectives are different: to create a product. A product is subject to many more constraints than a device. Mainly, it has to be highly manufacturable and to use inexpensive, easy-to-obtain and, ideally, multiple-sourced components. It's behavior has to be reliably reproducible, which entails a conservative design, and easy to explain to a novice user. Products which attempt to push the bleeding edge of performance often come back to haunt a company and their tech support staff, resulting in a net loss of both profits and reputation.

Nonetheless, good luck with your endeavor! I'm excited to see what you come up with.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!

Rayman

Yes, I must confess that this is just a hobby for me... And, I don't really have much free time these days...

I'm also aiming toward low cost. But, I'm aiming toward something that people with good soldering skills can do themselves. So, I'm limiting components to a minimum pin distance of 0.65 mm BC...

Cluso99

@Rayman: I interleaved 4 cogs to sample at the full clock cycle, not per instruction cycle which is every 4 clocks.

Rayman

Yes, that's my idea too. I first saw Hanno doing this with self-generating code about a year ago and it thoroughly confused me then. But, I think I have a handle on it now...

Jo

Paul,

can you reveal what is the approximate price point Parallax is aiming for the PropScope?
I'm currently in the market for an oscilloscope/logic analyzer and the specs Hanno mentions
on his ViewPort home page would suit my requirements quite well, so I'm interested, assuming
that it will come out at end of year or at least first quarter next year.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jo

Bob Lawrence (VE1RLL)

Jo

Ariba

Paul Baker (Parallax) said...
We are way ahead of you, Hanno and Parallax have teamed up to create the next generation oscilloscope, named (you guessed it) PropScope. We're on the second prototype and the subcircuits appear to be working for the most part. There are some issues concerning manufacturability and there are some aspects which need work for the board to achieve the target feature set. It will be clocked at 80MHz because we didn't want to base the design on a potentially hard to get item (6.25 MHz crystal), and to reduce the cost of other components (high speed = high $$$). The target sample rate is 20Msps/channel, but the frequency response of the input needs further refinement to get a flatband response from 0 to 10 MHz (the Nyquist frequency of the system). I am no longer heading the project (I'm more of an internal consultant now) so I can't give you an ETA, but it will most likely be sometime next quarter.

With 20 MHz real time sampling, a realistic signal bandwith is around 2..3 MHz, not 10 MHz. The serious manufactors of oscilloscopes choose a sampling frequency of 10 times the max. measured signal frequency. The Nyquist frequency is not much relevant for a visual representation of the signal.
With a strong SinX/X interpolation fs/2.5 (8 MHz) is possible, but the resulting sine curve is more an artificial one, and not really measured.

@Rayman

developing such a scope was the reason for me, to try out the propeller chip, 1.5 years ago. I had a design with an FPGA before, but want to switch to the propeller, because the hardware is simpler, cheaper, and has more RAM for the sampling buffer. But then I get lost in the propeller world, where new project ideas comes faster than you ever can realize ...
From time to time I work on the scope, and have already the PCB and a big part of the PC software.

Andy

Rayman

It's true that scopes usually have an analog bandwidth less than the sampling rate.
However, there are some neat tricks you can do via subsampling...

For example, with 100MSPS and 150MHz analog, one can look at the frequency content of a 122MHz FM radio source. And, maybe even do direct demodulation to listen to that station...

If your analog bandwidth were only 20 MHz, that would be impossible...

Paul Baker

Andy, The true bandwidth will indeed be smaller, the target bandwidth for the PropScope is to provide a decent (but not necessarily perfect) representation of a colorburst, 20 Mhz/3.58 Mhz = ~5.6 oversample. The reason I designed the system to have a flatband over the entire Nyquist is that the casual user is not going to know the whole bandwidth vs sample rate issue. I did not want them to erronously think that a signal·faster than the bandwidth has a smaller amplitude than it does because they don't understand the scope is attenuating the signal. I·concluded the system should only sacrifice it's ability to resolve the waveform, but not amplitude when the input signal is between the bandwidth and the Nyquist frequency.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 11/11/2008 1:51:50 AM GMT

Hanno

While the PropScope won't be able to demodulate FM Radio, it has the bandwidth to digitize video! See Paul's remark about the target bandwidth being able to resolve the colorburst signal...
I find video much more interesting than audio, coupled with a cheap camera you can perform decently advanced vision processing.
ViewPort comes with a couple video tutorials that let you do cool stuff. Both require you to feed the Propeller with a digitized video signal. This is easy and cheap to do. I use a 08100 adc and a grayscale NTSC camera- total cost<$25. ViewPort comes with an object that acts as a frame grabber- it yields a 240x200 pixel image in global memory- updated at 30fps. Another object let's you set up vision filters that transform the image in various ways. The resulting image is streamed at up to 10fps to ViewPort where you can look at scanlines, histograms, and inspect individual pixel values. I'm currently writing up an article for Circuit Cellar on vision processing with the Propeller- it's amazing what this chip can do!
Hanno

Rayman

I think you will have a real winner with just the ability to view video waveforms. Add to that video capture and it could be a blockbuster.

For mine, I'm rethinking my twin 50 MSPS and leaning toward an external 100 MHz oscillator to drive both the Prop and two 100 MSPS ADCs... Won't be able to easily change the conversion rate, but I don't think that's so important anyway... This also makes it fast enough so that it's not so crazy to scale up to the 1 GSPS range (by using 5 or more Props), assuming I can keep the analag bandwith in the 250 MHz range...

I'm still facing a pre-trigger dilema though...· Don't see any easy way to start capture before the trigger when running at full speed...

Post Edited (Rayman) : 11/11/2008 1:15:23 AM GMT

Cluso99

@Rayman:

I was thinking about this when I was writing my code. (I didn't realise a lot of work had been done before me). However, I think my use of 4 cogs and the way I did it was new (self replicate the code and interlacing cogs).

Triggering - I thought that the prop would have to be cycling around storing the data. 4 cogs would be storing the data in their cogs while the other 4 would be preparing to store their data while looking for a trigger. Each set of 4 cogs would be storing their data which would be overlapped 50% (which would give about 480 x 4 x 1.5 = about 2800 samples at 12.5ns (or 10nS with 100MHz).

Now each cog set would start storing while the next cogset would prepare and look for the trigger. It trigger is identified a flag in hub would be set and the first co set would see this at the end of sampling and keep it's sample. The second cog set would also keep its sample (but remember they are overlapped 50%).

With 10nS sampling could give 2 16-bit channels of 100MSPS, or 2 x 10-bit and 1 x 12-bit samples. (If you free up all prop pins). And of course 32-bit digital samples (logic).

The new pcb Leon is making could also be a fine solution.

Rayman

Cluso99: Interesting idea... Using all 8 cogs in assembly. I don't think I've seen this before, but I suppose it might work! I think that would indeed resolve my dilema...

Cluso99

It is not required that any cog run spin. They all can execute pasm. It is also possible to execute LMM style code (but of course slower) from hub to conserve as much space as possible for storing the data samples.

Hanno

Cluso,
My self-modifying code takes quite a bit more time to create the "sampling program" than to run it at full speed. When it's sampling, it's taking 1 sample/instruction. However, writing the program has to take at least 3 instructions: mov, add, dnz.... This makes it difficult to sample at full speed with pre-trigger.
Hanno

Rayman

I think the idea (admittedly not completely thought through) would be to have all 8 cogs running in an interleaved fashion so that while four are acquiring, the other four would check to see if there was a trigger...· If there were no trigger they would continue acquiring while the other four would check for a trigger...

I think this is the only way, without external memory, to have a pre-trigger at full speed.

I am a bit concerned about the long time it would take to launch all 8 cogs and have them self-assemble their code, as you describe.· This would have to be redone for each acquisition and may limit the acquisition rate...

Post Edited (Rayman) : 11/17/2008 11:35:59 AM GMT

Cluso99

@Hanno: The self replicating code does take a loop, but you could partially do a loop, having the remainder already preloaded. That way, once the trigger is set, the partial loop would retain the data and build the remainder, meanwhile the next 4xcogs would do a complete sample. I am sure thi can be done. BTW, I didn't realise you had done self-replicating and interleaved code before I had. I wouldn't have bothered reinventing the wheel

@Rayman: You would only be able to have each cog effecively do one set of samples as you cannot unload the data quick enough from the cog (at full speed). There may be a way to do a partial though, which could extend the samples to some extent.

Little-endian

I'm entertaining the idea of purchasing a scope. Any updates available on any of the scopes mentioned in this thread?

fixitman

i want to buy one

Hanno

My code is now continuously sampling all 32bits of the IO port at configurable frequencies up to 20Msps, WHILE looking for complex triggers. It's dumping the data into circular buffers in 4 cogs which allows the scope to look quite a bit BEFORE a trigger has occurred. This is a very powerful feature typically found in higher end scopes.
Hanno

Cluso99

Hanno:
With all 8 cogs, you should be able to get 40Msps. And because the buffers would be in hub, the buffer size is much increased. What a scope

I still think there is a possible solution with complex coding to sample at 80Msps.

BTW I love your pc displays

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

ghost2

Hanno,

my compliments on what seems to be an impressive suite of apps; Viewport and the upcoming Debugger and Propscope. And much joy for those who will be able to run them - I'm on a Mac

So I'd like to know how these apps will run in VMware Fusion and Parallels Desktop. I'd imagine it won't be difficult finding a beta tester for this.

Even better of course are native versions for MacOSX and Linux. Since Brad C in this forum has done great work with his bst tool, may I humbly suggest that you contact him and see if anything can be suggested.

And finally, as a motivation for this, a Mac version of Viewport and friends is worth quite a bit more than 29USD, IMO.

Cheers,

G

Mike Huselton

Hanno,

Would please supply a schematic and code of what you have done so far? I want to replicate it for testing.

Just whatever you happen to have so far - I am looking to duplicate tour component values.

Thanks...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH - Electronics: Engineer - Programming: Professional

Hanno

Hi Goran,
People have been using ViewPort (the basis of PropScope) on the Mac and Unix for quite some time in emulation- so give it a try. ViewPort is a .net application, and I've played a bit with Mono, which would let it run natively on Mac/Unix with a bit of work. The Propellent.dll from Parallax and some other pieces I need are not cross platform- so this won't happen soon.
Hanno

Quantum- The PropScope is a Parallax product so I can't share that. I'll call you tomorrow to talk about your iodreamkit...

T'Saavik

Any update on the Propscope? I need a scope and Ebay is tempting me too much lately!


UPDATE: opps, looks like a new thread was started: http://forums.parallax.com/forums/default.aspx?tabid=&f=25&m=342214&p=1

Post Edited (T'Saavik) : 4/10/2009 11:52:32 PM GMT