[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Amateur Radio APRS AX.25 A-FSK
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Amateur Radio APRS AX.25 A-FSK |
Date: |
Fri, 14 Jan 2005 15:52:58 -0800 |
User-agent: |
Mutt/1.5.6i |
On Fri, Jan 14, 2005 at 04:22:57PM -0700, address@hidden wrote:
>
> I'm starting an effort to implement transmit/receive functions for the
> amateur radio APRS (AX.25) standard using 1200 bps A-FSK. I've provided
> background information on the standard at the end of this message. The
> project is designed to learn about GNU Radio as well as contribute
> something to the project. Now on to the questions/comments:
>
> Is anyone else working on this effort? (I don't want to spend time
> inventing yet another wheel).
>
> This is an Eric type question, what is the best way to implement this
> function? Here is the demod path:
>
>
> NCO Tuner (select frequency) >
> Filter to channel bandwidth (16KHz typically) >
> FM Demod >
> Filter for each tone (1200Hz / 2200Hz) >
> Integrate/Dump (1200bps) >
> NRZI decode >
> Search for start symbol >
> Decode bit stream >
> Check and generate complete message
>
> How many of these are already in the GNU library?
Yes. Most of them.
In fact there's an FSK receiver and transmitter in
gnuradio-examples/python/usrp1/fsk_{tx,rx}.py
They need a bit of work, but as I recall, they worked last time I tried.
> Was the thought of GNU core primitives to take a sampled baseband signal
> and generate a data stream output?
Yes.
> Can the same primitives operate on the stream and generate a complete
> message that could be sent to a log file or to other processes via a
> TCP/IP socket? For example, received APRS messages could be logged to a
> database.
Yes. The tcp sink and source need to be ported. They both existed in
the 0.9 code base... or using the idea below, you'd just send a
message with the decoded packet to some python code that did whatever
it liked with it.
The other plan I have is for a message passing overlay that works along
with the data flow model. The primitives would be:
* Thread safe message queues
* Some kind of message with a fixed and a variable length component
* Have every signal block have an optional msg queue.
* Arbitrary python code can create msg queues and send or receive
from them.
Eric