There is some confusion about history/search/navigate usage. I don't find an exact answer in the manual so hopefully someone can enlight me
btw can I overlay the frames after stopping and going to history agin or is that only done in 'live-mode'?
There is some confusion about history/search/navigate usage. I don't find an exact answer in the manual so hopefully someone can enlight me
- Press "Search"
- Touch "One Key Navigate"
- Select Type = "History Frame"
- Select appropriate interval time - the default 1 µs is fine for search
- Enable "Stop On Search Event"
- Now play the event list in any direction and playback will automatically stop as soon as a frame that contains the search condition is displayed. Any hits are highlited by white triangles below the menu bar on the screen
btw can I overlay the frames after stopping and going to history agin or is that only done in 'live-mode'?You can play back the whole history at maximum speed, i.e. with a short interval time. This will look pretty much like the live signal display did.
P.S. Although a different thing. I recently noticed some strange behaviour with zone triggers. They work fine, but with zone triggering and and sequence I had Signal flashing through the disclosed zone from time to time. But only in sequence recording normal work was ok.
What trigger setting and threshold are you using?
First 2 things I do after getting any protocol on screen are to determine the correct Idle setting and max packet length and then set a correct Edge trigger for the very first edge in a packet and Holdoff a shade longer than the longest packet.
QuoteFirst 2 things I do after getting any protocol on screen are to determine the correct Idle setting and max packet length and then set a correct Edge trigger for the very first edge in a packet and Holdoff a shade longer than the longest packet.
Thanks. I will try this again and see how my packets look like.
At the same time, when I see the scope presenting a successfully decoded message (not marked as an error) then I assume it should be correct. Or is that a wrong assumption?
@Tautech: did you check that you are getting the right data on screen? The fact you get some data on the screen doesn't mean it is decoded properly. When I look in the manual of the STB-3 board I see different data being specified and your screendump also shows not all packets are being decoded.
@Tautech: did you check that you are getting the right data on screen? The fact you get some data on the screen doesn't mean it is decoded properly. When I look in the manual of the STB-3 board I see different data being specified and your screendump also shows not all packets are being decoded.
Manual for STB-3 board specifies exactly this data:
h 54_5f
h 54_5f
h 45_4e_54_5f
h 53_49_47_4E_54_5f (h53_49_47_4c_54_5f as written is error because it is not SIGLELT, as can be seen in a screen capture below in the manual)
I'm sure you can figure out order and convert hex to ASCII...
Those 4 repeat in a sequence.
And all the data in Tautech screenshots is decoded, except first and last packet that are chopped of...
Hi, I am quite confused about the logic operations of the pattern trigger. Maybe somebody can check my thinking:
I was referring to the last screenshot Tautech posted assuming that it is his measurement.
OK, I think I found the solution to the LIN decode problem. Long story short: It’s about whether the LIN signal is idle high or idle low.
- On the RTB and PicoScope, you can change polarity in a setting in the protocol menu.
- The SDOX has no such setting in the protocol menu and defaults to idle HIGH, but you can invert the selected channel. Fair enough.
- The SDS has no such setting in the protocol menu and defaults to idle LOW, but you can invert the selected channel. Fair enough.
So far so good…. Now, where is the issue?
Well, the RTB, DSOX or PicoScope simply show no decoded signal when the polarity setting is wrong and decode is impossible. BUT THE SDS SHOWS A COMPLETELY WRONG DECODED SIGNAL WHEN POLARITY IS WRONG AND SHOWS IT AS IF IT’S A GOOD SIGNAL WITH NO ERRORS!
Once you are aware polarity is wrong (by instance by noticing different results on three other devices ;-), you change channel polarity, re-do the threshold, and it works properly. Now I figured that out, I am able to decode all my busses correctly. But the SDS behaviour is troublesome. When the user thinks a proper signal is decoded, it may be actually totally wrong. I consider this to be a bug. If someone wants to report to Siglent, be my guest...
PS. Like nctnico noted, successful decode is totally independent of trigger. Even works perfectly on free run (auto trigger) when trigger is not configured at all.
Another maybe silly question: I thought that the scope was automatically capable to reconize if the probes are set to 10x or a 100x but It doesn't do It.
Is due to cheap probes they gave in bundle?
Well, yes, but I've never seen 1X/10X switchable probes that had that sensor feature. It would be tricky to implement automatically and there's not much point to making it a manual selection. Higher end fixed ratio probes may have readout pins, but not 1X/10X.
Lots of 1X/10X probes have that feature. I have a few probes from probemaster.com that have 1X/R/10X switching and the readout pin. Mine are from the 4900 series that I use with the SDS2KP. You can flip the switch on the probe and the scope detects the change.
Thanks,
Josh
Could you please elaborate more on this?
LIN signal is active LOW. That is standard. It means it sits at positive voltage on idle and gets pulled down to ground when active (logical 1).
How on earth did you achieve polarity on SDS2000X+ to be wrong in a first place? All these scopes have common ground, how did you connect it the wrong way?
I did check now and Siglent does seem to get confused (same as I am by negative going LIN signal, I guess :-). But that is a fringe case.
Well, the RTB, DSOX or PicoScope simply show no decoded signal when the polarity setting is wrong and decode is impossible. BUT THE SDS SHOWS A COMPLETELY WRONG DECODED SIGNAL WHEN POLARITY IS WRONG AND SHOWS IT AS IF IT’S A GOOD SIGNAL WITH NO ERRORS!
Once you are aware polarity is wrong (by instance by noticing different results on three other devices ;-), you change channel polarity, re-do the threshold, and it works properly. Now I figured that out, I am able to decode all my busses correctly. But the SDS behaviour is troublesome. When the user thinks a proper signal is decoded, it may be actually totally wrong. I consider this to be a bug. If someone wants to report to Siglent, be my guest...
I think it would be nice to see the interpreted data, but highlight (in red?) that the checksum is wrong.