(Michael Black) wrote in message ...
tim gorman ) writes:
David Harper wrote:



Is anyone familiar with the hardware details of the FSK process?
Specifically what components are involved in transforming a frequency
into a bit?

Thanks!
Dave

I think you already have a couple of messages on how the frequency can be
generated from a bit.

It appears to me you are asking for the opposite.

You're right, I completely missed that.

Michael VE2BVW

Thanks all, that was informative and I appreciate the insight.

Dave

Ok, I have one more additional question. :-)

For a communications protocol such as RTTY, I know the mark and space
frequencies indicate 0 and 1 values of a (usually) 5-bit character.
But how does the receiving side synchronize with the transmitting
side? How does the receiver continue to properly allocate the
incoming bits? After, say, the 30th bit value, how does the receiver
know that it *IS* the 30th bit value? Especially with three 1's or
three 0's consecutively and no frequency changes...?

Is the receiver just very accurately timed? When it occurs, do the
transitions from 0's to 1's (and vice versa) serve to resynchronize
the receiver with the transmitter?

Sorry for the storm of questions, but thanks in advance!
Dave

Ok, I have one more additional question. :-)

For a communications protocol such as RTTY, I know the mark and space
frequencies indicate 0 and 1 values of a (usually) 5-bit character.
But how does the receiving side synchronize with the transmitting
side? How does the receiver continue to properly allocate the
incoming bits? After, say, the 30th bit value, how does the receiver
know that it *IS* the 30th bit value? Especially with three 1's or
three 0's consecutively and no frequency changes...?

Is the receiver just very accurately timed? When it occurs, do the
transitions from 0's to 1's (and vice versa) serve to resynchronize
the receiver with the transmitter?

Sorry for the storm of questions, but thanks in advance!
Dave

----- Original Message -----
From: "David Harper"
Subject: FSK technical question


For a communications protocol such as RTTY, I know the mark and space
frequencies indicate 0 and 1 values of a (usually) 5-bit character.
But how does the receiving side synchronize with the transmitting
side? How does the receiver continue to properly allocate the

OK, remember the whole start and stop bit thing?

The line sits at mark when idle. When a character comes, the line drops to
space for one bit time. This is the start bit. Then the 5 or 8 bits are
transmitted, then one, 1.5 or two stop bits, which are really nothing more
than the minimum time between characters. So the receiver is guaranteed *at
least* one bit time of mark followed by exactly one bit time of space
between characters. The receiving side does need to be reasonably accurate,
but only accurate enough to not garble a character. It never has to keep in
sync for more than 10 bits worth (8 data bits plus a start and stop bit).
If the protocol specifies more than one stop bit, from the receiver's
perspective that is nothing more than additional time the transmitter has
allotted to do end of character processing.

On your earlier question about receiving FSK, the various posters answered
what you would do if you wanted to use an SSB or AM rig, or an audio FM rig
to receive FSK. However, a purpose-built FSK receiver would probably use an
FM discriminator, and simply recover data, rather than audio, from the
discriminator. Remember that an FM discriminator has an output that is
related to the frequency. If you fed the discriminator two frequencies, the
output would be two voltages.

...

----- Original Message -----
From: "David Harper"
Subject: FSK technical question


For a communications protocol such as RTTY, I know the mark and space
frequencies indicate 0 and 1 values of a (usually) 5-bit character.
But how does the receiving side synchronize with the transmitting
side? How does the receiver continue to properly allocate the

OK, remember the whole start and stop bit thing?

The line sits at mark when idle. When a character comes, the line drops to
space for one bit time. This is the start bit. Then the 5 or 8 bits are
transmitted, then one, 1.5 or two stop bits, which are really nothing more
than the minimum time between characters. So the receiver is guaranteed *at
least* one bit time of mark followed by exactly one bit time of space
between characters. The receiving side does need to be reasonably accurate,
but only accurate enough to not garble a character. It never has to keep in
sync for more than 10 bits worth (8 data bits plus a start and stop bit).
If the protocol specifies more than one stop bit, from the receiver's
perspective that is nothing more than additional time the transmitter has
allotted to do end of character processing.

