I'm working on a telemetry board and wish to include software FSK1200
(MX-614's are getting harder to find). The official Bell 202 spec is
out of print and hard to find as well, so I pieced this together from
what I can find. Multimon won't decode the output, so I'm likely doing
something wrong. This is supposed to be (once it works) my reference
implementation before I port it to my telemetry board, so I'm trying
to keep it as simple as possible.

The program outputs 22050 hz 8-bit signed data to stdout;
gcc fsk.c -o fsk -lm; ./fsk test; sox -s -b -r 22050 test -w
test.wav

Phase is coherent, and there are peaks at 1200 and 2200 in the
spectrum analysis.

Any help or suggestions would be appreciated.

Robert Cicconetti
KG4MVB

-- begin fsk.c --
#include math.h
#include stdio.h

// $#@$#@
//#define BAUDRATE 1200
// octet rate is 150 octet / sec. (1200 / 8). BIT period is
// .000666, or 1/1500 (10 bits per symbol, including start and stop).
// BAUDRATE is therefor used improperly here; fixme.
#define BAUDRATE 1500
#define MARK 1200
#define SPACE 2200

// For convenience when working with multimon
#define SAMPLERATE 22050

double sendbyte(char a, double angle);

int main (void)
{
// 8 bit output; encoder DAC is likely to be only 3 or 4 bit
short outbyte;
int i;
double angle = 0;
char test[]= "fm KG4MVB-0 to FFFFFF-0 SABM+";

for (i = 0 ; i 5000; i++) putchar(0);
//PREAMBLE
for (i = 0 ; i 24; i++) sendbyte(0, angle);

for (i = 0 ; i 29 ; i++)
{
angle = sendbyte(test[i], angle);
}

for (i = 0 ; i 2; i++) sendbyte(0, angle);
for (i = 0 ; i 50000; i++) putchar(0);
return 0;
}

double sendbyte(char a, double angle)
{
// LSB first. Start bit MARK end bit SPACE
// MARK is 1, SPACE is 0
//
double phase_offset = 0;
int freq, j = 0, i;
char bit;

for (i = 0; i 10; i++)
{
if (i == 0)
bit = 1;
else if (i == 9)
bit = 0;
else
bit =( a (i-1)) & 0x1;

if (bit == 1)
freq = MARK;
else
freq = SPACE;

phase_offset = angle -
(double)2*M_PI*freq*((double)(j-1)/SAMPLERATE);
while (j ((i+1)*SAMPLERATE)/BAUDRATE )
{
angle =
(double)2*M_PI*freq*((double)j/SAMPLERATE) + phase_offset;
putchar((short)(0.5*sin(angle)*128));
j++;
}
}
return angle;
}

On 4 Jul 2003 23:21:05 -0700, (R C) wrote:

I'm working on a telemetry board and wish to include software FSK1200
(MX-614's are getting harder to find). The official Bell 202 spec is
out of print and hard to find as well, so I pieced this together from
what I can find. Multimon won't decode the output, so I'm likely doing
something wrong.

What is this Multimon thing expecting ?

Is it expecting ordinary asynchronous characters ?

// LSB first. Start bit MARK end bit SPACE
// MARK is 1, SPACE is 0

for (i = 0; i 10; i++)
{
if (i == 0)
bit = 1;
else if (i == 9)
bit = 0;
else
bit =( a (i-1)) & 0x1;

In that case I assume you have mixed the polarity of the start and
stop bits.

In ordinary RS-232 asynchronous communication the start bit is "0"
SPACE, interrupting the idle MARK state, followed by the data bits
with LSB sent first. The stop bit is "1" or MARK, which then transfers
to a MARK idle state if no more characters are to be transmitted.

If that Multimon thing is expecting AX.25, don't forget to add the bit
stuffing in the last stage before transmission.

Paul OH3LWR

Paul Keinanen wrote in message . ..
On 4 Jul 2003 23:21:05 -0700, (R C) wrote:

I'm working on a telemetry board and wish to include software FSK1200
(MX-614's are getting harder to find). The official Bell 202 spec is
out of print and hard to find as well, so I pieced this together from
what I can find. Multimon won't decode the output, so I'm likely doing
something wrong.

What is this Multimon thing expecting ?

Okay, I've figured some things out since I first posted. Multimon was
written by Thomas Sailer, who also wrote the soundmodem program.

It's available at http://www.baycom.org/~tom/ham/linux/multimon.html.

Documentation is lacking, but reviewing the source (don't try and
debug at 4 AM; I should've figured this out originally) the afsk1200
decoder expects hdlc encoding, and possibly AX.25 framing (didn't
trace that far). However, an undocumented option -v 10 yields the raw
bit stream.

In that case I assume you have mixed the polarity of the start and
stop bits.

In ordinary RS-232 asynchronous communication the start bit is "0"
SPACE, interrupting the idle MARK state, followed by the data bits
with LSB sent first. The stop bit is "1" or MARK, which then transfers
to a MARK idle state if no more characters are to be transmitted.

That part I figured out from APRS packets recorded off the air. Start
is definately 1200 hz, stop is 2200 hz.

Thanks for the suggestions,
R C
KG4MVB

On 6 Jul 2003 19:46:48 -0700, (R C) wrote:

In ordinary RS-232 asynchronous communication the start bit is "0"
SPACE, interrupting the idle MARK state, followed by the data bits
with LSB sent first. The stop bit is "1" or MARK, which then transfers
to a MARK idle state if no more characters are to be transmitted.

That part I figured out from APRS packets recorded off the air. Start
is definately 1200 hz, stop is 2200 hz.

How did you determine this ?

APRS is definitively AX.25, which is a version of the X.25 protocol,
which are all members of the HDLC protocol family. These protocols
are _synchronous_ protocols, thus, they do not contain any start or
stop bits. The AX.25 protocol sends 8 bit octets (bytes) packed
immediately side by side without any bits in between them forming a
multiple octet frame. The whole frame starts with on octet with the
"01111110" bit pattern (the flag pattern) and it also ends with the
same pattern (or a single flag is used as a _frame_ separators, if
multiple frames are sent at once). In order to avoid false flag
detection within the data part of the frame, the 0 bit is inserted
after five consecutive 1 bits.

To illustrate how synchronous protocols work and how the bit stuffing
is done in HDLC, here is a simplified example (use fixed font).

Assume that you want to send the characters "a?b" which is 0x61 0x3F
0x62. First convert to bits (LSB first)

10000110 = 'a'
11111100 = '?'
01000110 = 'b'

Put them side by side

100001101111110001000110
.........^^^^^...........

Check for 5 consecutive 1 bits and add the bit stuffing.

1000011011111010001000110
_____________I___________

Add the flag octets

01111110100001101111101000100011001111110

It should be noted that the checking for five 1 bits must be done
after the bytes are put into a single bit stream, since sending two
consecutive bytes such as 00001111 11110000 do not violate the
five1bit rule separately, but when the bytes are combined into a bit
sequence, you would end up with 0000111111110000, bit stuffing must be
inserted 00001111101110000. Sending 11111111 11111111 requires three
stuff bits: 1111101111101111101

This a very simplified example, a real AX.25 frame would contain the
address fields and the CRC field at the end.

When you say that the APRS frame starts with a Mark and ends with a
Space, are you sure you are not seeing some effects of TxDelay, i.e.
the Tx is on but no data (or some preamble) is sent.

Paul OH3LWR

Paul Keinanen wrote:
On 6 Jul 2003 19:46:48 -0700, (R C) wrote:


In ordinary RS-232 asynchronous communication the start bit is "0"
SPACE, interrupting the idle MARK state, followed by the data bits
with LSB sent first. The stop bit is "1" or MARK, which then transfers
to a MARK idle state if no more characters are to be transmitted.

That part I figured out from APRS packets recorded off the air. Start
is definately 1200 hz, stop is 2200 hz.


How did you determine this ?

APRS is definitively AX.25, which is a version of the X.25 protocol,
which are all members of the HDLC protocol family. These protocols
are _synchronous_ protocols, thus, they do not contain any start or
stop bits. The AX.25 protocol sends 8 bit octets (bytes) packed
immediately side by side without any bits in between them forming a
multiple octet frame. The whole frame starts with on octet with the
"01111110" bit pattern (the flag pattern) and it also ends with the
same pattern (or a single flag is used as a _frame_ separators, if
multiple frames are sent at once). In order to avoid false flag
detection within the data part of the frame, the 0 bit is inserted
after five consecutive 1 bits.


Well, don't forget that HDLC is NRZI encoded - the absolute level
(mark vs. space) is meaningless. A transition indicates a 0 and
the lack of a transition indicates a 1. Sending a series of 0s
results in a square wave of 1/2 the baud rate (since each baud
is the opposite of the previous baud). Sending a series of 1s
results in a series of unchanged bauds.

So, if the initial state of the NRZI encoder is '1' and the
'01111110' flag sequence is sent, the resulting output is:

initial state 1 : 0 0 0 0 0 0 0 1 and the next flag looks like
0 0 0 0 0 0 0 1 and this pattern repeats as long
as flags are being sent.

If the initial state is 0 you get:

initial state 0 : 1 1 1 1 1 1 1 0 and this pattern repeats.

So, you can't tell anything about the date being sent
from the absolute levels.

Dana

Paul Keinanen wrote in message . ..
APRS is definitively AX.25, which is a version of the X.25 protocol,
which are all members of the HDLC protocol family. These protocols
are _synchronous_ protocols, thus, they do not contain any start or
stop bits. The AX.25 protocol sends 8 bit octets (bytes) packed
immediately side by side without any bits in between them forming a
multiple octet frame. The whole frame starts with on octet with the
"01111110" bit pattern (the flag pattern) and it also ends with the
same pattern (or a single flag is used as a _frame_ separators, if
multiple frames are sent at once). In order to avoid false flag
detection within the data part of the frame, the 0 bit is inserted
after five consecutive 1 bits.

Therein lies the problem I was having. I was looking at this as
another protocol layered on top of an asynchronous serial connection.

Thank you, it makes more sense now. Bitstuffing on a synchronous
serial
connection is trivial. Receiving is slightly less so, but not too
difficult.

I think I got the impression that bell 202 is asynchronous from some
of the commercial bell 202 modems I found on google; nearly all of
them say asynchronous. (Which, on reflection, is probably on the
computer-modem interface.)

Caller ID _does_ use an asynchronous wireline format, and also uses
Bell 202 signaling. Okay.. so it can go either way, and hdlc is
synchronous.

When you say that the APRS frame starts with a Mark and ends with a
Space, are you sure you are not seeing some effects of TxDelay, i.e.
the Tx is on but no data (or some preamble) is sent.

It does indeed appear to be some sort of runout to keep the squelch
from closing too quickly, but the of end packet flag occurs approx. 32
bits before.

Thanks,
R C
KG4MVB
(In any case, telemetry is not required to be AX.25 encapsulated, but
it's nice for interoperation)

Paul Keinanen wrote:
On 6 Jul 2003 19:46:48 -0700, (R C) wrote:


In ordinary RS-232 asynchronous communication the start bit is "0"
SPACE, interrupting the idle MARK state, followed by the data bits
with LSB sent first. The stop bit is "1" or MARK, which then transfers
to a MARK idle state if no more characters are to be transmitted.

That part I figured out from APRS packets recorded off the air. Start
is definately 1200 hz, stop is 2200 hz.


How did you determine this ?

APRS is definitively AX.25, which is a version of the X.25 protocol,
which are all members of the HDLC protocol family. These protocols
are _synchronous_ protocols, thus, they do not contain any start or
stop bits. The AX.25 protocol sends 8 bit octets (bytes) packed
immediately side by side without any bits in between them forming a
multiple octet frame. The whole frame starts with on octet with the
"01111110" bit pattern (the flag pattern) and it also ends with the
same pattern (or a single flag is used as a _frame_ separators, if
multiple frames are sent at once). In order to avoid false flag
detection within the data part of the frame, the 0 bit is inserted
after five consecutive 1 bits.


Well, don't forget that HDLC is NRZI encoded - the absolute level
(mark vs. space) is meaningless. A transition indicates a 0 and
the lack of a transition indicates a 1. Sending a series of 0s
results in a square wave of 1/2 the baud rate (since each baud
is the opposite of the previous baud). Sending a series of 1s
results in a series of unchanged bauds.

So, if the initial state of the NRZI encoder is '1' and the
'01111110' flag sequence is sent, the resulting output is:

initial state 1 : 0 0 0 0 0 0 0 1 and the next flag looks like
0 0 0 0 0 0 0 1 and this pattern repeats as long
as flags are being sent.

If the initial state is 0 you get:

initial state 0 : 1 1 1 1 1 1 1 0 and this pattern repeats.

So, you can't tell anything about the date being sent
from the absolute levels.

Dana

Paul Keinanen wrote in message . ..
APRS is definitively AX.25, which is a version of the X.25 protocol,
which are all members of the HDLC protocol family. These protocols
are _synchronous_ protocols, thus, they do not contain any start or
stop bits. The AX.25 protocol sends 8 bit octets (bytes) packed
immediately side by side without any bits in between them forming a
multiple octet frame. The whole frame starts with on octet with the
"01111110" bit pattern (the flag pattern) and it also ends with the
same pattern (or a single flag is used as a _frame_ separators, if
multiple frames are sent at once). In order to avoid false flag
detection within the data part of the frame, the 0 bit is inserted
after five consecutive 1 bits.

Therein lies the problem I was having. I was looking at this as
another protocol layered on top of an asynchronous serial connection.

Thank you, it makes more sense now. Bitstuffing on a synchronous
serial
connection is trivial. Receiving is slightly less so, but not too
difficult.

I think I got the impression that bell 202 is asynchronous from some
of the commercial bell 202 modems I found on google; nearly all of
them say asynchronous. (Which, on reflection, is probably on the
computer-modem interface.)

Caller ID _does_ use an asynchronous wireline format, and also uses
Bell 202 signaling. Okay.. so it can go either way, and hdlc is
synchronous.

When you say that the APRS frame starts with a Mark and ends with a
Space, are you sure you are not seeing some effects of TxDelay, i.e.
the Tx is on but no data (or some preamble) is sent.

It does indeed appear to be some sort of runout to keep the squelch
from closing too quickly, but the of end packet flag occurs approx. 32
bits before.

Thanks,
R C
KG4MVB
(In any case, telemetry is not required to be AX.25 encapsulated, but
it's nice for interoperation)

On 6 Jul 2003 19:46:48 -0700, (R C) wrote:

In ordinary RS-232 asynchronous communication the start bit is "0"
SPACE, interrupting the idle MARK state, followed by the data bits
with LSB sent first. The stop bit is "1" or MARK, which then transfers
to a MARK idle state if no more characters are to be transmitted.

That part I figured out from APRS packets recorded off the air. Start
is definately 1200 hz, stop is 2200 hz.

How did you determine this ?

APRS is definitively AX.25, which is a version of the X.25 protocol,
which are all members of the HDLC protocol family. These protocols
are _synchronous_ protocols, thus, they do not contain any start or
stop bits. The AX.25 protocol sends 8 bit octets (bytes) packed
immediately side by side without any bits in between them forming a
multiple octet frame. The whole frame starts with on octet with the
"01111110" bit pattern (the flag pattern) and it also ends with the
same pattern (or a single flag is used as a _frame_ separators, if
multiple frames are sent at once). In order to avoid false flag
detection within the data part of the frame, the 0 bit is inserted
after five consecutive 1 bits.

To illustrate how synchronous protocols work and how the bit stuffing
is done in HDLC, here is a simplified example (use fixed font).

Assume that you want to send the characters "a?b" which is 0x61 0x3F
0x62. First convert to bits (LSB first)

10000110 = 'a'
11111100 = '?'
01000110 = 'b'

Put them side by side

100001101111110001000110
.........^^^^^...........

Check for 5 consecutive 1 bits and add the bit stuffing.

1000011011111010001000110
_____________I___________

Add the flag octets

01111110100001101111101000100011001111110

It should be noted that the checking for five 1 bits must be done
after the bytes are put into a single bit stream, since sending two
consecutive bytes such as 00001111 11110000 do not violate the
five1bit rule separately, but when the bytes are combined into a bit
sequence, you would end up with 0000111111110000, bit stuffing must be
inserted 00001111101110000. Sending 11111111 11111111 requires three
stuff bits: 1111101111101111101

This a very simplified example, a real AX.25 frame would contain the
address fields and the CRC field at the end.

When you say that the APRS frame starts with a Mark and ends with a
Space, are you sure you are not seeing some effects of TxDelay, i.e.
the Tx is on but no data (or some preamble) is sent.

Paul OH3LWR

Paul Keinanen wrote in message . ..
On 4 Jul 2003 23:21:05 -0700, (R C) wrote:

I'm working on a telemetry board and wish to include software FSK1200
(MX-614's are getting harder to find). The official Bell 202 spec is
out of print and hard to find as well, so I pieced this together from
what I can find. Multimon won't decode the output, so I'm likely doing
something wrong.

What is this Multimon thing expecting ?

Okay, I've figured some things out since I first posted. Multimon was
written by Thomas Sailer, who also wrote the soundmodem program.

It's available at http://www.baycom.org/~tom/ham/linux/multimon.html.

Documentation is lacking, but reviewing the source (don't try and
debug at 4 AM; I should've figured this out originally) the afsk1200
decoder expects hdlc encoding, and possibly AX.25 framing (didn't
trace that far). However, an undocumented option -v 10 yields the raw
bit stream.

In that case I assume you have mixed the polarity of the start and
stop bits.

In ordinary RS-232 asynchronous communication the start bit is "0"
SPACE, interrupting the idle MARK state, followed by the data bits
with LSB sent first. The stop bit is "1" or MARK, which then transfers
to a MARK idle state if no more characters are to be transmitted.

That part I figured out from APRS packets recorded off the air. Start
is definately 1200 hz, stop is 2200 hz.

Thanks for the suggestions,
R C
KG4MVB