discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] FW: HF transmitter hardware solutions


From: Daniel Pocock
Subject: Re: [Discuss-gnuradio] FW: HF transmitter hardware solutions
Date: Fri, 8 Apr 2016 21:36:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0


On 07/04/16 20:01,  John Petrich wrote:
> Dan, Lou, Ron, and others,
> 
> Dan you are doing a great job of beating the drum: searching for "solutions
> for transmitting on HF"  The question is a big one and can be broken down
> into three basic issues.  The basic or elemental SDR platform solutions are
> changing rapidly.  With the third generation SDRs, and tightly integrated
> RFICs, there are a number of excellent, high performance, solutions, as has
> been pointed out, and as you well know.
> 
> I think your real question, Dan, asks about the rest of the HF system: the
> elements necessary to complete the transmitter for practical communication
> purposes.  The question moves beyond SDR hardware to that of station
> building.  That station building part of the system, I call the "interface".

Yes, this is very much where I was aiming with this question/email thread

> The "interface" provides the receive and transmit filtering and antenna
> switching, power control, amplifier stages, and other functions.  The
> "interface" is built upon analog technology.  Much information along these
> lines is addressed by the QRP (low power) movement within Amateur Radio.
> The American Radio Relay League (ARRL) publishes small paperback books
> devoted to QRP equipment and station building, and available for purchase
> on-line.  The material covers homemade solutions, as well as purchased kits
> and turnkey solutions.  Maybe, a group of interested GRC/SDR enthusiasts can
> collect and publish a few example systems as starters for those who want to
> experiment in this area.
> 

One thing that arises with SDR is that we will see more people in this
field who have software and DSP knowledge but slightly less hardware
knowledge than the traditional ham.

That is why I keep coming back to the idea of listing some off-the-shelf
solutions on the wiki.

> The second aspect of the "solutions" question asks if there are suitable GRC
> DSPs as starters, at least.  With Lou's help, I have authored a library of
> transceiver DSPs for all of the commonly used HF transmission modes.  The
> GRC DSPs are  'ham friendly' in the sense that they implement functional,
> ordinary and familiar transceiver interfaces.  However, I have no easy means
> to publish the DSP's.  Would collecting and publishing GRC DSPs be helpful
> at addressing your "solutions" question?  If so, what is the best approach
> for maximum visibility to the experimenter community?
> 

It could be interesting to look at how gqrx is being produced and then
packaged in the Debian world and try to get your designs delivered in a
similar way.

Somebody on Debian or Ubuntu can just do

   $ sudo apt-get install gqrx-sdr

and they get everything installed automatically.

> Last but not least, a third issue for communication system functionality, is
> to use the GRC GUI to control the auxiliary functions of an HF transmitter,
> e.g. transmit / receiver relay.  I do not know of a means to access the GPIO
> from the GRC GUI.  My present solution is to use current from the USRP
> transmit or receive LED signal to control external equipment via a relay
> system.  Maybe someone can publish a different solution.
>

There are actually two approaches:

- sensing: the hardware key activates the transmitter and power amp
directly and the GUI is able to sense this transition somehow, through
some input connector

- managed: the hardware key (possibly a joystick button) sends a signal
to the GUI application and the application then sends some control
signal through the GPIO or similar hardware to activate the transmitter
circuits

This type of thing is not too hard with Python and C++ code.

If the flow graph is running in an embedded device like a Raspberry Pi
then it has its own GPIO pins too.

Regards,

Daniel



reply via email to

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