Re: [PLUG] Serial communication with dmm

[Denis Heidtmann]

I appreciate you forwarding this to me.  However, I find most of what is
described is above my head; also it may require Windows I do not have.

I  have been distracted by another issue for a while now, but that is
solved, so I intend to get back to the DMM shortly.  The last effort I put
into it was using some of the Python code I found.  It seemed to acquire
data correctly most of the  time, except randomly the first data field was
empty, or at least equal to zero.  I hope to test for that problem and
perhaps that will be a work-around.  I will relate my progress when I  have
something definitive.

-Denis

On Tue, Mar 6, 2018 at 12:09 PM, wes  wrote:

> Today I chanced upon "USPPcap" - a utility designed to capture traffic on
> USB ports.
>
> http://desowin.org/usbpcap/tour.html
>
> It seems to me, since the Windows-based software for this thing works well,
> and you have a USB->serial adapter, this utility could potentially be used
> to monitor the traffic on a successful meter read, which could then be used
> to re-create those steps in whatever other environment you'd like to use.
>
> -wes
>
> On Sun, Jan 7, 2018 at 5:13 PM, Denis Heidtmann  >
> wrote:
>
> > The meter schematic I have shows two opto-isolators connected to the
> serial
> > pins.  The output from the meter is an emitter follower driving the RxD
> pin
> > and the emitter resistor connected to RTS.  The collector is connected to
> > DTR.  The input to the meter drives an LED in series with a 3.3K
> resistor,
> > TxD (+) to GND .  Does this explain the RTS being driven low?
> >
> > The protocol I have seen documented is:
> >
> > 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.
> > Data string format:
> >MAS-345 sends a 14 bytes string with:
> >  < >< >
> >:  two bytes with the oerating mode: DC, AC, OH, CA, TE ...
> >:  one byte with - or space
> >: five bytes with four digits and one decimal dot.
> >: four bytes with the units: mV, A, kOhm, nF ...
> >: '\r'
> >One space is inserted between  and , one between
> > and .
> > The data string (without the '\r') is sent to the output device.
> >
> > The changes I made to the code to get some results were line 116 timeout
> > changed from 0.1 to 3.0 and  commented out 129,  self.s.setTimeout(1)
> since
> > it generated an error msg. indicating serial had no such object.   These
> > changes gave me output if the meter was set at dc volts, otherwise an
> > instruction to change it to dc volts.   Later I changed line 56 to make
> > debug = True.  This gave me a listing of the what was coming from the
> meter
> > (repeatedly), matching the above listing.
> >
> > So for starters I need to get it to poll the meter no more rapidly than
> > 1/sec.  But I guess even in its wounded condition I could try to see if
> it
> > will work with the usb-serial adapter.
> >
> > -Denis
> >
> > On Sun, Jan 7, 2018 at 2:18 PM, Denis Heidtmann <
> denis.heidtm...@gmail.com
> > >
> > wrote:
> >
> > > My goal is to be able to get data from the dmm using my laptop, which
> has
> > > only USB.  I have an RS-232--USB adapter.  Eventually I want to make
> the
> > > choices more friendly.
> > >
> > > Later today I will study the details of your observations.  The
> protocol
> > I
> > > have seen described elsewhere says the host needs to send a single byte
> > > (H?) to get the dmm to send one reading.  I had to change two time
> values
> > > and remove the setTimeout line to get it to work.  At present it locks
> > the
> > > meter for some time.  I expect that is because the host is sending
> bytes
> > > too fast, causing the meter to try to respond before it is ready, a
> > > difficulty I saw referenced in another description of how to deal with
> > this
> > > meter.
> > >
> > > Thanks for looking at the code.
> > >
> > > -Denis
> > >
> > > On Sun, Jan 7, 2018 at 12:35 PM, Galen Seitz 
> > > wrote:
> > >
> > >> On 01/07/18 10:04, Denis Heidtmann 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.
> > >> >>
> > >> > 
> > >> >
> > >> > I found a python script intended to interface with the mas-345:
> > >> > https://github.com/markrages/py_test_interface
> > >> > https://github.com/markrages/py_test_interface/blob/master/
> mas345.py
> > >> >
> > >> > I gave it a try on my desktop (which has a serial port).  To get it
> to
> > >> run
> > >> > I changed a couple of parameters and commented out one that was
> > >> generating
> > >> > a no-such-parameter error.  Then I put it into debug mode so I could
> > see
> > >> > the 

Re: [PLUG] Serial communication with dmm

[wes]

Today I chanced upon "USPPcap" - a utility designed to capture traffic on
USB ports.

http://desowin.org/usbpcap/tour.html

