After much searching and gleaning of details from various on-line docs,
including the AX.25 Howto, I have reached a dead end with an attempt to
find a new use for an old Baycom serial modem. The flavor of Linux is
Gentoo 2.6.11 r3

The ultimate goal is to use it with Xastir, which appears to be
functioning properly.

The specific problem is with transmitted data. I can issue a CALL or
BEACON at the bash prompt and the radio transmits data that sounds like
2400bps packet. I am also monitoring the data from a Windows PC with
with a PK-232. Every time that I transmit from the Linux / baycom, DCD
is active on the PK-232 and it "sounds" like packet on the scanner, but
nothing shows on the terminal on the Windows PC. The monitor level on
the PK-232 is set to 6 (highest / most data).
I can change the radio connected to the Windows PC / PK-232 to 144.390
(APRS) and the data streams in like crazy.

I can boot the Linux PC with my old DOS / Baycom boot disk and
transmitted data is monitored fine on the Windows / PK-232 PC when I
transmit via the Baycom.

The Baycom is receiving fine on the Linux PC. I can fire up Xastir and
watch the local APRS activity, no problem.
Here are some of the config details:

AXPORTS
# /etc/ax25/axports
#
# The format of this file is:
#
# name callsign speed paclen window description
#
baycom-com2 KD4TWJ-9 1200 250 2 144.390 APRS (1200 bps)

:ifconfig bcsf1
bcsf1 Link encap:AMPR AX.25 HWaddr KD4TWJ-9
inet addr:192.168.10.10 Mask:255.255.255.0
UP RUNNING MTU:256 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:16
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:3 Base address:0x2f8

:sethdlc -i bcsf1 -a
sethdlc: Version 0.5; (C) 1996-1997 by Thomas Sailer HB9JNX/AE4WA
current parameters: TX delay 300ms, TX tail 300ms, slottime 100ms,
p-persistence 40/256, Half duplex

:sethdlc -i bcsf1 -p
sethdlc: Version 0.5; (C) 1996-1997 by Thomas Sailer HB9JNX/AE4WA
driver name: baycom_ser_fdx
current parameters: mode ser12* io 0x2f8 irq 3

If I use "Listen -a -h -p baycom-com2" while using Call in another
term, here is what I see;
baycom-com2: fm KD4TWJ-9 to KD4TWJ-1 ctl SABM+
baycom-com2: fm KD4TWJ-9 to KD4TWJ-1 ctl SABM+
baycom-com2: fm KD4TWJ-9 to KD4TWJ-1 ctl DISC+

I am cancelling Call after the second attemp, that is why DISC is the
third entry.
This looks like the right stuff.
It is as if the packets are empty by the time that they reach the radio
for transmission.
Any ideas?

Thanks

Dean

Hi Dean

I assume you mean "sounds like 1200bps packet" rather than 2400?

I doubt this is relevant but I had some issues with using the serial
port for PTT under soundmodem. Ended up running setserial and turning
the serial port "off" before use. (ie "uart none") I'd think though that
baycom mode would be simply a "synchronous" form of transmitting to/from
a standard serial port and wouldnt need to be turned off this way..

Since the whole thing should be synchronous at 1200bps I'd start looking
for any inter bit delays that may be being introduced. This I think
would be more commonly a RX rather than TX problem. I remember having an
older kernel that didnt recognise the 16650 UART properly and defaulted
to something without either a RX or TX buffer. Perhaps some playing with
setserial will help (defining the UART type also defines whether it uses
buffering. I think the kernel module allows you to change the buffer
size but I havent checked this)

You may also be able to capture the audio with your soundcard and make
some hard comparisons with a spec-an etc to determine where it falls down.

If you think it may be linux version/kernel dependent try the Knoppix
boot CD. I think there is also a ham radio version if AX25 support isnt
in the original

Apologies for not being more helpful

Cheers Bob W5/VK2YQA

data ham wrote:

After much searching and gleaning of details from various on-line docs,
including the AX.25 Howto, I have reached a dead end with an attempt to
find a new use for an old Baycom serial modem. The flavor of Linux is
Gentoo 2.6.11 r3