On your earlier question about receiving FSK, the various posters answered
what you would do if you wanted to use an SSB or AM rig, or an audio FM rig
to receive FSK. However, a purpose-built FSK receiver would probably use an
FM discriminator, and simply recover data, rather than audio, from the
discriminator. Remember that an FM discriminator has an output that is
related to the frequency. If you fed the discriminator two frequencies, the
output would be two voltages.

...

"David Harper" wrote in message
m...
Ok, I have one more additional question. :-)

Sorry, I skipped something on the previous response.

I answered for ASYNCHRONOUS serial such as RTTY or async ASCII.

Some protocols, such as packet, use SYNCHRONOUS serial. Synchronous serial
is a lot harder to receive. There are no start and stop bits, so the
protocol doesn't involve that part of the overhead that async uses.

There are several synchronous protocols, but they mostly involve two
characteristics.... first, there is some mechanism for the receiver to
recover the clock. Frequently, the clock is embedded in the data, although
is could be sent over another channel. This allows the receiver to know the
bit boundaries. Every so often (typically every data packet) a special
pattern is sent that allows the receiver to identify the character
boundaries. In the common protocols, such as X.25 (or AX.25), there is also
a prohibition against sending too many of the same bit in a row. Special
procedures are invoked if this happens in the data.

...

"David Harper" wrote in message
m...
Ok, I have one more additional question. :-)

Sorry, I skipped something on the previous response.

I answered for ASYNCHRONOUS serial such as RTTY or async ASCII.

Some protocols, such as packet, use SYNCHRONOUS serial. Synchronous serial
is a lot harder to receive. There are no start and stop bits, so the
protocol doesn't involve that part of the overhead that async uses.

There are several synchronous protocols, but they mostly involve two
characteristics.... first, there is some mechanism for the receiver to
recover the clock. Frequently, the clock is embedded in the data, although
is could be sent over another channel. This allows the receiver to know the
bit boundaries. Every so often (typically every data packet) a special
pattern is sent that allows the receiver to identify the character
boundaries. In the common protocols, such as X.25 (or AX.25), there is also
a prohibition against sending too many of the same bit in a row. Special
procedures are invoked if this happens in the data.

...

In (rec.radio.amateur.digital.misc), David Harper wrote:
Ok, I have one more additional question. :-)

For a communications protocol such as RTTY, I know the mark and space
frequencies indicate 0 and 1 values of a (usually) 5-bit character.
But how does the receiving side synchronize with the transmitting
side? How does the receiver continue to properly allocate the
incoming bits? After, say, the 30th bit value, how does the receiver
know that it *IS* the 30th bit value? Especially with three 1's or
three 0's consecutively and no frequency changes...?

Is the receiver just very accurately timed? When it occurs, do the
transitions from 0's to 1's (and vice versa) serve to resynchronize
the receiver with the transmitter?

I don't view it as a storm of questions; I'd be surprised if anyone
did, considering the floods asked by folks in some other newsgroups.

Synchronization can be A Right Bitch. Good, Cheap Timing is part of
the answer, and I think that the receivers also do some timebase
adjustments as needed to keep their bit-rate clocks in sync with the
transmitters'.

When you add start and/or stop bit, things get a lot easier, and
that is the case with most serial communications: you can reset the
character and bit-time clocks per-character. When no sync bits are
present, you have to derive the bit timing and character timing from
the data-bit transitions in the data stream, and things can get a bit
iffy. Telco circuits have hardware that requires K transitions per N
bit times, and will stuff "1" or "0" bits into the stream on one end,
and delete them on the other, before they get to the customer gear,
so that the stream appears to be synchronous, even though it isn't
really synchronous inside the telco circuit.

But TY gear is _asynchronous_: it has bits to signal the start and
end of each character.

The general structure of a TTY character is

Start_Bit, Data_Bits, Stop_Bit.

The Start_Bit tells the machinery that there's a character coming
down the pipe, and that it should get ready to move. When I was doing
military communications, Way Back When, the start bit was a 1.5 bit
time MARK, since there really were parts that had to get ready to
move, clutches to engage, and so on, and the extra time ensured that
things were ready when the first data bit came in. The stop bit was a
1.0 bit SPACE, IIRC, so that there was always a polarity change to
signal a new character. But that's memories almost 40 years old, and
I Could Be Wrong.

