Picoscope 2204A streaming mode & trigger Holdoff

[markone]

I'm assessing the (small) capabilities of Picoscope 2204A and I have some doubts :

1) really there is no Trigger Holdoff mechanism ?
2) really streaming mode is limited to 1MS/s ?
3) why it's impossible to use streaming mode below 100ms/div time base ?

About the point 2 it seems to me more due to a marketing decision than technical limitation, the instruments mount an old but good CY7C68013A that is capable to do much more and i do not believe that the FPGA cannot keep up to higher data transfer rate.

I've been playing for a few hours with both Picoscope 6  & 7 and now I wonder if there are other programs that address some of the point that i reported.

[markone]

More I test this thing more I get limits that i do not understand, in example why I'm not free to select the already crippled streaming mode (1MS/s max) for a desired amount of sample and/or time ?

Unless I'm completely stoned I cannot set any Picoscope version (6/7) for less than 1s capture time @ 1MS/s, this destroy any hope to use this device to decode low baud rate (i.e 19200bps) medium sized serial messages (200-300 bytes) in segments.

IF streaming mode is disabled, you are limited to cold war era 8000 points internal buffer that allows you to correctly decode only a couple of dozens of characters.   

Second : why limit spectrum function to 10MHz scale @ 25MS/s ?
 
I understand that the scope is declared for 10Mhz BW (actually analog front doubles that number) but it would be nice to allow the user to select full sampling rate and higher spectrum chart frequency axis with the awareness of instrument limits as well as to manage sampling rate and sampling memory at desired values.

In my opinion this is an example of a decent HW equipment (for build quality/price ratio) with handbrake engaged, if you consider the HW used inside the box, AD9288 + XC3S250E + CY7C68013A, you understand that the potential is not fully exploited.

I also discovered that the model 2205A's board seems to be right the same, I guess the only differentiation between two models could be CY7C68013A E2PROM content.

Any help about a possible hack to upgrade 2204A to 2205A will, of course, be appreciated 

[_Wim_]

Have a look here, I was able to upgrade my picoscope by modifying the eprom contents:
https://www.eevblog.com/forum/testgear/picoscope-hack/

And yes, pico does sometimes impose some software limits to differentiate between products.

BTW: Trigger hold-off is not available on higher end models also (like for example my 5000-series)

[_Wim_]

I also discovered that the model 2205A's board seems to be right the same, I guess the only differentiation between two models could be CY7C68013A E2PROM content.

The should be an ST 24C02 eprom on your board that contains probably the same data structure as in the above thread. You can verify this by checking the serial number and version info first...

https://sigrok.org/wiki/Pico_Technology_PicoScope_2204A

[markone]

Have a look here, I was able to upgrade my picoscope by modifying the eprom contents:
https://www.eevblog.com/forum/testgear/picoscope-hack/

And yes, pico does sometimes impose some software limits to differentiate between products.

BTW: Trigger hold-off is not available on higher end models also (like for example my 5000-series)

Hi Wim,

