SDS800X HD Wanted Features

[AndyC_772]

I'm sorry to say that CAN_H-CAN_L did not work on the SDS800X HD with V1.1.3.3 firmware.

That's a shame, but not a problem. It's why I own an active differential probe.

I don't suppose you know if it's any different on the 2000X-HD series?

[2N3055]

I'm sorry to say that CAN_H-CAN_L did not work on the SDS800X HD with V1.1.3.3 firmware.

That's a shame, but not a problem. It's why I own an active differential probe.

I don't suppose you know if it's any different on the 2000X-HD series?

Whole series is the same in that respect.
If there are some enhancements with time, they will likely be applied to whole platform.

EDIT: I was talking about UART.

[ebastler]

It would be really cool if you could acknowledge, every now and then, that what you considered a bug is not one [...]

I did not say the B-Wort 

You missed my point, I'm afraid. It was not about whether you called this a bug report or an improvement suggestion.

Point is, your suggestion to let Auto-trigger always re-capture a new waveform immediately, without waiting for another trigger event at all, did not make sense. I tried to explain why. And it would have been nice of you -- in this and similar instances before -- to acknowledge that you understood and appreciated the explanation. But all we get is another "But what I want should be possible!".

That has gotten under other several readers' skin a while ago, and it is beginning to get under mine. Hence this friendly suggestion for your future communication in this thread.

[eTobey]

You missed my point, I'm afraid. It was not about whether you called this a bug report or an improvement suggestion.

Point is, your suggestion to let Auto-trigger always re-capture a new waveform immediately, without waiting for another trigger event at all, did not make sense. I tried to explain why. And it would have been nice of you -- in this and similar instances before -- to acknowledge that you understood and appreciated the explanation. But all we get is another "But what I want should be possible!".

That has gotten under other several readers' skin a while ago, and it is beginning to get under mine. Hence this friendly suggestion for your future communication in this thread.

Then dont say that i considered it a bug! Its just not true.

I just can not accept things, that i think can be made better. My apologies for beeing me...

[eTobey]

Isnt the auto trigger supposed to trigger "all the time" even when there are no changes in the level, when there is no holdoff set up?

My auto trigger does not even trigger when there are pulses... It does for a few moments, then freezes. The frequency reading is reading something.

Just realized, that the normal trigger does this too!

Short pulses every 2.5us and some longer in between.

When i move the trigger, it starts to work again for a few seconds.

WTF? This scope starts to get annoying! Only started to use it this morning. 

Edit:
Issue confirmed on pulse trigger mode too! Does happen with 3ms holdoff. The thresshold when it happens is about 885us holdoff.
It seems that there is a general holdoff bug, that is not only related to edge trigger???

I suprisingly could not reproduce this issue. I suspect some lost settings, that are not saved when turning off the scope. Trigger levels of none active channels? (they shouldt not, but youll never know).

But just now i had this problem again. Only with the difference, that it now took many minutes for it so freeze. I made a video, since sharing settings seemingly does not help to find the exact cause (open in youtube to see all the details):


