Products > Test Equipment

Picoscope 2204A streaming mode & trigger Holdoff

<< < (3/5) > >>

jasonRF:

--- Quote from: markone on December 02, 2022, 11:47:30 pm ---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.

--- End quote ---
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


--- Quote from: jasonRF on December 04, 2022, 02:28:44 am ---
--- Quote from: markone on December 02, 2022, 11:47:30 pm ---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.

--- End quote ---
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. 

--- End quote ---

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).


--- Quote from: jasonRF on December 04, 2022, 02:28:44 am ---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. 

--- End quote ---

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.


--- Quote from: jasonRF on December 04, 2022, 02:28:44 am ---But of course this does not help the fact that within the Picoscope software you cannot get around these streaming limitations.

--- End quote ---

 :(


--- Quote from: jasonRF on December 04, 2022, 02:28:44 am ---The trigger hold-off is another matter completely.  It hasn't bothered me personally, but I don't do very complicated stuff. 

jason

--- End quote ---

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_:

--- Quote from: markone on December 04, 2022, 01:59:27 am ---Please let me know if there is a "trick" to obtain a  similar functionality.

--- End quote ---

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. 


--- Quote from: markone on December 04, 2022, 01:59:27 am ---Which port are you referring to ?

--- End quote ---

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:

--- Quote from: _Wim_ on December 04, 2022, 08:03:13 am ---
--- Quote from: markone on December 04, 2022, 01:59:27 am ---Please let me know if there is a "trick" to obtain a  similar functionality.

--- End quote ---

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. 

--- End quote ---

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


--- Quote from: _Wim_ on December 04, 2022, 08:03:13 am ---
--- Quote from: markone on December 04, 2022, 01:59:27 am ---Which port are you referring to ?

--- End quote ---

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.

--- End quote ---

Ok, I was making confusion with Digilent discussion  :D

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  ;)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod