Unable to trigger on CAN ID or CAN frame error

[bornant]

With our 5443D we can successfully decode CAN frame but cannot trigger on specific CAN Id's or CAN error frames.

Can anyone explain how to do this ?

[Gerry]

Hi Bornant,

I've deliberately avoided answering this, as I didn't want to just post a negative response (some other forum user may have needed to do this and might be able to point you in the direction of specific equipment that can help), but as no-one seems to have provided you with an answer I will let you know what is not possible.

The picoScope 5443D, along with our PicoScope 6 software has some complex triggering capabilities but, unfortunately, what it can't do is trigger from decoded data. The main problem is that the decoding is done in the computer while the triggering is done in the hardware.

Even when using our Software Development Kit to decode data and extract it from a captured CAN transmission, you would then need to be able to do something after having found your specific CAN ID's or CAN error frames. So, you would have to create some kind of signal (from the PC or from something else controlled by it) to capture in the hardware PicoScope in order to be able to trigger from it. However for this to work, the decoding and signal generation would have to be fast enough to avoid missing some of the data immediately following the frames you would be triggering from. What you would have in your favour is that you could set the PicoScope up to capture all post-trigger data and use all of your available buffer memory, so that by the time you have decoded the data and generated a trigger, you will have just finished, or not yet finished, capturing the data that you want. What you would have against you is that the data will take time to transfer over USB, which, when you add the time to decode, and finally generate the trigger signal, will be longer than the time capturing your data, because of the time it takes to establish a USB connection and initiate the transfer.

However, it might be possible that there's some hardware frame grabber (like a packet sniffer) out there that can decode what you want and provide some kind of electronic indication that you can use as a trigger, faster than the time it takes to finish capturing your post-trigger data.

Regards,

Gerry

[bennog]

Is it possible to run the PicoScope6 software in streaming mode and let some other (preferably C or C++) program peek at the data at the same time.

I know this will be a feature request

And if generate a software trigger from this code (treated as a hardware trigger with some delay because of USB latency)

On modern hardware a C/C++ is capable enough to decode the protocol data (so the user can write his own trigger software) and display it on the PicoScope 6 software.

Benno

[Gerry]

Hi Benog,

The data stream will be USB up to the PC, and then handled by the driver, so where would you be thinking of peeking? You would need low level understanding of the USB protocol and then details of how our driver talks to the PicoScope (which is proprietary information that PicoTech would not give out to customers) to peek at the live USB stream (assuming that the peeking doesn't corrupt the USB signalling. You would need knowledge of how our driver works to peek at the data coming into the PC on the USB port (again very proprietary). After the stream has exited the driver you could then peek at it, which is what our SDK allows you to do, by writing your own application.

It takes typically some 10s of milliseconds to establish a USB connection, then there is waiting for CPU time, then waiting for all of the data, then decoding it, and then generating the trigger through the computer i/o. That could be a lot of data that you would need to capture in order not to miss the data you're looking for. Without having done the Math, I guess, under certain circumstances it may be possible to do it (perhaps I should have said "it is likely to be longer than the time capturing your data") but I would doubt it. You're welcome to attempt developing an application that shows it working .

Regards,

Gerry

[bennog]

With peeking i mean the PicosSocpe6 software has some interface to export the received data in realtime to a external application (TCP or something else) so this application can look at the samples at the same time as the PicoScope6 software does.

Extra bonus points if the external application can send something back on the TCP stream to generate a trigger or stop the streaming.

The realtime decode of the CAN messages at 2.5 or 5 MS/sec is not a big problem.
I have done this in the past with the SDK (C++). The only problem was I can not look at the data in PicoScope6 software anymore.

Benno

[Gerry]

Hi Bennog,

Unfortunately, with PicoScope 6 there are proprietary reasons why that is not something PicoTech are prepared to do.

However, you could always get another PicoScope to probe the CAN data stream with at the same time, and then run your application on to trigger the first PicoScope.

Regards,

Gerry

[bennog]

Other option and more fun to do is hacking the .psdata format and write .psdata files.

Benno