Another freeze (also only after dozents of minutes:

[Performa01]

I'm sorry to say that CAN_H-CAN_L did not work on the SDS800X HD with V1.1.3.3 firmware.

That's a shame, but not a problem. It's why I own an active differential probe.

I don't suppose you know if it's any different on the 2000X-HD series?

No, this is a problem exclusively of the SDS800X HD series SLA1016 digital channel adapter. It works as expected when using analog channels.

The SDS2000X HD is a higher class instruments with more (FPGA, memory) resources. There CAN works also with differential signals:

Here's how it looks like on a SDS2000X HD:


SDS2504X HD_Decode_CAN_125kBd_diff

EDIT: bug description corrected.

[Performa01]

It seems like everyone has already forgotten that there is indeed a general bug with trigger holdoff:

https://www.eevblog.com/forum/beginners/holdoff-does-not-work-siglent-sds814x-hd/msg5419874/#msg5419874

This bug has been confirmed quite a while ago here:

https://www.eevblog.com/forum/beginners/holdoff-does-not-work-siglent-sds814x-hd/msg5422700/#msg5422700

This will be fixed with the next firmware, which shall be distributed to beta testers this week.

[ebastler]

It seems like everyone has already forgotten that there is indeed a general bug with trigger holdoff: [...]
This will be fixed with the next firmware, which shall be distributed to beta testers this week.

My perception so far was that the bug essentially has the effect of the trigger holdoff time being ignored (under certain circumstances?).  If there are other known side effects, it would be good if they can be published -- to bridge the time until a new firmware can be released, and avoid duplicate reports on already known issues.

[eTobey]

It seems like everyone has already forgotten that there is indeed a general bug with trigger holdoff:

It may or may not be directly related to it. Hard to tell. Because in the latest case, it is a persistant failure of the trigger. Not just missing a few edges.

The fact, that is not reproducible as the other issue bug, makes me think that it might be a different one.

[pdenisowski]

I'm sorry to say that CAN_H-CAN_L did not work on the SDS800X HD with V1.1.3.3 firmware.

Among other things, this bug will be fixed with the next firmware release, yet unfortunatley the fix might not be what you expect: the CAN_H-CAN_L setting will just be deleted from the UI.

Some background information:

Serial decoders are closely related to serial triggers. We can copy settings from one to the other. Triggers are working in hardware on the trigger data stream, which is completely seperate to the record data. This should explain why a digital trigger can only work on physical input channels and not math results, and for some reasons we don't get the subtraction done in hardware on the basic SDS800X HD. And because of the before mentioned close relationship with the decoders, they also cannot accept any other data sources as the input channels.

Sorry if I'm being dense, but I don't understand the relationship between CAN_H or CAN_L not working using a single-ended probe and the background information you provided.   Is this a triggering issue?  Do you have to use a serial trigger (which, presumably, is protocol-aware, so to speak) to decode serial signals?

[Performa01]

I'm sorry to say that CAN_H-CAN_L did not work on the SDS800X HD with V1.1.3.3 firmware.

Among other things, this bug will be fixed with the next firmware release, yet unfortunatley the fix might not be what you expect: the CAN_H-CAN_L setting will just be deleted from the UI.

Some background information:

Serial decoders are closely related to serial triggers. We can copy settings from one to the other. Triggers are working in hardware on the trigger data stream, which is completely seperate to the record data. This should explain why a digital trigger can only work on physical input channels and not math results, and for some reasons we don't get the subtraction done in hardware on the basic SDS800X HD. And because of the before mentioned close relationship with the decoders, they also cannot accept any other data sources as the input channels.

Sorry if I'm being dense, but I don't understand the relationship between CAN_H or CAN_L not working using a single-ended probe and the background information you provided.   Is this a triggering issue?  Do you have to use a serial trigger (which, presumably, is protocol-aware, so to speak) to decode serial signals?

It has been suggested that decoders could use a poor men's differential probe solution, using two single ended probles and just a simple math operation to get the difference signal. I tried to explain why decoders don't work on anything else than physical input channels - because settings must be compatible with triggers, which cannot work on math channels.

CAN was just raised as an example where differential signals can be processed by a serial decoder. Both CAN_H and CAN_L are working fine here, and for most higher class scopes like the SDS2000X HD the differential signal CAN_H-CAN_L works just as well, but not for the bottom line 800 series.

Of course we could demand a similar feature for differential signals in any other decoder as well, because nobody prevents us from using a differential bus for e.g. SPI - and for UART there is even the well established RS485 standard. Yet I guess there isn't much demand for this because folks who regularly deal with differential signals would hopefully have appropriate active differential probes which also prevents heavy capacitive loading, which in turn could cause signal reflections on the bus lines.

[Performa01]

It seems like everyone has already forgotten that there is indeed a general bug with trigger holdoff: [...]
This will be fixed with the next firmware, which shall be distributed to beta testers this week.

My perception so far was that the bug essentially has the effect of the trigger holdoff time being ignored (under certain circumstances?).  If there are other known side effects, it would be good if they can be published -- to bridge the time until a new firmware can be released, and avoid duplicate reports on already known issues.

Yes, that is my perception too. Yet I rarely ever use Holdoff – this is kind of a last resort if I can’t get a stable triggering even from the bunch of advanced triggers. And with holdoff being disabled, triggers work as expected.

I can only repeat that my spare time is limited and that’s the reason why I don’t want to waste my time testing any other possible side effects of the Holdoff defect. I’m busy with more than half a dozen DSOs, so I leave further bug verification to Siglent. They are certainly able to get it right, as in all higher-class instruments, where there is not only Holdoff by Time but also by Event. They are aware of the (real) issues and have promised a fast bug-fix release (which would be fast indeed if we get a beta version this week), whereas reasonable feature requests will be considered too but they will have to wait for a later firmware release.

[eTobey]

My apologies...

You should read this:
https://www.eevblog.com/forum/news/my-apologies/

[Performa01]

I'm sorry, but I've spread misinformation in my earlier posting. The SDS800X HD works fine with differential CAN bus signals:


SDS824X HD_Serial_CAN_diff

It's just the SLA1016 digital probe that does not support differential signals for CAN.

[AndyC_772]

That would make sense, because digital inputs inherently use a simple comparator and threshold to make a 0 or 1 decision, per channel. Short of including real, physical differential amplifiers in the scope (now there's a feature request...!), they couldn't possibly have any CMRR.

In that case, though, I think I'd reiterate my earlier suggestion, that if it can decode a differential signal in CAN mode, then the hardware should be physically capable of doing the same in UART mode. That would have been useful to me last week when it turned out I had an RS485 receiver that, contrary to the explicit guarantee in the data sheet, definitely did NOT always output a logic '1' when the bus was terminated but not driven.

[markone]

Hi folks,

I received an SDS814HD a couples of hours ago, after FW update and Self calibration I connected an UART line to channel 1 and It tooks few seconds that trigger Holdoff is not working at all ...
 
Jumped here and discovered that is a known bug, damn I should have checked before, I had a presentation of this instrument scheduled tomorrow and trigger holdoff is mandatory for the purpose.

Quick question : there is a way to obtain the beta FW that fix the problem today ?

Otherwise I have to cancel the presentation, causing some loss of credibility in my person and / or the instrument itself 

[ebastler]

I had a presentation of this instrument scheduled tomorrow and trigger holdoff is mandatory for the purpose.

Do you really need holdoff there? To my mind it is mainly a legacy trigger option, dating back to CRO days where edge trigger and holdoff was all we got. Pulse trigger allows you to trigger at the end of defined quiet periods in the signal, and is a more flexible and robust choice in most situations. Or the various advanced triggers for more specialized situations, of course.

[markone]

I had a presentation of this instrument scheduled tomorrow and trigger holdoff is mandatory for the purpose.

Do you really need holdoff there? To my mind it is mainly a legacy trigger option, dating back to CRO days where edge trigger and holdoff was all we got. Pulse trigger allows you to trigger at the end of defined quiet periods in the signal, and is a more flexible and robust choice in most situations. Or the various advanced triggers for more specialized situations, of course.

Thank you very much for the suggestion, i gave it a try and it works for the purpose, presentation saved 

[eTobey]

Improvement suggestion:
Placing the zoom window with a double tap on the upper window does not work, if there is a cursor at the same spot.

Edit:
Improvement suggestion 2:
After having captured a few traces on persistance, moving the traces to measure with cursors is not possible, since all traces except one dissappear. 

[tautech]

Hi folks,

I received an SDS814HD a couples of hours ago, after FW update and Self calibration I connected an UART line to channel 1 and It tooks few seconds that trigger Holdoff is not working at all ...
 
Jumped here and discovered that is a known bug, damn I should have checked before, I had a presentation of this instrument scheduled tomorrow and trigger holdoff is mandatory for the purpose.

Quick question : there is a way to obtain the beta FW that fix the problem today ?

Otherwise I have to cancel the presentation, causing some loss of credibility in my person and / or the instrument itself 

We are working through the beta FW which so far looks very good.

Holdoff issues seem completely remedied at least in my tests with packets and clocks.
Bode plot Save works correctly. (no AWG or signals connected.)

Time clock running on Linux time for a 24hr test of internal clock accuracy against another scope with NTP time engaged.....especially for Muttley....sorry mate should've got onto this weeks ago. 

[ebastler]

My auto trigger does not even trigger when there are pulses... It does for a few moments, then freezes. The frequency reading is reading something.

I have been able to reproduce this bug. I only got it when trigger holdoff is enabled, but it is clearly a different symptom from the "holdoff not working" that was described before. Maybe it is already fixed with the new beta firmware nevertheless? It would be great if the beta testers could check:

Test signal
- SDG2042X, connected via BNC into 50 Ohm terminator
- Square wave, 1 Vpp
- Frequency-sweep 10 kHz .. 100 kHz over 100 ms.
- Edit: A frequency sweep from 10 kHz .. 1 MHz over 100 ms will produce the problem much faster.

Scope settings
- Start from Default settings
- Connect signal to CH1
- Edge trigger, positive edge, 3 ms holdoff
- Leave timebase at default 1µs/div (but 5, 10, 50 µs/div also show the problem)
- Leave memory at default 10 MPt (but other settings also show the problem)

Observed behaviour
- Leave scope in RUN mode, wait up to a minute or so (but sometimes the problem occurs within seconds)
- In AUTO trigger mode, the scope will stop rendering new waveforms entirely. Trigger status shows READY, trigger frequency counter is still updated, waveform is frozen. Operation restarts after any user interaction.
- In NORMAL trigger mode, the error seems rarer, but occurs eventually. Before it does, I noticed sporadic "hickups" , where the trigger status switches to "Arm" and the waveform is not updated for a few thenths of a second.

[electronics hobbyist]

Improvement suggestion:
Placing the zoom window with a double tap on the upper window does not work, if there is a cursor at the same spot.

I haven't figured out a good solution because don't know if the user wants to choose the cursor or select an area. If want to distinguish between single and double clicks, I don't know if it's technically feasible.

Edit:
Improvement suggestion 2:
After having captured a few traces on persistance, moving the traces to measure with cursors is not possible, since all traces except one dissappear.

Do you want to keep the persistance until you clear it?

[Performa01]

My auto trigger does not even trigger when there are pulses... It does for a few moments, then freezes. The frequency reading is reading something.

I have been able to reproduce this bug. I only got it when trigger holdoff is enabled, but it is clearly a different symptom from the "holdoff not working" that was described before. Maybe it is already fixed with the new beta firmware nevertheless? It would be great if the beta testers could check:

It should not be different at all. Holdoff not working means exactly that - and things not working might produce all kind of symptoms.

Thank you for providing a complete gudance how to reproduce the issue. I've used 100 Hz to 1 MHz sweep and enabled advanced measurements on top of that, just to prove that the scope was running for at least 10 minutes with 3 ms trigger holdoff:


SDS824X HD_Trigger_HO3ms_10min

No glitches, no hickups, no "freezing".

[electronics hobbyist]

My auto trigger does not even trigger when there are pulses... It does for a few moments, then freezes. The frequency reading is reading something.

I have been able to reproduce this bug. I only got it when trigger holdoff is enabled, but it is clearly a different symptom from the "holdoff not working" that was described before. Maybe it is already fixed with the new beta firmware nevertheless? It would be great if the beta testers could check:

Using this setting, it is easy to stop waveform acquisition in version 1.1.3.3, It seems that it is the same issue as bug No.9.

[ebastler]

Thanks to performa01 and electronics hobbyist for checking the trigger behaviour with both, the current and the upcoming firmware. This seems to confirm that, while the symptoms are different from the previously reported holdoff malfunction, the underlying cause is a common one and has now been fixed. Great!