Products > Test Equipment
Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests
tautech:
--- Quote from: Martin72 on December 03, 2023, 10:49:51 pm ---I currently have a Plus model in the house, but my STB-3 board is still a bit buggy when it comes to I²C decoding. ;)
--- End quote ---
Yep yours is and when I visit Siglent next year you can be sure I'll be taking it up with them as all I have heard back about yours is crickets ! :horse:
MathWizard:
Ok I'll check into warranty on the probes, thanks. I never yanked on them or tripped over them, so IDK.
Now I'm afraid that my "good probes" which cost +$100 for 4, also had a problem way early than I expected, and that's why I was using these new included probes from day 1. Or was I just giving the old ones a rest?
tautech:
--- Quote from: MathWizard on December 03, 2023, 11:10:54 pm ---Ok I'll check into warranty on the probes, thanks. I never yanked on them or tripped over them, so IDK.
--- End quote ---
They are much better now however we did have a poor batch of P215 and Siglent have worked with their supplier to improve quality.
The shield connection was often poor and would make/break when flexed.
Member xrunner had one replaced and went on to fix the faulty one.
Here and investigations are in previous posts:
https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/msg4667176/#msg4667176
Slartibartfast:
--- Quote from: tautech on December 03, 2023, 10:01:06 pm ---
--- Quote from: Slartibartfast on December 03, 2023, 09:26:14 pm ---Why do you think triggering is related to the issue?
--- End quote ---
The spikes on Ch2 here:
--- End quote ---
Those spikes are real and are there because the master released data a little earlier than the slave asserts it for the ACK. They are harmless, because they happen during clock being low, hence they are ignored. They are not due to premature re-triggering. Please note there is no retriggering, as single acquisition was used. Acquisition is stopped, as ebastler pointed out before me.
--- Quote ---
--- Quote ---From my point of view, there are traces that show signals from a specific time window of 200µs at some instance in time. This acquired data is what the decoder has to work on. Now, it is clear that if the traces would start right in the middle of an ongoing transmission, the decoder has nothing to sync on at the beginning of the trace, but even then it should resynchronise when it sees START or STOP conditions. But even that is not the case. The trace starts at a time when the bus is idle, and consequently the decoder start decoding porperly, and then suddenly looses sync. Later in the trace, the decoded information is inconsistent with the traces. This should not happen.
I completely fail to see any connection to the triggering.
--- End quote ---
225us trigger offset is NOT Holdoff !
--- End quote ---
I never claimed it is. I still don't see what's the issue with hold-off. I don't use it (in this case). Why should I?
--- Quote ---Using Holdoff and a Falling Edge for simple decoding illustrations is how I do it too but to trigger on specific bits one must use a decode trigger.
--- End quote ---
I do not trigger on bits, but on the first clock edge.
--- Quote ---Holdoff is never shown/displayed so set it to a bit longer than a packet and show us the result.
--- End quote ---
I did that anyway, and as I expected(*), the result ist basically the same. It lost sync one byte earlier, but repeating a few times I found it sometimes looses sync on one, sometimes on the other byte. This indeed seems to suggest that the decoder fails to cope with the borderline pull-ups, i.e. not rapidly enough rising edges. No issue for the chips on the bus, though, the I2C communication seems to work properly.
(*) With single acquisition, and the last clock edge many seconds to minutes before the trigger point, what's the point of hold-off?
--- Quote ---BTW, please state firmware version in use.
--- End quote ---
The firmware is obviously the latest, 1.5.2r3. What's the point of trying to identify a firmware bug if the firmware weren't the latest?
tautech:
--- Quote from: Slartibartfast on December 04, 2023, 08:51:26 am ---With single acquisition, and the last clock edge many seconds to minutes before the trigger point, what's the point of hold-off?
--- End quote ---
Sure for single it shouldn't be needed however in Run mode the correct Holdoff gives rock solid triggering although with multiple packets coming through the payload is often changing.
I need make room on the bench to setup some examples......
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version