Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
RealTerm Spy Mode
2,767 views
Skip to first unread message
rickman
Jul 10, 2012, 7:44:10 PM7/10/12
to
I've been using RealTerm for comms work and I would like to use the
spy mode to "see" the traffic between my program and the serial device
I am controlling. But I don't know if this will actually be any
better than the method I am using now where the program echos the
serial data to RealTerm in telnet mode as a terminal.
Mainly I am wondering where the spy attaches. If it is right in the
comm port driver then it might be useful. But if it just connects at
the same point the program does, it won't be likely to give me much
info. The problem I'm seeing is missing or delayed data and I'm
pretty confident the program is not the culprit. I think it is either
the driver being distracted by Windoze or possibly the device being
controlled.
I should probably rig up a cable to use two serial ports and monitor
the hardware, but I doubt I will be able to get that done before I
need to have this problem resolved. Are there cables out there to
split one DB-9 out to two DB-9s for this type of debugging? I guess I
should check eBay. They seem to have everything these days.
Rick
spy mode to "see" the traffic between my program and the serial device
I am controlling. But I don't know if this will actually be any
better than the method I am using now where the program echos the
serial data to RealTerm in telnet mode as a terminal.
Mainly I am wondering where the spy attaches. If it is right in the
comm port driver then it might be useful. But if it just connects at
the same point the program does, it won't be likely to give me much
info. The problem I'm seeing is missing or delayed data and I'm
pretty confident the program is not the culprit. I think it is either
the driver being distracted by Windoze or possibly the device being
controlled.
I should probably rig up a cable to use two serial ports and monitor
the hardware, but I doubt I will be able to get that done before I
need to have this problem resolved. Are there cables out there to
split one DB-9 out to two DB-9s for this type of debugging? I guess I
should check eBay. They seem to have everything these days.
Rick
Meindert Sprang
Jul 11, 2012, 3:55:54 AM7/11/12
to
"rickman" <gnu...@gmail.com> wrote in message
news:30b10707-53a1-47ec...@l32g2000yqc.googlegroups.com...
>But if it just connects at
> the same point the program does, it won't be likely to give me much
> info.
That would be impossible because your program opens a com port. RealTerm
cannot open that same com port at the same time. Therefore this only works
when RealTerm "attaches" at some point in the driver. In fact, it installs a
special driver to do this.
Meindert
news:30b10707-53a1-47ec...@l32g2000yqc.googlegroups.com...
> I've been using RealTerm for comms work and I would like to use the
> spy mode to "see" the traffic between my program and the serial device
> I am controlling. But I don't know if this will actually be any
> better than the method I am using now where the program echos the
> serial data to RealTerm in telnet mode as a terminal.
>
> Mainly I am wondering where the spy attaches. If it is right in the
> comm port driver then it might be useful.
Yes it does.
> spy mode to "see" the traffic between my program and the serial device
> I am controlling. But I don't know if this will actually be any
> better than the method I am using now where the program echos the
> serial data to RealTerm in telnet mode as a terminal.
>
> Mainly I am wondering where the spy attaches. If it is right in the
> comm port driver then it might be useful.
>But if it just connects at
> the same point the program does, it won't be likely to give me much
> info.
cannot open that same com port at the same time. Therefore this only works
when RealTerm "attaches" at some point in the driver. In fact, it installs a
special driver to do this.
Meindert
Andy Sinclair
Jul 11, 2012, 4:25:55 AM7/11/12
to
Hello.
For this sort of troubleshooting on Windows I use:
http://www.serial-port-monitor.com/free-serial-port-monitor-product-details.html
Andy
For this sort of troubleshooting on Windows I use:
http://www.serial-port-monitor.com/free-serial-port-monitor-product-details.html
Andy
rickman
Jul 11, 2012, 4:00:48 PM7/11/12
to
On Jul 11, 4:25 am, Andy Sinclair <a...@invalid.invalid> wrote:
> Hello.
>
> For this sort of troubleshooting on Windows I use:http://www.serial-port-monitor.com/free-serial-port-monitor-product-d...
> Hello.
>
>
> Andy
>
> On 11/07/12 00:44, rickman wrote:
>
>
>
>
>
>
>
> > I've been using RealTerm for comms work and I would like to use the
> > spy mode to "see" the traffic between my program and the serial device
> > I am controlling. But I don't know if this will actually be any
> > better than the method I am using now where the program echos the
> > serial data to RealTerm in telnet mode as a terminal.
>
> > Mainly I am wondering where the spy attaches. If it is right in the
> > comm port driver then it might be useful. But if it just connects at
> > the same point the program does, it won't be likely to give me much
> > info. The problem I'm seeing is missing or delayed data and I'm
> > pretty confident the program is not the culprit. I think it is either
> > the driver being distracted by Windoze or possibly the device being
> > controlled.
>
> > I should probably rig up a cable to use two serial ports and monitor
> > the hardware, but I doubt I will be able to get that done before I
> > need to have this problem resolved. Are there cables out there to
> > split one DB-9 out to two DB-9s for this type of debugging? I guess I
> > should check eBay. They seem to have everything these days.
>
> > Rick
Thanks Andy. They don't do a good job of letting you know the
> Andy
>
> On 11/07/12 00:44, rickman wrote:
>
>
>
>
>
>
>
> > I've been using RealTerm for comms work and I would like to use the
> > spy mode to "see" the traffic between my program and the serial device
> > I am controlling. But I don't know if this will actually be any
> > better than the method I am using now where the program echos the
> > serial data to RealTerm in telnet mode as a terminal.
>
> > Mainly I am wondering where the spy attaches. If it is right in the
> > comm port driver then it might be useful. But if it just connects at
> > the same point the program does, it won't be likely to give me much
> > info. The problem I'm seeing is missing or delayed data and I'm
> > pretty confident the program is not the culprit. I think it is either
> > the driver being distracted by Windoze or possibly the device being
> > controlled.
>
> > I should probably rig up a cable to use two serial ports and monitor
> > the hardware, but I doubt I will be able to get that done before I
> > need to have this problem resolved. Are there cables out there to
> > split one DB-9 out to two DB-9s for this type of debugging? I guess I
> > should check eBay. They seem to have everything these days.
>
> > Rick
differences between the free version and the multiple paid versions.
One thing I notice is that the free version doesn't support anything
past WinXP (no Vista or 7) and the paid version don't support 2000!
I'll give it a try.
Rick
peter_g...@supergreatmail.com
Jul 11, 2012, 5:34:39 PM7/11/12
to
http://technet.microsoft.com/en-us/sysinternals/bb896644
It's free and it works well.
Rich Webb
Jul 11, 2012, 9:17:00 PM7/11/12
to
On Wed, 11 Jul 2012 13:00:48 -0700 (PDT), rickman <gnu...@gmail.com>
wrote:
>Thanks Andy. They don't do a good job of letting you know the
>differences between the free version and the multiple paid versions.
>One thing I notice is that the free version doesn't support anything
>past WinXP (no Vista or 7) and the paid version don't support 2000!
Not so. I'm running RealTerm 2.0.0.70 (free version) under Win7 64-bit.
Works fine. Check the download page at Sourceforge.
--
Rich Webb Norfolk, VA
wrote:
>Thanks Andy. They don't do a good job of letting you know the
>differences between the free version and the multiple paid versions.
>One thing I notice is that the free version doesn't support anything
>past WinXP (no Vista or 7) and the paid version don't support 2000!
Works fine. Check the download page at Sourceforge.
--
Rich Webb Norfolk, VA
rickman
Jul 12, 2012, 9:44:50 AM7/12/12
to
FreeSerialPortMonitor. It seems to run under Vista 32 bit, but I just
got an email saying the "x64" [sic] 64 bit systems are not supported
"for sure". He seems to be using "supported" instead of "works" as he
says "supported but not tested". I find it a bit odd, they have the
free version, but list it separately from the paid versions. I can't
find any way to compare features except I suppose it has no more than
the "lite" version. The free version is only stated to run under XP,
2000 and NT and the paid versions don't support anything before XP.
Maybe the "free" version is a discontinued line and they isn't really
the same software. Very odd, but it worked and I got some insight
into the problem.
I saw a failure where the response was abnormal while the message out
was as expected. Analyzing the error I can see a character was
dropped between the PC and the tester. So either the driver is
dropping characters or the tester is dropping them. Now I need to
monitor the serial line... another search project.
The display on FSPM is not exactly what I would like, way too much
white space, but it does the job. It is also rather slow. I echo all
data from the app to a telnet terminal and it streams in real time.
FSPM meanwhile keeps scrolling and scrolling for many seconds after
the burst is done.
I also tried the Microsoft monitor and it has a poor display. The
data is all there, but hard to see what is happening. It is more for
debugging the PC internal software than the app or external device.
Rick
Rich Webb
Jul 12, 2012, 9:58:42 AM7/12/12
to
On Thu, 12 Jul 2012 06:44:50 -0700 (PDT), rickman <gnu...@gmail.com>
[snippety snip]
capture buffer would work too, but AFAIK the ones that can "interpret"
async serial streams are rather pricey.
Much depends on what you need to see in the serial streams, of course,
but I've found a LA very handy for checking issues like the effects of
FIFO sizes, how quickly (and whether) a response show up after receiving
a particular packet, and so forth.
wrote:
>On Jul 11, 9:17 pm, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
>> On Wed, 11 Jul 2012 13:00:48 -0700 (PDT), rickman <gnu...@gmail.com>
>> wrote:
>>
>> >Thanks Andy. They don't do a good job of letting you know the
>> >differences between the free version and the multiple paid versions.
>> >One thing I notice is that the free version doesn't support anything
>> >past WinXP (no Vista or 7) and the paid version don't support 2000!
>>
>> Not so. I'm running RealTerm 2.0.0.70 (free version) under Win7 64-bit.
>> Works fine. Check the download page at Sourceforge.
>>
>> --
>> Rich Webb Norfolk, VA
>
>I'm not talking about RealTerm. I'm talking about
>FreeSerialPortMonitor.
Whoops. My bad.
>On Jul 11, 9:17 pm, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
>> On Wed, 11 Jul 2012 13:00:48 -0700 (PDT), rickman <gnu...@gmail.com>
>> wrote:
>>
>> >Thanks Andy. They don't do a good job of letting you know the
>> >differences between the free version and the multiple paid versions.
>> >One thing I notice is that the free version doesn't support anything
>> >past WinXP (no Vista or 7) and the paid version don't support 2000!
>>
>> Not so. I'm running RealTerm 2.0.0.70 (free version) under Win7 64-bit.
>> Works fine. Check the download page at Sourceforge.
>>
>> --
>> Rich Webb Norfolk, VA
>
>I'm not talking about RealTerm. I'm talking about
>FreeSerialPortMonitor.
[snippety snip]
>I also tried the Microsoft monitor and it has a poor display. The
>data is all there, but hard to see what is happening. It is more for
>debugging the PC internal software than the app or external device.
Do you have access to a logic analyzer? A digital 'scope with a long
>data is all there, but hard to see what is happening. It is more for
>debugging the PC internal software than the app or external device.
capture buffer would work too, but AFAIK the ones that can "interpret"
async serial streams are rather pricey.
Much depends on what you need to see in the serial streams, of course,
but I've found a LA very handy for checking issues like the effects of
FIFO sizes, how quickly (and whether) a response show up after receiving
a particular packet, and so forth.
Grant Edwards
Jul 12, 2012, 10:47:17 AM7/12/12
to
On 2012-07-12, Rich Webb <bbe...@mapson.nozirev.ten> wrote:
> Do you have access to a logic analyzer? A digital 'scope with a long
> capture buffer would work too, but AFAIK the ones that can
> "interpret" async serial streams are rather pricey.
If you do a lot of serial stuff and can spend a few hundred dollars, I
> Do you have access to a logic analyzer? A digital 'scope with a long
> capture buffer would work too, but AFAIK the ones that can
> "interpret" async serial streams are rather pricey.
can highly recommend this:
https://iftools.com/analyzer/msb-rs232/index.en.php
It records the actual (binary) waveform with a timestamp for each
transition. Of course you can also tell it baud/parity/stop and it
will show you the bytestreams (with timestamps for each byte).
Software for both Linux and Windows. I do all my development on Linux,
so that was a nice bonus.
It let me figure out a very tricky problem cause by a bit of customer
gear switching baud rate on-the-fly while using Xon/Xoff flow control:
they sent an Xoff, changed baud rate, and then sent an Xon.
There are cheaper "dongles" that try to do the same thing, but they
use off-the-shelf UARTs to decode the two data streams (rx/tx), so
you can't troubleshoot low-level stuff (baud rate drift, stop bits
missing, glitches, breaks, etc.).
--
Grant Edwards grant.b.edwards Yow! It's the RINSE CYCLE!!
at They've ALL IGNORED the
gmail.com RINSE CYCLE!!
rickman
Jul 12, 2012, 12:33:21 PM7/12/12
to
On Jul 12, 10:47 am, Grant Edwards <inva...@invalid.invalid> wrote:
a serial protocol analyzer so I'm not inclined to spend a lot on
something like this. Thanks for the tip.
BTW, can you point me to one of the "cheaper" dongles? I didn't find
anything on eBay. I'd like to see what is out there.
Rick
> On 2012-07-12, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
>
> > Do you have access to a logic analyzer? A digital 'scope with a long
> > capture buffer would work too, but AFAIK the ones that can
> > "interpret" async serial streams are rather pricey.
>
> If you do a lot of serial stuff and can spend a few hundred dollars, I
> can highly recommend this:
>
> https://iftools.com/analyzer/msb-rs232/index.en.php
>
> It records the actual (binary) waveform with a timestamp for each
> transition. Of course you can also tell it baud/parity/stop and it
> will show you the bytestreams (with timestamps for each byte).
>
> Software for both Linux and Windows. I do all my development on Linux,
> so that was a nice bonus.
>
> It let me figure out a very tricky problem cause by a bit of customer
> gear switching baud rate on-the-fly while using Xon/Xoff flow control:
> they sent an Xoff, changed baud rate, and then sent an Xon.
>
> There are cheaper "dongles" that try to do the same thing, but they
> use off-the-shelf UARTs to decode the two data streams (rx/tx), so
> you can't troubleshoot low-level stuff (baud rate drift, stop bits
> missing, glitches, breaks, etc.).
When all is said and done, I expect to have a device that can serve as
>
> > Do you have access to a logic analyzer? A digital 'scope with a long
> > capture buffer would work too, but AFAIK the ones that can
> > "interpret" async serial streams are rather pricey.
>
> If you do a lot of serial stuff and can spend a few hundred dollars, I
> can highly recommend this:
>
> https://iftools.com/analyzer/msb-rs232/index.en.php
>
> It records the actual (binary) waveform with a timestamp for each
> transition. Of course you can also tell it baud/parity/stop and it
> will show you the bytestreams (with timestamps for each byte).
>
> Software for both Linux and Windows. I do all my development on Linux,
> so that was a nice bonus.
>
> It let me figure out a very tricky problem cause by a bit of customer
> gear switching baud rate on-the-fly while using Xon/Xoff flow control:
> they sent an Xoff, changed baud rate, and then sent an Xon.
>
> There are cheaper "dongles" that try to do the same thing, but they
> use off-the-shelf UARTs to decode the two data streams (rx/tx), so
> you can't troubleshoot low-level stuff (baud rate drift, stop bits
> missing, glitches, breaks, etc.).
a serial protocol analyzer so I'm not inclined to spend a lot on
something like this. Thanks for the tip.
BTW, can you point me to one of the "cheaper" dongles? I didn't find
anything on eBay. I'd like to see what is out there.
Rick
rickman
Jul 12, 2012, 12:31:02 PM7/12/12
to
I have a logic analyzer, but it wasn't where I was. It also is a very
old unit, and I mean *old*! It only has a 4k buffer I believe. Still
it would have been useful just to see the relative timing of the data
in the two directions. The first problem made me think something was
getting overlapped. That problem is gone and now I am trying to
figure out who is dropping characters. A second serial port
monitoring the bad channel should do the trick. If needed, I can rig
up the special cable with two monitor serial ports and use RealTerm in
monitor mode to show the two directions in an interleaved display.
Rick
0 new messages