thank you very much for your reply, I just took a fast glimpse reading first post of your linked 3ad (i'll read all the rest later), I understand that you desoldered from the PCB the E2PROM attached to USB bridge (CY7C68013A ?) and after some data content analysis you have understood where and how the instrument model is specified.

In the past I used, under Windows, a Cypress utility to read (and write) the E2PROM attached to an FX2 device without the need to touch the hardware, so  I should be able to get the 2204A E2PROM content dumped without opening the box.     

Have you maybe found any resource / discussion forum (apart Sigrok) about the matter on the web ?

[markone]

-snip

BTW: Trigger hold-off is not available on higher end models also (like for example my 5000-series)

This thing drives me nut ... one of the reasons for my 2204A purchase was to make an assessment of Picoscope HW/SW platform before to spend much more money for a decent device but the lack of what I consider a mandatory function (Trigger Holdoff) is something that probably will prevent me to do that.

There is, maybe, something hidden (or that I simply missed) in Picoscope programs that allows to obtain something similar to a "normal" Trigger Holdoff function ?

[egonotto]

Hello,

Maybe there is no fine resolution clock in the Picoscope and therefore the time stamp is missing in segmented memory and there is no hold off.

Best regards
egonotto

[markone]

Hello,

Maybe there is no fine resolution clock in the Picoscope and therefore the time stamp is missing in segmented memory and there is no hold off.

Best regards
egonotto

I'm more inclined to think that trigger management is implemented at HW level, not like some "China designed" trash that you can find on the web.

Anyhow, regardless of how it's implemented, this lack would be understandable for low cost line like 2204A/2205A but NOT for all the rest of the catalog, considering how much you pay for, i.e.,  a 100MHz 2 channels 1GS/s DSO with some sampling buffer onboard.

[_Wim_]

Anyhow, regardless of how it's implemented, this lack would be understandable for low cost line like 2204A/2205A but NOT for all the rest of the catalog, considering how much you pay for, i.e.,  a 100MHz 2 channels 1GS/s DSO with some sampling buffer onboard.

While a trigger hold-off function is sometimes useful, the fact that it is lacking on the picoscope never really has bothered me, as typically I can find a triggering solution without it. I have been a longtime user of Picoscope (since the ADC212), and still quite like my 5442B. But I do which their software (especially the FFT part) would become more feature rich (peak analysis functions, decent overlay functionality, normalisation…). I also own an Analog Discovery, and their “Waveforms” software is much better in many aspects, but not their hardware. Still, maybe when they are finally finished porting their software to Picosoft, new features will again be implemented.

thank you very much for your reply, I just took a fast glimpse reading first post of your linked 3ad (i'll read all the rest later), I understand that you desoldered from the PCB the E2PROM attached to USB bridge (CY7C68013A ?) and after some data content analysis you have understood where and how the instrument model is specified.

I just desoldered  the eprom, made a backup via my eprom programmer (a TL866), and then changed the contents and reprogrammed it also via the TL866. Most probably it is possible to program the eprom while still on the board (as that is how they do it in the factory), but as I want to be able to switch between 2 eproms, I had to desolder it anyway to make the adaptations.

[markone]

While a trigger hold-off function is sometimes useful, the fact that it is lacking on the picoscope never really has bothered me, as typically I can find a triggering solution without it.

I guess you mainly use your scope for analog tasks, I make an heavy use of serial port messages transmitted in deterministic way to "tag" analog signals in closed loop systems so I need to capture & store segments starting precisely from the first falling edge of the first byte of the packet, of course in conjunction of analog signal (at least one).

Depending on the combination of packet length, packets time interval and DSO horizontal scale it could be necessary to use trigger holdoff.

The reason why I'm considering to use a USB DSO is that in some cases it's much easier to bring a small box operated and supplied directly from a laptop, here the reason of my purchase.

The 2204A analog specs are enough for my purpose but not the small memory depth, I was hoping to use the streaming mode to solve this (1MS/s it's enough) but I soon found out the impossibility to operate in that way I need,  that is to set both sample rate & sample length at the same time to obtain acquisition segments of about 100-200 ms length.

To let you better understand, engaging the "Progressive Mode" with 10ms/div horizontal scale will allow also the 2204A to collect 100ms segment @ the right sample rate (at least 200KS/s) ... but it's impossible because Picoscope enables this feature from 100ms/div, so with a minimal segment length  of 1 second.

Therefore it is necessary to use an higher model with a bigger acquisition memory, but before to consider that I have to understand if exist a way to solve the trigger holdoff matter.

Please let me know if there is a "trick" to obtain a  similar functionality.
 

I have been a longtime user of Picoscope (since the ADC212), and still quite like my 5442B. But I do which their software (especially the FFT part) would become more feature rich (peak analysis functions, decent overlay functionality, normalisation…).

 I also own an Analog Discovery, and their “Waveforms” software is much better in many aspects, but not their hardware. Still, maybe when they are finally finished porting their software to Picosoft, new features will again be implemented.

Which port are you referring to ?

[jasonRF]

I'm assessing the (small) capabilities of Picoscope 2204A and I have some doubts :

1) really there is no Trigger Holdoff mechanism ?
2) really streaming mode is limited to 1MS/s ?
3) why it's impossible to use streaming mode below 100ms/div time base ?

