RS232 decode routines from raw scope data?

Not really self clocking, right? It's return to zero data, so no clock with the data. It works by using a similar clock at each end and a start bit.

Rick C.

++ Get 6 months of free supercharging ++ Tesla referral code -

Am 22.01.19 um 21:16 schrieb Joerg:

Hello,

try setup and connect.

Bernd Mayer

Afraid I don't understand. After the install there were no such menu items. Meantime I uninstalled it but can of course re-install.

--
Regards, Joerg 

http://www.analogconsultants.com/

Yeah, ok, if that doesn't count as self-clocking (for capturing the frames) then I guess it isn't self-clocking. But it works without a clock :-)

--
Regards, Joerg 

http://www.analogconsultants.com/

took a second, I sent it

that doesn't sound right, the analyzer doesn't know about rs232 or how to synchronize to the data it just samples at a fixed rate

Assuming the data you're processing is a file containing a sequence of null-terminated ASCII strings, sure. Since the OP stated the data was raw ADC data don't know why I would assume it was formatted that way I was assuming it would be just a buncha bytes. There's no way to "read lines" from a raw binary data file in C it's just a blob.

Thanks, and it worketh!

This was pretty much my first real use of a Linux computer :-)

Yes, it sure doesn't sound right. I just made Pulse View crash. Guess I'll have to wait until the little analyzer is here and then play some more with it.

--
Regards, Joerg 

http://www.analogconsultants.com/

your first step towards freedom ;)

Oh I took those already when I unpeeled myself from the stranglehold of the giant beer conglomerates and started home brewing again. No more InBev, Coors, Heineken, Diageo oder Carlsberg here :-)

--
Regards, Joerg 

http://www.analogconsultants.com/

in as much that the timing information for the data bits is transmitted on the same line as the data bits themselves it's self clocking.

--
  When I tried casting out nines I made a hash of it.

Hardly. Every UART I've ever seen has a clock running to it. That's how you generate the baud rate.

Rick C.

--- Get 6 months of free supercharging --- Tesla referral code -

So-called self-clocking refers to tweaking the local (receive) clock to phase-lock it to the distant (sending) clock. Done digitally, a local oscillator at 8x or so of the transition period is required. Short Ethernet frames had to waste circa 8 bytes of data just to synchronize, but for long-burst transmissions it works well. RS-232, on the other hand, typically has SUCH short data (ten or eleven must-be-valid windows) that clock accuracy can be off a few percent and still work without any synchronization.

On Jan 22, 2019, Joerg wrote (in article ):

in hardware is about.

What defines an event then? Excel can search using the usual logical operators, like greater than. One can write compound tests, yielding another column having +1 in event rows.

Joe Gwinn

Currently I only have ADC raw data recordings of serial data lines from a scope, in 8-bit samples. That needs to be be converted into data, to find out what was sent.

An event in this case is, unfortunately, something that I don't know yet. Something happens that can cause the whole thing to hang. So I have to monitor other HW lines and also RS232 responses to find out what might possibly lead to a smoking gun. Clues in RS232 answers could be detected with nifty software or maybe one of the programs such as Sigrok. Triggerable events on other nets, not really, that requires a digital oscilloscope and sometimes also other analyzers.

My old boat anchor logic analyzer has nifty trigger qualifier settings which could be pressed into service here but it does not decode serial data streams. The little one I ordered (hopefully) does.

--
Regards, Joerg 

http://www.analogconsultants.com/

No, pulseview can definitely handle oversampled data, at least within reason. Also, you can test it on wavforms that came from disk. That is how I usually use it, because it crashes so often I always save the waveforms as soon as I capture them, and then do the decoding later so that my waveforms are safe even if it crashes.

If this is for money so that you can also spend some money on the tools, and if you are not as opposed to closed-source tools as I am, then you might be better served by the products from

I haven't tried them but I hear that they are good, and are likely to crash less than Pulseview.

I would definitely save them first, then look at data.

The cheap analyzer that Lasse suggested should suffice for this. Arrives tomorrow but I won't have time to test it until mid next week. I am hoping to log stuff so I can see what the RS232 response to a sent command set was and how all that correlates with other events. The latter I'll have to capture with the scope and one fairly easy way would be to let the scope trigger, crank up the brightness, add in some noise for more "fuzz" on the trace, tap off its screen via a photodiode and amp, then send that into one of the logic analyzers digital pins. That would place trigger markers on an otherwise unused input which I can use to snoop around in the data. This should get me around the problem that my DSO doesn't have a trigger-out jack.

I can run PulseView either on a Windows or a Linux computer. Whichever software crashes less :-)

--
Regards, Joerg 

http://www.analogconsultants.com/