On Fri, 25 Nov 2005, data ham wrote:

After much searching and gleaning of details from various on-line docs,
including the AX.25 Howto, I have reached a dead end with an attempt to
find a new use for an old Baycom serial modem. The flavor of Linux is
Gentoo 2.6.11 r3

The ultimate goal is to use it with Xastir, which appears to be
functioning properly.

The specific problem is with transmitted data. I can issue a CALL or
BEACON at the bash prompt and the radio transmits data that sounds like
2400bps packet. I am also monitoring the data from a Windows PC with
with a PK-232. Every time that I transmit from the Linux / baycom, DCD
is active on the PK-232 and it "sounds" like packet on the scanner, but
nothing shows on the terminal on the Windows PC. The monitor level on
the PK-232 is set to 6 (highest / most data).
I can change the radio connected to the Windows PC / PK-232 to 144.390
(APRS) and the data streams in like crazy.

I can boot the Linux PC with my old DOS / Baycom boot disk and
transmitted data is monitored fine on the Windows / PK-232 PC when I
transmit via the Baycom.

The Baycom is receiving fine on the Linux PC. I can fire up Xastir and
watch the local APRS activity, no problem.
Here are some of the config details:

AXPORTS
# /etc/ax25/axports
#
# The format of this file is:
#
# name callsign speed paclen window description
#
baycom-com2 KD4TWJ-9 1200 250 2 144.390 APRS (1200 bps)

:ifconfig bcsf1
bcsf1 Link encap:AMPR AX.25 HWaddr KD4TWJ-9
inet addr:192.168.10.10 Mask:255.255.255.0
UP RUNNING MTU:256 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:16
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:3 Base address:0x2f8

:sethdlc -i bcsf1 -a
sethdlc: Version 0.5; (C) 1996-1997 by Thomas Sailer HB9JNX/AE4WA
current parameters: TX delay 300ms, TX tail 300ms, slottime 100ms,
p-persistence 40/256, Half duplex

:sethdlc -i bcsf1 -p
sethdlc: Version 0.5; (C) 1996-1997 by Thomas Sailer HB9JNX/AE4WA
driver name: baycom_ser_fdx
current parameters: mode ser12* io 0x2f8 irq 3

If I use "Listen -a -h -p baycom-com2" while using Call in another
term, here is what I see;
baycom-com2: fm KD4TWJ-9 to KD4TWJ-1 ctl SABM+
baycom-com2: fm KD4TWJ-9 to KD4TWJ-1 ctl SABM+
baycom-com2: fm KD4TWJ-9 to KD4TWJ-1 ctl DISC+

I am cancelling Call after the second attemp, that is why DISC is the
third entry.
This looks like the right stuff.
It is as if the packets are empty by the time that they reach the radio
for transmission.
Any ideas?

Thanks

Dean


Each TNX and softwre package has its own particular settings even though
in ax25 protocol. My only answer is to give you my settings used with
VHF only and software called Digicom.
Name Setting
HBAUD 1200
PACLEN 255 (blks)
TXD (anywhere between 10 and 60)
Monitor MBEQHI
MAXFRAMES 7 (means if sigs good gives fastest throughput)
Joe

Bob Bob wrote:

Hi Dean

I assume you mean "sounds like 1200bps packet" rather than 2400?

Yeah, that is what I meant. I guess that when I was typing, my brain
was
faster than 1200bps AX.25! :-

I doubt this is relevant but I had some issues with using the serial
port for PTT under soundmodem. Ended up running setserial and turning
the serial port "off" before use. (ie "uart none") I'd think though that
baycom mode would be simply a "synchronous" form of transmitting to/from
a standard serial port and wouldnt need to be turned off this way..

Yep, doing that. I chose to load everything as modules, instead of the
kernel, so the first command in my script is "setserial /dev/ttyS1 uart
none". The Baycom driver is unhappy if it does not have the UART, so
this
is pretty much required.

