On 2019-01-22 06:12, Joseph Gwinn wrote:> On Jan 21, 2019, Joerg wrote > (in article <gamfknFg1i9U1@mid.individual.net>): > >> On 2019-01-21 07:55, Joseph Gwinn wrote:[...]>>> 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. >> >> I don't 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. > > Given that you have a CSV file, name the file something like data.csv, and > ask Excel to open the file. It should just open. Nor will 25000 points be a > problem. Select the data column (first to last sells, and all between being > selected) and go to Charts in the menu. There will be a suitable plot type. > Choose it. If you don�t like that one, delete the plot and try something > else. > > Scroll through the plot to find the events. Then find the critical span of > data samples. >I knew that and it works. Finding events is the key problem. Yesterday I did but that was a tedious job using a paper ruler on the screen, made to scale for the baud rate and zoom. Just like I did in the 90's. -- Regards, Joerg http://www.analogconsultants.com/
RS232 decode routines from raw scope data?
Started by ●January 20, 2019
Reply by ●January 22, 20192019-01-22
Reply by ●January 22, 20192019-01-22
On 2019-01-21 17:44, Mike wrote:> On 1/21/2019 12:41 PM, Joerg wrote: >> On 2019-01-21 12:11, Mike wrote: >>> On 1/21/2019 7:36 AM, Joerg wrote: >>>> On 2019-01-21 05:02, Chris Jones wrote: >>>>> On 21/01/2019 10:06, Joerg wrote: >>>>>> On 2019-01-20 14:49, bitrex wrote: >>>>>>> On 01/20/2019 05:26 PM, Joerg wrote: >>>>>>>> On 2019-01-20 13:54, Sjouke Burry wrote: >>>>>>>>> On 20-1-2019 22:51, Sjouke Burry wrote: >>>>>>>>>> On 20-1-2019 21:52, Joerg wrote: >>>>>>>>>>> Is there a simple Windows or Linux program that can decode >>>>>>>>>>> serial >>>>>>>>>>> data >>>>>>>>>>> out of raw data from an digital oscilloscope? >>>>>>>>>>> >>>>>>>>>>> My old logic analyzer does not have any serial data decoding and >>>>>>>>>>> neither >>>>>>>>>>> does my scope. So I'd need something that can take in the ADC >>>>>>>>>>> raw >>>>>>>>>>> data, >>>>>>>>>>> I set a threshold to turn that into H/L digital values and the >>>>>>>>>>> software >>>>>>>>>>> would fish out the data words. Not sure if it even exist. Not >>>>>>>>>>> something >>>>>>>>>>> expensive because I'll only need it once for a short time, to >>>>>>>>>>> find if >>>>>>>>>>> there's a bug visible in the data. It'll be a challenge >>>>>>>>>>> because my >>>>>>>>>>> scope >>>>>>>>>>> only has 25,000 points recording length. >>>>>>>>>>> >>>>>>>>>> For reading/writing the hardware ports, (for me in DOS) you >>>>>>>>>> can download my code. >>>>>>>>>> The exe can be loaded on both sides of a nul modem connection, >>>>>>>>>> and gives both screen access to the oher computer. >>>>>>>>>> >>>>>>>>>> It uses the hardware buffer in the rs232 chip, no interrupt used. >>>>>>>>>> >>>>>>>>> Sorry, I forgot the link.> >>>>>>>>> http://home.planet.nl/~burry004/COMPORT.ZIP >>>>>>>>> >>>>>>>> >>>>>>>> Thanks, Sjouke, but unfortunately this isn't coming from the >>>>>>>> harware >>>>>>>> port. It is raw data in the form of an oscilloscope data dump. >>>>>>>> Basically 25,000 data words of 8-bits each where a threshold >>>>>>>> needs to >>>>>>>> be set to turn this into high-low digital data, then the frames >>>>>>>> need >>>>>>>> to be found according to start/stop bits and the result output as >>>>>>>> ASCII. >>>>>>>> >>>>>>>> Similar to morse code decoding, just that instead of morse code >>>>>>>> it's >>>>>>>> RS232 data. Or in my case RS485 but it's the same thing. >>>>>>>> >>>>>>> >>>>>>> "Tomorrow" is a pretty tight deadline I'd have to charge a lot >>>>>>> for but >>>>>>> if you can post a set of example data I could whip up a softwares >>>>>>> that >>>>>>> might be usable for next time for 'bout $0 >>>>>>> >>>>>> >>>>>> Thanks, but I can't post that publicly. One engineer from the UK >>>>>> wrote >>>>>> me a PM and wants to take a stab at it in Excel. I sent him a >>>>>> recorded >>>>>> CSV file. I don't yet have the data format info, probably one start >>>>>> and one stop bit though I won't know for sure until tomorrow. >>>>>> >>>>>> I can do this one using the old ruler and conting method, hoping I'll >>>>>> never need to do this again for the rest of my life. >>>>>> >>>>>> It just puzzles me that there isn't any software out there for such a >>>>>> decoding. I can't be the only one with an older DSO. >>>>> Sigrok can do it. https://sigrok.org/ >>>>> That software supports cheap USB logic analysers (I know you don't >>>>> have >>>>> one, so no good for this time, but you should spend the $6.86 so that >>>>> you have one ready for next time): >>>>> https://www.dx.com/p/logic-analyzer-w-dupont-lines-and-usb-cable-for-scm-black-2017429 >>>>> >>>>> >>>>> >>>>> I understand that Sigrok also supports many DSOs, and may support the >>>>> one that you have, or some intermediate format that you can save to. >>>>> >>>>> It is a while since I installed Sigrok (on linux). I seem to recall >>>>> needing a fairly recent version of linux and Sigrok, though I didn't >>>>> have to build anything from source. It was a pain to set up, but saved >>>>> me a lot of time in the end. I think I used a nightly build appimage: >>>>> https://sigrok.org/jenkins/job/sigrok-native-appimage/platform=native-i686-appimage/lastSuccessfulBuild/artifact/cross-compile/appimage/out/PulseView-NIGHTLY-i686.AppImage >>>>> >>>>> >>>>> >>>>> >>>> >>>> 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: >>>> >>>> https://sigrok.org/wiki/Protocol_decoder:Uart >>>> >>>> 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. >>>> >>> 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. >> >> >> No pre-trigger view needed but pre-trigger logging would be easy with >> my DSO. >> >> >>> Not clear whether this is a one-time measurement or whether you're >>> looking >>> for an infrequent event/bug. >>> >> >> There is a repetitive bug and some units and on others there isn't. >> >> >>> 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. >>> >> >> 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. >> >> >>> If you have serial data, it's going somewhere. Why can't you use the >>> destination to acquire the data you need? >>> >> >> It needs to be acquire at or around an event and that's best done >> using a DSO or a logic analyzer. > > I'd agree, except that you don't have a scope or logic analyzer that's up > to the task. >Soon I might. I ordered the little USB logic analyzer that Lasse suggested, it just ain't here yet. In case there is a next time. I hope there won't be but one never knows.> 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. >> >> >>> 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? >>> >> >> It's not that easy. This scope only has 25,000 recording length and >> even that only if limiting to single-channel. >> >> >>> The devil is in the details. >>> >> >> It sure is :-) >> >> >>> 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. >>> >> >> That is nifty but if wouldn't allow trigger on a fault. >> >> >>> 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. >> >> >> xfer of 3.3V logic into RS232 is easy but that won't allow any trigger >> capture. >> > I betcha you could inject the trigger into the stream and generate > a sync or parity error. Or just terminate the data stream some appropriate > number of seconds after the trigger. >Only if the scope has a fast enough trigger output. Mine doesn't, it only has a "go - no go" type alert output and that isn't true realtime.> Another kludge you could try is to use two serial ports > and switch between them at the trigger event. > > I have a Tektronix 308 that would probably do what you want if you can > spit the acquired data out of the scope at the proper baud rate. > Unfortunately, > it maxes out at 9600 baud. >That would be a problem because this set-up shifts gears. Once communication is established it steps on it and shifts from 9600bd to 19200bd, in the middle of the data stream.> At some point, it becomes easier to program up an arduino to do exactly > what you want. It's so easy to upload the microcode that you could > hard code the > whole thing without a complicated user interface. Patch the code as you > zero > in on the fault. >Only if you are versed in programming stuff. That's why I couldn't compile Lasse's code, I am just not experienced in handling software jobs.> Is the data rate maxing out the serial baud rate? If it is, you can't > inject characters to indicate the trigger.It ratchets up to 19200bd later and injecting characters would require some coding which I have no experience with. Once I get SigRok going on the little analyzer pod that is being shipped here I should be able to solve such puzzles easier. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●January 22, 20192019-01-22
On 2019-01-22 04:55, Chris Jones wrote:> On 22/01/2019 02:36, Joerg wrote: >> On 2019-01-21 05:02, Chris Jones wrote: >>> On 21/01/2019 10:06, Joerg wrote: >>>> On 2019-01-20 14:49, bitrex wrote: >>>>> On 01/20/2019 05:26 PM, Joerg wrote: >>>>>> On 2019-01-20 13:54, Sjouke Burry wrote: >>>>>>> On 20-1-2019 22:51, Sjouke Burry wrote: >>>>>>>> On 20-1-2019 21:52, Joerg wrote: >>>>>>>>> Is there a simple Windows or Linux program that can decode serial >>>>>>>>> data >>>>>>>>> out of raw data from an digital oscilloscope? >>>>>>>>> >>>>>>>>> My old logic analyzer does not have any serial data decoding and >>>>>>>>> neither >>>>>>>>> does my scope. So I'd need something that can take in the ADC raw >>>>>>>>> data, >>>>>>>>> I set a threshold to turn that into H/L digital values and the >>>>>>>>> software >>>>>>>>> would fish out the data words. Not sure if it even exist. Not >>>>>>>>> something >>>>>>>>> expensive because I'll only need it once for a short time, to >>>>>>>>> find if >>>>>>>>> there's a bug visible in the data. It'll be a challenge because my >>>>>>>>> scope >>>>>>>>> only has 25,000 points recording length. >>>>>>>>> >>>>>>>> For reading/writing the hardware ports, (for me in DOS) you >>>>>>>> can download my code. >>>>>>>> The exe can be loaded on both sides of a nul modem connection, >>>>>>>> and gives both screen access to the oher computer. >>>>>>>> >>>>>>>> It uses the hardware buffer in the rs232 chip, no interrupt used. >>>>>>>> >>>>>>> Sorry, I forgot the link.> >>>>>>> http://home.planet.nl/~burry004/COMPORT.ZIP >>>>>>> >>>>>> >>>>>> Thanks, Sjouke, but unfortunately this isn't coming from the harware >>>>>> port. It is raw data in the form of an oscilloscope data dump. >>>>>> Basically 25,000 data words of 8-bits each where a threshold needs to >>>>>> be set to turn this into high-low digital data, then the frames need >>>>>> to be found according to start/stop bits and the result output as >>>>>> ASCII. >>>>>> >>>>>> Similar to morse code decoding, just that instead of morse code it's >>>>>> RS232 data. Or in my case RS485 but it's the same thing. >>>>>> >>>>> >>>>> "Tomorrow" is a pretty tight deadline I'd have to charge a lot for but >>>>> if you can post a set of example data I could whip up a softwares that >>>>> might be usable for next time for 'bout $0 >>>>> >>>> >>>> Thanks, but I can't post that publicly. One engineer from the UK wrote >>>> me a PM and wants to take a stab at it in Excel. I sent him a recorded >>>> CSV file. I don't yet have the data format info, probably one start >>>> and one stop bit though I won't know for sure until tomorrow. >>>> >>>> I can do this one using the old ruler and conting method, hoping I'll >>>> never need to do this again for the rest of my life. >>>> >>>> It just puzzles me that there isn't any software out there for such a >>>> decoding. I can't be the only one with an older DSO. >>> Sigrok can do it. https://sigrok.org/ >>> That software supports cheap USB logic analysers (I know you don't have >>> one, so no good for this time, but you should spend the $6.86 so that >>> you have one ready for next time): >>> https://www.dx.com/p/logic-analyzer-w-dupont-lines-and-usb-cable-for-scm-black-2017429 >>> >>> >>> I understand that Sigrok also supports many DSOs, and may support the >>> one that you have, or some intermediate format that you can save to. >>> >>> It is a while since I installed Sigrok (on linux). I seem to recall >>> needing a fairly recent version of linux and Sigrok, though I didn't >>> have to build anything from source. It was a pain to set up, but saved >>> me a lot of time in the end. I think I used a nightly build appimage: >>> https://sigrok.org/jenkins/job/sigrok-native-appimage/platform=native-i686-appimage/lastSuccessfulBuild/artifact/cross-compile/appimage/out/PulseView-NIGHTLY-i686.AppImage >>> >>> >>> >> >> 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: >> >> https://sigrok.org/wiki/Protocol_decoder:Uart > No, that page is a bit misleading, it is just an example: the prolific > chip is the "device under test" on that webpage, and > "The logic analyzer used was a Saleae Logic (at 16MHz)" > > It is definitely a software decoder, as I have used it on waveforms that > I captured with a USB logic analyser and then saved to disk (as a VCD > file), had the program crash, re-started it and then reloaded the > waveforms and then decoded the bytes. The program that I had to run is > called "pulseview". I do remember having to do some fiddly configuration > to get it to access the USB logic analyser without being root, and also > that to properly reboot the logic analyser after a crash, I had to > remove both USB and also all logic signals that were powering it via ESD > diodes. > > I have used the $6-ish one that I linked above > https://www.dx.com/p/logic-analyzer-w-dupont-lines-and-usb-cable-for-scm-black-2017429 > > though those seem to be sold-out and you might have to go for the $10 > version that they listed as an alternative. Those are quite useful as > they can capture 8 channels at 24 megasamples per second, with a memory > depth in principle only limited by the size of your hard drive. The bare > chip can do 16 channels (but not as fast sampling as for 8 channels) and > I soldered one up with them all brought out, though most of the boards > only bring out 8 channels to the header. > > Anyway sigrok / pulseview could very likely decode the data from your > scope, if it is in a format that it can read: > https://sigrok.org/wiki/Input_output_formats >I ordered a similar one after Lasse brought it up. We'll see, maybe I'll dive deeper into the digital world. I think I could get rid of my old Dolch LAM-3250 logic analyzer but probably nobody would want to have it. It's a nice-looking machine, pretty enclosure and all, but nowadays considered a boat anchor. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●January 22, 20192019-01-22
On 2019-01-22 07:33, Bernd Mayer wrote:> Am 20.01.19 um 21:52 schrieb Joerg: >> Is there a simple Windows or Linux program that can decode serial data >> out of raw data from an digital oscilloscope? >> >> My old logic analyzer does not have any serial data decoding and >> neither does my scope. So I'd need something that can take in the ADC >> raw data, I set a threshold to turn that into H/L digital values and >> the software would fish out the data words. Not sure if it even exist. >> Not something expensive because I'll only need it once for a short >> time, to find if there's a bug visible in the data. It'll be a >> challenge because my scope only has 25,000 points recording length. > > Hello, > > may be the Software for bitscope is capable for this job. > https://bitscope.com/software/logic/ > > This software is available für Linux and for Windows. > > For testing purposes you don't need the hardware, you can use a bitscope > over the internet. >Interesting, thanks. I'd have to find out how to feed in a CSV file or some similar file. Converting the scope recordings into ones and zeroes is easy but I'd have to get into into a format that this software can read. Anyhow, I have ordered a small 8-line logic analyzer which works with the SigRok environment. That ought to do the trick for next time. I'd like to run it on a laptop that I just converted to Linux but that seems to be no problem with such software. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●January 22, 20192019-01-22
On 2019-01-22 09:18, makolber@yahoo.com wrote:> question to the OP, > > is your serial data self clocking or do you have a separate clock and data line? >It's self-clocking. The usual 1-start, 1-stop and no parity on a single serial data line. Like RS232 and RS485. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●January 22, 20192019-01-22
Am 22.01.19 um 19:51 schrieb Joerg:> On 2019-01-22 07:33, Bernd Mayer wrote: >> Am 20.01.19 um 21:52 schrieb Joerg: >> >> may be the Software for bitscope is capable for this job. >> https://bitscope.com/software/logic/ >> >> This software is available für Linux and for Windows. >> >> For testing purposes you don't need the hardware, you can use a bitscope >> over the internet. >> > > Interesting, thanks. I'd have to find out how to feed in a CSV file or > some similar file. Converting the scope recordings into ones and zeroes > is easy but I'd have to get into into a format that this software can read. >Hello, bitscope can hello, bitscope is capable of capturing and replaying the data. If they use the same file-format then you can try to replay your data into the software and analyze it. Bernd Mayer
Reply by ●January 22, 20192019-01-22
Am 22.01.19 um 19:51 schrieb Joerg:> On 2019-01-22 07:33, Bernd Mayer wrote: >> Am 20.01.19 um 21:52 schrieb Joerg: >> >> may be the Software for bitscope is capable for this job. >> https://bitscope.com/software/logic/ >> >> This software is available für Linux and for Windows. >> >> For testing purposes you don't need the hardware, you can use a bitscope >> over the internet. >> > > Interesting, thanks. I'd have to find out how to feed in a CSV file or > some similar file. Converting the scope recordings into ones and zeroes > is easy but I'd have to get into into a format that this software can read.hello, bitscope is capable of capturing and replaying the data. If they use the same file-format then you can try to replay your data into the software and analyze it. Bernd Mayer
Reply by ●January 22, 20192019-01-22
On 2019-01-22 11:32, Bernd Mayer wrote:> Am 22.01.19 um 19:51 schrieb Joerg: >> On 2019-01-22 07:33, Bernd Mayer wrote: >>> Am 20.01.19 um 21:52 schrieb Joerg: >>> >>> may be the Software for bitscope is capable for this job. >>> https://bitscope.com/software/logic/ >>> >>> This software is available für Linux and for Windows. >>> >>> For testing purposes you don't need the hardware, you can use a bitscope >>> over the internet. >>> >> >> Interesting, thanks. I'd have to find out how to feed in a CSV file or >> some similar file. Converting the scope recordings into ones and >> zeroes is easy but I'd have to get into into a format that this >> software can read. > > hello, > > bitscope is capable of capturing and replaying the data. > If they use the same file-format then you can try to replay your data > into the software and analyze it. >The DDR files it uses are simple CSV which is easy but AFAICT they require a header with meta data in it (at about 75% scroll down): https://www.bitscope.com/software/dso/guide/2.5/?p=14#files My oscilloscope is similar. I writes files with meta data which I truncate when importing into Excel. However, reading such files back into the scope, for example to perform math on them, requires this meta data to be there. Else the scope can't know how to interpret the data such as the number of channels it represents, what the time base was, and so on. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●January 22, 20192019-01-22
On 2019-01-22 11:52, Joerg wrote:> On 2019-01-22 11:32, Bernd Mayer wrote: >> Am 22.01.19 um 19:51 schrieb Joerg: >>> On 2019-01-22 07:33, Bernd Mayer wrote: >>>> Am 20.01.19 um 21:52 schrieb Joerg: >>>> >>>> may be the Software for bitscope is capable for this job. >>>> https://bitscope.com/software/logic/ >>>> >>>> This software is available für Linux and for Windows. >>>> >>>> For testing purposes you don't need the hardware, you can use a >>>> bitscope >>>> over the internet. >>>> >>> >>> Interesting, thanks. I'd have to find out how to feed in a CSV file or >>> some similar file. Converting the scope recordings into ones and >>> zeroes is easy but I'd have to get into into a format that this >>> software can read. >> >> hello, >> >> bitscope is capable of capturing and replaying the data. >> If they use the same file-format then you can try to replay your data >> into the software and analyze it. >> > > The DDR files it uses are simple CSV which is easy but AFAICT they > require a header with meta data in it (at about 75% scroll down): > > https://www.bitscope.com/software/dso/guide/2.5/?p=14#files > > My oscilloscope is similar. I writes files with meta data which I > truncate when importing into Excel. However, reading such files back > into the scope, for example to perform math on them, requires this meta > data to be there. Else the scope can't know how to interpret the data > such as the number of channels it represents, what the time base was, > and so on. >I just tried it. The installed version on the Windows PC here at the office is missing the whole top menu bar and other stuff. It doesn't look quite ready yet :-) -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●January 22, 20192019-01-22
tirsdag den 22. januar 2019 kl. 19.41.05 UTC+1 skrev Joerg:> On 2019-01-21 17:44, Mike wrote: > > On 1/21/2019 12:41 PM, Joerg wrote: > >> On 2019-01-21 12:11, Mike wrote: > >>> On 1/21/2019 7:36 AM, Joerg wrote: > >>>> On 2019-01-21 05:02, Chris Jones wrote: > >>>>> On 21/01/2019 10:06, Joerg wrote: > >>>>>> On 2019-01-20 14:49, bitrex wrote: > >>>>>>> On 01/20/2019 05:26 PM, Joerg wrote: > >>>>>>>> On 2019-01-20 13:54, Sjouke Burry wrote: > >>>>>>>>> On 20-1-2019 22:51, Sjouke Burry wrote: > >>>>>>>>>> On 20-1-2019 21:52, Joerg wrote: > >>>>>>>>>>> Is there a simple Windows or Linux program that can decode > >>>>>>>>>>> serial > >>>>>>>>>>> data > >>>>>>>>>>> out of raw data from an digital oscilloscope? > >>>>>>>>>>> > >>>>>>>>>>> My old logic analyzer does not have any serial data decoding and > >>>>>>>>>>> neither > >>>>>>>>>>> does my scope. So I'd need something that can take in the ADC > >>>>>>>>>>> raw > >>>>>>>>>>> data, > >>>>>>>>>>> I set a threshold to turn that into H/L digital values and the > >>>>>>>>>>> software > >>>>>>>>>>> would fish out the data words. Not sure if it even exist. Not > >>>>>>>>>>> something > >>>>>>>>>>> expensive because I'll only need it once for a short time, to > >>>>>>>>>>> find if > >>>>>>>>>>> there's a bug visible in the data. It'll be a challenge > >>>>>>>>>>> because my > >>>>>>>>>>> scope > >>>>>>>>>>> only has 25,000 points recording length. > >>>>>>>>>>> > >>>>>>>>>> For reading/writing the hardware ports, (for me in DOS) you > >>>>>>>>>> can download my code. > >>>>>>>>>> The exe can be loaded on both sides of a nul modem connection, > >>>>>>>>>> and gives both screen access to the oher computer. > >>>>>>>>>> > >>>>>>>>>> It uses the hardware buffer in the rs232 chip, no interrupt used. > >>>>>>>>>> > >>>>>>>>> Sorry, I forgot the link.> > >>>>>>>>> http://home.planet.nl/~burry004/COMPORT.ZIP > >>>>>>>>> > >>>>>>>> > >>>>>>>> Thanks, Sjouke, but unfortunately this isn't coming from the > >>>>>>>> harware > >>>>>>>> port. It is raw data in the form of an oscilloscope data dump. > >>>>>>>> Basically 25,000 data words of 8-bits each where a threshold > >>>>>>>> needs to > >>>>>>>> be set to turn this into high-low digital data, then the frames > >>>>>>>> need > >>>>>>>> to be found according to start/stop bits and the result output as > >>>>>>>> ASCII. > >>>>>>>> > >>>>>>>> Similar to morse code decoding, just that instead of morse code > >>>>>>>> it's > >>>>>>>> RS232 data. Or in my case RS485 but it's the same thing. > >>>>>>>> > >>>>>>> > >>>>>>> "Tomorrow" is a pretty tight deadline I'd have to charge a lot > >>>>>>> for but > >>>>>>> if you can post a set of example data I could whip up a softwares > >>>>>>> that > >>>>>>> might be usable for next time for 'bout $0 > >>>>>>> > >>>>>> > >>>>>> Thanks, but I can't post that publicly. One engineer from the UK > >>>>>> wrote > >>>>>> me a PM and wants to take a stab at it in Excel. I sent him a > >>>>>> recorded > >>>>>> CSV file. I don't yet have the data format info, probably one start > >>>>>> and one stop bit though I won't know for sure until tomorrow. > >>>>>> > >>>>>> I can do this one using the old ruler and conting method, hoping I'll > >>>>>> never need to do this again for the rest of my life. > >>>>>> > >>>>>> It just puzzles me that there isn't any software out there for such a > >>>>>> decoding. I can't be the only one with an older DSO. > >>>>> Sigrok can do it. https://sigrok.org/ > >>>>> That software supports cheap USB logic analysers (I know you don't > >>>>> have > >>>>> one, so no good for this time, but you should spend the $6.86 so that > >>>>> you have one ready for next time): > >>>>> https://www.dx.com/p/logic-analyzer-w-dupont-lines-and-usb-cable-for-scm-black-2017429 > >>>>> > >>>>> > >>>>> > >>>>> I understand that Sigrok also supports many DSOs, and may support the > >>>>> one that you have, or some intermediate format that you can save to. > >>>>> > >>>>> It is a while since I installed Sigrok (on linux). I seem to recall > >>>>> needing a fairly recent version of linux and Sigrok, though I didn't > >>>>> have to build anything from source. It was a pain to set up, but saved > >>>>> me a lot of time in the end. I think I used a nightly build appimage: > >>>>> https://sigrok.org/jenkins/job/sigrok-native-appimage/platform=native-i686-appimage/lastSuccessfulBuild/artifact/cross-compile/appimage/out/PulseView-NIGHTLY-i686.AppImage > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> 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: > >>>> > >>>> https://sigrok.org/wiki/Protocol_decoder:Uart > >>>> > >>>> 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. > >>>> > >>> 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. > >> > >> > >> No pre-trigger view needed but pre-trigger logging would be easy with > >> my DSO. > >> > >> > >>> Not clear whether this is a one-time measurement or whether you're > >>> looking > >>> for an infrequent event/bug. > >>> > >> > >> There is a repetitive bug and some units and on others there isn't. > >> > >> > >>> 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. > >>> > >> > >> 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. > >> > >> > >>> If you have serial data, it's going somewhere. Why can't you use the > >>> destination to acquire the data you need? > >>> > >> > >> It needs to be acquire at or around an event and that's best done > >> using a DSO or a logic analyzer. > > > > I'd agree, except that you don't have a scope or logic analyzer that's up > > to the task. > > > > Soon I might. I ordered the little USB logic analyzer that Lasse > suggested, it just ain't here yet. In case there is a next time. I hope > there won't be but one never knows. > > > > 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. > >> > >> > >>> 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? > >>> > >> > >> It's not that easy. This scope only has 25,000 recording length and > >> even that only if limiting to single-channel. > >> > >> > >>> The devil is in the details. > >>> > >> > >> It sure is :-) > >> > >> > >>> 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. > >>> > >> > >> That is nifty but if wouldn't allow trigger on a fault. > >> > >> > >>> 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. > >> > >> > >> xfer of 3.3V logic into RS232 is easy but that won't allow any trigger > >> capture. > >> > > I betcha you could inject the trigger into the stream and generate > > a sync or parity error. Or just terminate the data stream some appropriate > > number of seconds after the trigger. > > > > Only if the scope has a fast enough trigger output. Mine doesn't, it > only has a "go - no go" type alert output and that isn't true realtime. > > > > Another kludge you could try is to use two serial ports > > and switch between them at the trigger event. > > > > I have a Tektronix 308 that would probably do what you want if you can > > spit the acquired data out of the scope at the proper baud rate. > > Unfortunately, > > it maxes out at 9600 baud. > > > > That would be a problem because this set-up shifts gears. Once > communication is established it steps on it and shifts from 9600bd to > 19200bd, in the middle of the data stream. > > > > At some point, it becomes easier to program up an arduino to do exactly > > what you want. It's so easy to upload the microcode that you could > > hard code the > > whole thing without a complicated user interface. Patch the code as you > > zero > > in on the fault. > > > > Only if you are versed in programming stuff. That's why I couldn't > compile Lasse's code, I am just not experienced in handling software jobs. >if you are on linux I can send you an excutable, I'm not sure I have a windowsbox with a c compiler