About the point 2 it seems to me more due to a marketing decision than technical limitation, the instruments mount an old but good CY7C68013A that is capable to do much more and i do not believe that the FPGA cannot keep up to higher data transfer rate.

I've been playing for a few hours with both Picoscope 6  & 7 and now I wonder if there are other programs that address some of the point that i reported.

Yes, within Picoscope 6 these are the limitations.  I haven't been using picoscope7 as it doesn't have all the features yet and I am not very fond of it. 

With the API you can eliminate 3 completely as you pick the streaming sample rate and the total number of samples.  You can also stream 2 MS/s sample rate.  I have only used the python wrappers that picotech provides for the API, and the streaming_mode_gathering.py script is already setup for 2 MS/s.  It throws an error when I try to push it higher.  Below is a figure where I have captured a 200 kHz sinusoid and we clearly see 10 samples / period. 

But of course this does not help the fact that within the Picoscope software you cannot get around these streaming limitations.

The trigger hold-off is another matter completely.  It hasn't bothered me personally, but I don't do very complicated stuff. 

jason

[markone]

Hi Jason, thank you very much for your reply

I'm assessing the (small) capabilities of Picoscope 2204A and I have some doubts :

1) really there is no Trigger Holdoff mechanism ?
2) really streaming mode is limited to 1MS/s ?
3) why it's impossible to use streaming mode below 100ms/div time base ?

About the point 2 it seems to me more due to a marketing decision than technical limitation, the instruments mount an old but good CY7C68013A that is capable to do much more and i do not believe that the FPGA cannot keep up to higher data transfer rate.

I've been playing for a few hours with both Picoscope 6  & 7 and now I wonder if there are other programs that address some of the point that i reported.

Yes, within Picoscope 6 these are the limitations.  I haven't been using picoscope7 as it doesn't have all the features yet and I am not very fond of it. 

Picoscope 7 has the very same limitation in this regard, the smallest segments that I'm able to capture and store in streaming mode is 1 second long (@ 100ms/div).

With the API you can eliminate 3 completely as you pick the streaming sample rate and the total number of samples.  You can also stream 2 MS/s sample rate.  I have only used the python wrappers that picotech provides for the API, and the streaming_mode_gathering.py script is already setup for 2 MS/s.  It throws an error when I try to push it higher.  Below is a figure where I have captured a 200 kHz sinusoid and we clearly see 10 samples / period. 

This confirms what I was saying, it's not an HW limitation and 1MS/s would be enough for my purpose.
Of course a model with some more acquisition memory would solve the matter, but they are not exactly cheap and i's a pity that an application design severely cripples HW capabilities.

But of course this does not help the fact that within the Picoscope software you cannot get around these streaming limitations.

 

The trigger hold-off is another matter completely.  It hasn't bothered me personally, but I don't do very complicated stuff. 

jason

It sounds strange to me that this feature is not yet implemented, if trigger detection happens at HW level with the FPGA support it should be easily doable to build that mechanism, but it could be that i'm missing something.

[markone]

In attachment a screen that shows the Picoscope7's setup that would be good with 10ms/div (please note the menu inside the red square), apart that is working good.

[_Wim_]

Please let me know if there is a "trick" to obtain a  similar functionality.

I would expect you probably can use interval triggering for this (if I understood your requirement correctly). This will trigger on the second falling edge if a large time (time longer than your packet length) has been between the first and the second edge, so you always trigger on the first falling edge of the "new" package. I am however not sure if it will also "see" again the first edge in this new package and retrigger on the next package or you will always mis a package in between. I indeed use this the pico more for analog work instead of protocol analysis. 

Which port are you referring to ?

