Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
I'm a nomad. Let's see how this week turns out. I may have some time on Friday. You can always email me off list. I'll call or text you later when I have more info about my availability. -wes On Mon, Jan 1, 2018 at 3:30 PM, Denis Heidtmann wrote: > Fantastic, Wes! My feeble abilities need lots of help. Where are you > located? I am on the west side of Portland, not far from the zoo. I guess > posting my phone number here is not too risky. 2972837. > > -Denis > > On Mon, Jan 1, 2018 at 12:36 PM, wes wrote: > > > On Mon, Jan 1, 2018 at 11:46 AM, Denis Heidtmann < > > denis.heidtm...@gmail.com> > > 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? > > > > > > > > I've been following this thread with interest. I've been thinking all > > along, "wouldn't it be great if you could just monitor the bits on the > > serial port?" This post struck me with inspiration: what you're looking > for > > is the equivalent of tcpdump for serial. That seems like something a lot > of > > people would ask about, so I googled just that: "tcpdump for serial". And > > that returned a lot of relevant pages, including this one: > > > > https://unix.stackexchange.com/questions/12359/how-can-i- > > monitor-serial-port-traffic > > > > which points us to: > > > > http://freshmeat.net/projects/linuxserialsniffer/ > > > > as well as jpnevulator. > > > > There's a lot of other interesting talk in that thread, and links to > other > > threads with other educational material. > > > > -wes > > > > > > > > > > > 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 am interested enough in your endeavor that I would like to get my hands > > on it. If this sounds agreeable to you, please let me know and we can set > > up a time to work on it together. > > > > -wes > > ___ > > 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
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
Fantastic, Wes! My feeble abilities need lots of help. Where are you located? I am on the west side of Portland, not far from the zoo. I guess posting my phone number here is not too risky. 2972837. -Denis On Mon, Jan 1, 2018 at 12:36 PM, wes wrote: > On Mon, Jan 1, 2018 at 11:46 AM, Denis Heidtmann < > denis.heidtm...@gmail.com> > 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? > > > > > I've been following this thread with interest. I've been thinking all > along, "wouldn't it be great if you could just monitor the bits on the > serial port?" This post struck me with inspiration: what you're looking for > is the equivalent of tcpdump for serial. That seems like something a lot of > people would ask about, so I googled just that: "tcpdump for serial". And > that returned a lot of relevant pages, including this one: > > https://unix.stackexchange.com/questions/12359/how-can-i- > monitor-serial-port-traffic > > which points us to: > > http://freshmeat.net/projects/linuxserialsniffer/ > > as well as jpnevulator. > > There's a lot of other interesting talk in that thread, and links to other > threads with other educational material. > > -wes > > > > > > 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 am interested enough in your endeavor that I would like to get my hands > on it. If this sounds agreeable to you, please let me know and we can set > up a time to work on it together. > > -wes > ___ > 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
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
On Mon, Jan 1, 2018 at 11:46 AM, 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? > > I've been following this thread with interest. I've been thinking all along, "wouldn't it be great if you could just monitor the bits on the serial port?" This post struck me with inspiration: what you're looking for is the equivalent of tcpdump for serial. That seems like something a lot of people would ask about, so I googled just that: "tcpdump for serial". And that returned a lot of relevant pages, including this one: https://unix.stackexchange.com/questions/12359/how-can-i- monitor-serial-port-traffic which points us to: http://freshmeat.net/projects/linuxserialsniffer/ as well as jpnevulator. There's a lot of other interesting talk in that thread, and links to other threads with other educational material. -wes > 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 am interested enough in your endeavor that I would like to get my hands on it. If this sounds agreeable to you, please let me know and we can set up a time to work on it together. -wes ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
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 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 > > > > > 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: > > > > > > > > > > > > > > > > > > sig
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
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 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 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 = ; quit = ;
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
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 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 >>> 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 = ; quit = ; erase = ; kill = ; eof = >>> > ; >>> > eol = ; eol2 = ; swtch = ; start = ; stop = >>> > ; >>> > susp = ; rprnt = ; werase = ; lnext = ; >>> > discard = ; 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 maili
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
Tomas, Thanks so much for the offer. I will look at the Bitscope website to see if it would help. -Denis On Fri, Dec 29, 2017 at 3:36 PM, Tomas Kuchta wrote: > I have one of those simple Bitscope scopes/analysers for slow RPi type > interface hacking it might be the right tool for the job and it runs on > Linux. > > Would that help? Do you want to borrow it? > > Check the Bitscope website for details, but it is good enough for serial > ports. Perhaps even decoding it. > > Tomas > > On Dec 29, 2017 2:44 PM, "Denis Heidtmann" > 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 > > >> 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 = ; quit = ; erase = ; kill = ; > eof = > > >> > ; > > >> > eol = ; eol2 = ; swtch = ; start = ; > stop > > = > > >> > ; > > >> > susp = ; rprnt = ; werase = ; lnext = ; > > >> > discard = ; 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
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
I have one of those simple Bitscope scopes/analysers for slow RPi type interface hacking it might be the right tool for the job and it runs on Linux. Would that help? Do you want to borrow it? Check the Bitscope website for details, but it is good enough for serial ports. Perhaps even decoding it. Tomas On Dec 29, 2017 2:44 PM, "Denis Heidtmann" 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 > >> 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 = ; quit = ; erase = ; kill = ; eof = > >> > ; > >> > eol = ; eol2 = ; swtch = ; start = ; stop > = > >> > ; > >> > susp = ; rprnt = ; werase = ; lnext = ; > >> > discard = ; 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/plu
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
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 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 >> 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 = ; quit = ; erase = ; kill = ; eof = >> > ; >> > eol = ; eol2 = ; swtch = ; start = ; stop = >> > ; >> > susp = ; rprnt = ; werase = ; lnext = ; >> > discard = ; 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
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
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 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 > 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 = ; quit = ; erase = ; kill = ; eof = > > ; > > eol = ; eol2 = ; swtch = ; start = ; stop = > > ; > > susp = ; rprnt = ; werase = ; lnext = ; > > discard = ; 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
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
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 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 = ; quit = ; erase = ; kill = ; eof = > ; > eol = ; eol2 = ; swtch = ; start = ; stop = > ; > susp = ; rprnt = ; werase = ; lnext = ; > discard = ; 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] serial communication with dmm (was com port in guest to usb in host (virtual box))
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 = ; quit = ; erase = ; kill = ; eof = ; eol = ; eol2 = ; swtch = ; start = ; stop = ; susp = ; rprnt = ; werase = ; lnext = ; discard = ; 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
