YAM/Tekk help

YAM/Tekk help

[Jim Meehan]

I'm trying to get two Linux systems talking to each other over 9600 bps packet.
Here's my setup:

System 1:
Pentium 133 MHz running RedHat 8
Kenwood TM-D700A /w integrated 9600 bps TNC
AX25 HW addr: W6XE-12
IP addr 10.0.0.1


System 2:
Soekris single-board computer running custom Linux mini-distro
Kernel version 2.4.20
YAM 9600 bps modem
Tekk KS-900L radio
AX25 HW addr: W6XE-14
IP addr 10.0.0.2

Problem 1:

If I ping from either side, that machine sends out ARP requests endlessly.
If I do "ifconfig" on the other side, I can see the RX packet counter
incrementing, and in "listen" I can see the ARP requests being received.
But no ARP reply is ever sent.  If I create a static ARP entries on both sides,
then the machines can find each other, and I can ping in both directions.
I guess it's not really such a problem to add static ARP entries on both sides,
since there won't be any stations other than these two.  Would be nice to
know why ARP isn't working though.

Problem 2:

The link is not reliable.  Right now, I've got the txdelay set to 300 ms on
both sides, and I'm still getting 3 or 4 percent packet loss with 64 byte
pings.  If I increase that to 192 byte pings (which is a more realistic size
for real world data transfer) that goes up to ~ 12 percent packet loss.  This
isn't really acceptable, especially since the two systems are just one room
away from each other at the moment.

It looks like packets sent by the TM-D700A are received reliably by the 
YAM/Tekk side, but packets going the other direction are prone to bit errors.
Since there are really no adjustments to make on the TM-D700A, I suspect that
something needs to be adjusted on the YAM/Tekk combo.  There's one adjustment
on the YAM, for TX gain, and I've tried to adjust that for best reliability.
There are also a ton of trimmers and adjustments inside the Tekk, and I suspect
it needs to be realigned.  There are pretty detailed tune-up instructions for
the Tekk radio here:

http://www.guerrilla.net/reference/tekk/ks960_techman.html

But I don't own the equipment necessary to make all the adjustments.

Anyone in the SF bay area who has access to that gear who'd be willing to
help me tune up the Tekk radio?  Any other suggestions on how to get the 
YAM/Tekk combo tuned up and working more reliably?

Thanks,

Jim Meehan, W6XE
Oakland, CA

Re: YAM/Tekk help

[Ralf Baechle DL5RB]

On Wed, Nov 16, 2005 at 07:17:48AM -0800, Jim Meehan wrote:

> If I ping from either side, that machine sends out ARP requests endlessly.
> If I do "ifconfig" on the other side, I can see the RX packet counter
> incrementing, and in "listen" I can see the ARP requests being received.
> But no ARP reply is ever sent.  If I create a static ARP entries on both sides,
> then the machines can find each other, and I can ping in both directions.
> I guess it's not really such a problem to add static ARP entries on both sides,
> since there won't be any stations other than these two.  Would be nice to
> know why ARP isn't working though.

It this IP over raw AX.25 or IP over NET/ROM?  ARP works over AX.25 but
not over NET/ROM.  Anyway, the majority of sites deciede to disable ARP
and use static ARP tables simply because ARP uses some bandwidth and 9k6
isn't exactly alot.

  Ralf

Re: YAM/Tekk help

[Jim Meehan]

On Wed, Nov 16, 2005 at 04:29:53PM +0000, Ralf Baechle DL5RB wrote:
> 
> It this IP over raw AX.25 or IP over NET/ROM?  ARP works over AX.25 but
> not over NET/ROM.  Anyway, the majority of sites deciede to disable ARP
> and use static ARP tables simply because ARP uses some bandwidth and 9k6
> isn't exactly alot.

It's IP over raw AX.25, so it should be working. 

Re: YAM/Tekk help

[Bill Vodall]

