SALEAE prices ...

[markone]

Interesting discussion, sorry for cross posting here, but it is kind related.

https://www.picotech.com/support/topic40355.html

It shows what Picoscope developers are thinking about the trigger in serial stuff....

Quite old stuff, gone nowhere :

"Unfortunately, a decision has been made, and this is not likely to be implemented in our software anytime soon. We will, instead be implementing the mitigating features mentioned in my previous reply".

It seems that Picoscope fan base is made mainly with analog boyz 

[jasonRF]

Have you tried the Picoscope 2000 MSO series?

Update :

just watched the following video that seems promising

 

 i will definitely look further in ther website.

Edit: I see someone else beat me to it!

Unless this will be a new feature added in future Picoscope 7 updates, picoscopes cannot trigger on decoded values.  They do all decoding in software after each capture. 

Jason

[jasonRF]

Interesting discussion, sorry for cross posting here, but it is kind related.

https://www.picotech.com/support/topic40355.html

It shows what Picoscope developers are thinking about the trigger in serial stuff....

Quite old stuff, gone nowhere :

"Unfortunately, a decision has been made, and this is not likely to be implemented in our software anytime soon. We will, instead be implementing the mitigating features mentioned in my previous reply".

It seems that Picoscope fan base is made mainly with analog boyz 

I mostly do analog stuff, and my 2-channel picoscopes are great for that.  I was just doing some SPI decoding this morning (in response to this thread) and re-verified that triggering on decoded values is not supported.  If I end up needing serial decoding that requires more than 2 channels I will obviously need to pick up a separate logic analyzer anyway. 

Jason

[sokoloff]

Not talking about the right to keep hosting it.
If you don't want to keep hosting it, that's ok!
But blocking the creator while still keeping the code... Nope!

The code was released under a license that explicitly and intentionally allows them (or anyone else who has a copy of it) to "keep it".

They haven't taken it away from the creator. The creator still has it and has the same set of rights they had before they performed their sabotage exercise. if the creator happens to have lost all copies of it, because of the licensing, github is able to provide them a copy of the repository, anonymously in incognito mode if they wish.

github has the right to keep hosting it, explicitly because of the license.
github has the right to suspend service to marak (which appears to have since been restored, though that is substantially irrelevant here).

[markone]

Have you tried the Picoscope 2000 MSO series?

Update :

just watched the following video that seems promising

 

 i will definitely look further in ther website.

Edit: I see someone else beat me to it!

Unless this will be a new feature added in future Picoscope 7 updates, picoscopes cannot trigger on decoded values.  They do all decoding in software after each capture. 

Jason

Also SALEAE's Logic does all the decoding in software, at least with "pure" Cypress CY7C68013A LA, they simply build up a pipelined process where the application capture continuously data segments and decode them in parallel, that is something that thousands of programs do in every kind of platforms.

When you have a match with the trigger pattern you start to push data segments outside the pipeline in a queue until the desired amount of data is reached, so I do not see any particular reason that prevent Picoscope to implement a such functionality, for what i have understood reading some posts in their forum they (Picoscope) are not focused on that kind of application, reason why I dropped the brand for this purpose.

[mwb1100]

As far as i understood their application started as a fork of Sigrok Pulseview but at a some point they started to crash with the community.

DSLogic guys are a bunch of thieving knobs who used a Kickstarter and the open source vibe for their own commercial benefit, without actually being open.

...

The original PulseView developer discusses this situation here.

The original Pulseview developer (Joel Holdsworth, aka OpenTechLab) doesn't seem to be as upset about it:

So at the end of this review it's time for me to give my verdict, and I'm feeling pretty positive about this device.  The price is very, very competitive compared to other logic analyzers with similar features...  And on the software side of things, I'd say that DSView has really matured in many ways.  It's pretty nice to use. And if you want to use it with sigrok, that's also an option.  I think I will be using it mainly with sigrok going forward in the future because I think sigrok's a bit more powerful than DSView in terms of the things it can do for you.

As far as DreamSourceLab not keeping the github repository up to date, it looks like they have pushed the source for v1.2.1: 

  - https://github.com/DreamSourceLab/DSView/releases/tag/v1.2.1

Though I can't say whether that tag actually builds 1.2.1 correctly (I haven't tried building DSView).

Since DSView is covered by the GPL it is completely legitimate to use the DSView software on a clone device if you want to save a bit of money.  Note that the clone devices generally don't have the shielded fly wires, which might be important in high speed scenarios (DreamSourceLab sells the shielded fly wires separately)

Never fully undertsood GPL, the ideology of free sharing is nice, but also like shooting yourself at the same time, giving away all your work for free, then let others make millions with it.

The idea behind the GPL is *user* oriented.  It was designed to make it so users aren't prevented from doing what they want with the software.  Philosophy of the GNU Project.  Essentially, the GPL imposes no restrictions on users of the the software.  It only imposes restrictions if you redistribute the software - the restriction being that you must supply the source code (including any modifications) and you have to license your distributed software under the GPL as well, preserving the user's rights to do whatever they want with it (until they redistribute).

