OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
PA2AGA > HDDIG    26.11.99 06:31l 259 Lines 7735 Bytes #-9671 (0) @ EU
BID : HD_99_302B
Read: DL6KCF GUEST
Subj: HamDigitalDigest 99/302B
Path: DB0AAB<DB0PV<DB0MAK<DB0ERF<DB0SHG<DB0BRI<PI8DRS<PI8ZWL<PI8APD<PI8WNO<
      PI8HGL<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 991126/0105Z @:PI8VNW.#ZH2.NLD.EU #:24877 [HvHolland] FBB7.00g $:HD_99_30
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To  : HDDIG@EU

Received: from pa2aga by pi1hvh with SMTP
	id AA24370 ; Fri, 26 Nov 99 00:12:26 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
	id AA00016992 ; Fri, 26 Nov 99 00:51:58 MET
Date: Fri, 26 Nov 99 00:51:34 MET
Message-Id: <hd_99_302B>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/302B
X-BBS-Msg-Type: B

bytes
>> of
>> >> the data packet, and you have to parse those, to tell it which window
>to
>> >go
>> >> to.  All WA8DED knows, is that a host channel got a packet, and it
>tells
>> >> which channel it's on.
>> >>
>> >> And you have to leave WA8DED host mode to use the other modes i.e.
Term
>5
>> >> (which is what XPWin uses).
>> >>
>> >> I've mentioned to Peter at SCS that it might be a good idea to allow
>the
>> >> other modes work through the packet channel. For sure, it would allow
>> >other
>> >> modes than Pactor to allow simultaneous dual port session,  and not
>> having
>> >> to deal with two types of HOST interfaces.
>> >>
>> >> You're probably aware of the PTC-Term program we're working on. It
will
>> >> support WA8DED HOST in the configuration above, and all that remains
>> >> outstanding for us to do, is to add the TERM 5 interface for the other
>HF
>> >> modes.
>> >>
>> >>
>> >> --
>> >> Rick Ruhl
>> >> President, Creative Services Software
>> >> http://www.cssincorp.com
>> >>
>> >> Rob wrote in message ...
>> >> >I am looking for a good packet terminal program for my SCS PTC II
>which
>> >> >supports the WA8DED host mode.  The SCS PTC II has two packet ports -
>> one
>> >> >for 1200 baud and one for 9600 baud.  I would like it to run under
>> >windows
>> >> >98.
>> >> >
>> >> >Unfortunately most the programs for the SCS PTC just handle the HF
>modes
>> >> not
>> >> >Packet.
>> >> >
>> >> >Will WinPak work??  There is any consensus out there on what is the
>best
>> >> >windows packet terminal program that supports WA8DED host mode  (and
>> >> >multiple ports)??
>> >> >
>> >> >73's
>> >> >Rob
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>


>.

------------------------------

Date: 23 Nov 1999 09:10:26 GMT
From: Hamish Moffatt <hamish@rising.com.au>
Subject: Decoding packet with a soundcard in Windows

Rob <NoEmail@NoWay.com> wrote:
> Is this PTT interface the same used by many PSK31 programs for use with a
> soundcard?? (e.g.  G3PLX PSK31 program for windows or LOgger)

Yes.

Depends on the software, of course. All the stuff I've seen works
exactly the same way. The built in HF modem and AX.25/packet stuff from
Tom Sailer supports both parallel and serial ports, and even the 
MIDI/joystick port. Or VOX.


Hamish VK3SB
-- 
Hamish Moffatt       Mobile: +61 412 011 176     hamish@rising.com.au
Rising Software Australia Pty. Ltd.    http://www.risingsoftware.com/
Phone: +61 3 9894 4788    Fax: +61 3 9894 3362    USA: 1 888 667 7839
>.

------------------------------

Date: Thu, 25 Nov 1999 00:36:53 +0000
From: Oliver Welp <welp@muenster.de>
Subject: Decoding packet with a soundcard in Windows

Dale Gillilan wrote:
> 
> Is there a program that will decode and encode Pactor and Wefax for Windows
or
> DOS?

Maybe you want to visit my site:

http://www.muenster.de/~welp/sb.htm

73, Oliver
(DL9QJ, N3NSF)

