discuss-gnuradio
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]