It seems to me, since the Windows-based software for this thing works well,
and you have a USB->serial adapter, this utility could potentially be used
to monitor the traffic on a successful meter read, which could then be used
to re-create those steps in whatever other environment you'd like to use.

-wes

On Sun, Jan 7, 2018 at 5:13 PM, Denis Heidtmann 
wrote:

> The meter schematic I have shows two opto-isolators connected to the serial
> pins.  The output from the meter is an emitter follower driving the RxD pin
> and the emitter resistor connected to RTS.  The collector is connected to
> DTR.  The input to the meter drives an LED in series with a 3.3K resistor,
> TxD (+) to GND .  Does this explain the RTS being driven low?
>
> The protocol I have seen documented is:
>
> 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.
> Data string format:
>MAS-345 sends a 14 bytes string with:
>  < >< >
>:  two bytes with the oerating mode: DC, AC, OH, CA, TE ...
>:  one byte with - or space
>: five bytes with four digits and one decimal dot.
>: four bytes with the units: mV, A, kOhm, nF ...
>: '\r'
>One space is inserted between  and , one between
> and .
> The data string (without the '\r') is sent to the output device.
>
> The changes I made to the code to get some results were line 116 timeout
> changed from 0.1 to 3.0 and  commented out 129,  self.s.setTimeout(1) since
> it generated an error msg. indicating serial had no such object.   These
> changes gave me output if the meter was set at dc volts, otherwise an
> instruction to change it to dc volts.   Later I changed line 56 to make
> debug = True.  This gave me a listing of the what was coming from the meter
> (repeatedly), matching the above listing.
>
> So for starters I need to get it to poll the meter no more rapidly than
> 1/sec.  But I guess even in its wounded condition I could try to see if it
> will work with the usb-serial adapter.
>
> -Denis
>
> On Sun, Jan 7, 2018 at 2:18 PM, Denis Heidtmann  >
> wrote:
>
> > My goal is to be able to get data from the dmm using my laptop, which has
> > only USB.  I have an RS-232--USB adapter.  Eventually I want to make the
> > choices more friendly.
> >
> > Later today I will study the details of your observations.  The protocol
> I
> > have seen described elsewhere says the host needs to send a single byte
> > (H?) to get the dmm to send one reading.  I had to change two time values
> > and remove the setTimeout line to get it to work.  At present it locks
> the
> > meter for some time.  I expect that is because the host is sending bytes
> > too fast, causing the meter to try to respond before it is ready, a
> > difficulty I saw referenced in another description of how to deal with
> this
> > meter.
> >
> > Thanks for looking at the code.
> >
> > -Denis
> >
> > On Sun, Jan 7, 2018 at 12:35 PM, Galen Seitz 
> > wrote:
> >
> >> On 01/07/18 10:04, Denis Heidtmann 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.
> >> >>
> >> > 
> >> >
> >> > I found a python script intended to interface with the mas-345:
> >> > https://github.com/markrages/py_test_interface
> >> > https://github.com/markrages/py_test_interface/blob/master/mas345.py
> >> >
> >> > I gave it a try on my desktop (which has a serial port).  To get it to
> >> run
> >> > I changed a couple of parameters and commented out one that was
> >> generating
> >> > a no-such-parameter error.  Then I put it into debug mode so I could
> see
> >> > the traffic from the meter.  The good news is it appears that the
> meter
> >> > does report values as the documented protocol indicates.  How the
> >> > communication is done is buried in the "serial" Python module. Someone
> >> who
> >> > understands Python could learn from this; I cannot.
> >>
> >> I've used the python serial module a few times.  Looking at that code, I
> >> see a few things that strike me as unusual.  First is RTS is
> >> cleared(line 125).  Normally both DTR and RTS would be set during serial
> >> communication.  The second thing is that the meter apparently requires
> >> the host to send 14 null characters(line 138) in order to cause it to
> >> send its measurement data.  Finally, requiring two stop bits(line 117)
> >> is unusual.  (Note that two stop bits and seven bit data is equivalent
> >> to one stop bit and including a mark parity bit in eight bit data.)
> >>
> >> Since its 

Re: [PLUG] serial communication with dmm

[Tomas Kuchta]

Someone here, probably Wes, thought me embarrassing lesson:

http://lmgtfy.com/?q=python+crash+course

Put one/two day into learning basic python data types and syntax. It will
be worth it, I guarantee it.

T

On Jan 15, 2018 6:57 PM, "Denis Heidtmann" 
wrote:

