BFisher

Ok, thanks. I get that you don't have the specific time in the protocol. But I'd like to place an informative time stamp in the script output, but "Timestamp" does not appear under "View" in the script tab. In other words, I'm using a script to replace the normal CAN protocol output to show more details of things I am interested in, but timestamp is not available under the script tab. Alternatively, if I could get the time somehow within the script, I could print it myself. Or perhaps I am missing something? Is the Script tab the only place you can run the script or can you actually somehow run the script in the protocol tab?

I'm writing a script which displays CAN messages in a slightly different format from the standard CAN protocol decoder. I'd like to indicate the time that a CAN message arrived, as can be done in the standard display (with View/Timestamp). However, I can't find a way to get the time. The example shows getting time from Scope.Time.taken, for example, but this does not work either from CAN.Time.taken or Protocol.CAN.Time.taken or Protocol.Time.taken (all seems like possibilities based on the doc saying that it would work with any "instrument". It would also be fine to get the real time rather than the received time. Is any of this possible?

The documentation *seems* to imply that to spy on the CAN protocol with the Digital Discovery, you must connect to the Rx and Tx lines on the device side of a transceiver. Unfortunately, most time a transceiver is on the board and trace-wired to the device. Is there a way to look on the actual CAN differential bus, which is more likely to be accessible? Thanks!

I see. Too bad, but thanks for the answer.

I'm a bit unsure what you are saying in the first sentence. I probably should have said that I am spying in all cases, not driving anything. Thanks for the thought about the glitch filter. I saw elsewhere that the glitch filter depends on having the clock speed set correctly (which was not clear until just now) so that might answer the question about why there is an error. But I have to say that the ability to have the protocol and LA screens together (not on separate tabs) is a lot less useful if they are not displaying the same signal at the same time. Thanks! And btw, the protocol analyzer and the protocol-based LA are great and really helpful.

I would really like to run the PA and the LA simultaneously. Here is an example of why: Every once in a while sniffing the I2c bus with the PA, I see "Error" and I'd like to look at the LA to see what the signals were actually doing at that point. I've seen one similar question where Atilla said that it would not be possible to trigger the LA on an error (too bad!) and another where someone else showed how to do the sniffing on either the LA or the PA. In addition, some of the documentation seems to talk about triggering multiple virtual instruments with the same signal (in this case it would be an I2c start). But anything I try either gives me an error or else when I start the LA it stops the PA (or vice versa). Is anything like this possible? It seems like a potentially important feature! Thanks!

Hi everyone, I've always found forums like this to be even more helpful than documentation, which tends to either miss subtleties or be written such that my issue is difficult to find. I'm pleased to see that Digilent has a forum like this. I just bought a Digital Discover which has not arrived yet, but I'm borrowing the DD of a friend. Question coming up when I find the right place to put it (unless I find the answer already!)