Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #220956 > unrolled thread

Re: Serial Port Issues

Back to article view | Back to linux.debian.user

Contents

  Re: Serial Port Issues Chris Rhodin <cprhodin@gmail.com> - 2020-04-06 07:30 +0200
    Re: Serial Port Issues deloptes <deloptes@gmail.com> - 2020-04-06 09:00 +0200
      Re: Serial Port Issues Joe <joe@jretrading.com> - 2020-04-06 09:40 +0200
        Re: Serial Port Issues <tomas@tuxteam.de> - 2020-04-06 10:00 +0200
          Re: Serial Port Issues deloptes <deloptes@gmail.com> - 2020-04-06 10:10 +0200
          Re: Serial Port Issues rhkramer@gmail.com - 2020-04-06 16:00 +0200
            Re: Serial Port Issues <tomas@tuxteam.de> - 2020-04-06 16:10 +0200
              Fwd: Serial Port Issues Chris Rhodin <cprhodin@gmail.com> - 2020-04-07 08:00 +0200
                Re: Fwd: Serial Port Issues deloptes <deloptes@gmail.com> - 2020-04-07 08:50 +0200
                  Re: Fwd: Serial Port Issues "Martin McCormick" <martin.m@suddenlink.net> - 2020-04-07 15:30 +0200
                    Re: Serial Port Issues Joe <joe@jretrading.com> - 2020-04-07 18:50 +0200
                Re: Serial Port Issues Chris Rhodin <cprhodin@gmail.com> - 2020-04-07 09:00 +0200
                  Re: Serial Port Issues <tomas@tuxteam.de> - 2020-04-07 09:10 +0200
                  Re: Serial Port Issues Chris Rhodin <cprhodin@gmail.com> - 2020-04-07 09:10 +0200
                  Re: Serial Port Issues songbird <songbird@anthive.com> - 2020-04-08 13:50 +0200
                Re: Serial Port Issues Joe <joe@jretrading.com> - 2020-04-07 09:30 +0200
        Re: Serial Port Issues Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-06 14:40 +0200
          Re: Serial Port Issues Joe <joe@jretrading.com> - 2020-04-06 15:30 +0200

#220956 — Re: Serial Port Issues

[Multipart message — attachments visible in raw view] — view raw

tomas@tuxteam.de wrote:

