Siglent SDS1102X Serial decoder not decoding properly

[MrW0lf]

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
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/
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

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.

[JPortici]

it should be the beta that added SENT decoding. it crashed A LOT on our computers here

[MrW0lf]

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.

[JPortici]

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

[djnz]

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.

[nctnico]

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.

[djnz]

@nctnico Edited my post to say that some Saleae also have analog inputs. 12 bit ADC, actually!

[MrW0lf]

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

[rf-loop]

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)

[GeorgeOfTheJungle]

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.

[GeorgeOfTheJungle]

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);

[nctnico]

That almost seems like the baudrate generator in the microcontroller is too far off! Did you check that?

[GeorgeOfTheJungle]

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.

[rf-loop]

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)

[GeorgeOfTheJungle]

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.

[rf-loop]

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"

[GeorgeOfTheJungle]

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,

[rf-loop]

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

[GeorgeOfTheJungle]

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.

[rf-loop]

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.

[JPortici]

didn't siglent decode on acquisition memory?

[rf-loop]

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.

[rf-loop]

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.

[GeorgeOfTheJungle]

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.

[ebastler]

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.