> not over NET/ROM.  Anyway, the majority of sites deciede to disable ARP
> and use static ARP tables simply because ARP uses some bandwidth and 9k6
> isn't exactly alot.

We've had not trouble with zillions of APR packets even at 1200 baud.

Are you using the D700 internal TNC.  It's braindead with a teeny
buffer and won't work for much beyond APRS and some simple BBS
work.

73,
Bill - WA7NWP

Re: YAM/Tekk help

[Mike Murphree]

Jim Meehan said:
> I'm trying to get two Linux systems talking to each other over 9600 bps
> packet.
> Here's my setup:
>
> System 1:
> Pentium 133 MHz running RedHat 8
> Kenwood TM-D700A /w integrated 9600 bps TNC
> AX25 HW addr: W6XE-12
> IP addr 10.0.0.1
>
>
> System 2:
> Soekris single-board computer running custom Linux mini-distro
> Kernel version 2.4.20
> YAM 9600 bps modem
> Tekk KS-900L radio
> AX25 HW addr: W6XE-14
> IP addr 10.0.0.2

Hi Jim,

I sold a KS-900L sometime ago, I can't remember if it was to you.
I did find the manuals eventually.

>
> Problem 1:
>
> If I ping from either side, that machine sends out ARP requests endlessly.
> If I do "ifconfig" on the other side, I can see the RX packet counter
> incrementing, and in "listen" I can see the ARP requests being received.
> But no ARP reply is ever sent.  If I create a static ARP entries on both
> sides,
> then the machines can find each other, and I can ping in both directions.
> I guess it's not really such a problem to add static ARP entries on both
> sides,
> since there won't be any stations other than these two.  Would be nice to
> know why ARP isn't working though.

Do you have some problem with your DCD detection?  If the receiving end
thinks that DCD is always active, it won't transmit.

> Problem 2:
>
> The link is not reliable.  Right now, I've got the txdelay set to 300 ms
> on
> both sides, and I'm still getting 3 or 4 percent packet loss with 64 byte
> pings.  If I increase that to 192 byte pings (which is a more realistic
> size
> for real world data transfer) that goes up to ~ 12 percent packet loss.
> This
> isn't really acceptable, especially since the two systems are just one
> room
> away from each other at the moment.

The Tekk radio only needs maybe 70 ms for txdelay, but your D700A could be
much longer.

>
> It looks like packets sent by the TM-D700A are received reliably by the
> YAM/Tekk side, but packets going the other direction are prone to bit
> errors.
> Since there are really no adjustments to make on the TM-D700A, I suspect
> that
> something needs to be adjusted on the YAM/Tekk combo.  There's one
> adjustment
> on the YAM, for TX gain, and I've tried to adjust that for best
> reliability.
> There are also a ton of trimmers and adjustments inside the Tekk, and I
> suspect
> it needs to be realigned.  There are pretty detailed tune-up instructions
> for
> the Tekk radio here:
>
> http://www.guerrilla.net/reference/tekk/ks960_techman.html

A KS-900L should almost work out of the box without messing with anything
inside.  The KS-960 was a lot harder.  Make sure your deviation level does
not exceed 3.5 kHz maximum.  It's unlikely that you needed to do anything
beyond netting the crystal and possibly retuning the front end if you
moved the frequency a lot.

> But I don't own the equipment necessary to make all the adjustments.
>
> Anyone in the SF bay area who has access to that gear who'd be willing to
> help me tune up the Tekk radio?  Any other suggestions on how to get the
> YAM/Tekk combo tuned up and working more reliably?

Just a quick check of the deviation with another open squelch FM receiver
is that when you are transmitting 9600 bps FSK, the noise should actually
decrease during transmit.

I also agree with the comment that the TNCs in the Kenwood radios are crap
for this application.  They were not designed for this kind of use.

73
Mike W4LNA

Re: YAM/Tekk help

[Wilson G. Hein]

I've also heard that there are issues with kiss mode using the internal
modem in the D700. You might have better luck using the soundmodem and
not the internal TNC.