Try this for more info:
http://www.repairfaq.org/filipg/LINK/PORTS/F_The_Serial_Port1.html#THESERIALPORT_008

--
Mike Andrews

Tired old sysadmin

In (rec.radio.amateur.digital.misc), David Harper wrote:
Ok, I have one more additional question. :-)

For a communications protocol such as RTTY, I know the mark and space
frequencies indicate 0 and 1 values of a (usually) 5-bit character.
But how does the receiving side synchronize with the transmitting
side? How does the receiver continue to properly allocate the
incoming bits? After, say, the 30th bit value, how does the receiver
know that it *IS* the 30th bit value? Especially with three 1's or
three 0's consecutively and no frequency changes...?

Is the receiver just very accurately timed? When it occurs, do the
transitions from 0's to 1's (and vice versa) serve to resynchronize
the receiver with the transmitter?

I don't view it as a storm of questions; I'd be surprised if anyone
did, considering the floods asked by folks in some other newsgroups.

Synchronization can be A Right Bitch. Good, Cheap Timing is part of
the answer, and I think that the receivers also do some timebase
adjustments as needed to keep their bit-rate clocks in sync with the
transmitters'.

When you add start and/or stop bit, things get a lot easier, and
that is the case with most serial communications: you can reset the
character and bit-time clocks per-character. When no sync bits are
present, you have to derive the bit timing and character timing from
the data-bit transitions in the data stream, and things can get a bit
iffy. Telco circuits have hardware that requires K transitions per N
bit times, and will stuff "1" or "0" bits into the stream on one end,
and delete them on the other, before they get to the customer gear,
so that the stream appears to be synchronous, even though it isn't
really synchronous inside the telco circuit.

But TY gear is _asynchronous_: it has bits to signal the start and
end of each character.

The general structure of a TTY character is

Start_Bit, Data_Bits, Stop_Bit.

The Start_Bit tells the machinery that there's a character coming
down the pipe, and that it should get ready to move. When I was doing
military communications, Way Back When, the start bit was a 1.5 bit
time MARK, since there really were parts that had to get ready to
move, clutches to engage, and so on, and the extra time ensured that
things were ready when the first data bit came in. The stop bit was a
1.0 bit SPACE, IIRC, so that there was always a polarity change to
signal a new character. But that's memories almost 40 years old, and
I Could Be Wrong.

Try this for more info:
http://www.repairfaq.org/filipg/LINK/PORTS/F_The_Serial_Port1.html#THESERIALPORT_008

--
Mike Andrews

Tired old sysadmin

Another little piece of the story is that in start-stop operation the
receiver samples the incoming signal at the place where it expects the
center of the bit to be. Thus it is tolerant of signals that are too
fast or too slow. Of course today it is easy to get the speed very
precise; but in the early days it was a matter of motors with centrifugal
speed governors.

With synchronous transmission the receiver knows where the bit boundaries
are going to be, so it is possible to sample near the end of each bit time
when all of the energy in the received signal has come in. Start-stop
has to throw away roughly half of the energy in each bit because of the
center sampling. Hence synchronous transmission has an advantage in
signal-to-noise ratio.

In the days of mechanical teleprinters, synchronous operation had a much
greater advantage. A mutilated STOP pulse would allow the receiving
shaft to continue rotating, and then several characters would be
received in error as a result of that single bit error. With electronic
reception there is no rotating shaft, so it is possible to reset the
receiver to the starting position instantly.

It is also possible with electronics to achieve a quasi-synchronous
operation with start-stop signals. The idea is that instead of having
the STOP pulse be arbitrarily long, it is of fixed length and an idle
character is sent if there is nothing to send from the keyboard. This
is usually called "diddle". With the incoming data stream being a
steady stream of printable characters and nonprinting idle characters
it is synchronous for the duration of the transmission. The detector
can synchronize to this signal and take advantage of all of the energy
in each signal pulse. The K6STI RITTY software (no longer marketed)
operates on this principle.
--

jhhaynes at earthlink dot net