And keep in mind that if you release source code for your software, the possibility of it being improperly used by others for profit exists regardless of the license (unless you release it to the public domain, in which case there is no "improper use" possible as far as rights to the source code).

[Zucca]

Quite old stuff, gone nowhere :

[]

It seems that Picoscope fan base is made mainly with analog boyz 

It shows that a (Pico)scope is "generally" not the right tool for advanced serial data trigger...

[nctnico]

Where it comes to I2C and CAN decoding, the ability to trigger on specific addresses is mandatory. I use that quite often while decoding I2C or CAN data.

[DavidAlfa]

It makes sense and i agree with that, but Sigrock lacks (or seems to lack) the feature that i need most : trigger on UART decoder output byte sequence and / or stacked protocol analysis.

Well, the uart decoder has some sort of functionality, "packet delimiter", all data sent before a delimiter byte will be threaten as a packet."

So if you set '$' (0x24)" as delimiter and send:

$STARTING PACKET
$ANOTHERPACKET
$CONFIG DATA
$blah
You packets will look like:
$
STARTING PACKET$
ANOTHERPACKET$
CONFIG DATA$
blah (Not shown as a packet until next $  is sent


As you see, the only problem is it behaves in the opposite way as you would expect:
The packet will be "EverythingBefore$", not "$EverythingAfter".
But I think it should be easy to modify.

Of course it supports stack decoder on top of the UART data, but not whatever you customized, but you could make a custom stack decoder with some time and patience, they're made in python and easily editable, no need to compile etc...

[markone]

Well, the uart decoder has some sort of functionality, "packet delimiter", all data sent before a delimiter byte will be threaten as a packet."

So if you set '$' (0x24)" as delimiter and send:

$STARTING PACKET
$ANOTHERPACKET
$CONFIG DATA
$blah
You packets will look like:
$
STARTING PACKET$
ANOTHERPACKET$
CONFIG DATA$
blah (Not shown as a packet until next $  is sent


As you see, the only problem is it behaves in the opposite way as you would expect:
The packet will be "EverythingBefore$", not "$EverythingAfter".
But I think it should be easy to modify.

Of course it supports stack decoder on top of the UART data, but not whatever you customized, but you could make a custom stack decoder with some time and patience, they're made in python and easily editable, no need to compile etc...

Hi David,

custom stack decoder is interesting but right now it's not what i'm looking for, currently I need something with a simple menu to define bytes  triggering sequence in HEX format straight and simple, function that I would consider mandatory for any serious test on the field.

Le me get back to DSlogic : do you know if also the U2Basic model is compatible with DSview Serial Multi Stage Trigger or it is a feature that requires DSlogic plus (or higher) ?

[thm_w]

U2Basic and Plus are the same, just the memory size change, that David mentioned above. Then the slightly lower bandwidth probes too.
It might not have sigrok support yet: https://sigrok.org/wiki/DreamSourceLab_DSLogic_U2Basic

edit: maybe its capped at 100MHz by default, prior to hack https://www.eevblog.com/forum/testgear/dslogic-u2basic-model-logic-analyzer-now-has-64mbit-buffer/
You can read all the old threads to find this information https://www.eevblog.com/forum/testgear/upgrading-dslogic-basic-to-plus-without-eeprom-modification/msg2859158/#msg2859158

[markone]

U2Basic and Plus are the same, just the memory size change, that David mentioned above. Then the slightly lower bandwidth probes too.
It might not have sigrok support yet: https://sigrok.org/wiki/DreamSourceLab_DSLogic_U2Basic

edit: maybe its capped at 100MHz by default, prior to hack https://www.eevblog.com/forum/testgear/dslogic-u2basic-model-logic-analyzer-now-has-64mbit-buffer/
You can read all the old threads to find this information https://www.eevblog.com/forum/testgear/upgrading-dslogic-basic-to-plus-without-eeprom-modification/msg2859158/#msg2859158

Many thanks for the hint, i'm going to read the full 3ad "upgrading-dslogic-basic-to-plus".

[markone]

U2Basic and Plus are the same, just the memory size change, that David mentioned above. Then the slightly lower bandwidth probes too.
It might not have sigrok support yet: https://sigrok.org/wiki/DreamSourceLab_DSLogic_U2Basic

edit: maybe its capped at 100MHz by default, prior to hack https://www.eevblog.com/forum/testgear/dslogic-u2basic-model-logic-analyzer-now-has-64mbit-buffer/
You can read all the old threads to find this information https://www.eevblog.com/forum/testgear/upgrading-dslogic-basic-to-plus-without-eeprom-modification/msg2859158/#msg2859158

Update : after reading the entire "upgrading-dslogic-basic-to-plus" thread and watched some tube review I decided to go for the "DSlogic plus", so i pulled the trigger on Ebay for about 125 Euros shipped, now the long wait begins 

Many thanks to everyone for the help, I will update with my impression on device arrival (i hope before Christmas...).