73, Willie WJ3G

On Wed, 2005-11-16 at 07:17, Jim Meehan wrote:
> I'm trying to get two Linux systems talking to each other over 9600 bps packet.
> Here's my setup:
> 
> System 1:
> Pentium 133 MHz running RedHat 8
> Kenwood TM-D700A /w integrated 9600 bps TNC
> AX25 HW addr: W6XE-12
> IP addr 10.0.0.1
> 
> 
> System 2:
> Soekris single-board computer running custom Linux mini-distro
> Kernel version 2.4.20
> YAM 9600 bps modem
> Tekk KS-900L radio
> AX25 HW addr: W6XE-14
> IP addr 10.0.0.2
> 
> Problem 1:
> 
> If I ping from either side, that machine sends out ARP requests endlessly.
> If I do "ifconfig" on the other side, I can see the RX packet counter
> incrementing, and in "listen" I can see the ARP requests being received.
> But no ARP reply is ever sent.  If I create a static ARP entries on both sides,
> then the machines can find each other, and I can ping in both directions.
> I guess it's not really such a problem to add static ARP entries on both sides,
> since there won't be any stations other than these two.  Would be nice to
> know why ARP isn't working though.
> 
> Problem 2:
> 
> The link is not reliable.  Right now, I've got the txdelay set to 300 ms on
> both sides, and I'm still getting 3 or 4 percent packet loss with 64 byte
> pings.  If I increase that to 192 byte pings (which is a more realistic size
> for real world data transfer) that goes up to ~ 12 percent packet loss.  This
> isn't really acceptable, especially since the two systems are just one room
> away from each other at the moment.
> 
> It looks like packets sent by the TM-D700A are received reliably by the 
> YAM/Tekk side, but packets going the other direction are prone to bit errors.
> Since there are really no adjustments to make on the TM-D700A, I suspect that
> something needs to be adjusted on the YAM/Tekk combo.  There's one adjustment
> on the YAM, for TX gain, and I've tried to adjust that for best reliability.
> There are also a ton of trimmers and adjustments inside the Tekk, and I suspect
> it needs to be realigned.  There are pretty detailed tune-up instructions for
> the Tekk radio here:
> 
> http://www.guerrilla.net/reference/tekk/ks960_techman.html
> 
> But I don't own the equipment necessary to make all the adjustments.
> 
> Anyone in the SF bay area who has access to that gear who'd be willing to
> help me tune up the Tekk radio?  Any other suggestions on how to get the 
> YAM/Tekk combo tuned up and working more reliably?
> 
> Thanks,
> 
> Jim Meehan, W6XE
> Oakland, CA
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAM/Tekk help

[David Rivenburg]

Jim Meehan wrote:
> Problem 1:
> 
> If I ping from either side, that machine sends out ARP requests endlessly.

Just a quick sanity check: did you set the ping interval to something 
higher than 3 seconds?  The round trip time for radio pings is about 3 
seconds, and if you use something less (like the default of 1 second) 
the pingee will have a hard time getting an out an arp reply between the 
pingers requests.

> Problem 2:
> 
> The link is not reliable.  Right now, I've got the txdelay set to 300 ms on
> both sides, and I'm still getting 3 or 4 percent packet loss with 64 byte
> pings.

Only 3-4%?  That's actually pretty good.  Reliable 9600 baud packet is 
practically nonexistant without using hardware specifically designed for 
9600 baud baseband fsk.  I am not aware of any commercial radio or tnc 
that is.  They may *try* to do 9600, and even have modest success with 
it, but they are flawed from the start and cannot be counted on for 
reliable operation.

You would actually be better off with 1200 baud since that *is* 
implemented correctly in the bulk of the hardware out there.  Fewer 
retries = faster throughput.  If you're really adventursome, give the 
4800bps psk soundmodem a try.  It is *much* more reliable than 9600 
baud, and about 6x faster than 1200 baud (taking into account a longer 
mtu with fewer retries).

