Re: 300bps Packet

[Dave Platt <dplatt@xxxxxxxxxxxx>]

Tsutsumi Family wrote:
> John,
> 
> My experience is the same and it can transmit two tones at 400 bps lowest.
> 
> I wish to analyze the source codes but have not yet done due to my software
> capability limitation.

It looks to me as if the immediate cause of this may lie in the
following code in afsk/modem.c:

        if (params[0]) {
                s->bps = strtoul(params[0], NULL, 0);
                if (s->bps < 100)
                        s->bps = 100;
                if (s->bps > 9600)
                        s->bps= 9600;
        } else
                s->bps = 1200;
        if (params[1]) {
                s->f0 = strtoul(params[1], NULL, 0);
                if (s->f0 > s->bps * 4)
                        s->f0 = s->bps * 4;
        } else
                s->f0 = 1200;
        if (params[2]) {
                s->f1 = strtoul(params[2], NULL, 0);
                if (s->f1 > s->bps * 4)
                        s->f1 = s->bps * 4;
        } else
                s->f1 = 2200;
        s->notdiff = params[3] ? !strtoul(params[3], NULL, 0) : 0;
        *samplerate = 8 * s->bps;

The modem-configuration code appears to be insisting that the
frequencies being used, must be no less than four times the
bit-rate.  The audio sample-generation rate is then set to
8x the bit-rate.

I *think* this is being done, in order to limit the number
of times that the loop down in "modsendbits" must iterate
for each individual bit-symbol being transmitted... looks
like no more than two audio output samples are being
generated per bit.

As a result of this approach, if you try to set the bit
rate to below 575 bits/second, the upper frequency (f1)
can no longer be sustained at 2200 Hz... the software starts
to decrease it.  At 300 bits/second, it ends up being
reduced all the way down to 1200 Hz (4 * 300) and you end
up transmitting a monotone.

For the transmit side of things, you could probably fix
this by changing the logic in this section.  If one were
to disable the logic which selectively reduces s->f0 and
s->f1, one would need to change the final calculation
of *samplerate, and increase the sample rate actually
being used.

It looks to me as if a similar - and probably much hairier -
set of changes would be needed to the demodulator code
further down in this file.  The demodulator is setting
up and using a set of digital filters, through which the
incoming samples are being fed.  You'd need to make changes
to run the receiver/demodulator at a higher sampling rate,
with longer filters, and more samples being captured prior
to being fed into the demodulator filter chain.

So, making this sort of change would be a job for someone
willing to dig through the DSP logic in the modulator and
demodulator, and generalize it a bit (and quite possibly
reduce its performance in the interest of generality).

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