Ham radio designates as QRP transmission carrying low power (5W or less) and QRPp those that are even smaller, 1W or less.
As ham radio can legally use (depending on band privileges and categories of each license) up to 1.5 KW (1500 W) the QRP power, and even further the QRPp power, looks as pointless and not usable.
This is far from the truth. Really small power can be enough to sustain communications over great distances and therefore being a per se limiting factor to communicate, however there might other factors in the basic implementation which makes enables or makes it difficult to communicate for other reasons. Antenna setup, transmission mode and propagation conditions can be counted among some of these factors.
Great distances can be achieved using the HF spectrum (3 to 30 MHz) where most of the traditional ham bands are located; local coverage can be achieved using VHF (30 to 300 MHz), UHF (300 to 3000 MHz) and Microwaves (3000 MHz and beyond) where QRP or less power is the norm but essentially the communication happens within the, pretty much, observable horizon.
Bands below HF, such as medium frecuencies (300 KHz to 3 Mhz) or even lower (less than 300 KHz) requires power well above the QRP levels and/or combined with very specialized antennas.
Having HF as the target band for the project the higher the frequency the larger the distance which can be achieved with QRP power levels, however, the hight the frequency the more dependent the actual propagation is from the moment of the day and solar conditions, A great deal of information about this topic can be obtained from here.
At the ham bands communications can be carried using different modes, which is the way the information is "encoded" in the signal. The most obvious way is just talking, called Phone in ham parlance. In ham bands Phone communications is carried out using SSB (USB or LSB depending on the band), in some higher bands narrow band FM is also used (28 MHz) but this mode is fairly more popular in VHF and beyond rather than HF. Phone conversations can also be carried using amplitude modulation (AM) like the one used by broadcast radios but this mode, even if still used, is relatively inefficient for lower powers and trend not to be much used. Modes not carrying actual voice are also fairly popular. The oldest and more traditional is CW where information is sent using Morse code, to many the most efficient mode of communication since it requires very low powers to achieve long distance communications, this situation is actually being changed with the introduction of Weak Signal Modes (such as FT8) where highly specialized coding techniques are used to carry small amoount of informations using incredibly low powers and still been able to be decoded in the other side. The modes hams uses for communications are many to be discussed in detail here, further information can be obtained from here.
Finally, for a short introduction at least, an antenna component is required to carry ham radio communications. A very specialized topic by itself and a field of endless experimentation. More information about this topic can be obtained from here.
In order to use amateur radio bands for listening the activity is free and without requirements, in most parts of the world at least, check your local communications authorities requirements for the subject to find any condition to met. In the HF bands persons doing that activities are close relatives of Hams, usually called SWL (Short Wave Listerners) and for many it's a very specialized hobby, which by the way isn't incompatible with being a Ham at the same time. See here.
To carry amateur radio comunications, the radioamateurs or "hams", needs to both receive and transmit at designated frequencies, which are called "ham bands", although ham frequencies "allocations" are somewhat generic for that particular use, each communication authority at each band allow individuals to access certain segments based on their license level or "privileges", typically associated with demonstrated technical ability, proof of mastery of certain aspects of ham radio or age in the activity. Certains part of the bands are, at the same time, designated to carry specific modes in them; although the general assignment is made at the global level each administration usually introduces a fine tuning on that usage based on their own spectrum management policies. As an example ham radio frequency assignments or "band plan" for USA can be seen here but remember to check the ones specific for your country.
Digital signal processing here techniques applied to radio communications are normally named software defined radio, further information here.
Some recent technology breakthrus has been made quite recently that enables very sophisticated projects to be made by individual experimenters, in particular for this project the following combination:
- Very cheap digital generic purpose receivers such as the RTL-SDR dongle, see the RTL-SDR site here.
- Very powerful yet affordable high performance embedded boards able to execute Linux, see the Raspberry Pi site here.
- Direct frequency synthesis libraries enabling the Raspberry Pi to act as a RF generator on frequencies from 0 to 1000 MHz and beyond, see the librpitx site here.
The Orange Thunder project is a technology implementation looking to act as a proof of concept of merging the above technologies, glue them together with many public domain libraries and developing some structure code to glue all together into implementing a ham radio transceiver with the following general spec.
- Specialized for the 20m (14 MHz band) but able to be implemented with TAPR filter/amplification boards to any other band.
- Able to operate in most ham usual modes such as CW, SSB, PSK31, FM, SSTV, RTTY and, specially, in FT8.
- Low consumption, able to be feed with a single +5V cc@2A power supply.
- Relatively simple to implement, simple additional circuitry with common parts needed.
- A platform for learning and further experimenting thru its release under a Open Source.
- Headless operation (minimum hardware controls) thru software such as FLRig or rigctl.
- Can operate stand-alone or paired with another computer acting like a standard transceiver.
- Support CAT operations with a limited emulation of a Yaesu FT817 protocol.
- External soundcard support for voice modes (Phone, SSB) or externally generated modes.
- Forgiving and tolerant implementation, avoiding novice catastrophic mistakes turning them into learning experiences.
- Hopefully, a platform to get some well deserved fun.
This statement of specs will be implemented slowly over time, progress will be checked at this repository.
A very similar project, based on the same foundations is named PixiePi, software libraries created for it are used on this project, and viceversa. The main difference among projects is the hardware used to implement the transceiver.
Main features and differences of PixiePi compared with OrangeThunder
- The receiver chain is a direct conversion receiver and the transmitter chain a CW (class C) amplifier, based on the DIY kit Pixie.
- It is based on a Raspberry Pi Zero board which is substancially less powerful than a Raspberry Pi 3 or 4 board.
- It is intended to be used pretty much as a stand alone transceiver as it lack resources to host a user and GUI usage.
- Requires a 9 to 12V power supply
- Mostly headed toward CW usage although other modes are supported.
- Optionally allows a local control with LCD display, tuning knob and other direct operation hardware.
This is a pure, non-for-profit, project being performed in the pure ham radio spirit of experimentation, learning and sharing. This project is original in conception and has a significant amount of code developed by me, it does also being built up on top of a giant effort of others to develop the base platform and libraries used. Therefore this code should not be used outside the limits of the license provided and in particular for uses other than ham radio or similar experimental purposes. No fit for any purpose is claimed nor guaranteed, use it at your own risk. The elements used are very common and safe, the skills required very basic and limited, but again, use it at your own risk. Despite being a software enginering professional with access to technology, infrastructure and computing facilities of different sorts I declare this project has been performed on my own time and equipment.
Raspberry Pi is a marvel.
Hamradio is the best thing ever invented.
¡So don't ruin either by connecting GPIO4 directly to an antenna!
You'll make life of others in your neighboor unsormountable, and even could get your Raspberry Pi fried in the process.
Google "raspberry pi rpitx low pass filter" to get some good advice on what to put between your Raspberry and your antenna Or go to https://www.dk0tu.de/blog/2016/05/28_Raspberry_Pi_Lowpass_Filters/ for very good and easy to implement ideas
Remember that most national regulations requires the armonics and other spurious outcome to be -30 dB below the fundamental.
*********************************************************
* Unfinished - incompletely published code - WIP *
* No support, issues or requests can be honored until *
* the project stabilizes. Check for updates here *
*********************************************************
Most scripts arguments can be obtained using either -h o --h as argument, or just execute without them
Most pre-requisites are described on the excellent tutorial "Setting up a low cost QRP monitoring station with an RTL-SDR V3 and Raspberry Pi 3" here
sudo apt-get update
sudo apt-get install libusb-1.0-0-dev git cmake -y
git clone https://github.com/keenerd/rtl-sdr
cd rtl-sdr/
mkdir build
cd build
cmake ../ -DINSTALL_UDEV_RULES=ON
make
sudo make install
sudo cp ../rtl-sdr.rules /etc/udev/rules.d/
sudo ldconfig
echo 'blacklist dvb_usb_rtl28xxu' | sudo tee --append /etc/modprobe.d/blacklist-dvb_usb_rtl28xxu.conf
sudo apt-get install pulseaudio pavucontrol mplayer -y
sudo apt-get install ntp
Install ALSA
cd /usr/src
mkdir alsa
cd alsa
cp /downloads/alsa-* .
unzip and install ALSA driver
bunzip2 alsa-driver-xxx
tar -xf alsa-driver-xxx
cd alsa-driver-xxx
./configure --with-cards=aloop --with-sequencer=yes ; make ; make install
unzip and install ALSA firmware
cd ..
bunzip2 alsa-firmware-xxx
tar -xf alsa-firmware-xxx
cd alsa-firmware-xxx
./configure ; make ; make install
unzip and install ALSA utils
cd ..
bunzip2 alsa-utils-xxx
tar -xf alsa-utils-xxx
cd alsa-utils-xxx
./configure ; make ; make install
Install modules into kernel
modprobe snd-aloop ; modprobe snd-pcm-oss ; modprobe snd-mixer-oss ; modprobe snd-seq-oss
You might want to introduce such line into the /etc/rc.local file for automatic loading during startup.
We need to initially create virtual audio sinks for each frequency. The example below will set up a two virtual audio sinks that load on boot. To set up another, simply add more lines from Virtual 2 and and so on. First open the pulseaudio default.pa file:
sudo nano /etc/pulse/default.pa
and add the following lines to the end of the file:
load-module module-null-sink sink_name=Virtual0 sink_properties=device.description="Virtual0"
load-module module-null-sink sink_name=Virtual1 sink_properties=device.description="Virtual1"
We also recommend disabling PulseAudio logging, as this seems to be a large user of CPU cycles.
sudo nano /etc/pulse/daemon.conf Now find "log-level" and change it to "log-level = error". Remove the semi-colon on the log-level line too. Save and exit.
; log-target = auto
log-level = error
; log-meta = no
You can now reload pulseaudio either by rebooting, or running at command line
pulseaudio -k
This library is used to allow the implementation of a virtual serial port enabling the operation thru CAT commands from a program executing in the same machine (i.e. WSJTX or FLDIGI) and with some modifications from a different machine.
The F5OEO's librpitx library (iqdmasync.cpp/h) component is used and it's required to operate the program. Also, the sendiq program from F5OEO is also used to implement the usb transceiver.
Sister project PixiePi sources are needed to build OrangeThunder, therefore it needs to be installed as pre-requisite
cd /home/pi
git clone https://github.com/lu7did/PixiePi
cd PixiePi/src
sudo make
sudo make install
Download and compile code:
sudo rm -r /home/pi/OrangeThunder
cd /home/pi
git clone https://github.com/lu7did/OrangeThunder
cd OrangeThunder/src
sudo make
sudo make install
A simple USB transceiver has been included in the package, it's able to operate on a single frequency within the 14 MHz band (or other bands with suitable changes in the PA & filter hardware) operating as a single frequency, headless, CAT controlled USB transceiver. It's a proof of concept but also a simple transceiver able to operate on digital modes such as FT8, FT4 or WSPR.
Operation using other modes digital modes such as RTTY or PSK31, even CW, is allowed. Theoretically modes requiring linear modulation such as SSB can be implemented as well using examples with the rpitx package.
A simple script is included
cd /home/pi/OrangeThunder
cd bash
./OT4D.sh [f in Hz, defautls to 14074000]
The radio configuration is similar of using a Yaesu FT-817 rig whose CAT interface this program partially emulates, however no real serial port is used and a pipe needs to be used instead, the execution script creates a pipe using the socat program, one end being connected to the program and the other to an application such as WSJTX (/tmp/ttyv1).
The PTT can be activated either using CAT commands or the built in VOX command which needs to be activated in the transceiver.
The audio end uses an ALSA loopback, one end connected to the transceiver program and the other to WSJTX.
in order to execute WSJTX either select from the menue or open a LXTerminal and type:
wsjtx
The rig can be configured at FLRig in a way to control it using the CAT interface thru the virtual serial port /tmp/ttyv1 defined using the socat program at the execution script.
In order to transmit legally, a HAM Radio License is REQUIRED for running this experiment. The output is a square wave so a low pass filter is REQUIRED. Connect a low-pass filter (via decoupling C) to GPIO4 (GPCLK0) and Ground pin of your Raspberry Pi, connect an antenna to the LPF. The GPIO4 and GND pins are found on header P1 pin 7 and 9 respectively, the pin closest to P1 label is pin 1 and its 3rd and 4th neighbour is pin 7 and 9 respectively. See this link for pin layout: http://elinux.org/RPi_Low-level_peripherals
Examples of low-pass filters can be found here: here
TAPR makes a very nice shield for the Raspberry Pi that is pre-assembled, performs the appropriate filtering for the 20m band, and also increases the power output to 20dBm! Just connect your antenna and you're good-to-go! TAPR kit
The expected power output is 10mW (+10dBm) in a 50 Ohm load. This looks neglible, but when connected to a simple dipole antenna this may result in reception reports ranging up to several thousands of kilometers.
As the Raspberry Pi does not attenuate ripple and noise components from the 5V USB power supply, it is RECOMMENDED to use a regulated supply that has sufficient ripple supression. Supply ripple might be seen as mixing products products centered around the transmit carrier typically at 100/120Hz.
DO NOT expose GPIO4 to voltages or currents that are above the specified Absolute Maximum limits. GPIO4 outputs a digital clock in 3V3 logic, with a maximum current of 16mA. As there is no current protection available and a DC component of 1.6V, DO NOT short-circuit or place a resistive (dummy) load straight on the GPIO4 pin, as it may draw too much current. Instead, use a decoupling capacitor to remove DC component when connecting the output dummy loads, transformers, antennas, etc. DO NOT expose GPIO4 to electro- static voltages or voltages exceeding the 0 to 3.3V logic range; connecting an antenna directly to GPIO4 may damage your RPi due to transient voltages such as lightning or static buildup as well as RF from other transmitters operating into nearby antennas. Therefore it is RECOMMENDED to add some form of isolation, e.g. by using a RF transformer, a simple buffer/driver/PA stage, two schottky small signal diodes back to back.
In weak modes some sort of additional time sync is needed, the usage of the ntpd package is recommended.
As of 2017-02, NTP calibration is enabled by default and produces a frequency error of about 0.1 PPM after the Pi has temperature stabilized and the NTP loop has converged.
Frequency calibration is REQUIRED to ensure that the WSPR-2 transmission occurs within the narrow 200 Hz band. The reference crystal on your RPi might have an frequency error (which in addition is temp. dependent -1.3Hz/degC @10MHz). To calibrate, the frequency might be manually corrected on the command line or a PPM correction could be specified on the command line.
NTP automatically tracks and calculates a PPM frequency correction. If you are running NTP on your Pi, you can use the --self-calibration option to have this program querry NTP for the latest frequency correction before each WSPR transmission. Some residual frequency error may still be present due to delays in the NTP measurement loop and this method works best if your Pi has been on for a long time, the crystal's temperature has stabilized, and the NTP control loop has converged.
A practical way to calibrate is to tune the transmitter on the same frequency of a medium wave AM broadcast station; keep tuning until zero beat (the constant audio tone disappears when the transmitter is exactly on the same frequency as the broadcast station), and determine the frequency difference with the broadcast station. This is the frequency error that can be applied for correction while tuning on a WSPR frequency.
Suppose your local AM radio station is at 780kHz. Use the --test-tone option to produce different tones around 780kHz (eg 780100 Hz) until you can successfully zero beat the AM station. If the zero beat tone specified on the command line is F, calculate the PPM correction required as: ppm=(F/780000-1)*1e6 In the future, specify this value as the argument to the --ppm option on the comman line. You can verify that the ppm value has been set correction by specifying --test-tone 780000 --ppm on the command line and confirming that the Pi is still zero beating the AM station.
Preliminary files, pending finalization and fine adjustment, can be found at The Thingiverse
The code uses the RPi PWM peripheral to time the frequency transitions of the output clock. This peripheral is also used by the RPi sound system and hence any sound events that occur during a WSPR transmission will interfere with WSPR transmissions. Sound can be permanently disabled by editing /etc/modules and commenting out the snd-bcm2835 device.
Most credits are inherited from the core package enabling this project which is the librpitx library by Evariste Coujard (F5EOE).
Credits goes to Oliver Mattos and Oskar Weigl who implemented PiFM [1] based on the idea of exploiting RPi DPLL as FM transmitter.
Dan MD1CLV combined this effort with WSPR encoding algorithm from F8CHK, resulting in WsprryPi a WSPR beacon for LF and MF bands.
Guido PE1NNZ [email protected] extended this effort with DMA based PWM modulation of fractional divider that was part of PiFM, allowing to operate the WSPR beacon also on HF and VHF bands. In addition time-synchronisation and double amount of power output was implemented.
James Peroulas [email protected] added several command line options, a makefile, improved frequency generation precision so as to be able to precisely generate a tone at a fraction of a Hz, and added a self calibration feature where the code attempts to derrive frequency calibration information from an installed NTP deamon. Furthermore, the TX length of the WSPR symbols is more precise and does not vary based on system load or PWM clock frequency.
Michael Tatarinov for adding a patch to get PPM info directly from the kernel.
Retzler András (HA7ILM) for the massive changes that were required to incorporate the mailbox code so that the RPi2 and RPi3 could be supported.
Credits will be updated by the many (many) persons that created software ultimately been used in this project.
Have fun! 73 de Pedro LU7DID