73
AD5OO

Re: YAM/Tekk help

[Mike Murphree]

David Rivenburg said:
> Jim Meehan wrote:
>> Problem 1:
>>
>> If I ping from either side, that machine sends out ARP requests
>> endlessly.
>
> Just a quick sanity check: did you set the ping interval to something
> higher than 3 seconds?  The round trip time for radio pings is about 3
> seconds, and if you use something less (like the default of 1 second)
> the pingee will have a hard time getting an out an arp reply between the
> pingers requests.

You should only see one arp request on the first ping after a period of
inactivity.  Endless arps indicates that the link was very unreliable to
start with.

>
>> Problem 2:
>>
>> The link is not reliable.  Right now, I've got the txdelay set to 300 ms
>> on
>> both sides, and I'm still getting 3 or 4 percent packet loss with 64
>> byte
>> pings.
>
> Only 3-4%?  That's actually pretty good.  Reliable 9600 baud packet is
> practically nonexistant without using hardware specifically designed for
> 9600 baud baseband fsk.  I am not aware of any commercial radio or tnc
> that is.  They may *try* to do 9600, and even have modest success with
> it, but they are flawed from the start and cannot be counted on for
> reliable operation.

3 to 4 percent on small ping packets translates into much worse for actual
data transfers.  He is using at least one real (Tekk) data radio, but the
other one will be worse.  It would be worth setting maxframe on both ends
to 1 to see if that helps the Kenwood's TNC cope better with this kind of
usage.


> You would actually be better off with 1200 baud since that *is*
> implemented correctly in the bulk of the hardware out there.  Fewer
> retries = faster throughput.  If you're really adventursome, give the
> 4800bps psk soundmodem a try.  It is *much* more reliable than 9600
> baud, and about 6x faster than 1200 baud (taking into account a longer
> mtu with fewer retries).

The only 1200 bps system that I've ever seen come close to a decent 9600
bps setup was a full duplex repeater.   Otherwise 1200 bps was just
painful for tcp/ip use...

73
Mike W4LNA

Re: YAM/Tekk help

[Chuck Hast]

On 11/22/05, David Rivenburg <driven@onr.com> wrote:
> Jim Meehan wrote:
> > Problem 1:
> >
> > If I ping from either side, that machine sends out ARP requests endlessly.
>
> Just a quick sanity check: did you set the ping interval to something
> higher than 3 seconds?  The round trip time for radio pings is about 3
> seconds, and if you use something less (like the default of 1 second)
> the pingee will have a hard time getting an out an arp reply between the
> pingers requests.
>
> > Problem 2:
> >
> > The link is not reliable.  Right now, I've got the txdelay set to 300 ms on
> > both sides, and I'm still getting 3 or 4 percent packet loss with 64 byte
> > pings.
>
> Only 3-4%?  That's actually pretty good.  Reliable 9600 baud packet is
> practically nonexistant without using hardware specifically designed for
> 9600 baud baseband fsk.  I am not aware of any commercial radio or tnc
> that is.  They may *try* to do 9600, and even have modest success with
> it, but they are flawed from the start and cannot be counted on for
> reliable operation.

The 8100 series Tait radios are designed as "data radios" with voice as a
add on. The IF is all DSP and there are 6 tap points for audio in both the
RX and TX paths. I have used two of them on a link and seen what were
almost no retries over a several day period. You can find out more about
them by going to:
www.taitworld.com,
Also PacComm Packet radio systems can sell you the radios, you can
give Linda a call a 813.874.2980

These radios a VERY good, I used then in a moble 9k6 data application
for a gov. project, and those are the only radios that group will use now.

--
Chuck Hast
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Re: YAM/Tekk help

[Ralf Baechle DL5RB]

On Tue, Nov 22, 2005 at 12:57:38AM -0600, David Rivenburg wrote:

> Only 3-4%?  That's actually pretty good.  Reliable 9600 baud packet is 
> practically nonexistant without using hardware specifically designed for 
> 9600 baud baseband fsk.  I am not aware of any commercial radio or tnc 
> that is.  They may *try* to do 9600, and even have modest success with 
> it, but they are flawed from the start and cannot be counted on for 
> reliable operation.

I've made pretty positive experience with the PR-430 radio (available
through www.wimo.com).  They're not cheap but the combination of a TNC
and a radio virtually eleminates the delicate adjustment procedure
otherwise needed for 9k6 and the 12ms RX -> TX and 10ms TX -> RX switching
times means this radio isn't a hazard to the whole network.

Downside - the radio is running a variant of the 6pack protocol that needs
extensive changes to the Linux 6pack driver; while I do have such a
driver it's not yet in the shape for going to kernel.org ...

  Ralf

Re: YAM/Tekk help

[Chuck Hast]

On 11/23/05, Ralf Baechle DL5RB <ralf@linux-mips.org> wrote:
> On Tue, Nov 22, 2005 at 12:57:38AM -0600, David Rivenburg wrote:
>
> > Only 3-4%?  That's actually pretty good.  Reliable 9600 baud packet is
> > practically nonexistant without using hardware specifically designed for
> > 9600 baud baseband fsk.  I am not aware of any commercial radio or tnc
> > that is.  They may *try* to do 9600, and even have modest success with
> > it, but they are flawed from the start and cannot be counted on for
> > reliable operation.
>
> I've made pretty positive experience with the PR-430 radio (available
> through www.wimo.com).  They're not cheap but the combination of a TNC
> and a radio virtually eleminates the delicate adjustment procedure
> otherwise needed for 9k6 and the 12ms RX -> TX and 10ms TX -> RX switching
> times means this radio isn't a hazard to the whole network.
>
> Downside - the radio is running a variant of the 6pack protocol that needs
> extensive changes to the Linux 6pack driver; while I do have such a
> driver it's not yet in the shape for going to kernel.org ...
>

Ralf,
What is the freq coverage of the radio? I know it is somewhere around 430 Mhz,
but in this country we have a lot of packet up in the 440 region. If
the radio goes
up there that is good. The price for the radio alone was not all that
bad at 195 Euros.

The other factor is that we also have packet radio on 145 Mhz and 220 Mhz, so
radios are needed for those bands. This is where the Tait radios come in, they
are about double the price, but the 8100 series radios will do data very well,
indeed the radio was designed for data and voice with data taking a
high priority.

Tait is supposed to be looking at bringing out a 900Mhz version of that radio
also, that will open that band up to us here (Region II has 900 Mhz as a ISM
and amateur radio band, Region I it is used for GSM)

I have been testing them here in Tampa and am very impressed with the radio.



--
Chuck Hast
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Re: YAM/Tekk help

[Ralf Baechle DL5RB]

On Wed, Nov 23, 2005 at 10:38:46AM -0500, Chuck Hast wrote:

> Ralf,
> What is the freq coverage of the radio? I know it is somewhere around 430 Mhz,
> but in this country we have a lot of packet up in the 440 region. If
> the radio goes
> up there that is good. The price for the radio alone was not all that
> bad at 195 Euros.

I can't give you actual number for the RX / TX frequency range but I'm
quite certain it goes beyond the Region 1 frequency range of 430-440MHz.
I suggest you check with the manufacturer; they should hopefully also
be able to tell you if the radio doesn't only transmit but also delivers
a clean signal.  You don't want the FCC hop in for a visit ;-)

  Ralf  (being paranoid today ...)

Re: YAM/Tekk help

[Gérard / F6FGZ]

Ralf Baechle DL5RB a écrit :

> I can't give you actual number for the RX / TX frequency range but I'm
> quite certain it goes beyond the Region 1 frequency range of 430-440MHz.
> I suggest you check with the manufacturer; they should hopefully also
> be able to tell you if the radio doesn't only transmit but also delivers
> a clean signal.  You don't want the FCC hop in for a visit ;-)

