| |
PA2AGA > HDDIG 06.02.00 14:24l 207 Lines 6797 Bytes #-9589 (0) @ EU
BID : HD_2000_36E
Read: DL6KCF GUEST
Subj: HamDigitalDigest 2000/36E
Path: DB0AAB<DB0FSG<DB0SL<DB0RGB<DB0ABH<DB0SRS<DB0AIS<DB0ME<ON6AR<PI8HWB<
PI8HGL<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 000206/0931Z @:PI8VNW.#ZH2.NLD.EU #:49909 [HvHolland] FBB7.00g24
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA29933 ; Sun, 06 Feb 00 08:08:24 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.70/7.5.3) with SMTP
id AA00017812 ; Sun, 06 Feb 2000 02:31:46 MET
Date: Sun, 06 Feb 00 02:25:09 MET
Message-Id: <hd_2000_36E>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 2000/36E
X-BBS-Msg-Type: B
have this mode as well (and are usually operated in this mode).
The software needs to catch those interrupts, and twiddle its state to
not send more output to the UART when CTS state says it shouldn't.
But the bytes that were already put in the UART will still be sent out
to the line. The driver cannot reliably "cancel" bytes already written
to the UART.
Traditionally, this could be up to two bytes: one in the transmitter
shift register (the one currently being shifted out), the other in the
transmitter holding register (the next one to be clocked into the shift
register).
However, with the advent of FIFO buffers, there can be more bytes waiting
in the UART. The popular 16550A has a 16-byte FIFO, although it can be
configured to contain fewer bytes.
"It only happens under Windows" is probably a matter of slow reaction to
interrupts, that is a general problem with Windows. This was the reason
the FIFO UARTs were introduced in the first place: in the 486 days, when
a Windows machine had extreme trouble to reliably keep up with a UART
above 9600 bps when it had no FIFO, my Linux system happily did 57600
without ever losing a byte. To reliably receive data without loss, you
need to react to each interrupt quickly enough. Windows, because of the
frequent disabling of interrupts during long code fragements, doesn't.
This is probably because of switching between different CPU modes.
Transmit is less critical, but CTS handshake is, in a sense. When you
don't react on the CTS interrupt quickly, you would in theory be in the
position to send more data while the CTS line is low. However, the sending
of data is done in an interrupt handler as well, and one would need to
have a very stupidly designed driver for it to continue servicing transmit
interrupts while it is putting off service of CTS interrupts...
I don't know how this detail is handled in Windows, but I cannot believe
it would be implemented that way. On the other hand...
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1chl@amsat.org | WWW: http://www.knoware.nl/users/rob |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
>.
------------------------------
Date: Thu, 03 Feb 2000 08:19:21 GMT
From: Don <dnelsch@neo.rr.com>
Subject: Kenwood D700A arrived
By using the menu option on the D700, you can change that speed! RTFM!
Gun Steele wrote:
> What computer are you using with your D700A? We got ready to use one of our
> IBM z-50's and noticed that the data rate between radio and computer was
> held to 9600bps @ the radio and the z-50 com port cannot apparently be set
> lower than 19200. Don't think it's worth digging up a null modem adapter
> that the PakRattCE needs, if there is no chance for a correct connection
> speed.
>
> Gun Steele, WØGUN
> SYNERTOOL
> "Chris Arndt" <carndt@slonet.org> wrote in message
> news:%vse4.9$v8.3107@news.callamer.com...
> > I don't know, to both questions.
> >
> > In article <VA.0000034a.0001b8c3@p233>,
> > Joop van der Velden <pe1dna@amsat.org> wrote:
> > >Chris Arndt wrote:
> > >
> > >> This is a dual band 200 channel radio, and can do the standard 2m/440,
> > >> also 2m/2m, and I think 440/440. There is an integral 1200/9600 TNC,
> which
> > >> can be used split between bands for PACSAT work.
> > >
> > >> Post questions and I'll try to answer them.
> > >
> > >What is the tx <> rx turnaround time ?
> > >What is the bit error rate for 9600bd use ? Did they make the classical
> > >mistake of modulating the VCO ?
> > >
> > >--
> > >Joop van der Velden
> > >pe1dna@amsat.org
> > >
> > >
> >
> >
>.
------------------------------
Date: Thu, 03 Feb 2000 13:43:55 -0800
From: Dana Myers K6JQ <dana@source.net>
Subject: Kenwood D700A arrived
This is a multi-part message in MIME format.
--------------8C76A58D6376E074FC379EC3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Gun Steele wrote:
> I would RTFM if there were more hours in a day!! Besides, after all of the
> 'cup holder type support questions' we field; I suppose we're allowed one
> too.
I suppose so, but "I'm too busy to read the manual" is about the worst excuse
in the book. It's like saying "We don't have time to stop for gas" when
driving somewhere.
--------------8C76A58D6376E074FC379EC3
Content-Type: text/x-vcard; charset=us-ascii;
name="dana.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dana Myers K6JQ
Content-Disposition: attachment;
filename="dana.vcf"
begin:vcard
n:Myers;Dana H.
x-mozilla-html:FALSE
url:http://www.source.net/dana/
adr:;;;;;;
version:2.1
email;internet:dana@source.net
x-mozilla-cpt:;-22336
fn:Dana H. Myers K6JQ
end:vcard
--------------8C76A58D6376E074FC379EC3--
>.
------------------------------
Date: Fri, 04 Feb 2000 17:56:25 GMT
From: apbiddle@ateaandtee.not (Alan WA4SCA)
Subject: Motorola 56002EVM needed
Hi,
It looks as if the source has really dried up. If anybody has one
gathering dust and wants to sell it, please let me know. I have a
TAPR Interface Kit with nothing to interface. <grin>
--
Alan
WA4SCA
For E-mail reply, please reply to:
Napbiddle@att.net, removing the "N"
from the front, since the other address
is reserved for spam only.
>.
------------------------------
Date: 04 Feb 2000 20:16:53 GMT
From: btf1@aol.com (Btf1)
Subject: New : Analyzer2000 4.0
Analyzer2000, one of the world's most fastest and famous audio/radio
analyzers,
is now available in the 4.00 version.
It's full functional shareware and can be download at
http://www.brownbear.de
NEW : Universal Demodulator for FSK/F7B and other FM based modulations
with Baudrate Estimation, Hellschreiber and Frame Detection
+++Superfast spectral analysis with FFT display for time and frequency variant
signals
+++FFT sizes from 256 to 16384 points, dynamic range up to 160 dB, graphical
zoom up to 32:1
+++linear or logarithmic frequency axis
+++Time analysis with oscilloscope and envelope display
+++Sonagraphic analysis with waterfall display
+++Measurement tools like markers, frequency rulers, level rulers, time rulers
+++Easy determination of THD, SNR (SINAD) and VCO phase noise (dBc/Hz)
+++Built-in test generator for sinewave and/or noise stimulation (full duplex
To be continued in digest: hd_2000_36F
Read previous mail | Read next mail
| |
