I have a problem with a system that only occurs 1 time a day. Normal triggering is not working, so the only way is to stream raw data from de logic pro 24/7 and save a chink of data when the problem occurs.
This is because the triggering depends on 2 analog inputs.
Is there a way to do this. (I used to do this with picoscope but I need 6 analog data streams for this problem, so my 4 ch picoscope won’t do the trick this time)
Benno
Hi Benno,
We don’t currently support analog triggers. I would suggest using our automation API to automate the process of capturing and saving a series of shorter captures. I recommend lowering the analog sample rate as low as you can to reduce the size of the save files.
You can learn more about our automation API here: Automation
It’s not practical to take extremely long analog captures with our devices due to the high memory usage, so we recommend automating the process of saving smaller captures to disk over and over to get around this limitation.
However, we don’t have a good built-in feature for searching the analog data. If it’s easy to visually identify, then the fastest option would be to just open each file and check, but if it’s not easy to visually verify, you can use the same automation API to export the analog data to CSV. You could then try writing a script to search the exported analog data for the event in question.
Could you tell us a bit more about your use case, and specifically what event you’re trying to trigger on, and what trigger feature you would need to trigger on that?
Thanks!
That is why I used ringbuffers for data storage and let it run for day’s and when the event occurs keep capturing for 1 second and then save the whole ringbuffer with the offset at the end.
It is for problems on a CAN bus where one of the members sometimes does not drive the can_h signal to the positive (can bus is at 500kbps) so capture analog signal at 5Msamples/sec would be ideal.
We also want to capture the 5V from the device that gives the problems and the internal CAN data lines.
If you save a lot of captures then you can trouw 99.9% of the captures away.
In above example you could trigger op the CAN_H below 1.4V or something like that.
You will end up wit about 50% of useless captures (common mode stuff).
Benno
Hi @saleae –
Try adding CAN_H and CAN_L as digital channels vs. analog, and experiment with the logic level threshold setting.
Note: For this discussion, I am assuming you have a Logic Pro (8 or 16), where these settings can be adjusted vs. only fixed threshold values:
For some more background on the problem itself – is the CAN bus (and all modules connected) supposed to be powered on continuously during this test, or are some modules intentionally going to sleep and/or offline, followed by a CAN bus wake-up? If so, is the wake-up on the CAN bus, or via some other signal that could be captured and used as a trigger source? What type of system & CAN modules are being debugged?
Meanwhile, trying to capture analog data at high data rates for long periods of time can be problematic, unless you have lots of RAM and a fast PC that can keep up – and you should minimize any other interference during the capture:
[Edit] It may also help to know what kind of CAN transceivers are being used. Is it a network of the same type of module, or may different modules / different suppliers? Does the CAN transceiver itself have a signal that can be probed for going to sleep/offline? E.g., you could monitor the VCC pin to every CAN transceiver, or possibly wake-up (e.g., WAKE or WUP) and/or INH signal(s), if available?
Yes I have a logic pro 16 coming this way.
The CAN transceivers are always powered.
We know what device is causing the problem but are now digging into the root cause.
The triggering in digital inputs has crossed my mind also as a solution.
As far as I can tell the CAN decoding is done after all the data is captured and not in realtime. So triggering on CAN errors makes it impossible.
I have done C++ coding for the picoscope to decode CAN in realtime over long periods of time and save only the data around the problem. This used a ring buffer of 500MB and save the whole buffer on error.
The driver with the problems is a NCV7351D10R2G it is isolated from the power supply.
We suspect some power problems because this motor has real dynamic loads acting on it.
And exactly the same motor has no problems in other places where the load is not as dynamic.
So we are planning on sampling 6 or 8 analog data streams at about 5MSamples / sec.
Benno
Okay, I would think such a basic CAN transceiver shouldn’t typically have CAN_H going low in a way that affects the CAN bus, so a digital channel on the VCC pin of the offending module might be a good place to monitor/trigger (e.g., NCV7351D10R2G pin #3)?
From this, I think you could use your analog channels to also monitor VCC and any other voltage rails on the motor/loads in the circuit to see if something is causing the VCC supply on the CAN transceiver to fall below (or otherwise outside) of expected operating voltage levels?
Note: the NCV7351 datasheet does say “Under all Supply Conditions the Chip Behaves Predictably. No Disturbance of the Bus Lines with an Unpowered Node” … so the electrical issues might be a bit more complicated than just the VCC pin going low (??) E.g., could you be having transients that are momentarily exceeding Table 4. ABSOLUTE MAXIMUM RATINGS (e.g., VCC and/or other IO pin(s) going outside of the [-0.3 to 6] V range, or ??)
Regardless, your scope plot above looks like something is actually momentarily dragging down the entire CAN bus (i.e., both CAN_H and CAN_L are going low temporarily, while some edges are still seen in the ‘noise’ as the bus is being dragged down to GND). Usually, CAN transceivers are ‘passive’ or ‘floating’ on the CAN_H/L pins when sleeping/standby/OFF, rather than driving the bus toward GND – so it seems to me like an electrical transient issue with something in the CAN bus circuit of the offending module.
We have this problem for some time now and at the moment only the master and this motor are on the bus, nothing else.
Something I thought of yesterday was that if the CAN connector gives a high resistance on the CAN_H line then the termination resistors will pull down the CAN_H because of the CAN_L is pulled down. If for example the connector has a resistance of 5k or then the 60ohm termination will pull both CAN_H and CAN_L down. And when the connection is good again the signal is also good again.
This is something we can measure with the 4 channel pico-scope will happen sometime next week.
Benno
The termination should be only 120 ohm on each terminating node (2 terminators per bus), and thus a 60 ohm bus load (2 x 120 ohm in parallel on each ‘end’). In that case, measure CAN_H on both ends and see if it looks the same – if it is an intermittent bus wiring issue, you’ll see it.
However, the CAN transceiver should be biasing the bus voltage up to 2.5V at idle, and CAN_H is driven up while CAN_L is driven down. So, a ‘good’ can bus will be nominally 2.5V at idle when online – and the terminating resistors/nominal bus loading shouldn’t override the biasing from the transceiver if all is working properly.
Thus, it does appear like something is either pulling down the bus, or failing to bias/drive it to idle levels during the failure condition. I’d suggest a deeper look at the schematic by an electrical engineer who is familiar with such failure modes and possible transients.
Were the charts above measured from the ‘bad’ module? Right at the transceiver pins?
[Edit] the other clue is that CAN_H == CAN_L == ~0V during failure, but only at times when bus is apparently active (vs. passive). In this case, monitor the TX pin on both nodes to see which node is actively communicating during the failure, but not actually driving CAN_H/L apart. As you see, the differential (CAN_H - CAN_L) is ~0V the whole time, even during the ‘glitch pulses’ which may be when the bus is ‘passive’ and going back to 2.5V idle.
No there was a M12 connector in between so we suspect the connector is the bad point of failure.
When we replace the motor it runs fine for a couple of weeks and then starts acting up.
We plan on measuring all the points on the bus and on the chip to see if this assumption is correct.
That is why I hoped the logic pro 16 could bea read out directly form a SDK (like you can do with the PicoScope SDK). The PicoScopes I have over here are all 4 channel and I need 6 channel to monitor.
I can read 2 PicoScopes at the same time with the SDK and then trigger both scopes with the same signal.
I Was hoping that the logic pro could give a higher sampling rate and more channels at the same time.
Not only for this problem but also for other problems.
The user interface is only a tool, the hardware is the main part for collecting data and understanding what is going on.
Benno
I agree, it would be nice to have a ‘headless’ mode that could just stream from USB to logfile(s) and skip the GUI. Today, you might be able to get this capability from sigrok-cli, but the Saleae Logic Pro 16 support is ‘experimental’ and likely depends on your device hardware model/chipset.
See: Saleae Logic Pro 16 - sigrok
However, I don’t know which of the newer models would work and the recent supply chain issues plagued the chipset availability for Saleae Logic Pro 16 manufacturing. By checking your Saleae hardware revision, you can see if yours is old enough to be supported by sigrok. I’m guessing that revision 0.0.0 to 3.0.0 might be supported (the older the hardware, the more likely the support), but as of 5.0.0, the FPGA hardware was changed and broke compatibility with Logic 1.x (where the firmware is extracted for sigrok support).
So, if you have a pre 5.0.0, you might be able to use sigrok and have a command-line only interface for data logging. Otherwise, it is up to Saleae to natively support a headless/command-line mode in Logic 2 and/or provide some way of getting updated firmware on newer models for use with sigrok.
Note: I don’t have personal support with sigrok (as the Saleae Logic 2 GUI works much better for my needs, and my personal Logic 8 hardware isn’t supported yet), but I do like some of the features it advertises.
PS / Note to Saleae support: I think it would be interesting and useful to expose a more ‘bare-metal’ API on the host side of the USB connection to allow lower-level access to the data stream(s) than what is available from the existing LLA/HLA Analyzer SDKs (tightly coupled with the Logic 2 GUI). I understand, this capability is currently not supported for newer hardware, and the old Saleae Device SDK that worked on previous hardware may be completely defunct/obsolete. I also understand you massively changed the GUI + API strategy and software architecture from native builds and DLLs/LIBs to Electron and gRPC (for a more unified platform across the diverse Windows/MacOS/Linux ecosystems), but I would think (hope) that gRPC is still light weight enough to include support for a lower-level feature set, too? Depending on your future software architectural plans for your next-gen hardware, I do think you could devise an API in a forward-looking way for both current and future hardware designs that could definitely enrich your Automation API/SDK and a variety of other end-user use cases 
Yes I hope we get some low level API support too.
Tis would make the Pro 16 that is coming to me a lot more useful for me.
Benno
Can the picoscope generate a digital trigger out to the Saleae?
No you can not directly, you can use alarm or something, or the SDK to evaluate the data an output some USB HID io, then you can get within 1-2 ms delay (if done in C/C++)
Most time I use the picoscope as a fast multichannel ADC, I had hope that with the logic pro I had a fast 16 channel ADC, to use in my C/C++ test applications.
You can see:
… for a way to collect a lot of data for a long time duration; I suggest minimizing the amount of analog channel data captured to reduce disk usage and USB overhead – enable as few analog channels as possible and use as low of an analog sample frequency as you can tolerate.
Note: you can also ‘hack’ the calibration to improve the bandwidth at lower sample rates, see:
Saleae Logic2 Analog filtering technical details? - #17 by Sebastian
… for a script that reduces filtering (increases analog bandwidth). You may want to back it up first so you can go back to factory default. You will need to tweak it for which analog channels to edit, and it assumes only a Pro 16 device.
As the image shows in the original post we have 500kbps CAN bus that has some problems. So you need to capture at least 5Msamples/sec. For the test we need to monitor the CAN_L CAN_H and 3 power supply’s (so a total or 5 analog channels)
The only thing we can do is use a micro to generate a digital trigger and then use that to trigger the software.
If we only could use the device as a fast 16 channel ADC using an API or so and get all the values in C/C++ for an unlimited time this would be a gamechanger for us.
I suggest trying out some sample captures and see the actual signal ‘resolution’ you get at different sample rates. You may find the default analog filtering is more aggressive on Saleae Logics than an oscilloscope (especially one with much higher bandwidth). Check out the link above for more details and ways to reduce the filtering for better analog signal captures at lower sample rates.
However, I still totally agree that it would be awesome if Saleae updated their API(s) to access live analog data streams vs. only live digital or static analog measurements. Either extending the low-level API for custom analog analyzers/plugins, and/or adding new gRPC methods for the automation API.
Also, if this API chained with new virtual channels (digital or analog), it would open up many new creative possibilities.