BTW, if you need the technical and maintenance manual, I have a PDF on line.

http://f6fgz.free.fr/Fichiers/KS-1000.pdf

--
73 Gérard F6FGZ



-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAM/Tekk help

[Chuck Hast]

On 11/23/05, Gérard / F6FGZ <f6fgz@free.fr> wrote:
> Ralf Baechle DL5RB a écrit :
>
> > I can't give you actual number for the RX / TX frequency range but I'm
> > quite certain it goes beyond the Region 1 frequency range of 430-440MHz.
> > I suggest you check with the manufacturer; they should hopefully also
> > be able to tell you if the radio doesn't only transmit but also delivers
> > a clean signal.  You don't want the FCC hop in for a visit ;-)
>
> BTW, if you need the technical and maintenance manual, I have a PDF on line.
>
> http://f6fgz.free.fr/Fichiers/KS-1000.pdf
>
Gérard,
This appears to be the manual for the KS-1000 Tekk radio. I looked in your
directory to see if there was a pdf for the PR-430, but saw nothing.

--
Chuck Hast
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAM/Tekk help

[Chuck Hast]

On 11/23/05, Ralf Baechle DL5RB <ralf@linux-mips.org> wrote:
> On Wed, Nov 23, 2005 at 10:38:46AM -0500, Chuck Hast wrote:
>
> > Ralf,
> > What is the freq coverage of the radio? I know it is somewhere around 430 Mhz,
> > but in this country we have a lot of packet up in the 440 region. If
> > the radio goes
> > up there that is good. The price for the radio alone was not all that
> > bad at 195 Euros.
>
> I can't give you actual number for the RX / TX frequency range but I'm
> quite certain it goes beyond the Region 1 frequency range of 430-440MHz.
> I suggest you check with the manufacturer; they should hopefully also
> be able to tell you if the radio doesn't only transmit but also delivers
> a clean signal.  You don't want the FCC hop in for a visit ;-)
>

Haaa! they should visit more sites, most of them are diry noise generators.

I shall check with them as the price is not at all bad. Also will ask if they
have wider filters for higher speeds.


--
Chuck Hast
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Re: YAM/Tekk help

[Ralf Baechle DL5RB]

On Wed, Nov 23, 2005 at 02:05:24PM -0500, Chuck Hast wrote:
> Date:	Wed, 23 Nov 2005 14:05:24 -0500
> From:	Chuck Hast <wchast@gmail.com>
> To:	Ralf Baechle DL5RB <ralf@linux-mips.org>
> Subject: Re: YAM/Tekk help
> Cc:	ad5oo@arrl.net, linux-hams@vger.kernel.org,
> 	Jim Meehan <jmeehan@vpizza.org>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On 11/23/05, Ralf Baechle DL5RB <ralf@linux-mips.org> wrote:
> > On Wed, Nov 23, 2005 at 10:38:46AM -0500, Chuck Hast wrote:
> >
> > > Ralf,
> > > What is the freq coverage of the radio? I know it is somewhere around 430 Mhz,
> > > but in this country we have a lot of packet up in the 440 region. If
> > > the radio goes
> > > up there that is good. The price for the radio alone was not all that
> > > bad at 195 Euros.
> >
> > I can't give you actual number for the RX / TX frequency range but I'm
> > quite certain it goes beyond the Region 1 frequency range of 430-440MHz.
> > I suggest you check with the manufacturer; they should hopefully also
> > be able to tell you if the radio doesn't only transmit but also delivers
> > a clean signal.  You don't want the FCC hop in for a visit ;-)
> >
> 
> Haaa! they should visit more sites, most of them are diry noise generators.
> 
> I shall check with them as the price is not at all bad. Also will ask if they
> have wider filters for higher speeds.

The thing is built for 1k2 AFSK / 9k6 FSK.  I suspect anything else will
require surgery.

73 de DL5RB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21