> Well,  I have solved the issue of  "mult=self.units.strip()+'  '[0]:
> TypeError: can't concat bytes to int". It needs parentheses, which the
> original code had.  Now the code runs, but, alas, now it does not report
> the readings from the meter.  Since I really do not understand
> object-oriented python, I am at a loss.  It seems to me that this format is
> inadequate and inappropriate for schooling a coding novice on such things,
> so I will see what I help I can get in person.  Thanks for all who have had
> to suffer through this.
>
> -Denis
>
> On Sun, Jan 14, 2018 at 6:30 PM, Denis Heidtmann <
> denis.heidtm...@gmail.com>
> wrote:
>
> > Last discussion on this issue I mentioned a python program I found.  I
> > have since put the program in Spyder using Python3.  I had to make a
> number
> > of changes to accommodate the change to 3.  The latest is that I see that
> > the readings are available to the  program although parsing the data is
> > running into difficulty associated, I believe, with  Python3's fussiness
> > with bytes, strings, etc.  (The data I see is via some print statements
> > stuck in the code.)
> >
> > line 72: originally it had
> >
> > mult=self.units.strip()+'  '[0]
> > TypeError: can't concat bytes to int
> >
> > I tried:
> > mult=self.units.strip()+'  '.encode()[0]
> >
> > and
> > mult=self.units.strip()+b'  '[0]
> >
> > to no avail.
> >
> > Note:
> > data =  b'DC -0.000   V\r'
> > type data =  
> > 01234567890123456789
> > type units =  
> >
> > But the good news is that when I changed the reading on the meter the
> > value in data changed accordingly.  So I see the issue now as one of
> > knowing how to fix the Python so that it parses the data correctly,
> rather
> > than an issue of how  to communicate with the dmm.
> >
> > BTW, I  see no way to change the manufacture's sw running under Windows
> to
> > look at the usb, which is what I need to test the usb interface under
> > Windows.  I will explore the usb using Linux, which is  the ultimate
> goal.
> >
> >
> ___
> 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

[Denis Heidtmann]

Well,  I have solved the issue of  "mult=self.units.strip()+'  '[0]:
TypeError: can't concat bytes to int". It needs parentheses, which the
original code had.  Now the code runs, but, alas, now it does not report
the readings from the meter.  Since I really do not understand
object-oriented python, I am at a loss.  It seems to me that this format is
inadequate and inappropriate for schooling a coding novice on such things,
so I will see what I help I can get in person.  Thanks for all who have had
to suffer through this.

-Denis

On Sun, Jan 14, 2018 at 6:30 PM, Denis Heidtmann 
wrote:

> Last discussion on this issue I mentioned a python program I found.  I
> have since put the program in Spyder using Python3.  I had to make a number
> of changes to accommodate the change to 3.  The latest is that I see that
> the readings are available to the  program although parsing the data is
> running into difficulty associated, I believe, with  Python3's fussiness
> with bytes, strings, etc.  (The data I see is via some print statements
> stuck in the code.)
>
> line 72: originally it had
>
> mult=self.units.strip()+'  '[0]
> TypeError: can't concat bytes to int
>
> I tried:
> mult=self.units.strip()+'  '.encode()[0]
>
> and
> mult=self.units.strip()+b'  '[0]
>
> to no avail.
>
> Note:
> data =  b'DC -0.000   V\r'
> type data =  
> 01234567890123456789
> type units =  
>
> But the good news is that when I changed the reading on the meter the
> value in data changed accordingly.  So I see the issue now as one of
> knowing how to fix the Python so that it parses the data correctly, rather
> than an issue of how  to communicate with the dmm.
>
> BTW, I  see no way to change the manufacture's sw running under Windows to
> look at the usb, which is what I need to test the usb interface under
> Windows.  I will explore the usb using Linux, which is  the ultimate goal.
>
>
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

[PLUG] serial communication with dmm

[Denis Heidtmann]

Last discussion on this issue I mentioned a python program I found.  I
have since put the program in Spyder using Python3.  I had to make a number
of changes to accommodate the change to 3.  The latest is that I see that
the readings are available to the  program although parsing the data is
running into difficulty associated, I believe, with  Python3's fussiness
with bytes, strings, etc.  (The data I see is via some print statements
stuck in the code.)

line 72: originally it had

mult=self.units.strip()+'  '[0]
TypeError: can't concat bytes to int

I tried:
mult=self.units.strip()+'  '.encode()[0]

and
mult=self.units.strip()+b'  '[0]

to no avail.

Note:
data =  b'DC -0.000   V\r'
type data =  
01234567890123456789
type units =  

But the good news is that when I changed the reading on the meter the value
in data changed accordingly.  So I see the issue now as one of knowing how
to fix the Python so that it parses the data correctly, rather than an
issue of how  to communicate with the dmm.

BTW, I  see no way to change the manufacture's sw running under Windows to
look at the usb, which is what I need to test the usb interface under
Windows.  I will explore the usb using Linux, which is  the ultimate goal.

