Re: 1-way modem

Thanks for your excellent thoughts Moe!

What KIND of modem? External? Internal? Built-in? PCI? USB? ISA? How
is is connected to the computer? What shows up in /var/log/messages
at boot time related to the appropriate serial port? Which serial
driver is being used? Is it appropriate to your unspecified hardware?

I could easily screw up this definition, but it's on COM1 which
from lspci is on a ISA bridge:

0b:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface
Controller (rev 09)
Subsystem: NEC Corporation Unknown device 8350
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Step
ping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 0

The messages file shows the 2 active serial ports at the correct IRQ:

Feb 29 17:20:53 box kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Feb 29 17:20:53 box kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

setserial agrees on the IRQ:

/dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test


I do get occasional messages like:
Feb 29 17:15:06 box pppd[7197]: Connect: ppp0 <--> /dev/ttyS0
Feb 29 17:15:37 box pppd[7197]: LCP: timeout sending Config-Requests
Feb 29 17:15:37 box pppd[7197]: Connection terminated.
Feb 29 17:15:37 box pppd[7197]: Receive serial link is not 8-bit clean:
Feb 29 17:15:37 box pppd[7197]: Problem: all had bit 7 set to 0

Though i think the 8-bit stuff could be a red-herring. I believe the
16550A identification is correct.

Are you using some form of 'connect' option such as '/usr/sbin/chat' to
dial the modem? Set that tool into the debug or verbose mode (for
'/usr/sbin/chat', add the -v option), and look at the resulting logs.
Does the modem respond (more or less) instantly?

Jul 3 09:55:00 gtech chat[925]: send (AT&F1)
Jul 3 09:55:01 gtech chat[925]: expect (OK)
Jul 3 09:55:01 gtech chat[925]: AT&F1
Jul 3 09:55:01 gtech chat[925]: OK
Jul 3 09:55:01 gtech chat[925]: -- got it

Great tip, yes we're using chat, and mostly they fall close together --
certainly no 19 second delay, but there is a 2-second delay I see:

Mar 1 10:03:25 box pppd[8453]: pppd 2.4.4 started by root, uid 0
Mar 1 10:03:26 box chat[8454]: abort on (NO CARRIER)
Mar 1 10:03:26 box chat[8454]: abort on (NO DIALTONE)
Mar 1 10:03:26 box chat[8454]: abort on (ERROR)
Mar 1 10:03:26 box chat[8454]: abort on (BUSY)
Mar 1 10:03:26 box chat[8454]: send (ATH^M)
Mar 1 10:03:26 box chat[8454]: expect (OK)
Mar 1 10:03:28 box chat[8454]: ^M <<<---- relevant gap??
Mar 1 10:03:28 box chat[8454]: OK
Mar 1 10:03:28 box chat[8454]: -- got it
Mar 1 10:03:28 box chat[8454]: send (ATE0^M)
Mar 1 10:03:28 box chat[8454]: expect (OK)
Mar 1 10:03:28 box chat[8454]: ^M
Mar 1 10:03:28 box chat[8454]: ^M
Mar 1 10:03:28 box chat[8454]: OK
Mar 1 10:03:28 box chat[8454]: -- got it
Mar 1 10:03:28 box chat[8454]: send (AT^M)
Mar 1 10:03:28 box chat[8454]: expect (OK)
Mar 1 10:03:28 box chat[8454]: ^M
Mar 1 10:03:28 box chat[8454]: ^M
Mar 1 10:03:28 box chat[8454]: OK
Mar 1 10:03:28 box chat[8454]: -- got it
Mar 1 10:03:28 box chat[8454]: send (ATDT5591^M)
Mar 1 10:03:28 box chat[8454]: timeout set to 120 seconds
Mar 1 10:03:28 box chat[8454]: expect (CONNECT)
Mar 1 10:03:28 box chat[8454]: ^M
Mar 1 10:03:54 box chat[8454]: ^M
Mar 1 10:03:54 box chat[8454]: CONNECT
Mar 1 10:03:54 box chat[8454]: -- got it
Mar 1 10:03:54 box pppd[8453]: Serial connection established.

On the upgraded box, is minicom using an appropriate (as defined by the
manufacturer) modem init string? (That usually means something like AT&F0
or AT&F1, and NOT "ATZ" which may just reset the modem to what-ever you
may have saved into NVRAM.) Are the modem commands being echoed back?
Does the echo or the result code occur within a fraction of a second, or
is there a long (up to a half minute) delay? Does your modem have lights
on it, and are they blinking appropriately? (If no lights, there are a
number of applications that can mimic these lights - "modemlights" is
but one example.)

The commands get their OKs echo'd back promptly. We're not sending
AT&F1 or ATZ, but during my manual test i sent it AT&F1 and it didn't
make a difference. I've watched the lights via statserial, and they
seem like appropriate settings during the state transitions -- on
ever-lasting CD or anything.

Looking at a working case, I see that stty -a < /dev/ttyS0 (the modem
port) looks the same, and setserial -a /dev/ttyS0 is basically the same
(I tried setting it to auto_irq with no diff). Looking at
/proc/tty/driver/serial during the PPP negotiation seem to only show
transmissions, not receptions.

Fire up minicom. Look at the contents of /proc/interrupts:

7: 969503 + serial

We only have serial showing up in 3 and 4 as expected, the IRQ
of interest being 4 (3/COM2 is a console).


(Here, the modem is configured to use IRQ 7, because other devices are
using the so-called "standard" values of 4 or 3. Note also that the data
is only present when some application is actually USING the interrupt.)
In minicom, press the A, T, and return key - which should send the
Hayes command prefix to the modem. The modem should respond with a
non-error result - the number 0 if non-verbal result codes are selected,
or the letters "OK". Now look again at /proc/interrupts:

7: 969515 + serial

Echoing the command, and then producing the "verbal result" here caused
12 interrupts. What do _you_ see on your system?

This works normally, but when the LCP/IPCP fragments are going to
the other side, only TX is bumped in /proc/tty/driver/serial, not the
RX count.

Old guy

Damn, i thought i was the old guy. But excellent tip about the chat
timings.

.

Relevant Pages

  • Re: minicom serial output
    ... >>doesn't react and a multimeter accross the serial port shows that no data ... I already changed the modem initialisation string to ... >>'D' (one of the commands recognised by my device) and I can get my device ... > present minicom configuration, go back to the default configuration ...
    (comp.os.linux.hardware)
  • Re: minicom serial output
    ... >doesn't react and a multimeter accross the serial port shows that no data ... >initialisation / hangup commands. ... I already changed the modem initialisation string to ... present minicom configuration, go back to the default configuration ...
    (comp.os.linux.hardware)
  • Re: minicom serial output
    ... doesn't react and a multimeter accross the serial port shows that no data ... It also reacts to the modem ... 'D' (one of the commands recognised by my device) and I can get my device ... If you are changing the settings each time, ...
    (comp.os.linux.hardware)
  • Re: CF2.0 WM5 Comms help required please
    ... FOr the built-in modem, it won't work like a serial port. ... What I *now* want to do is develop the app further my using VB.Net 2005 to ... The previous GSM modem worked, as did previous attemtps to use a GSM ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: CF2.0 WM5 Comms help required please
    ... During the development of this application I also connected a GSM modem to ... The latter two methods used a virtual serial port rather ... What I *now* want to do is develop the app further my using VB.Net 2005 to ...
    (microsoft.public.dotnet.framework.compactframework)