If you decide that you need to make the measurements - there is Bitscope logic http://bitscope.com/software/logic/ application which should be able to display and decode the serial signal for you from the probes.
I never needed/used it with the bitscope, but it looks legit enough within the speed and capture memory limitations of the ancient bitscope HW. My bitscope has 4 analog channels which should be enough to cover your high swing serial port signals. It sure will take some time to setup, use, debug your problem, but it should be a lot of HW fun. If you have the time. Tomas On Mon, 2018-01-01 at 11:46 -0800, Denis Heidtmann wrote: > I am looking into ways to examine the serial traffic to/from my > dmm. The > arrangement I think would be the most useful to examine is with the > mfg.'s > sw running in the win2k guest in the desktop. This arrangement is > the only > one that successfully communicates with the dmm. > > I hope (assume?) that a linux program running simultaneously in the > host > would be able to capture the traffic. Is this true? > > I have found the program jpnevulator. It seems to me that it could > perform > the traffic monitoring function, but since there is a lot about > serial > communications that I do not understand I could be mistaken. In the > read > mode will it capture the traffic in both directions (between the > windows sw > and the dmm), or must it be the recipient of the traffic, thereby > removing > the windows sw from the interaction? > > If this whole idea is ill-founded there is Tomas' > instrument. However I > did not see in the documentation that it was capable of any > decoding. How > do I convert a train of pulses to a sequence of bytes and know which > end > sent them? > > I appreciate any advice. > > -Denis > > On Fri, Dec 29, 2017 at 6:54 PM, Denis Heidtmann <denis.heidtmann@gma > il.com> > wrote: > > > > > I just ran the mfg. sw in the vb win2k guest. I then checked the > > serial > > parameters in the host. I then ran sigrok-cli --driver > > mastech-mas345:conn=/dev/ttyS0 --samples 10 in the host after > > shutting down > > the guest. Same no-response result. This would seem to rule out > > the > > possibility that the serial parameters are wrong. > > > > -Denis > > > > > > > > On Fri, Dec 29, 2017 at 2:44 PM, Denis Heidtmann < > > denis.heidtm...@gmail.com> wrote: > > > > > > > > I made the measurements with my 'scope. The voltages and > > > waveforms are > > > identical comparing DTR, RTS (also RXD), although I am surprised > > > a little > > > that the pulses on DTR are as large as they are: 2.4V > > > swing. Must be some > > > resistance in the supply to the drain. But the level is up at > > > 11.6V, so > > > those 2.4V drops cannot matter. The signals on the RXD pin are > > > -3.6 to > > > +8.2V for both the mfg. sw and sigrok. > > > > > > So no explanation yet, and hence no solution. Is there a way to > > > examine > > > the serial parameters the mfg. sw uses? Perhaps the docs on the > > > protocol > > > are in error. > > > > > > On Fri, Dec 29, 2017 at 9:17 AM, Denis Heidtmann < > > > denis.heidtm...@gmail.com> wrote: > > > > > > > > > > > I will make those measurements, but I am doubtful it will show > > > > anything. The schematic I have shows DTR to be the collector > > > > and RTS to be > > > > the low end of the emitter resistor of the output NPN. I did > > > > see solid > > > > pulses on the emitter with sigrok. But perhaps DTR and/or RTS > > > > are pulsed > > > > when they should not be. It is too bad my 'scope has limited > > > > record length > > > > and no way to store the data off the 'scope. > > > > > > > > On Thu, Dec 28, 2017 at 11:42 PM, Russell Senior < > > > > russ...@personaltelco.net> wrote: > > > > > > > > > > > > > > Have you measured the voltages on DTR and RTS during the > > > > > runs? > > > > > > > > > > Try it with sigrok and with the vendor software and see if > > > > > there is a > > > > > difference in those values. > > > > > > > > > > On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann > > > > > <denis.heidtm...@gmail.com> wrote: > > > > > > > > > > > > This saga continues. > > > > > > > > > > > > On the laptop with a usb-serial adapter I got to the point > > > > > > where the > > > > > > commands: > > > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show > > > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan > > > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 -- > > > > > > samples 10 > > > > > > > > > > > > behave as expected except the last one returns no data. I > > > > > > was > > > > > advised to > > > > > > > > > > > > try using these same commands on the desktop which has an > > > > > > RS232 port, > > > > > thus > > > > > > > > > > > > removing the usb-serial adapter from the picture. Good > > > > > > idea. > > > > > > > > > > > > After just guessing what serial port to use, I run the > > > > > > following > > > > > command: > > > > > > > > > > > > > > > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --scan > > > > > > The following devices were found: > > > > > > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > > > > > > > > > > > > This is the same response I got on the laptop. > > > > > > > > > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --show > > > > > > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > > > > > > Supported driver options: > > > > > > conn > > > > > > serialcomm > > > > > > Supported configuration options: > > > > > > > > > > > > This is the same response I got on the laptop. > > > > > > > > > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 -- > > > > > > samples 10 > > > > > > > > > > > > [no response except the usual ~10 second delay] > > > > > > > > > > > > This is the same response I got on the laptop. RATS! > > > > > > > > > > > > This eliminates the usb-serial device from the picture. > > > > > > > > > > > > Recall that when running --samples 10 command on the laptop > > > > > > I was > > > > > able to > > > > > > > > > > > > detect pulses on the serial line consistent (in a general > > > > > > sense) with > > > > > a > > > > > > > > > > > > response from the dmm. Also recall that running the mfg. > > > > > > sw under > > > > > windows > > > > > > > > > > > > on the desktop showed flawless communication. > > > > > > > > > > > > finally, I report: > > > > > > stty -F /dev/ttyS0 -a speed 600 baud; rows 0; columns 0; > > > > > > line = 0; > > > > > > intr = <undef>; quit = <undef>; erase = <undef>; kill = > > > > > > <undef>; eof = > > > > > > <undef>; > > > > > > eol = <undef>; eol2 = <undef>; swtch = <undef>; start = > > > > > > <undef>; stop > > > > > = > > > > > > > > > > > > <undef>; > > > > > > susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = > > > > > > <undef>; > > > > > > discard = <undef>; min = 0; time = 0; > > > > > > -parenb -parodd -cmspar cs7 hupcl cstopb cread clocal > > > > > > -crtscts > > > > > > -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr > > > > > > -icrnl > > > > > -ixon > > > > > > > > > > > > -ixoff > > > > > > -iuclc -ixany -imaxbel -iutf8 > > > > > > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel > > > > > > nl0 cr0 tab0 > > > > > bs0 > > > > > > > > > > > > vt0 ff0 > > > > > > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh > > > > > > -xcase > > > > > -tostop > > > > > > > > > > > > -echoprt > > > > > > -echoctl -echoke -flusho -extproc > > > > > > > > > > > > And the protocol is reported to be: > > > > > > > > > > > > data format: 7n2 at 600 baud (7 bits, no parity, 2 stop > > > > > > bits). > > > > > > Control lines: > > > > > > DTR and RTS lines are used to power the TX line: RTS is > > > > > > clear > > > > > > for -12 supply; DTR is set for +12 supply. Data > > > > > > transmission is > > > > > > solicited sending whatever character to the RX line. > > > > > > > > > > > > Any suggestions as to where to go from here? > > > > > > > > > > > > Thanks, > > > > > > -Denis > > > > > > _______________________________________________ > > > > > > PLUG mailing list > > > > > > PLUG@pdxlinux.org > > > > > > http://lists.pdxlinux.org/mailman/listinfo/plug > > > > > _______________________________________________ > > > > > PLUG mailing list > > > > > PLUG@pdxlinux.org > > > > > http://lists.pdxlinux.org/mailman/listinfo/plug > > > > > > > > > > > > > > > > > > > _______________________________________________ > PLUG mailing list > PLUG@pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug _______________________________________________ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