Picosoft 7 is a complete new verion of Picosoft they are building from the ground up. Currently not all features from Picosoft 6 are migrated to 7.

[markone]

Please let me know if there is a "trick" to obtain a  similar functionality.

I would expect you probably can use interval triggering for this (if I understood your requirement correctly). This will trigger on the second falling edge if a large time (time longer than your packet length) has been between the first and the second edge, so you always trigger on the first falling edge of the "new" package. I am however not sure if it will also "see" again the first edge in this new package and retrigger on the next package or you will always mis a package in between. I indeed use this the pico more for analog work instead of protocol analysis. 

Ok, I got what you mean, it's worth to give a try, thank you.

Which port are you referring to ?

Picosoft 7 is a complete new verion of Picosoft they are building from the ground up. Currently not all features from Picosoft 6 are migrated to 7.

Ok, I was making confusion with Digilent discussion 

Yesterday I did make use of Picoscope 7 for a few hours and i got a dozen of "crash to desktop" simply changing some parameters, missing features apart I can see a long path to final release 

[markone]

Please let me know if there is a "trick" to obtain a  similar functionality.

I would expect you probably can use interval triggering for this (if I understood your requirement correctly). This will trigger on the second falling edge if a large time (time longer than your packet length) has been between the first and the second edge, so you always trigger on the first falling edge of the "new" package. I am however not sure if it will also "see" again the first edge in this new package and retrigger on the next package or you will always mis a package in between. I indeed use this the pico more for analog work instead of protocol analysis. 
-snip

Finally i had the time to extensively try Interval trigger as you suggested: it works for the purpose but essentially only with certain ratio between horizontal time scale & Trigger "time" parameter, luckily in a way that is compatible with my needs, so problem solved   

Now i have another question that could be silly for Picoscope's users :

why if i set (i.e.) horizontal scale to 10ms/div and number of samples to 10Ks the resulting sample interval is 10.24us ? 

[jasonRF]

Please let me know if there is a "trick" to obtain a  similar functionality.

I would expect you probably can use interval triggering for this (if I understood your requirement correctly). This will trigger on the second falling edge if a large time (time longer than your packet length) has been between the first and the second edge, so you always trigger on the first falling edge of the "new" package. I am however not sure if it will also "see" again the first edge in this new package and retrigger on the next package or you will always mis a package in between. I indeed use this the pico more for analog work instead of protocol analysis. 
-snip

Finally i had the time to extensively try Interval trigger as you suggested: it works for the purpose but essentially only with certain ratio between horizontal time scale & Trigger "time" parameter, luckily in a way that is compatible with my needs, so problem solved   

Now i have another question that could be silly for Picoscope's users :

why if i set (i.e.) horizontal scale to 10ms/div and number of samples to 10Ks the resulting sample interval is 10.24us ?

The fastest sample rate is 10ns.   Each time you increase the time base this goes up by a factor of 2.  So you must have done this 10 times since 2^(10) = 1024 and 10ns * 1024 = 10.24 us. 

[markone]

Please let me know if there is a "trick" to obtain a  similar functionality.

I would expect you probably can use interval triggering for this (if I understood your requirement correctly). This will trigger on the second falling edge if a large time (time longer than your packet length) has been between the first and the second edge, so you always trigger on the first falling edge of the "new" package. I am however not sure if it will also "see" again the first edge in this new package and retrigger on the next package or you will always mis a package in between. I indeed use this the pico more for analog work instead of protocol analysis. 
-snip

Finally i had the time to extensively try Interval trigger as you suggested: it works for the purpose but essentially only with certain ratio between horizontal time scale & Trigger "time" parameter, luckily in a way that is compatible with my needs, so problem solved   

Now i have another question that could be silly for Picoscope's users :

why if i set (i.e.) horizontal scale to 10ms/div and number of samples to 10Ks the resulting sample interval is 10.24us ?

The fastest sample rate is 10ns.    Each time you increase the time base this goes up by a factor of 2.  So you must have done this 10 times since 2^(10) = 1024 and 10ns * 1024 = 10.24 us.

