RS232 decode routines from raw scope data?

Thanks. At first glance it looks like it does RS232 only via a Prolific chip which wouldn't allow my measurements because I have to trigger on an event:

IOW, I can't just hook a RS232-USB converter to a PC and log. Unless I somehow hardwire the scope's trigger output to a pass device that lets the stream start only after a trigger event.

I'll have to verify the data format today.

It's non-synchronized but grossly oversampled so that the detection should be easy. Essentially 25,000 8-bit sample points where low is around zero and high is around 80.

Unfortunately too late and my Instek GDS-2204 is of a generation that didn't have this yet.

That is pretty much what I am looking for. Should not be a big deal to turn a CSV file into WAV, I hope.

The other idea would be to cram the file into LTSpice and see if there's any way to decode it using the available logic models. Though that would become a project on its own.

Theoretically possible, with some transistor stuff.

Yeah, time is the issue and I am now to the point where I pretty much have to decode by hand.

Most RS232 receivers work fine with TTL input (unless it's inverted!)

Could be done but would require some fidgeting with hardware as well. I'll see.

Not really. If you send me a file I will write a program to pull out the data. What format do you want the output?

Rick C.

• Get 6 months of free supercharging + Tesla referral code -
  formatting link

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

What are you going to do in one day to process 25,000 data points by hand? I bet a plot will help a lot.

I think you are over-thinking this. No VBA programming needed. Just try it, using standard Excel functions. Or, just use Excel a a format converter.

Joe Gwinn

It's grossly oversampled so there are only a few dozen data words in that stream. The way I did that in the past was to make a paper ruler to scale, scroll the trace across the screen and figure out the hex code with a paper look-up table. Of course, now when fast-forwarding 25 years one has to first lay packaging plastic over the screen because they aren't glass anymore and could scratch.

I dnt know which standard Excel funtions or format converters would convert a scope raw data output to hex. Martin and Lasse sent me a VBA rountine and C code respectively and the hex data that came out of both methods was the same, which is very encouraging.

Ideally in hex. I had sent you the file this morning. Meantime Martin and Lasse sent me code (Martin in Excel VBA with macros, Lasse in C) which seems to work. They result in the same hex output which is encouraging.

Embarrassed to say but I am not familiar with compiling stuff so I'll probably try to plow ahead with Excel, or in my case try to run it in OpenOffice.

It appears that you have access to the real-time hardware data. It appears that you're triggering somehow on something. It's not at all clear whether you need to see data prior to the trigger event. Not clear whether this is a one-time measurement or whether you're looking for an infrequent event/bug.

If this is a blip on otherwise equal data streams, you might be able to compare a stored good waveform with a bad one. Then you only have to decode the mis-compares.

If you have serial data, it's going somewhere. Why can't you use the destination to acquire the data you need?

Stated another way, sometimes, focusing on a particular plan of attack, tunnel vision, can prevent examination of far easier paths.

Depending on your scope, you may be able to put it into single sweep mode with a LONG sweep time and use the sweep gate out as your enabler.

You may not have to gate the data at all. You just have to embed the event in the data. Can you trash a character and detect the parity error?

The devil is in the details.

Doubt this helps, but I've acquired data using an IR led on the data line and acquired it with the IR port on a PALM III with a serial data app. Use a second LED to saturate/'blind' the acquisition IR until the trigger event. A serial to Bluetooth dongle can make it work on more recent devices without hardware serial or IR.

A single transistor into a real RS232 port on an old laptop will reliably acquire RS232 with 0 to 5V swing. Maybe a second transistor depending on your source polarity.

I work in Forth. In theory I could send you a stand alone executable but I 'm not familiar with the process of generating that. The other alternativ e is to install a Forth app to run the code, which would be a bit of effort for you, but not tons. The Forth I use, Win32Forth can sometimes be flagg ed by AVS even though it is clean. Gforth is fine and I haven't heard of a ny AVS problems, but I haven't used it under Windows.

So do you still need this or is Martin and Lasse's work good enough?

Rick C.

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

No pre-trigger view needed but pre-trigger logging would be easy with my DSO.

There is a repetitive bug and some units and on others there isn't.

It's not that easy. Later in the message there are serial numbers and stuff embedded in the data and that's different between faulty units and non-faulty ones. This makes raw data comaring really tough. In decoded hex it's not so tough.

It needs to be acquire at or around an event and that's best done using a DSO or a logic analyzer. My logic analyzer is a model dating almost back to Fred Flintstone when all buses were parallel. So no serial decode there. It also doesn't have fancy trigger such as runt pulse like the DSO does.

It's not that easy. This scope only has 25,000 recording length and even that only if limiting to single-channel.

It sure is :-)

That is nifty but if wouldn't allow trigger on a fault.

xfer of 3.3V logic into RS232 is easy but that won't allow any trigger capture.

Thanks, but it should definitely be good enough. Currently the code in the uC firmware is being looked at because a bug is now suspected in it, which could be causing all this.

I've got 3.3V but easy to handle using a transistor. The problem is the event sync. My scope doesn't have a trigger-out, only a "good-bad" qualifier output that can turn on a the big red light but that's not

Gosh that's quite nice of Lasse, I'd have least asked for some beer money to do it in C!

Dealing with large numbers of data points from a data set of arbitrary size is a lot more civilized in C++ with its dynamically-re sizable containers (std::list, std::vector, etc.)

Girlfriend had a bad case of the sniffles and I know I'd say "Take a Sudafed and deal, sweetie, there's work to be done" for some price. Less than a $1 million. More than $0.

I might have to put more thought into the relationship-Laffer-curve at some point

out

the data size was know at compile time and no matter what language you use I think you'd want to figure out how much space you need and allocate that at the beginning so you don't have a vector grow as you read numbers from a file

For record sizes of tens of thousands of byte-sized elements or CSVs I suppose on modern PCs it hardly matters exactly how the data is loaded and processed it'll all be done before you know it. vectors are very generalized data structures, they can be allocated on the stack or heap, the stack is usually a couple megabytes in size on most modern desktop arch so for 25,0000 byte-sized records probably can just use the stack no heap allocation required at all. The overhead of simply opening, reading, and closing the file dominates the runtime by a longshot.

in that case it's mostly a matter of convenience from a programming/algorithm implementation perspective, once the data is in a generic container like a vector, however it got there, it's easy to write a std::algorithm of some kind that operates on the entire container in some way automatically, an element-wise mapping, in-place or by returning values, however you like.

I don't like "naked" for loops and avoid them when I can, they're error-prone the "modern" solution is to use iterators and avoid touching your actual data directly when you don't have to.

For large record sizes like millions or tens of millions of elements, where the amount of data is approaching a goodly percentage of the total available heap memory of the machine it makes sense to read the file in piece by piece in manageable chunks like multiples of a cache line size that would fit in an L2 cache, and farm the work out to worker threads leveraging multiple cores.