Since the whole thing should be synchronous at 1200bps I'd start looking
for any inter bit delays that may be being introduced. This I think
would be more commonly a RX rather than TX problem. I remember having an
older kernel that didnt recognise the 16650 UART properly and defaulted
to something without either a RX or TX buffer. Perhaps some playing with
setserial will help (defining the UART type also defines whether it uses
buffering. I think the kernel module allows you to change the buffer
size but I havent checked this)

dmesg output indicates that the UART is recognized as a 16550 and that
ttyS1
is set to 1200bps when baycom_ser_fdx is loaded.

You may also be able to capture the audio with your soundcard and make
some hard comparisons with a spec-an etc to determine where it falls down.

I have not gotten around to configuring sound on this notebook yet.

If you think it may be linux version/kernel dependent try the Knoppix
boot CD. I think there is also a ham radio version if AX25 support isnt
in the original

I do have a copy of Harv's around, I may try that.

Apologies for not being more helpful
Cheers Bob W5/VK2YQA

All help is appreciated.

Dean KD4TWJ

Just an extra thought or two Dean

Have you tried setting up soundmodem or a vanilla TNC with the same box?
Thinking in terms of checking that AX25 is working in the kernel properly.

And grabbing at straws.....

I wonder if "baycom-com2" can be a real valid port name. Mine have
always been real short names like "radio".

Is 300ms long enough TXD for your TX?

Is the PK232 DCD only based on audio present (unsquelched) or has it
detected a valid set of tones? (ie soft DCD)

And rather than using "call" also try and ping a box in the interface
subnet and monitoring the activity on the other PC (say 192.168.10.11).
I can never remember whether connect mode (ie "call") runs on top of the
IP interface or at a layer beneath...

I also copy/pasted this from the baycom website;

During the last three months we have been reported some problems with
RS-232 cards using the fast 16550 chips with internal FIFO instead of
the "traditional" 8250 chip. There seems to be a number of 16550
versions (not all of them!) which do not support the internal 6 bit mode
of the RS-232 we use for clock and baudrate generation in the BayCom
terminal. This mode is rarely needed for other applications and it looks
like chip designers have not implemented it on these chips.
As a consequence, BayCom will not run on these PCs. Unfortunately, there
is no easy workaround, so we could not solve this problem yet. We will
try to fix it with the next version.
If you run into trouble, buy a simple 8250 card for 10 US$ and put it
into your PC as COM3/COM4 and configure BayCom on it. Make sure, that
addresses AND interrupts are set properly as configured in the INSTALL
program.

We would have some interest to know, which of the 16550 do not run.
Currently, National Semiconductors are the only one's known to us. If
you have a trouble making card, please mail the name of the manufacturer
of the card and of the 16550 chip on the card to .

Have you tried telling setserial uart 8250?

Tom Sailer has answered a few queries of mine directly so that may be
another avenue. His personal website and email contact are on the baycom
website.

Last time I was running packet I actually used the soundmodem suite.
Almost got all fired up using Q15X25... (2500bps)

Cheers Bob VK2YQA

data ham wrote:
Yeah, that is what I meant. I guess that when I was typing, my brain
was
faster than 1200bps AX.25! :-

Bob Bob wrote:
Just an extra thought or two Dean

Have you tried setting up soundmodem or a vanilla TNC with the same box?
Thinking in terms of checking that AX25 is working in the kernel properly.

I wonder if "baycom-com2" can be a real valid port name. Mine have
always been real short names like "radio".

Is 300ms long enough TXD for your TX?
I am starting to wonder about the kernel also. I was not able to get
Harv's Knoppix to load properly on this Notebook, but I was able to get
AFU Knoppix (2.4 kernel) to load. It all worked fine, the Windows /
PK-232 decoded the packets perfectly. I knew that the UART worked fine
when booted with DOS and this now leads me to think that it is OK with
Linux AX.25. I used baycom-com2 as the port name and also 300ms was
plenty for the TX Delay.


Is the PK232 DCD only based on audio present (unsquelched) or has it
detected a valid set of tones? (ie soft DCD)
It is just audio present, nothing fancy.