Mmmh, i'm not able to follow your explanation, horizontal time division changes with 1-2-5 sequence like all desktop scope, not in power of 2, the weird thing here is that sample interval is often fractional resulting in "odd" total number of samples.

Let's take the following actual scope setting : 10ms/div -> 100ms full horizontal scale , Sample interval : 10.24us, No Samples : 9766

Why it's not like this : sample interval : 10us, number of sample  10000 ?

I fear that in 2204A/2205A sample clock generator is not capable to generate integer sample interval for all time base settings  amnd / or there are other trade-off that prevent that

If positive, i'm not happy.

[jasonRF]

Please let me know if there is a "trick" to obtain a  similar functionality.

I would expect you probably can use interval triggering for this (if I understood your requirement correctly). This will trigger on the second falling edge if a large time (time longer than your packet length) has been between the first and the second edge, so you always trigger on the first falling edge of the "new" package. I am however not sure if it will also "see" again the first edge in this new package and retrigger on the next package or you will always mis a package in between. I indeed use this the pico more for analog work instead of protocol analysis. 
-snip

Finally i had the time to extensively try Interval trigger as you suggested: it works for the purpose but essentially only with certain ratio between horizontal time scale & Trigger "time" parameter, luckily in a way that is compatible with my needs, so problem solved   

Now i have another question that could be silly for Picoscope's users :

why if i set (i.e.) horizontal scale to 10ms/div and number of samples to 10Ks the resulting sample interval is 10.24us ?

The fastest sample rate is 10ns.    Each time you increase the time base this goes up by a factor of 2.  So you must have done this 10 times since 2^(10) = 1024 and 10ns * 1024 = 10.24 us.

Mmmh, i'm not able to follow your explanation, horizontal time division changes with 1-2-5 sequence like all desktop scope, not in power of 2, the weird thing here is that sample interval is often fractional resulting in "odd" total number of samples.

Let's take the following actual scope setting : 10ms/div -> 100ms full horizontal scale , Sample interval : 10.24us, No Samples : 9766

Why it's not like this : sample interval : 10us, number of sample  10000 ?

I fear that in 2204A/2205A sample clock generator is not capable to generate integer sample interval for all time base settings  amnd / or there are other trade-off that prevent that

If positive, i'm not happy.

Of course you are right - it does not change by a factor of 2 for every time-base setting.  Not sure what I was thinking!   Depending on the number of samples desired, sometimes it changes by a factor of 4. 

But otherwise what I wrote is what the scope does for 'standard' mode.  The highest sample rate of the 2204a is 100 MHz (10 ns intervals), and after that it seems to divide the clock down by powers of 2.  When using the API you select the sample rate by specifying the power of 2 that divides down that fastest 100 MHz, so this could be a function of the hardware and not just a picoscope software thing.  The upshot is that you do not get the exact number of samples that you 'ask' for. 

In streaming mode (at least in the picoscope software) it seems to operate differently, in that the highest rate is 1 MHz, and it seems to divide it down by integers (not just powers of 2).   

One thing about your example that I don't understand: are you getting more than 8k samples with your 2204a?   With your settings I get 4.88 kS at 48.8 kS/s.  Or are you using a 2205a (or a hacked 2204a)? 

Jason

[markone]

-snip

One thing about your example that I don't understand: are you getting more than 8k samples with your 2204a?   With your settings I get 4.88 kS at 48.8 kS/s.  Or are you using a 2205a (or a hacked 2204a)? 

Jason

 

[markone]

I found the confirmation to my fear in series 2000 programming guide, Block Mode section :

A PicoScope 2000 Series oscilloscope can sample at a number of different rates that correspond to the maximum sampling rate divided by 1, 2, 4, 8 and so on.

so the rules of power of two ratio apply to sample rate, this results in not being able to freely choose the desired rate (i.e 100.000S/s)  and explains the way Picoscope 6/7 select sample interval & sample number.

I guess (and hope), higher models have not this limitation.