Serin / serout
Archiver
Posts: 46,084
I'm using the BS2 interfaced to my PC on an Activity Board. Every
time I tx a message to my Stamp, I get the message echoed back to me.
I wanted to know why, so I started poking around. I looked up the
schematic of the BS2 and found a 4.7k ohm resistor on the BS2 between
pins 1 and 2. I've concluded that the signal bleeds through
regardless of the BS2 being powered. What is the purpose of having
this resistor between pins 1 and 2? Can I just remove the resistor
between these 2 pins?
ed
time I tx a message to my Stamp, I get the message echoed back to me.
I wanted to know why, so I started poking around. I looked up the
schematic of the BS2 and found a 4.7k ohm resistor on the BS2 between
pins 1 and 2. I've concluded that the signal bleeds through
regardless of the BS2 being powered. What is the purpose of having
this resistor between pins 1 and 2? Can I just remove the resistor
between these 2 pins?
ed
Comments
apps, your program simply needs to filter everything it sends as an echo.
Seems tedious, but it's really not a problem.
The echo can, in fact, be used to let your app know that you're connected.
-- Jon Williams
-- Parallax
In a message dated 3/31/2003 5:34:58 PM Central Standard Time,
edsandoval@h... writes:
> I'm using the BS2 interfaced to my PC on an Activity Board. Every
> time I tx a message to my Stamp, I get the message echoed back to me.
> I wanted to know why, so I started poking around. I looked up the
> schematic of the BS2 and found a 4.7k ohm resistor on the BS2 between
> pins 1 and 2. I've concluded that the signal bleeds through
> regardless of the BS2 being powered. What is the purpose of having
> this resistor between pins 1 and 2? Can I just remove the resistor
> between these 2 pins?
>
> ed
[noparse][[/noparse]Non-text portions of this message have been removed]
I'm running into the same problem. I'm using minicom in Linux and
trying to get the Stamp2 to communicate with an existing controller on
the other end. The protocol is already established by the existing
controller. Every time the controller sends a two char request it
gets echoed back, screwing things up. I have to make a device that is
compatible with this controller. Is there a way to avoid the echo?
Is this only a problem on the SOUT pin? I thought it a good idea to
use SOUT as I could reprogram the Stamp and use it as the standard
comm port.
Thanks. I've been beating on this for a while.
Greg
--- In basicstamps@yahoogroups.com, jonwms@a... wrote:
> The circuitry is a pseudo-invertor. Don't change it. When writing
serial
> apps, your program simply needs to filter everything it sends as an
echo.
> Seems tedious, but it's really not a problem.
>
> The echo can, in fact, be used to let your app know that you're
connected.
>
> -- Jon Williams
> -- Parallax
>
> In a message dated 3/31/2003 5:34:58 PM Central Standard Time,
> edsandoval@h... writes:
>
> > I'm using the BS2 interfaced to my PC on an Activity Board. Every
> > time I tx a message to my Stamp, I get the message echoed back to
me.
> > I wanted to know why, so I started poking around. I looked up the
> > schematic of the BS2 and found a 4.7k ohm resistor on the BS2
between
> > pins 1 and 2. I've concluded that the signal bleeds through
> > regardless of the BS2 being powered. What is the purpose of
having
> > this resistor between pins 1 and 2? Can I just remove the
resistor
> > between these 2 pins?
> >
> > ed
>
>
>
> [noparse][[/noparse]Non-text portions of this message have been removed]
connections to two Stamp pins (four if you want to have flow control). You
can use a MAX232 or similar device to get true RS-232 levels.
-- Jon Williams
-- Parallax
In a message dated 5/2/2003 3:28:05 PM Central Standard Time,
greg@l... writes:
> Jon,
> I'm running into the same problem. I'm using minicom in Linux and
> trying to get the Stamp2 to communicate with an existing controller on
> the other end. The protocol is already established by the existing
> controller. Every time the controller sends a two char request it
> gets echoed back, screwing things up. I have to make a device that is
> compatible with this controller. Is there a way to avoid the echo?
> Is this only a problem on the SOUT pin? I thought it a good idea to
> use SOUT as I could reprogram the Stamp and use it as the standard
> comm port.
> Thanks. I've been beating on this for a while.
> Greg
[noparse][[/noparse]Non-text portions of this message have been removed]
(electronically) at TTL levels so I shouldn't need to add the driver
chip. I guess I'll have two DB9's for the prototyping stage.
Greg
--- In basicstamps@yahoogroups.com, jonwms@a... wrote:
> If you can't modify the other end, then you'll need to move your serial
> connections to two Stamp pins (four if you want to have flow
control). You
> can use a MAX232 or similar device to get true RS-232 levels.
>
> -- Jon Williams
> -- Parallax
>
>
> In a message dated 5/2/2003 3:28:05 PM Central Standard Time,
> greg@l... writes:
>
> > Jon,
> > I'm running into the same problem. I'm using minicom in Linux and
> > trying to get the Stamp2 to communicate with an existing controller on
> > the other end. The protocol is already established by the existing
> > controller. Every time the controller sends a two char request it
> > gets echoed back, screwing things up. I have to make a device that is
> > compatible with this controller. Is there a way to avoid the echo?
> > Is this only a problem on the SOUT pin? I thought it a good idea to
> > use SOUT as I could reprogram the Stamp and use it as the standard
> > comm port.
> > Thanks. I've been beating on this for a while.
> > Greg
>
>
>
> [noparse][[/noparse]Non-text portions of this message have been removed]
RS-I that shits levels. I, too, have had successful projects with TTL, but
you may ultimately not want to take a chance and decide to install a level
shifter. Al's board will plug into a breadboard, provides a DB-9 and allows
to do TX and RX with flow control if you want it.
-- Jon Williams
-- Parallax
In a message dated 5/2/2003 5:49:27 PM Central Standard Time,
greg@l... writes:
> Thanks Jon, I'll give it a try. It's working fine now
> (electronically) at TTL levels so I shouldn't need to add the driver
> chip. I guess I'll have two DB9's for the prototyping stage.
> Greg
[noparse][[/noparse]Non-text portions of this message have been removed]
writes:
> Al Williams (no relation)
I disagree. Both of you are very smart!!!!!!!!!!!!
[noparse][[/noparse]Non-text portions of this message have been removed]