> Permissions? (they would have to be a bit funny, write but not read,
> but hey, it'd be possible).

I checked the permissions and group memberships but they're already
correct.  I also tried executing at root privilege, no luck.

Chris

[toc] | [next] | [standalone]

#220959

Chris Rhodin wrote:

> I checked the permissions and group memberships but they're already
> correct.  I also tried executing at root privilege, no luck.

'R you sure about the baud rate (9600)? It might be something higher ...
also did you setup agetty accordingly? 

[toc] | [prev] | [next] | [standalone]

#220962

On Mon, 06 Apr 2020 08:53:05 +0200
deloptes <deloptes@gmail.com> wrote:

> Chris Rhodin wrote:
> 
> > I checked the permissions and group memberships but they're already
> > correct.  I also tried executing at root privilege, no luck.  
> 
> 'R you sure about the baud rate (9600)? It might be something higher
> ... also did you setup agetty accordingly? 
> 
>

I doubt it's that. 9600 is a sort of default these days, and a serial
port which could not use it would be of limited use. The XBee radio
modules, for example, come from the factory running at 9600, though of
course they will go much higher. But the configuration utility must run
at 9600 to begin with.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#220964

[Multipart message — attachments visible in raw view] — view raw

On Mon, Apr 06, 2020 at 08:38:58AM +0100, Joe wrote:
> On Mon, 06 Apr 2020 08:53:05 +0200
> deloptes <deloptes@gmail.com> wrote:
> 
> > Chris Rhodin wrote:
> > 
> > > I checked the permissions and group memberships but they're already
> > > correct.  I also tried executing at root privilege, no luck.  
> > 
> > 'R you sure about the baud rate (9600)? It might be something higher
> > ... also did you setup agetty accordingly? 

What has agetty to do with not being able to access a port?

> I doubt it's that. 9600 is a sort of default these days, and a serial
> port which could not use it would be of limited use. The XBee radio
> modules, for example, come from the factory running at 9600, though of
> course they will go much higher. But the configuration utility must run
> at 9600 to begin with.

Besides, the wrong baud rate wouldn't preclude a program from *reading*
from a serial interface. It would just get garbage, that's all.

Besides, a wrong baud rate would much less explain that writing is
possible, but reading isn't. Not for classical "serials" (i.e. RS-232).

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#220967

tomas@tuxteam.de wrote:

> What has agetty to do with not being able to access a port?
> 
>> I doubt it's that. 9600 is a sort of default these days, and a serial
>> port which could not use it would be of limited use. The XBee radio
>> modules, for example, come from the factory running at 9600, though of
>> course they will go much higher. But the configuration utility must run
>> at 9600 to begin with.
> 
> Besides, the wrong baud rate wouldn't preclude a program from *reading*
> from a serial interface. It would just get garbage, that's all.
> 
> Besides, a wrong baud rate would much less explain that writing is
> possible, but reading isn't. Not for classical "serials" (i.e. RS-232).

Well, I must admit you are right (once again). I don't agree with Joes
statement that 9600 is default. 

I just now have a memory enlight. I was also not able to write on the RPIs
UART port until I disabled the hardware flow control. Found out that for
the UART it doesn't matter if soft/hard is enabled or not.

[   | F - Hardware Flow Control : No
[   | G - Software Flow Control : No

it is worth checking

[toc] | [prev] | [next] | [standalone]

#221001

On Monday, April 06, 2020 03:50:59 AM tomas@tuxteam.de wrote:
> Besides, a wrong baud rate would much less explain that writing is
> possible, but reading isn't. Not for classical "serials" (i.e. RS-232).

From the OP: " On this system a serial port can only receive data and not 
transmit."

Wouldn't that mean that (from the perspective of a program running on the OP's 
computer) that the serial port can read but not write?

[toc] | [prev] | [next] | [standalone]

#221002

[Multipart message — attachments visible in raw view] — view raw

On Mon, Apr 06, 2020 at 09:51:15AM -0400, rhkramer@gmail.com wrote:
> On Monday, April 06, 2020 03:50:59 AM tomas@tuxteam.de wrote:
> > Besides, a wrong baud rate would much less explain that writing is
> > possible, but reading isn't. Not for classical "serials" (i.e. RS-232).
> 
> From the OP: " On this system a serial port can only receive data and not 
> transmit."
> 
> Wouldn't that mean that (from the perspective of a program running on the OP's 
> computer) that the serial port can read but not write?

My recollection is the other way around: write but not read.
But hey, I'm old and that.

That (and the fact that another serial over USB showed the same
symptoms) prompted me to (reluctantly) hint at permissions [1],
since, to my knowledge, a honest serial port cannot be configured
to different send and receive speeds. But this seems to be ruled
out.

Another possibility is, of course, the cable :-)

Do we know in which way the port fails to read/write or whatever
it fails at? Error messages?

Cheers
[1] this could be explained by a broken udev script setting
   the wrong permissions -- that would, e.g. cover the USB
   adapter case. It was such a nice model :-)
-- t

[toc] | [prev] | [next] | [standalone]

#221041

[Multipart message — attachments visible in raw view] — view raw

---------- Forwarded message ---------
From: Chris Rhodin <cprhodin@gmail.com>
Date: Mon, Apr 6, 2020 at 7:28 PM
Subject: Re: Serial Port Issues
To: <tomas@tuxteam.de>


I have two devices I'm trying to connect to, a UPS and a network switch.
By default the UPS runs at 2400 baud and the switch runs at 9600 baud.
Before connecting them to the server I verified the devices were working on
a laptop running Debian.  When I attached them to the server and powered
them up (with minicom already running) I saw the expected startup messages
being output by both devices (this is why I say I can receive serial
data).  I then started typing commands and but got no response.

I started debugging.  I tried other cables, I tried USB to serial cables, I
reattached the devices to the laptop to verify they hadn't spontaneously
and simultaneously stopped working.  Next I simplified my test setup.  I
made a loop back cable that connects Tx to Rx.  I tested this cable on the
laptop and verified it echoed everything I typed.  On the server no echo.