And rather than using "call" also try and ping a box in the interface
subnet and monitoring the activity on the other PC (say 192.168.10.11).
I can never remember whether connect mode (ie "call") runs on top of the
IP interface or at a layer beneath...
Tried that also. Same result, sounds like packet, but nothing usable
on Windows / PK-232 terminal.

Have you tried telling setserial uart 8250?
Yes, however the Baycom module needs control of the UART, so this will
not fly. You can still load the module, but the network interface will
not come up, since it sees a conflict with the serial module. Seems
strange until you see how the baycom module works.

I will have to try making a new Harv's Knoppix CD and see if that will
load OK. I am starting to wonder about Baycom with 2.6 kernels.

Thanks

Dean KD4TWJ

Minor update -
I created a new Harv's Knoppix CD (2.6.11 kernel) and it exhibited the
same problem. I then remembered that the AFU version of Knoppix would
load 2.6 (2.6.9) as well as the default 2.4 kernel. Once again, same
problem exhibited with the AFU version and the 2.6 kernel.

Next, I tried the same thing on a Desktop PC. First AFU Knoppix with
2.4 kernel, the baycom worked perfectly. Then both AFU and Harv's with
2.6 kernel, same Tx problem with each one.

I may try upgrading the Notebook PC to 2.6.14 as soon as time permits.
Hopefully that will make a difference.

Also, when I posted the message here originally, I had not been
thinking in terms of a kernel problem, I was thinking that I was
mis-configuring something. I have since done some Usenet searching
specific to Baycom serial / 2.6 kernel and it appears that others are
having the same problems.

Dean KD4TWJ

Just in case anyone is interested.
I finally finished the update to kernel 2.6.14 . I also did a modules
update.
And still no joy. Same results.
I have also found a few older messages and vague references in Usenet
messages to the data corruption / CRC problems with transmit and Baycom
serial modems. It appears the while there is recognition of a problem
with packet assembly prior to transmit, nothing seems to have been
accomplished to solve the problem. The best that I can tell, the end
of the line for the serial baycoms was the 2.4 kernels. I have also
seen messages that indicate that there are problems with AX.25 in the
2.4 kernels. Problems that are fixed in the 2.6 kernels.
Unfortunately, I am not in a postion to lend a hand towards resolution
of Baycom / kernel 2.6 issues, otherwise I would.
Sadly, I am now loading Win98 on the PC and hope to have Cygwin and
Xastir running with the Baycom in a few days. I need it for a trip
that I will be taking.
It's a damn shame. A Linux installation is terrible thing to waste.

Dean KD4TWJ

Well John, I never used a Baycom so cant say much about that.
AX25V2 protocol however is still the established WW protocol
for packet or TNC's of any kind. I use a C128 and a CBM
type TNC which is half homebru! I still use the V2 protocol
and it works fine with military PBBS systems. I use it mostly
for MARS traffic.
Joe/ABM6JF


************************************************** ********
* Ham KH6JF AARS/MARS ABM6JF QCWA WW2 VET WD RADIO SYSTEM*
* Army MARS PRECEDED by AARS (Army Amateur Radio System) *
* Hi State ARMY MARS COORDINATOR *
************************************************** ********

Tnxs for the followup Dean

Cheers Bob VK2YQA

data ham wrote:

Just in case anyone is interested.
I finally finished the update to kernel 2.6.14 . I also did a modules
update.
And still no joy. Same results.
I have also found a few older messages and vague references in Usenet
messages to the data corruption / CRC problems with transmit and Baycom
serial modems. It appears the while there is recognition of a problem
with packet assembly prior to transmit, nothing seems to have been
accomplished to solve the problem. The best that I can tell, the end
of the line for the serial baycoms was the 2.4 kernels. I have also
seen messages that indicate that there are problems with AX.25 in the
2.4 kernels. Problems that are fixed in the 2.6 kernels.
Unfortunately, I am not in a postion to lend a hand towards resolution
of Baycom / kernel 2.6 issues, otherwise I would.
Sadly, I am now loading Win98 on the PC and hope to have Cygwin and
Xastir running with the Baycom in a few days. I need it for a trip
that I will be taking.
It's a damn shame. A Linux installation is terrible thing to waste.

Dean KD4TWJ