-- 
[Oliver Welp - welp@muenster.de
 welp@uni-muenster.de
 http://www.muenster.de/~welp/]
>.

------------------------------

Date: Mon, 22 Nov 1999 11:23:00 GMT
From: Bent Bagger <bentbagger@my-deja.com>
Subject: DSP-12 Info

I have tried to e-mail you directly - hope yoy get it.

Bent


Sent via Deja.com http://www.deja.com/
Before you buy.
>.

------------------------------

Date: Wed, 24 Nov 1999 11:29:10 GMT
From: nomail@pe1chl.demon.nl (Rob Janssen)
Subject: JNOS vs TNOS??

Cathryn Mataga <cathryn@junglevision.com> wrote:
>I believe there's an advantage to running NOS over internet based IP stacks
>like with Linux and WIndows, that you can specify that the retry timers
backoff
>linearly, rather than exponentially.

That is actually a disadvantage.  It causes congestion collapse, and
makes outside observers judge TCP/IP as a bad protocol that jams
everything else.

>Apparently, this is considered extremely
>evil from the internet perspective, but it's a fast kluge to get ip to work
>a little better when the connection is dropping packets due to noisy links--
>rather than congestion. (There's a linux Kernel hack, I thought someone
posted
>to do this, though I haven't seen anything like this for Windows.)

Actually, when your links drop packets you should not attempt to retransmit
them from the endpoints, but you should adjust your links (individually)
to use a virtual circuit rather than a datagram technique to send the
packets over that hop.

Most NET and NOS versions support this.
My version of NET even allows you to setup automatic selection of VC or
Datagram mode based on the independently measured packet loss rate on the
connection, separately for each direction.
This works very well, without requiring inefficient retransmissions from
the endpoints that yield TCP/IP a bad reputation.

>It's actually, just a hard situation all around, the more I've looked into
this, since
>my understanding is that TCP/IP doesn't really work that efficiently either
if the
>underlying protocol provides reliable connections, or if the channel drops
packets
>do to random errors, and not due to congestion.

Right.  So just fix that.

Rob
-- 
+----------------------------------+--------------------------------------+
| Rob Janssen     pe1chl@amsat.org | WWWhome: http://www.pe1chl.demon.nl/ |
| AMPRnet:     rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
>.

------------------------------

Date: Wed, 24 Nov 1999 11:07:41 -0500
From: "Rob" <NoEmail@NoWay.com>
Subject: JNOS vs TNOS??

It sounds like IP/TCP is dying and most hams are turning back to NETROM  (or
KNET etc)

Rob

"Rob Janssen" <nomail@pe1chl.demon.nl> wrote in message
news:slrn83nj06.ue2.nomail@linux.pe1chl.ampr.org...
> Cathryn Mataga <cathryn@junglevision.com> wrote:
> >I believe there's an advantage to running NOS over internet based IP
stacks
> >like with Linux and WIndows, that you can specify that the retry timers
backoff
> >linearly, rather than exponentially.
>
> That is actually a disadvantage.  It causes congestion collapse, and
> makes outside observers judge TCP/IP as a bad protocol that jams
> everything else.
>
> >Apparently, this is considered extremely
> >evil from the internet perspective, but it's a fast kluge to get ip to
work
> >a little better when the connection is dropping packets due to noisy
links--
> >rather than congestion. (There's a linux Kernel hack, I thought someone
posted
> >to do this, though I haven't seen anything like this for Windows.)
>
> Actually, when your links drop packets you should not attempt to
retransmit
> them from the endpoints, but you should adjust your links (individually)
> to use a virtual circuit rather than a datagram technique to send the
> packets over that hop.
>
> Most NET and NOS versions support this.
> My version of NET even allows you to setup automatic selection of VC or
> Datagram mode based on the independently measured packet loss rate on the
> connection, separately for each direction.
> This works very well, without requiring inefficient retransmissions from
> the endpoints that yield TCP/IP a bad reputation.
>
> >It's actually, just a hard situation all around, the more I've looked
into this, since
> >my understanding is that TCP/IP doesn't really work that efficiently
either if the
> >underlying protocol provides reliable connections, or if the channel


To be continued in digest: hd_99_302C




Read previous mail | Read next mail


 19.05.2026 11:42:37lGo back Go up