Based on responses here I've verified the permissions and tried running as
root.  I've also checked the flow control as reported by minicom.

Q: Is "stty" the right command line tool to check all of a serial ports
settings?

And finally, last night I burned a Debian live DVD and booted the server
with it.  After installing the proprietary network drivers and minicom I
tried the serial ports again with the same results.

Tonight I'll look at the serial port ioctls and see if I can spot a
difference there.  I also try enabling flow control and fiddling with the
signals to see if that unstops it.

ChrisR






















































































....0

On Mon, Apr 6, 2020 at 7:08 AM <tomas@tuxteam.de> wrote:

> On Mon, Apr 06, 2020 at 09:51:15AM -0400, rhkramer@gmail.com wrote:
> > On Monday, April 06, 2020 03:50:59 AM tomas@tuxteam.de wrote:
> > > Besides, a wrong baud rate would much less explain that writing is
> > > possible, but reading isn't. Not for classical "serials" (i.e. RS-232).
> >
> > From the OP: " On this system a serial port can only receive data and
> not
> > transmit."
> >
> > Wouldn't that mean that (from the perspective of a program running on
> the OP's
> > computer) that the serial port can read but not write?
>
> My recollection is the other way around: write but not read.
> But hey, I'm old and that.
>
> That (and the fact that another serial over USB showed the same
> symptoms) prompted me to (reluctantly) hint at permissions [1],
> since, to my knowledge, a honest serial port cannot be configured
> to different send and receive speeds. But this seems to be ruled
> out.
>
> Another possibility is, of course, the cable :-)
>
> Do we know in which way the port fails to read/write or whatever
> it fails at? Error messages?
>
> Cheers
> [1] this could be explained by a broken udev script setting
>    the wrong permissions -- that would, e.g. cover the USB
>    adapter case. It was such a nice model :-)
> -- t
>

[toc] | [prev] | [next] | [standalone]

#221042

Chris Rhodin wrote:

> Tonight I'll look at the serial port ioctls and see if I can spot a
> difference there.  I also try enabling flow control and fiddling with the
> signals to see if that unstops it.

Are you sure that this is enabled in the BIOS, also some serial ports like
HP have special connectors and layouts.
Best would be to look at the manual first.

I have attached a USB to the server. From there I can log in to the
firewall. I can not use the same port in the opposite direction.

However it is strange that you do get the connection only in one direction.
It could be some kind of special connector

Otherwise I used those to enable the service

https://wiki.debian.org/systemd#Virtual_and_serial_console_changes

https://www.thegeekdiary.com/centos-rhel-7-how-to-configure-serial-getty-with-systemd/
https://wiki.archlinux.org/index.php/Working_with_the_serial_console

[toc] | [prev] | [next] | [standalone]

#221059

deloptes <deloptes@gmail.com> writes:
> Chris Rhodin wrote:
> 
> > Tonight I'll look at the serial port ioctls and see if I can spot a
> > difference there.  I also try enabling flow control and fiddling with 
> the
> > signals to see if that unstops it.
> 
> Are you sure that this is enabled in the BIOS, also some serial ports like
> HP have special connectors and layouts.
> Best would be to look at the manual first.
> 
> I have attached a USB to the server. From there I can log in to the
> firewall. I can not use the same port in the opposite direction.
> 
> However it is strange that you do get the connection only in one 
> direction.
> It could be some kind of special connector
> 
> Otherwise I used those to enable the service
> 
> https://wiki.debian.org/systemd#Virtual_and_serial_console_changes
> 
> https://www.thegeekdiary.com/centos-rhel-7-how-to-configure-serial-getty-with-systemd/
> https://wiki.archlinux.org/index.php/Working_with_the_serial_console

	Another possible fly in the ointment could be a hardware
issue.  Some RS-232 ports are old-school and aren't happy with
any voltage range other than +12 for one state and -12 for the
other while there are serial ports that can handle state changes
of + or - 3 volts so they safely handle logic-level signals and
also can handle the old-school RS-232 levels.  Then there are
some that handle logic-level signals and would figuratively melt
if you hit them with +-12 volts.

Martin

[toc] | [prev] | [next] | [standalone]