Full program as it stands (sorry I do not have line #'s)

#!/usr/bin/python

import serial, time, os

modes=['DC V','AC V','DC uA','DC mA','DC A',
   'AC uA','AC mA','AC A','OHM','CAP',
   'Hz','Net Hz','Amp Hz','Duty','Net Duty',
   'Amp Duty','Width','Net Width','Amp Width','Diode',
   'Continuity','hFE','Logic','dBm','EF','Temperature']

segs={ 0x00: ' ',
   0x20: '-',
   0xd7: '0',
   0x50: '1',
   0xb5: '2',
   0xf1: '3',
   0x72: '4',
   0xe3: '5',
   0xe7: '6',
   0x51: '7',
   0xf7: '8',
   0xf3: '9',
   0x87: 'C',
   0xa7: 'E',
   0x27: 'F',
   0x86: 'L',
   0x66: 'h',
   0x64: 'n',
   0x37: 'P',
   0x24: 'r',
   0xa6: 't'}

byte1=['Hz','Ohms','K','M','F','A','V','m']
byte2=['u','n','dBm','S','%','hFE','REL','MIN']
byte7=['Beep','Diode','Bat','Hold','-','~','RS232','Auto']

decimal=0x08

class ChecksumError(Exception): pass
class LengthError(Exception): pass
class TimeoutError(Exception): pass

import sys

infinity=9e # and beyond!

class Packet:
def __init__(self):
self.string=''
self.unit=''
self.value=None
self.mode=None
self.packet_len=14

def load_data(self,data):
debug=True
# DC -0.000   V
# 01234567890123
if debug:
print("data = ",data)
print("type data = ",type(data))
print("0123456789"*2)

if len(data) != 14:
raise LengthError

self.mode =data[0:2]
self.sign =data[3]
self.value=data[4:9]
self.units=data[9:14].strip()
print("type units = ",type(self.units))
mult=self.units.strip()+' '[0]
print("mult = ",mult)
if not mult in "MKmunp":  mult=' '

if debug:
print("mode",self.mode)
print("sign",self.sign)
print("value",self.value)
print("units",self.units)
print("mult",mult)

if data[2]!=' ' or data[13] != '\r':
raise ChecksumError


if 'O' in self.value and 'L' in self.value:
self.value=infinity
else:
self.value=float(self.value) * {'M':1e6,
'K':1e3,
' ':1,
'm':1e-3,
'u':1e-6,
'n':1e-9,
'p':1e-12}[mult]


if self.sign=='-':
self.value=-self.value

self.string=data

def __repr__(self):
return "%s %s"%(self.string,self.unit) #self.value)

def __nonzero__(self):
return None!=self.mode

class MasMeter:
def __init__(self, port='/dev/ttyPROLIFIC'):

if not os.path.lexists(port):
port = '/dev/ttyS0'

self.s=serial.Serial(port=port, timeout=3.0,
 baudrate=600, stopbits=2,
 bytesize=serial.SEVENBITS)
try:
self.s.setDTR()
except:
print("Could not set DTR")

try:
self.s.setRTS(0)
except:
print("Could not clear RTS")

#   self.s.setTimeout(1)
self.packet_len=14
self.packet=None

def flush(self):
self.s.flushInput()

def try_for_packet(self):
""" May return a None packet"""
self.s.write(b'\0'*14)

d=self.s.read(self.packet_len)
print("type d = ",type(d))

if len(d)==0: raise TimeoutError("is meter turned on?")

if len(d)<14: return False

#if len(d): print("read %d bytes"%len(d))

p=Packet()

Re: [PLUG] Serial communication with dmm

[Russell Senior]

Do you mean you are seeing data values from the DMM? If so, does the same
software work with the USB-serial cable? You might need to modify the code
to use /dev/ttyUSB0 instead of /dev/ttyS0.

On Jan 7, 2018 10:04 AM, "Denis Heidtmann" 
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.
>


I found a python script intended to interface with the mas-345:
https://github.com/markrages/py_test_interface
https://github.com/markrages/py_test_interface/blob/master/mas345.py

I gave it a try on my desktop (which has a serial port).  To get it to run
I changed a couple of parameters and commented out one that was generating
a no-such-parameter error.  Then I put it into debug mode so I could see
the traffic from the meter.  The good news is it appears that the meter
does report values as the documented protocol indicates.  How the
communication is done is buried in the "serial" Python module. Someone who
understands Python could learn from this; I cannot.

-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

Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))

[wes]

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))

[Denis Heidtmann]

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 

Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))

[Tomas Kuchta]

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
> >> > 

Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))

[Denis Heidtmann]

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))

[Denis Heidtmann]

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))

[Russell Senior]

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))

[Denis Heidtmann]

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