EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: GeorgeOfTheJungle on March 20, 2017, 01:29:52 pm
-
Hi, I'm playing with my new SDS1102X and it's refusing to decode, see the pictures, both scopes are connected to the same signal. Any ideas why?
Also there are a few things that I don't get:
1) Why is the memory depth just 1.4MB (and won't let me set it to 14MB) ?
2) Why such a low sample rate 5MSa/s @ 20ms/div ? There are 14 divs/screen, @ 20ms/div= 0,28s, @10MSa/s= 2,8MB, and even @ 50MSa/s 0,28s*50MSa/s= 14MB and it should fit.
3) When horizontal is > 20 ms/div it shuts down for good the serial decoder, why??
The firmware is the latest version. Is it broken or this is just the way it is?
-
Hi, I'm playing with my new SDS1102X and it's refusing to decode, see the pictures, both scopes are connected to the same signal. Any ideas why?
Also there are a few things that I don't get:
1) Why is the memory depth just 1.4MB (and won't let me set it to 14MB) ?
2) Why such a low sample rate 5MSa/s @ 20ms/div ? There are 14 divs/screen, @ 20ms/div= 0,28s, @10MSa/s= 2,8MB, and even @ 50MSa/s 0,28s*50MSa/s= 14MB and it should fit.
3) When horizontal is > 20 ms/div it shuts down for good the serial decoder, why??
The firmware is the latest version. Is it broken or this is just the way it is?
When decode is in use:
maximum acquisition length is 1.4M
lowest horizontal speed is 20ms/div
These are limits (in last FW versions - why, I do not know, 20ms/div also surprise for me).
I have not checked but is it so that this Agilent have hardware decoders?
What is your signal accurate speed (115k ?) and parameters?
(some day I can perhaps also look it bit...)
Old FW can
NOTE, Attached image is obsolete! (Old FW !!! (Perhaps P06)
-
Hi rf-loop,
Thanks for the quick response!
Yes, the baud rate is 115200.
So yours can decode @ 50ms/div??? But surely not @ 115Kbaud, have you tried? I need to decode a frame that's almost 2s long, and I need to do that with both channels on. Is that possible with this Siglent?
Why is mem depth just 1.4MB with decode on? What a bugger!
Mine seems to need 10MSa/s to be able o decode properly @115Kbaud which is strange, really, IIRC there were UARTs that did it well with just 16 samples per bit-slot, I don't get why does the siglent need hundreds of points per bit-slot to decode properly. Is it a bug? What do you think?
I'm afraid I'm going to have to return it, if that's the way it is it's useless for me. A pity because I like it very much.
Thanks,
-
So yours can decode @ 50ms/div???
No, it was very old obsolete FW version. Now 20ms/div is limit.
But surely not @ 115Kbaud, have you tried?
not with this acq. speed.
I need to decode a frame that's almost 2s long, and I need to do that with both channels on. Is that possible with this Siglent?
No, it is not.
Why is mem depth just 1.4MB with decode on? What a bugger!
Memory settings are 14k, 140k, 1.4M, 14M (for one channel in use). I do not know reason why max for Decode is 1.4M. Perhaps lack of processing power and it go too slow?
I'm afraid I'm going to have to return it, if that's the way it is it's useless for me. A pity because I like it very much.
All scopes do not meet all users specified needs. If you need ~>2second 115k speed Rx Tx decoded, this scope is not at all right tool (if you need do this using oscilloscope). If this is Go - NoGo question - it is end of game with this and you really need something other.
Most important is that you get tools what meet your individual needs.
-
If the purpose is to purely look at the data and not timing then a PC with a serial port monitoring program (there are many of them so spend some time testing a couple of them) is a much better tool. At some point the buffer for decoded data in an oscilloscope will be full and it doesn't matter if the oscilloscope costs $400 or $25000 for that to happen.
-
If the purpose is to purely look at the data and not timing then a PC with a serial port monitoring program (there are many of them so spend some time testing a couple of them) is a much better tool. At some point the buffer for decoded data in an oscilloscope will be full and it doesn't matter if the oscilloscope costs $400 or $25000 for that to happen.
These PC tools + oscilloscope for signal signal integrity and form analyzing is good combination for many this kind of things.
-
George
You can improve results by using the correct protocol trigger from the Trigger suite. Be sure to set the correct baud rate too.
As advised 20ms/div is the slowest decode speed, slower and the scope drops decode functionality and enters Roll mode.
-
@rf-loop, thank you very much. The thing is that I bought this siglent to replace a 2 years old 1074Z that's doing exactly that just fine and just because I don't like its UI nor its overall sluggishness. (and to get a new toy :-) I saw videos on youtube and thought wow, that thing flies (comparatively), has serial decode and 14MB is about right for this... but no :-(
@nctnico The other channel is sensing the current into the DUT, the code spits bytes at certain points to correlate execution with power input, the DUT is sleeping most of the time, only awakes every now and then and for less than ~2 seconds.
-
George
You can improve results by using the correct protocol trigger from the Trigger suite. Be sure to set the correct baud rate too.
As advised 20ns/div is the slowest decode speed, slower and the scope drops decode functionality and enters Roll mode.
I believe that's ok as it is (falling edge), I tried trigger/uart/condition start and it makes no difference, only switching horizontal to 5 ms/div or less makes it decode ok. See the pictures.
EDIT: This are the wrong pictures (triggering on rising edge), haven't got at hand the right ones, but it makes no difference.
-
@nctnico The other channel is sensing the current into the DUT, the code spits bytes at certain points to correlate execution with power input, the DUT is sleeping most of the time, only awakes every now and then and for less than ~2 seconds.
Then I guess your only option is to get a different oscilloscope with more memory and better decoding. Segmented recording won't be helpfull either for these kind of measurements.
-
I'm afraid I'm going to have to return it, if that's the way it is it's useless for me. A pity because I like it very much.
Do no suffer unneeded pain. Look at this as opportunity get even more gear. Just use your new scope for simple debugging and serial trigger for some large memory USB device that can capture and decode mega, if not gigabits in single shot and analyze in proper manner with search, sorting etc.
-
Then I guess your only option is to get a different oscilloscope with more memory and better decoding. Segmented recording won't be helpfull either for these kind of measurements.
The funny thing is the 1000z that's cheaper can do it well, huh, I wasn't expecting that.
-
Brand new unit straight out of the box, UART from Siglent test board, STB3
http://siglentamerica.com/prodcut-fjxx.aspx?fjid=4990&id=4688&tid=1&T=2 (http://siglentamerica.com/prodcut-fjxx.aspx?fjid=4990&id=4688&tid=1&T=2)
Decode and Serial trigger in use.
(https://www.eevblog.com/forum/testgear/siglent-sds1102x-serial-decoder-not-decoding-properly/?action=dlattach;attach=301289)
Edit
Oh yeah, 10x probes used but 1x set on inputs. |O
-
@tautech: Please try that @ 115200 baud
-
@tautech: Please try that @ 115200 baud
The UART source I have is 9600 baud only, sorry.
-
Do no suffer unneeded pain. Look at this as opportunity get even more gear. Just use your new scope for simple debugging and serial trigger for some large memory USB device that can capture and decode mega, if not gigabits in single shot and analyze in proper manner with search, sorting etc.
That sounds good ! :-) Any particular device do you have in mind?
-
@tautech: Please try that @ 115200 baud
The UART source I have is 9600 baud only, sorry.
No problem, I have an espruino here, let me check it out, one second...
-
That sounds good ! :-) Any particular device do you have in mind?
If you want additional 2 analog channels + digitals then there is scope/analyzer hybrid 2206B MSO from Pico (first model with large memory of 32MB, Pico MSOs go up to 512MB). If want only large mem digitals then look Digilent Digital Discovery and Saleae stuff*. Digilent Analog Discovery (2) is not suitable because of only tiny memory.
*Looking at the specs Saleae does not have oboard mem spec anywhere to be seen... Streaming only? That would explain why sample rates drop heavily when enabling many channels.
-
All goes well up to 38400 baud, any more than that and it misbehaves.
var baud= 38400;
var str= "George"+ baud;
Serial4.setup(baud);
setInterval(function () { Serial4.write(str); }, 500);
-
The thing is that I bought this siglent to replace a 2 years old 1074Z that's doing exactly that just fine and just because I don't like its UI nor its overall sluggishness. (and to get a new toy :-) I saw videos on youtube and thought wow, that thing flies (comparatively), has serial decode and 14MB is about right for this... but no :-(
What?! The "it's-useless-because-it-only-decodes-from-the-screen-buffer" Rigol can do something in the decoding department which the "only-way-to-do-it-right" Siglent can't?! Heresy! :P
Kidding aside, this seems to be a nice example that design decisions usually imply some trade-offs. In this particular use case, the Rigol's approach (capture it all, then decode piecemeal what is displayed on the screen) turns out to be less limiting. In other scenarios, the Siglent is ahead.
A good one to remember when the next round of "scope wars" unfurls in some other thread... ;)
(And yes -- I still like my DS1054Z very much, but agree that its user interface can become annoyingly slow with decodes, math, etc. enabled!)
-
Seems I was giving wrong advice regarding Saleae analyzers. Seems they do not have onboard memory, at that price!? :palm:
"All data is streamed in real time over USB. The maximum sample rates depends on the number of digital and analog channels used."
Pretty small list then remains.
-
All goes well up to 38400 baud, any more than that and it misbehaves.
var baud= 38400;
var str= "George"+ baud;
Serial4.setup(baud);
setInterval(function () { Serial4.write(str); }, 500);
The problem is clearly in the amount of oversampling needed by Siglent's decoding algorithm. It is one of the things I tested when I got the GW Instek GDS2204E and 13 samples per bit seemed to be the limit.
-
The problem is clearly in the amount of oversampling needed by Siglent's decoding algorithm. It is one of the things I tested when I got the GW Instek GDS2204E and 13 samples per bit seemed to be the limit.
Yes, that to me sounds about right, a paleolithic 6551 UART sampled (IIRC) 16 times per bit but this siglent seems to need hundreds to do it right.
-
If you want additional 2 analog channels + digitals then there is scope/analyzer hybrid 2206B MSO from Pico (first model with large memory of 32MB, Pico MSOs go up to 512MB). If want only large mem digitals then look Digilent Digital Discovery and Saleae stuff*. Digilent Analog Discovery (2) is not suitable because of only tiny memory.
*Looking at the specs Saleae does not have oboard mem spec anywhere to be seen... Streaming only? That would explain why sample rates drop heavily when enabling many channels.
Correct me if I'm wrong, but isn't it that most of these USB scopes come with Windows only software? And I'm a Mac-man. I wonder why don't they provide a web interface, browsers nowadays have websockets and that would make them chooch fine everywhere (Linux, Mac and Windows).
-
not those three.
you have osx software for pico, digilent, selae.
pico is a bit behind in terms of updates, unfortunately.
-
I wonder why don't they provide a web interface, browsers nowadays have websockets and that would make them chooch fine everywhere (Linux, Mac and Windows).
https://www.picotech.com/downloads (https://www.picotech.com/downloads)
I can see Mac, Linux betas.
Web interface would assume that processing is in the box, like with regular DSO. With Picos box has standalone memory and triggering, but no (full) processing. This has pros and cons depending on application.
I'm doing rolling review on non-MSO version here:
https://www.eevblog.com/forum/testgear/picoscope-2000/ (https://www.eevblog.com/forum/testgear/picoscope-2000/)
But have not yet gotten to triggering and decoding, it turned out they have come up with several tricks to circumvent USB-bottleneck and takes time to fully understand it all. Only little post here so far:
https://www.eevblog.com/forum/testgear/why-do-i-want-serial-decode-on-a-digital-scope/msg1162253/#msg1162253 (https://www.eevblog.com/forum/testgear/why-do-i-want-serial-decode-on-a-digital-scope/msg1162439/#msg1162439)
As for Digilent DD it just come out no end-user info yet. Suppose it's somewhere in the middle. Pico is more-scope like (segmented mem etc), while Saleae is "dumb (A)DC" style with no onboard memory.
-
it should be the beta that added SENT decoding. it crashed A LOT on our computers here
-
it should be the beta that added SENT decoding. it crashed A LOT on our computers here
Package as whole or only SENT decoding part? I have gotten latest PC version to crash but mostly with limits-of-possible testing on math channels.
-
the software as a whole. it's been ages though because i have windows on the work pc, that one has the most recent version of course
-
Before you reject the Saleae...
The Saleae Logic Pro 8 will will do up to 4 channels at 500 MS/s with USB 3. It can do this for ridiculously long times - the only limit is your computer's RAM. The flip side is it does not show signals in real-time. You set the record length, start the capture, wait for it to finish with no signals showing on screen while it is capturing, and then it shows stuff on screen after it is done. I just did a 3s test capture at 115200 baud rate, no problems.
BTW, their software is cross-platform and works on linux, but it is not open-source.
Edit: You can also set some channels as analog inputs (12-bit ADC) but they are limited to 50 MS/s. So if you don't need real-time, this could possibly work.
-
Before you reject the Saleae...
The OP wants to see an analog signal related to the decoded data (which seems to be a firmware state indicator) so any kind of logic analyser isn't going to work for the problem at hand.
-
@nctnico Edited my post to say that some Saleae also have analog inputs. 12 bit ADC, actually!
-
The OP wants to see an analog signal related to the decoded data (which seems to be a firmware state indicator) so any kind of logic analyser isn't going to work for the problem at hand.
Hm, I was proposing mixed use scope + second device. Scope will just trigger on protocol using serial trigger, put edge on Trig Out + display analog stuff, LA-style device will trigger on Trig Out and absorb stuff to be decoded + additional analog functionality depending on device. Making primary scope essentially "trigger slave".
This way OP can keep scope he likes + get additional toy. No need always seek ultimate do-it-all-perfectly, IMHO there is none currently. On the other hand mating many devices is fun :P
-
All goes well up to 38400 baud, any more than that and it misbehaves.
var baud= 38400;
var str= "George"+ baud;
Serial4.setup(baud);
setInterval(function () { Serial4.write(str); }, 500);
Please make tiny test.
Use 115200 tx speed.
Set oscilloscope for Custom Baud: 124500 (half way of 118k and 131k these both limits start generate around same amount errors, but my source is crap USB/UART so not accurate at all)
20ms/div.
My suspect is that there is some errors in FW
(also I wonder why decode is blocked >20ms/div in new FW, old FW it was possible (if turn scroll off) .)
EDIT:
Tested more. With longer data stream, errors.
(looks like for 115k baud need really some more deep FW repair more than just baud speed)
-
Please make tiny test.
Use 115200 tx speed.
Set oscilloscope for Custom Baud: 124500 (half way of 118k and 131k these both limits start generate around same amount errors, but my source is crap USB/UART so not accurate at all)
20ms/div.
My suspect is that there is some errors in FW
(also I wonder why decode is blocked >20ms/div in new FW, old FW it was possible (if turn scroll off) .)
Ok, wait a second.
-
Please make tiny test.
Use 115200 tx speed.
Set oscilloscope for Custom Baud: 124500 (half way of 118k and 131k these both limits start generate around same amount errors, but my source is crap USB/UART so not accurate at all)
20ms/div.
My suspect is that there is some errors in FW
(also I wonder why decode is blocked >20ms/div in new FW, old FW it was possible (if turn scroll off) .)
EDIT:
Tested more. With longer data stream, errors.
(looks like for 115k baud need really some more deep FW repair more than just baud speed)
Hi rf-loop, see the pictures. :-)
I tried with the serial threshold too, from just above the bottom of the signal to barely below the top and that did not help, but manually adjusting the baud rate does the trick.
Thank you very much!
var baud= 115200;
var ctr= 0;
Serial4.setup(baud);
setInterval(function () {
ctr+= 1;
Serial4.write("Pati"+ctr);
}, 3);
-
That almost seems like the baudrate generator in the microcontroller is too far off! Did you check that?
-
That almost seems like the baudrate generator in the microcontroller is too far off! Did you check that?
No, I did not, it may be off, perhaps, but:
1) This happens with both the espruino and the DUT (which is not a espruino).
2) Switching the Siglent to 5ms/div makes it chooch.
3) The Agilent decodes everything well, always.
4) A small % off should always be allowed.
-
Using signal generator and example 100 cycle burst, square wave 11.52kHz it works rock solid. (decoded as F0 (115.2k 8N1)
(this is going more weird)
-
Using signal generator and example 100 cycle burst, square wave 11.52kHz it works rock solid. (decoded as F0 (115.2k 8N1)
(this is going more weird)
Hi rf-loop,
What's with the message you deleted? Why?
A square wave is not the best way to test this, tx chars need not be (and usually are not) one right after the other without gaps, a UART has to be able to resynchronize at every chars' start bit no matter when it happens to appear. So a (square wave) stream made of 0xf0s without any gaps in between is an abnormal case, of course it should be able to decode that too, but also, of course, and more importantly, everything else as well.
Your previous message, the one you have deleted, was much more informative and close to the truth, what a shame that you deleted it.
-
Using signal generator and example 100 cycle burst, square wave 11.52kHz it works rock solid. (decoded as F0 (115.2k 8N1)
(this is going more weird)
Hi rf-loop,
What's with the message you deleted? Why?
A square wave is not the best way to test this, tx chars need not be (and usually are not) one right after the other without gaps, a UART has to be able to resynchronize at every chars' start bit no matter when it happens to appear. So a (square wave) stream made of 0xf0s without any gaps in between is an abnormal case, of course it should be able to decode that too, but also, of course, and more importantly, everything else as well.
Your previous message, the one you have deleted, was much more informative and close to the truth, what a shame that you deleted it.
I delete it because I rearrange my some tests and during this I get some very strange results. Then I have no time to finalize tests (very busy) and I do not know what time I can continue. Because my suspect was there was possible wrong information it was better delete - better to tell nothing than wrong information due to too sloppy work.
"Silence is better than lie"
-
Hi @rf-loop and @tautech,
I've been playing with the previous firmware, see the picture old_fw, there you have a few chars @ 115200, horizontal is set to 50ms/div and sample rate was 2MSa/s (*), that gives us 2e6(Sa/s)*50e-6(s) = 100 Sa/div (in the zoomed window @ 50µs/div). At that baud rate there are less than 6 bit-slots per div (again looking at the zoomed window), and that means slightly more than 16 samples per bit: that ought to be enough to decode properly (it was enough 40 years ago with a 6551), but it isn't.
WRT the new fw update, please see the picture new_fw, horizontal was set 10 ms/div, sample rate was 10MSa/s, so we've got 5 times more samples per div, or about 10e6(Sa/s)*50e-6(s)/6= 83.3 samples per bit, but again it isn't decoding properly.
So there is something wrong with the decode algorithm they are using, or there are still bugs somewhere.
I'm returning this scope, but I were the owner of an SDS1000X I wouldn't be happy at all if in order to "fix" a serial decoder bug, the solution was to remove functionality as in shutting down for good the serial decoder above 20 ms/div.
I have tested this with 2 different serial sources, and the Agilent next to the Siglent has been able to decode everything always, so I don't think the problem is in the serial streams. I don't have the Rigol 1000Z at hand right now, but I found no problems whatsoever when it was here, doing the same.
You or tautech or somebody should escalate this, ain't chooch, not skookum!
Thanks,
-
If there is example from 1GSa/s or 500MSa/s ADC raw samples decimated samplerate 10MS/s in use, least I do not know if this is decoder input or if there is some second decimation for decoder. I do not have any quess or knowlege how many samples decoder use.
1Gsa/s is fastest samplerate. If this samplerate is in use, I have "light" suspect that decoder do not decode from 1GSa/s .
Only I can say: Unknown so far
-
There's no need to guess when you can see and count them: in the worst case (old firmware 50ms/div 2MSa/s) there are 18 and that ought to be plenty enough.
-
There's no need to guess when you can see and count them: in the worst case (old firmware 50ms/div 2MSa/s) there are 18 and that ought to be plenty enough.
Displayed samples do not proof what is decoder input with all samplerates.
We can believe what ever but least I do not know.
-
didn't siglent decode on acquisition memory?
-
didn't siglent decode on acquisition memory?
All sampled data is in acquisition memory. But who knows how Decode process read data from there.
Feels bit strange if it need in some cases hundreds of samples for one serial data bit.
But so or so. Decoder have problems with 115kb with low speed timebases.
Also ASCII display need improve/repair. It must not show empty if there is example normal standard control bytes like SOH, STX, EOT, ACK, LF, CR etc etc.
-
So a (square wave) stream made of 0xf0s without any gaps in between is an abnormal case, of course it should be able to decode that too, but also, of course, and more importantly, everything else as well.
No need any gaps between bytes. If it fails in this, serial decoder is not ok. Also there can be random time gap and also if it do not decode it right decoder is not ok. And, what I have now tested using time accurate signals it looks more and more that baud rate setting is wrong. More or less depending samplerate and t/div.
Example with continuous 0x55 without gaps or example 5 bytes bursts it decode rock solid when custom baud rate is set for ~133k instead of 115.2k and timebase 20ms/div when memory set is 1.4M (samplerate 5MSa/s).
But, this is just preliminary tests and need more different tests (without total junk crab RS232 source as example Belkin USB-UART what is total shit) for reliable data.
-
Hey, rf-loop, get one of these: espruino.com/order you won't regret it, no need to compile anything, it's a purely text based interface/console in which you write javascript in an event/callback oriented style very much like Node.js. The original is better for prototypes/experiments than the pico, imho.
-
I wonder why don't they provide a web interface, browsers nowadays have websockets and that would make them chooch fine everywhere (Linux, Mac and Windows).
I assume that the PC performs a significant amount of data processing, which the USB scopes cannot do on board. Hence, a simple browser-based viewer is not enough.
-
Before you reject the Saleae...
The OP wants to see an analog signal related to the decoded data (which seems to be a firmware state indicator) so any kind of logic analyser isn't going to work for the problem at hand.
AFAIK, the Saleae has an analog input too:
Specification for analog use:
Sample Rate: 50 MS/s @ 12 Bits
-3dB Bandwidth: 5MHz (signals with frequency components above this will not appear right)
-10V to +10V voltage range
https://www.adafruit.com/product/2313 (https://www.adafruit.com/product/2313)