#221072

On Tue, 07 Apr 2020 08:24:50 -0500
"Martin McCormick" <martin.m@suddenlink.net> wrote:

> deloptes <deloptes@gmail.com> writes:
> > Chris Rhodin wrote:
> >   
> > > Tonight I'll look at the serial port ioctls and see if I can spot
> > > a difference there.  I also try enabling flow control and
> > > fiddling with   
> > the  
> > > signals to see if that unstops it.  
> > 
> > Are you sure that this is enabled in the BIOS, also some serial
> > ports like HP have special connectors and layouts.
> > Best would be to look at the manual first.
> > 
> > I have attached a USB to the server. From there I can log in to the
> > firewall. I can not use the same port in the opposite direction.
> > 
> > However it is strange that you do get the connection only in one 
> > direction.
> > It could be some kind of special connector
> > 
> > Otherwise I used those to enable the service
> > 
> > https://wiki.debian.org/systemd#Virtual_and_serial_console_changes
> > 
> > https://www.thegeekdiary.com/centos-rhel-7-how-to-configure-serial-getty-with-systemd/
> > https://wiki.archlinux.org/index.php/Working_with_the_serial_console
> >  
> 
> 	Another possible fly in the ointment could be a hardware
> issue.  Some RS-232 ports are old-school and aren't happy with
> any voltage range other than +12 for one state and -12 for the
> other while there are serial ports that can handle state changes
> of + or - 3 volts so they safely handle logic-level signals and
> also can handle the old-school RS-232 levels.  Then there are
> some that handle logic-level signals and would figuratively melt
> if you hit them with +-12 volts.

They're not 'old-school', they're badly designed. The spec says,
unequivocally, plus and minus 3V-15V and has done for a great many
years.

The 'logic' level data, quite common these days, is RS-422 or
RS-485. It should not ever be compatible with RS-232. Most serial data
originates at logic level (anything from 2.8V to 5V) and ends up at
logic level somewhere else, so there is little point in converting to
and from RS-232. But things like radio modules often run on 3.3V or
lower, so it may be necessary to convert to and from RS-422 levels.

Many modern 'RS-232' devices, particularly the really cheap USB-serial
modules, in fact use 3.3V/0V or 5V/0V logic levels, as the term 'RS-232'
has just come to mean 'low-speed serial' to many people.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#221043

[Multipart message — attachments visible in raw view] — view raw

I figured it out.  It was user error.  When I diff'd the output of "stty"
from my laptop and server I saw the server had "-crtscts" and laptop had
"crtscts".  It turns out minicom enables hardware flow control by default
and I had changed that default on my laptop somewhere in the past (at least
3 releases of Debain ago).  I thought I had checked this on the server but
either I didn't or I just missed it.  Changing this in minicom made it work.

Chris


On Mon, Apr 6, 2020 at 10:53 PM Chris Rhodin <cprhodin@gmail.com> wrote:

>
>
> ---------- Forwarded message ---------
> From: Chris Rhodin <cprhodin@gmail.com>
> Date: Mon, Apr 6, 2020 at 7:28 PM
> Subject: Re: Serial Port Issues
> To: <tomas@tuxteam.de>
>
>
> I have two devices I'm trying to connect to, a UPS and a network switch.
> By default the UPS runs at 2400 baud and the switch runs at 9600 baud.
> Before connecting them to the server I verified the devices were working on
> a laptop running Debian.  When I attached them to the server and powered
> them up (with minicom already running) I saw the expected startup messages
> being output by both devices (this is why I say I can receive serial
> data).  I then started typing commands and but got no response.
>
> I started debugging.  I tried other cables, I tried USB to serial cables,
> I reattached the devices to the laptop to verify they hadn't spontaneously
> and simultaneously stopped working.  Next I simplified my test setup.  I
> made a loop back cable that connects Tx to Rx.  I tested this cable on the
> laptop and verified it echoed everything I typed.  On the server no echo.
>
> Based on responses here I've verified the permissions and tried running as
> root.  I've also checked the flow control as reported by minicom.
>
> Q: Is "stty" the right command line tool to check all of a serial ports
> settings?
>
> And finally, last night I burned a Debian live DVD and booted the server
> with it.  After installing the proprietary network drivers and minicom I
> tried the serial ports again with the same results.
>
> Tonight I'll look at the serial port ioctls and see if I can spot a
> difference there.  I also try enabling flow control and fiddling with the
> signals to see if that unstops it.
>
> ChrisR
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ....0
>
> On Mon, Apr 6, 2020 at 7:08 AM <tomas@tuxteam.de> wrote:
>
>> On Mon, Apr 06, 2020 at 09:51:15AM -0400, rhkramer@gmail.com wrote:
>> > On Monday, April 06, 2020 03:50:59 AM tomas@tuxteam.de wrote:
>> > > Besides, a wrong baud rate would much less explain that writing is
>> > > possible, but reading isn't. Not for classical "serials" (i.e.
>> RS-232).
>> >
>> > From the OP: " On this system a serial port can only receive data and
>> not
>> > transmit."
>> >
>> > Wouldn't that mean that (from the perspective of a program running on
>> the OP's
>> > computer) that the serial port can read but not write?
>>
>> My recollection is the other way around: write but not read.
>> But hey, I'm old and that.
>>
>> That (and the fact that another serial over USB showed the same
>> symptoms) prompted me to (reluctantly) hint at permissions [1],
>> since, to my knowledge, a honest serial port cannot be configured
>> to different send and receive speeds. But this seems to be ruled
>> out.
>>
>> Another possibility is, of course, the cable :-)
>>
>> Do we know in which way the port fails to read/write or whatever
>> it fails at? Error messages?
>>
>> Cheers
>> [1] this could be explained by a broken udev script setting
>>    the wrong permissions -- that would, e.g. cover the USB
>>    adapter case. It was such a nice model :-)
>> -- t
>>
>

[toc] | [prev] | [next] | [standalone]

#221044

[Multipart message — attachments visible in raw view] — view raw

On Mon, Apr 06, 2020 at 11:59:14PM -0700, Chris Rhodin wrote:
> I figured it out.  It was user error.  When I diff'd the output of "stty"
> from my laptop and server I saw the server had "-crtscts" and laptop had
> "crtscts" [...]

Ah... I see.

Thanks for posting the resolution, much appreciated :-)

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#221045

[Multipart message — attachments visible in raw view] — view raw

Thanks for all the help.

Chris

On Mon, Apr 6, 2020 at 11:59 PM Chris Rhodin <cprhodin@gmail.com> wrote:

> I figured it out.  It was user error.  When I diff'd the output of "stty"
> from my laptop and server I saw the server had "-crtscts" and laptop had
> "crtscts".  It turns out minicom enables hardware flow control by default
> and I had changed that default on my laptop somewhere in the past (at least
> 3 releases of Debain ago).  I thought I had checked this on the server but
> either I didn't or I just missed it.  Changing this in minicom made it work.
>
> Chris
>
>
> On Mon, Apr 6, 2020 at 10:53 PM Chris Rhodin <cprhodin@gmail.com> wrote:
>
>>
>>
>> ---------- Forwarded message ---------
>> From: Chris Rhodin <cprhodin@gmail.com>
>> Date: Mon, Apr 6, 2020 at 7:28 PM
>> Subject: Re: Serial Port Issues
>> To: <tomas@tuxteam.de>
>>
>>
>> I have two devices I'm trying to connect to, a UPS and a network switch.
>> By default the UPS runs at 2400 baud and the switch runs at 9600 baud.
>> Before connecting them to the server I verified the devices were working on
>> a laptop running Debian.  When I attached them to the server and powered
>> them up (with minicom already running) I saw the expected startup messages
>> being output by both devices (this is why I say I can receive serial
>> data).  I then started typing commands and but got no response.
>>
>> I started debugging.  I tried other cables, I tried USB to serial cables,
>> I reattached the devices to the laptop to verify they hadn't spontaneously
>> and simultaneously stopped working.  Next I simplified my test setup.  I
>> made a loop back cable that connects Tx to Rx.  I tested this cable on the
>> laptop and verified it echoed everything I typed.  On the server no echo.
>>
>> Based on responses here I've verified the permissions and tried running
>> as root.  I've also checked the flow control as reported by minicom.
>>
>> Q: Is "stty" the right command line tool to check all of a serial ports
>> settings?
>>
>> And finally, last night I burned a Debian live DVD and booted the server
>> with it.  After installing the proprietary network drivers and minicom I
>> tried the serial ports again with the same results.
>>
>> Tonight I'll look at the serial port ioctls and see if I can spot a
>> difference there.  I also try enabling flow control and fiddling with the
>> signals to see if that unstops it.
>>
>> ChrisR
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ....0
>>
>> On Mon, Apr 6, 2020 at 7:08 AM <tomas@tuxteam.de> wrote:
>>
>>> On Mon, Apr 06, 2020 at 09:51:15AM -0400, rhkramer@gmail.com wrote:
>>> > On Monday, April 06, 2020 03:50:59 AM tomas@tuxteam.de wrote:
>>> > > Besides, a wrong baud rate would much less explain that writing is
>>> > > possible, but reading isn't. Not for classical "serials" (i.e.
>>> RS-232).
>>> >
>>> > From the OP: " On this system a serial port can only receive data and
>>> not
>>> > transmit."
>>> >
>>> > Wouldn't that mean that (from the perspective of a program running on
>>> the OP's
>>> > computer) that the serial port can read but not write?
>>>
>>> My recollection is the other way around: write but not read.
>>> But hey, I'm old and that.
>>>
>>> That (and the fact that another serial over USB showed the same
>>> symptoms) prompted me to (reluctantly) hint at permissions [1],
>>> since, to my knowledge, a honest serial port cannot be configured
>>> to different send and receive speeds. But this seems to be ruled
>>> out.
>>>
>>> Another possibility is, of course, the cable :-)
>>>
>>> Do we know in which way the port fails to read/write or whatever
>>> it fails at? Error messages?
>>>
>>> Cheers
>>> [1] this could be explained by a broken udev script setting
>>>    the wrong permissions -- that would, e.g. cover the USB
>>>    adapter case. It was such a nice model :-)
>>> -- t
>>>
>>

[toc] | [prev] | [next] | [standalone]

#221111

Chris Rhodin wrote:

> I figured it out.  It was user error.  When I diff'd the output of "stty"
> from my laptop and server I saw the server had "-crtscts" and laptop had
> "crtscts".  It turns out minicom enables hardware flow control by default
> and I had changed that default on my laptop somewhere in the past (at least
> 3 releases of Debain ago).  I thought I had checked this on the server but
> either I didn't or I just missed it.  Changing this in minicom made it work.

  excellent!  :)  have fun!  :)


  songbird

[toc] | [prev] | [next] | [standalone]

#221046

On Mon, 6 Apr 2020 22:53:25 -0700
Chris Rhodin <cprhodin@gmail.com> wrote:


> 
> Q: Is "stty" the right command line tool to check all of a serial
> ports settings?
> 
It Works For Me.

I had a very simple serial requirement recently, and this did the job.

Oh, as to 9600 Baud, if you plug a USB serial port into stretch or
unstable, the stty status shows the default as.... 9600.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#220996

On Mon, Apr 06, 2020 at 08:38:58AM +0100, Joe wrote:
> I doubt it's that. 9600 is a sort of default these days [...]

... 25 years ago.

[toc] | [prev] | [next] | [standalone]

#220999

On Mon, 6 Apr 2020 08:32:53 -0400
Greg Wooledge <wooledg@eeg.ccf.org> wrote:

> On Mon, Apr 06, 2020 at 08:38:58AM +0100, Joe wrote:
> > I doubt it's that. 9600 is a sort of default these days [...]  
> 
> ... 25 years ago.
> 

You'd be surprised how much serial stuff there is around. A lot of it
is based around low-power CPUs, PCs moved away from bare serial many
years ago (though Bluetooth is still widely used). The XBee is quite
commonly used for communication, and as I said, it comes set to 9600. So
did the serial-Ethernet converters I used a few years ago. So do the
Sony block camera modules, and other manufacturers of small cameras
have followed. This product:
https://www.lensadaptor.com/mtf-effect-control-unit-3-kit
uses 38400, but the XBees inside didn't come set that way.

-- 
Joe

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web