The satellite Es'Hail-2 is expected to be launched by the end of 2016. This will be the first geostationary satellite carrying an amateur radio transponder. As the launch date comes nearer, it becomes interesting to find a low cost solution to receive its 10GHz downlink.
Several amateurs have been experimenting with low cost LNBFs designed to receive satellite TV. These operate in the Ku band and usually cover the frequencies 10.7GHz-12.75GHz. However, many of these LNBFs have also good performance in the X band, and particularly in the amateur 10GHz band (10GHz-10.5GHz). In fact, the ASTRA-type LNBFs have a local oscillator which can be setted to either 9.75GHz or 10.6GHz. The 9.75GHz local oscillator mixes 10.386GHz (the narrowband terrestrial subband) to 618MHz, which is a frequency covered by most SDRs and conventional scanners. The satellite subband, which is 10.45GHz-10.5GHz gets mixed down to 700MHz-750MHz, a frequency which is also easy to deal with.
This is a quick introduction to my Arduino LED driver project, since the PCBs for the prototype have being shipped from ShenZhen2U a couple of days ago. This project is fairly simple. The idea is to have an Arduino-compatible ATmega328P drive many LED strings, composed of one of the following two types of LEDs: regular or high-efficiency LEDs taking about 30mA, and high-power LEDs modules taking between 700mA and 1A. The applications I have in mind for this project are several lightning projects where a bunch of LEDs have to be controlled, perhaps in a complex way, but without needing much input (or none at all) from the outside world. Christmas and party lightning are good examples.
A total of 4 AL8808 switching mode LED drivers can be installed on the PCB to drive strings of high-power LEDs requiring up to 1A of current. To drive strings of regular LEDs, the BCR420UW6 linear mode LED driver is used. A total of 18 of these can be installed on the PCB. This is as much as you can control with the ATmega328P, as all of the output pins get used.
No USB is included in this project, since the idea is to program it via ISP. In case some interaction with the outside world is needed, the ISP header could be used to interface with SPI hardware. Everything runs off 12VDC which has to be provided by an external switching mode power supply.
This is going to be open source hardware, so when I have actually built and tested the project I will post the schematics and PCB layouts to Github. Stay tuned for more information.
In a radio receiver composed of two stages, the total noise factor can be computed using Friis's formula as
where is the noise factor of the first block, is the gain of the first stage and is the noise factor of the second stage. If is large enough, then the contribution of the second factor is small and the total noise factor of the whole system is essentially the same as the noise factor of the first stage. This is the reason why a low noise amplifier is useful as a frontend, because it has a low noise factor and high gain .
If and are known (perhaps only approximately), then it is easy to check if the contribution of the frontend to the total noise figure is large enough so that the total noise figure is determined by the noise figure such frontend alone. However, it may happen that one or both of and are not known. In email communication, Leif Åsbrink mentioned that there is an easy way of checking the contribution of the frontend without knowing these parameters. The method is to switch off the frontend and note the drop in the noise floor. He gave the following estimates: if the noise floor drops by more than 10dB, then the total noise figure is the same as the noise figure of the frontend up to 1dB; if the noise floor drops by more than 17dB, then the total noise figure is the same as the noise figure of the frontend up to 0.1dB. Here I present the maths behind these kind of estimates.
A comb generator is essentially an RF oscillator whose output is amplified in a non-linear fashion, so that plenty of harmonics are produced. This is an easy way of producing microwave signals. The G0MRF comb generator was originally designed as a 2.4GHz signal source, to help in the alignment of receivers for the amateur radio satellite S-band. It has a 96.013MHz crystal oscillator, so its 25th harmonic falls at 2400.325MHz, right in the satellite allocation of the 13cm amateur band. Its harmonics are usable up to at least 10GHz, so this can be an useful tool when working with microwave equipment.
In fact, several other harmonics fall on the amateur bands: The 13th harmonic is 1248.169MHz. This is inside the 23cm amateur band, but quite far from the narrow-band segment, which is at 1296MHz. The 24th harmonic is 2304.312MHz. This falls inside the 13cm band. Indeed, 2302MHz is used for EME in some parts of the world. The 36th harmonic is 3456.468MHz, in the 9cm band, but far from the narrow-band segment. The 59th harmonic is 5664.767MHz, in the 6cm band. This is in the satellite uplink segment and quite near the first narrow-band segment, which is at 5668MHz. The 60th harmonic is 5760.780MHz, right in the second narrow-band segment of the 6cm band. The 105th-109th harmonics all fall in the 3cm band. In particular, the 108th harmonic is 10369.404MHz, which is in the narrow-band segment of the 3cm band.
This is a nice kit which is quite easy to build. Most of the components are through-hole, and it can be put together fairly quickly. I built my kit during the Christmas holidays, but I've had the PCB lying around until I installed it in a project box yesterday. Here I describe the kit briefly and show the extruded aluminium case I've used.
The Hardrock-50 HF is a very nice kit for a 50W amateur HF amplifier covering the 160m through 6m bands. It supports interfacing with the FT-817. With the proper cable, the amplifier can be connected to the ACC jack on the FT-817 in order to do PTT keying and read the BAND DATA signal from the FT-817 to select the proper band in the amplifier's low pass filter automatically. The connections required are shown in the Hardrock-50 Tech Site. Yesterday, I prepared the cable to interface my amplifier to my FT-817ND. However, I have found a problem in my amplifier that prevents automatic band switching from working properly. Apparently, this problem has been fixed in the newest units and can be fixed with an easy modification in the units which are affected.
Codec 2 is the open source and patent-free voice codec used in FreeDV, a digital voice mode used in amateur radio. Since Codec 2 is designed to be used at very low bitrates (the current version of FreeDV uses 1300bps and 700bps), it does an adequate job at encoding voice, but can't encode well other types of sounds, and thus fails poorly in the presence of noise. Hence, microphones which may be good enough for other applications can give poor results when used for FreeDV (if, for instance, they pick up too much ambient noise or have too much echo). This is a small note about how to test the microphone performance for Codec 2.
Recently, I installed a G4HUP PAT on my FT-817ND. This is a small board which allows one to tap the IF of a conventional radio receiver to use an SDR as a panadapter (essentially, a waterfall display which shows a chunk of spectrum about the frequency tuned on the receiver). In the previous post I described the installation of the hardware. Here I will describe how I've set up Linrad to suit my preferences. One interesting aspect of this set up is that I've ended up adding a bit of code in Linrad to make it read the dial frequency of the radio using CAT and make Linrad track the frequency as one tunes around in the radio.
Today I've been installing the G4HUP PAT kit on my FT-817ND transceiver. This kit is essentially a buffer amplifier that allows one to tap the IF of a transceiver, in order to send it to an SDR. Then, the SDR can be used as a panadapter. This kit is intended as an entry level SMD project and it can be fitted to many popular amateur radio transceivers. In fact, this has been my first SMD project, and I have found it quite easy to solder using the right tools and technique.
Gpredict stores the information for the satellite transponders in plain text files, one file per satellite. These files are called .trsp files. The files shipped with the stable version tend to become outdated pretty soon, as new satellites are launched. However, the project's git repository is usually up to date.
The following shell script will download the files from git and install the .trsp files in Gpredict's config path in the user's home folder. This can be used in Linux and probably other Unix-like operating systems. Something similar can also be done in Windows.
This is just an easy and temporary workaround to keep the transponder files updated, as Alexandru OZ9AEC, who is Gpredict's author, thinks of perhaps using an online database as a long-term solution.
When receiving signals from a satellite, it can be important to correct for the Doppler shift in the signal. Normally, I use Gpredict to track satellites and compute the Doppler shift. Gpredict can control the frequency of a receiver using Hamlib to track the Doppler shift. When using an SDR receiver, there are several possible ways of using Gpredict's frequency control.
Normally, the SDR software doesn't support Hamlib control in a way that it's useful and easy to use for this purpose. This is the case with Linrad, which is the software I use, and probably with many other popular SDR softwares. An easy solution is to let Gpredict completely control the frequency of the SDR receiver through Hamlib and prevent the SDR software from controlling the frequency. With the FUNCube Dongle Pro+, which is the receiver I normally use, this is easy to do. It can be controlled without problem with recent versions of Hamlib, and if you set the dongle in Linrad as an "Undefined" card instead of a FUNCube Dongle, then Linrad will not try to control its frequency.
The problem with this solution is that each time that the frequency gets updated, it does so in a non phase continuous manner, because the PLL of the receiver has to lock on to the new frequency, effectively losing reception for just a tiny amount of time. This supposes no problem for SSB, CW or FM reception, because your ears just don't notice. However, if you want to receive any digital signal or SSTV, the frequency change usually messes with the decoder software, which loses sync and suffers decoding problems. An alternative solution is to leave the receiver frequency fixed and correct for Doppler shift in software.