Products > Test Equipment

Siglent SDS2000 new V2 Firmware

<< < (30/56) > >>

Fagear:

--- Quote from: rf-loop on December 30, 2015, 08:17:48 am ---Setting delay and setting horizontal position is bit different. Because setting delay from center line moves horizontally. But this is based to time, not based to distance in divisions or millimeters etc. You set TIME position related to center line.
Now if we change time scale of course horizontal position moves because we have set how far in time we want be from center line.
There need be one setting more. Lock trigger position to the current user adjusted position on the screen independent of t/div scale  and then same function need include swap between delayed time position and this trigger position....

--- End quote ---
May I add a little to this topic?
As owner of Rigol DS2072A I can confirm that it can fix trigger position on whatever place on the screen. Just set "HorRef" as "Trig Pos" in Horizontal menu to lock it.
Or you can also set it as "User" to set "zoom point" independently at any point on the screen (not locking to the center of the screen or trigger position). DS1000Z cannot do it though.

Mark_O:
Thanks for the extensive breakdown.  One error I did want to point out though...


--- Quote from: Performa01 on December 31, 2015, 08:31:00 am ---Serial Decoding (DSO) - UART

As we can see in the list, the first four decoded values aren’t correct, quite obviously the decoder just starts with the first captured data and doesn’t seek for a proper start condition first. But at least it gets in sync eventually, so everything looks fine after the 4th decoded value.

--- End quote ---

This isn't the fault of the scope OR it's decoders.  It is the (expected) result from your setting the triggering on an arbitrary edge.  I believe if you adjust the triggering to UART mode, that your results will fall into alignment properly.

[Don't feel bad... I made the same mistake initially, when I started testing the decoders on the SDS1000X.  If it never managed to 'sync up' properly, and we had nothing but garbage, then the operator error would be obvious.  Since it eventually does sync, we overlook the fact that we didn't set it up properly in the first place.]

Mark_O:

--- Quote from: Performa01 on January 02, 2016, 01:01:45 pm ---Serial Decode (DSO) - SPI

...The first data item after the trigger is now the 4th item in the list and data appear to be correct here, but everything else? Oh boy, what a disaster!  First look at the timestamps in the list.  We have two entries with each -100.00µs and 0.00µs respectively, which might be a hint that the actual resolution of the timestamp is worse than 100µs, even though the display suggests a resolution of 10ns and the current sample rate of 20MSa/s allows 50ns after all.  Then what happens after the 4th entry? Timestamp suddenly jumps up to the maximum value and says 69.8ms for all the 860 remaining entries in the list!
--- End quote ---

Believe me, I feel your pain on this.  I've been running a 1000X through a battery of tests for some time now, and SPI was one of the first things I looked at.  And many of the same glitches and anomalies were present there as well (with edge-triggering).  That would tend to confirm the hypothesis that the two scopes share much the same core code-base.  As would the fact that most (not all) of the other problems you've reported from your extensive testing also appear in my list for the 1000X too.

However, unlike with your 2000(X), the SPI situation improved quite a bit when I changed from an edge-triggered mode to SPI-triggering.  I was surprised to hear your report that it made no difference.  So it's possible that some improvements on the 1000X side simply haven't made it over to the 2000X yet.


--- Quote ---As my little micro provides almost no hardware support for SPI, I stick with a clock of only 100kHz, but I also have no doubt that speed doesn’t matter for this test as long as the sample rate is kept about an order of magnitude higher than the SPI clock.
--- End quote ---

I believe that is correct.  I ran SPI tests from 10kHz to 14 MHz (using an embedded comms channel on an NXP chip), with both 8-bit and 16-bit message "words", and as long as the sample rate remained at least 4x the bit-clock, the 1000X handled it as well (or as badly).


--- Quote ---...I just want to point out that serial SPI trigger on 8 bit data only works for the upper 4 bits, whereas the lower nibble always is treated as zero, no matter what the actual setting is. And for the entire trigger word, the don’t care setting (‘X’) is ignored and treated as zero. So this is completely unusable as well.
--- End quote ---

This wasn't true on the 1000X, even on the earliest of the 3 Releases I have been working with.  I set up match patterns spanning 4, 8, and 16 bits, and all were observed properly.  And X was never treated as matching just "0".  And never did I observe a situation where multiple Cursor pointers in the List view were lit up simultaneously.

I mention this mainly to give you some hope, because the code appears to still be going through some significant transformations.  Which hopefully should eventually appear for you on the 2000(X) platform.


--- Quote ---Conclusion:
SPI decoding is totally unusable and I cannot even begin to list all the bugs I’ve found during my tests. Well, it’s more than just bugs, it simply doesn’t work. SPI trigger doesn’t work either.  This is clearly a case where nobody could claim this part of the scope has ever been tested, other than maybe one single message at one fixed timebase setting, just like my very first scenario.

--- End quote ---

While I don't think that SPI decode is unusable on the 1000X, I do have to agree that there are too many quirks, anomalies, and glitches to accept it as a reliable debug-platform, at the moment.  And the number of problems, which as you commented strongly suggest an inadequate level of in-house testing, makes the job of evaluating or reviewing the product far more difficult than anyone might anticipate, for a released product.

So I have a lot of respect for the amount of time you have invested in your exploration of the V2 software releases for the SDS2000(X).  I'm not sure where you've found the time to perform all the tests and write them up!   :-+  I'm having trouble just keeping up with reading them all!  :D  But I am sure it is providing Siglent with a wealth of extremely valuable information, which should enable them to quickly focus on correcting the issues.


[NB:  you mentioned about the List size for Serial decodes... "The list size can be configured from 4 to 7 lines and I’ve set it to the maximum right from the start."  Are you sure that isn't from 1-7?  The 1000X lets you drop it as low as 1 line (saves space), and the User Manual for the 2000X indicates 1-7 as well.]

Performa01:

--- Quote from: Mark_O on January 04, 2016, 04:54:12 am ---Thanks for the extensive breakdown.  One error I did want to point out though...


--- Quote from: Performa01 on December 31, 2015, 08:31:00 am ---Serial Decoding (DSO) - UART

As we can see in the list, the first four decoded values aren’t correct, quite obviously the decoder just starts with the first captured data and doesn’t seek for a proper start condition first. But at least it gets in sync eventually, so everything looks fine after the 4th decoded value.

--- End quote ---

This isn't the fault of the scope OR it's decoders.  It is the (expected) result from your setting the triggering on an arbitrary edge.  I believe if you adjust the triggering to UART mode, that your results will fall into alignment properly.

--- End quote ---

Thanks a lot for your replies – it is nice to see another user care for the topic and makes me feel not so alone now :)

Regarding edge triggering on an UART signal, you’re perfectly right and it’s probably just the way I put it was a bit misleading. I certainly didn’t expect the decoder to get in sync properly in the middle of a packet – that’s why I’ve set up this test with a series of packets (with small periods of idle level between them) instead of just one endless stream of data in the first place.

I personally cannot think of a way to reliably detect the start of a frame when decoding starts in the middle of a stream.

When using the UART trigger, there are no invalid packet fragments (as can be seen in the screenshots of my review of the UART trigger) – most of the time, that is. I have to make a reservation here, as it is obvious that the trigger would still fire if the incorrect decoding from any initial out-of-sync packet matches the trigger condition by accident.

Performa01:

--- Quote from: Mark_O on January 04, 2016, 07:41:02 am ---However, unlike with your 2000(X), the SPI situation improved quite a bit when I changed from an edge-triggered mode to SPI-triggering.  I was surprised to hear your report that it made no difference.  So it's possible that some improvements on the 1000X side simply haven't made it over to the 2000X yet.

--- End quote ---

Well, for my tests it cannot make a difference, since I didn’t trigger on a random edge of the clock or data, but on the falling edge of the slave select signal, which is always related to the start of a packet. Consequently, data after the trigger point have always been correct (apart from the extra 0x00 decoding between packets) and I did not complain about invalid data before the trigger point other than that it wasn’t marked invalid in some way (no error bit indication as e.g. the SPI decoder on my LA does).



--- Quote ---
[NB:  you mentioned about the List size for Serial decodes... "The list size can be configured from 4 to 7 lines and I’ve set it to the maximum right from the start."  Are you sure that isn't from 1-7?  The 1000X lets you drop it as low as 1 line (saves space), and the User Manual for the 2000X indicates 1-7 as well.]

--- End quote ---

You’re right of course. Four lines is just the default setting, but I can wind it down to one if required. Tanks for the hint - I’ve corrected that statement in my review post.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod