<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi Michelle,<br><br>Here's my first pass. Suggested changes:<br><br></div>change "aquire" to "acquire"<br></div>change "unecessarily" to "unnecessarily"<br></div>change "Curently" to "Currently"<br></div>change ""imabalance" to "imbalance"<br></div>change "ony" to "only"<br></div>change "demdulator" to "demodulator"<br></div>change ""operating moded" to "operating mode" ?<br></div><div>change "recordingq" to "recording"<br><br></div><div>For the sentence containing "...this noise is only <br>noticeable in without antenna noise covering it up"<br></div><div>remove the "in" or rewrite. <br></div><div><br></div>I would suggest a slightly different frequency for the example<br>"147m435" (147.435 MHz) as "435" is frequently used in the<br></div>context of 435 MHz (at least for satellite work) and this might<br></div>cause some confusion.<br><br></div><div>In written text, the FUNcube dongle is usually written as "FUNcube" <br>with the first three letters capitalized (Source: <a href="http://www.funcubedongle.com/">http://www.funcubedongle.com/</a>)<br></div><div><br></div>Is there a link to download the software? <br><br></div>Still checking,<br></div>Douglas KA2UPW/5<br><br><div><div><div><div><div><div><br><div><div><br></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 21, 2018 at 2:01 PM, Michelle Thompson via Ground-Station <span dir="ltr"><<a href="mailto:ground-station@lists.openresearch.institute" target="_blank">ground-station@lists.openresearch.institute</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Call for Comment and Critique. Contents are below. File is also attached! See most recent weekly report for an introduction to this package.<br><br>-mdt<div><br></div><div><br></div><div><br><br>ka9q-radio<br><br><br>Overview<br><br><br>This is a collection of software defined radio (SDR) modules connected<br><br>by the Internet Real Time Protocol (RTP) and IP multicasting. It is<br><br>intended to facilitate experimentation and education, and to be easy<br><br>to interface to data decoders and digital communication programs. It<br><br>can also smoothly track satellite Doppler shift in an open-loop mode<br><br>when fed velocity and acceleration information from an external<br><br>program.<br><br><br>The ka9q-radio modules currently execute from the command line on<br><br>either Linux or OSX.  As yet there is no fancy graphical user<br><br>interface. (This may come later, especially if someone volunteers to<br><br>create one).<br><br><br>Multicasting and the Real Time Protocol<br><br><br>The ka9q-radio modules are designed for maximum versatility.  Unlike<br><br>shell pipelines or TCP/IP connections, ka9q-radio modules can be<br><br>individually started and stopped at any time, and one can feed any<br><br>number of others without prearrangement. They can run on the same<br><br>computer or on different computers on a multicast-capable network<br><br>(e.g., an Ethernet LAN).<br><br><br>RTP is widely used for point-to-point voice over IP (VoIP), though it<br><br>was designed for multicasting with any codec or data<br><br>format. ka9q-radio uses four RTP payload types: raw I/Q data with a<br><br>custom receiver status header; mono or stereo 16-bit uncompressed PCM<br><br>audio sampled at 48 kHz; and the new Opus codec.<br><br><br>It should be easy to add PCM/RTP input to any ham SDR program that<br><br>uses a computer sound card to aquire receiver audio (e.g. WSJT-X,<br><br>fldigi and many others). This would bypass the computer's sound system<br><br>and providing a much cleaner and more reliable interface. No analog<br><br>audio cables, "rigblaster" adapter boxes, audio ground loops,<br><br>equalization problems, or tricky level adjustments! With multicasting,<br><br>any number of programs can process the same receiver output.<br><br><br>Parts of the ka9q-radio package should also be well suited to<br><br>"turnkey" networked receiver applications such as receive-only<br><br>APRS-to-Internet gateways and Broadcastify feeds.<br><br><br>Opus Compression and Audio Monitoring<br><br><br>Although PCM is best for digital decoders, it requires 800 kb/s for<br><br>mono and 1.6 Mb/s for stereo.  Much lower data rates suffice for human<br><br>listening over WiFi or a remote Internet connection. I use the new<br><br>Opus codec standardized by the Internet Engineering Task Force<br><br>(IETF). A high quality, open-source Opus implementation is available,<br><br>and it can be freely used without patent restrictions (unlike, e.g.,<br><br>ABME).  Opus automatically switches algorithms as needed to do the<br><br>best it can with whatever data rate is available, from very high<br><br>fidelity stereo audio at up to (an unecessarily high) 510 kb/s down to<br><br>monaural voice at only 6 kb/s. (VK5DGR's CODEC2 can handle even lower<br><br>data rates, which is on my to-do list.)  I typically use 32 kb/s,<br><br>which is actually much higher than needed for communications-quality<br><br>audio.<br><br><br>Popular media players like VLC support PCM and Opus so you can listen<br><br>to ka9q-radio audio on many smartphones and tablets. Curently the<br><br>player must receive multicasts, which usually means they must be on<br><br>the same LAN as the computer(s) generating the audio streams. Remote<br><br>unicast Internet connectivity is on the to-do list.<br><br><br>The ka9q-radio package also includes 'monitor', a RTP audio player<br><br>that can receive and mix several multicast audio streams to the local<br><br>sound output. It has a novel 'pan' feature that uses gain and delay<br><br>adjustments (<1 ms) to place each source at a user-chosen point in a<br><br>stereo image. This makes it easier to distinguish multiple sources,<br><br>e.g., in a round table. The 'monitor' program currently supports only<br><br>Opus and PCM, though CODEC2 is on the list.<br><br><br>The KA9Q 'radio' program<br><br><br>The heart of the ka9q-radio package is the program 'radio', an<br><br>interactive general coverage receiver. It reads raw I/Q data multicast<br><br>by a SDR front end, sending tuning and gain adjustments as<br><br>needed. radio's output is a mono or stereo PCM audio multicast<br><br>stream.<br><br><br>If audio compression is needed, a separate 'opus' module transcodes<br><br>PCM to Opus. I.e., it receives PCM, compresses it with Opus and<br><br>multicasts it to a different IP address.  This lets listeners and<br><br>players select compressed or uncompressed audio by merely joining the<br><br>corresponding multicast group.<br><br><br>A simple but entirely usable textual interactive user interface is<br><br>provided. If desired, it can be disabled entirely with all parameters<br><br>given instead on the command line (e.g., in shell scripts).<br><br><br>Architecture<br><br><br>The 'radio' program accepts a generic I/Q (complex) sample stream<br><br>multicast by a computer with a direct conversion ("zero IF") SDR front<br><br>end. At present, only the AMSAT UK Funcube Pro+ dongle is supported<br><br>with the 'funcube' module. The (mostly higher) sample rates produced<br><br>by other receivers such as the SDRPlay and RTL-SDR are supported but<br><br>only the Funcube's 192 kHz sampling rate has actually been tested.<br><br><br>An I/Q stream at 192 kHz with 16 bit samples is a constant 6.5 Mb/s<br><br>network load; this is no problem for modern Ethernet but it should be<br><br>kept away from inexpensive WiFi base stations and public Internets.<br><br>(More on problems with multicast and WiFi in the end notes).<br><br><br>Hardware Artifact Removal<br><br><br>Although a SDR front end is typically direct conversion, the complete<br><br>ka9q receiver is actually a dual-conversion superheterodyne: the first<br><br>LO and mixer are in analog hardware and the second LO and mixer are in<br><br>software. The first mixer is the quadrature (I/Q) type that produces a<br><br>complex first IF centered on zero Hz and extending from -Fs/2 to<br><br>+Fs/2, where Fs is the A/D sample rate.  For the Funcube dongle, Fs =<br><br>192 kHz so the IF extends 96 kHz above and below the first LO<br><br>frequency. (For a complex signal, the Nyquist rate is equal to the<br><br>bandwidth; for a more familiar real signal, the Nyquist rate is twice<br><br>the signal bandwidth.)<br><br><br>This is often called a "zero IF" architecture but this is a slight<br><br>misnomer. The actual first IF can be anywhere between -Fs/2 and +Fs/2<br><br>provided it contains the entire signal bandwidth, though the 10 kHz<br><br>near each edge from a Funcube dongle is best avoided because of<br><br>imperfect anti-alias filtering before the A/D converters.<br><br><br>There is also a "DC spike" at 0 Hz from crosstalk from the first LO to<br><br>the receiver input. The first processing step in 'radio' completely<br><br>removes this spike, but reciprocal mixing produces some low frequency<br><br>phase noise that cannot be removed. With the Funcube dongle this noise<br><br>is only noticeable in without antenna noise covering it up, but it is<br><br>still best avoided. E.g., the range from +48 kHz to +51 kHz (or -51<br><br>kHz to -48 kHz) might be selected for SSB with a 3 kHz bandwidth.<br><br><br>This is still an extremely low IF by usual standards as adequate image<br><br>rejection cannot be provided by ordinary filtering. The use of complex<br><br>I/Q signals allows the frequency image to be cancelled with digital<br><br>signal processing. This requires the 'radio' program to compensate for<br><br>any slight gain and phase imbalances between the I and Q channels, and<br><br>this is its second processing step. Typical values for the Funcube<br><br>dongle might be 0.07 dB of gain imabalance and 0.4 degrees of phase<br><br>error.<br><br><br>Frequency conversion<br><br><br>The third step is to convert the first IF signal to baseband, i.e., 0<br><br>Hz. This is performed by the second (software) LO and mixer in complex<br><br>arithmetic, which suppresses the unwanted image in the other half of<br><br>the IF. The LO and mixer each require only one complex multiply per<br><br>sample. Sine and cosine calls are needed ony when the LO is retuned.<br><br><br>Another LO and mixer are optionally used for open-loop correction of<br><br>satellite Doppler shift. The 'radio' program reads velocity and<br><br>acceleration from an external program, calculates and applies the<br><br>appropriate frequency offset and rate.<br><br><br>Filtering and Demodulation<br><br><br>The baseband signal is filtered with fast correlation.  With complex<br><br>signals, the passband can be asymmetric, e.g., +100 to +3000 Hz<br><br>selects upper sideband (USB) and -100 to -3000 Hz selects LSB. A<br><br>post-detection frequency shift is provided for CW; this is equivalent<br><br>to retuning the radio while simultaneously sliding the filter to keep<br><br>the signal at the same point in the passband. Modes other than SSB<br><br>typically use filters centered on 0 Hz but this is not required; the<br><br>edges can be individually varied, e.g. to suppress adjacent channel<br><br>interference.<br><br><br>The filtered baseband signal is then fed to one of three demodulators:<br><br>'AM', 'FM' and 'linear.'<br><br><br>The AM detector implements ordinary noncoherent envelope detection of<br><br>AM signals.<br><br><br>The FM demodulator handles narrowband frequency or phase modulation.<br><br>Two submodes are provided: 'FM', with a high pass cut on the received<br><br>audio below 300 Hz to remove PL/CTCSS tones and a standard -6<br><br>dB/octave audio de-emphasis above 300 Hz. The 'FMF' mode is straight<br><br>FM without post-detection filtering. Both modes use an FFT to measure<br><br>PL/CTCSS tone frequencies to 0.1 Hz accuracy. SNR, frequency offset<br><br>and peak deviation are also measured and displayed.<br><br><br>The 'linear' detector is used for all other modes, including SSB/CW,<br><br>ISB (independent sideband) and raw I/Q. In linear mode the filter<br><br>directly feeds the output: both the I and Q channels for stereo modes<br><br>and just the I channel for mono. Stereo is implied by I/Q and ISB and<br><br>is optional for CW/SSB, where it provides an interesting effect<br><br>because of the 90 degree phase shift (Hilbert transform) between the<br><br>channels.  This may be useful to minimize fatigue during long<br><br>contests.<br><br><br>The I/Q and ISB modes are the same except that in ISB the filter<br><br>processes the positive and negative frequency components to force the<br><br>lower sideband onto the I (left) channel and the upper sideband onto Q<br><br>(right).<br><br><br>A PLL and mixer can track a carrier for coherent (synchronous) AM<br><br>detection, which is usually less noisy than regular AM envelope<br><br>detection. In "calibrate" mode the PLL can adjust a TCXO offset<br><br>estimate to bring the carrier to exactly 0 Hz.  This is useful for<br><br>automatic calibration of the SDR TCXO against WWV/H, CHU, an ATSC<br><br>(North American digital TV) pilot carrier, or an external frequency<br><br>reference.<br><br><br>A squarer can be inserted in the PLL to track the suppressed carrier<br><br>in DSB-AM and BPSK.<br><br><br>User Interface<br><br><br>The 'radio' program has a textual user interface that uses the<br><br>"ncurses" library; it may look primitive by 2018 standards, but it is<br><br>lightweight, simple and very efficient over slow Internet paths. The<br><br>'h' key toggles a list of the supported commands. The textual user<br><br>interface can also be completely disabled and all receiver parameters<br><br>given on the command line, e.g, for invocation from a shell script.<br><br><br>Startup files are stored in ~/.radiostate (i.e., the directory<br><br>".radiostate") in the user's home directory). Invoking 'radio' with<br><br>the name of a startup file loads its settings. The state of the radio<br><br>can be saved to a state file with the 'w' key. On normal termination<br><br>the radio state is also stored as "default". It will be automatically<br><br>loaded on the next invocation if no explicit name is given.<br><br><br>The various operating modes are specified in<br><br>/usr/local/share/ka9q-radio/<wbr>modes.txt.  Each entry specifies a<br><br>demodulator along with filter parameters, the post-detection frequency<br><br>shift, AGC responses and option flags. For example, "USB" selects the<br><br>"linear" demdulator, a filter passband of +100 to +3000 Hz, a zero<br><br>post-detection frequency offset, an AGC attack rate of -50 dB/sec, an<br><br>AGC recovery rate of +6 dB/sec, an AGC hang time of 1.1 seconds and<br><br>mono output.<br><br><br>The text mode interface provides the following status windows:<br><br><br>The "Tuning" window shows the radio, LO and IF frequencies. If Doppler<br><br>correction is active, it is also shown here. The user can change<br><br>frequency with the arrow keys, a Griffin PowerMate USB knob, a mouse<br><br>wheel, or with text entered through a popup menu.<br><br><br>The "Signal" window shows signal, noise and SNR estimates at various<br><br>points in the signal path. Levels are in dBFS, i.e., decibels below<br><br>full scale (A/D saturation) as there is no way to know the gain ahead<br><br>of the A/D converters without careful calibration, which is invariably<br><br>frequency dependent.<br><br><br>The "Info" window shows, if available, the name of the channel or<br><br>frequency band and, if it's a ham band, the allowed emissions and<br><br>required license class.  This information comes from<br><br>/usr/local/share/ka9q-radio/<wbr>bandplan.txt.<br><br><br>The "Filtering" window gives the pre-detection filter and<br><br>post-detection frequency shift settings. The filter edges, frequency<br><br>shift and Kaiser window beta parameter can be adjusted in the same way<br><br>as the tuning. Smaller betas give sharper filters but poorer<br><br>stop-band attenuation; larger betas give wider transition bands<br><br>but better rejection outside the passband. [See the later discussion<br><br>about sample rates and decimation.]<br><br><br>The "Demodulator" window shows mode-specific information.  The AM and<br><br>linear modes include a simple fast-attack, slow decay AGC for SSB<br><br>(more work can be done here).<br><br><br>The "Options" window selects the various options for the "Linear"<br><br>demodulator.<br><br><br>The "SDR Hardware" window shows the A/D sample rate, TCXO offset,<br><br>nominal tuner frequency, analog gain settings and gain and phase<br><br>imbalance estimates.<br><br><br>The "Modes" window allows the operating moded to be conveniently selected<br><br>with a mouse click.<br><br><br>The "I/O" window gives information on the I/Q input and PCM audio<br><br>output network streams: IP addresses or host names; port numbers;<br><br>packet, sample and error counts; and a SDR timestamp useful when<br><br>playing back recorded I/Q data. It also estimates the true I/Q sample<br><br>rate against the local computer time-of-day clock.<br><br><br>A "Debug" area at the very bottom of the screen shows version information<br><br>and various test and debugging messages.<br><br><br>Textual user input entered through popup menus; for example a tuning<br><br>frequency can be directly entered as "147m435" (147.435 MHz), 760k<br><br>(760 kHz) or 1g296296 (1296.296 MHz). If no units letter is used, a<br><br>'best guess' is made to produce a valid frequency; e.g. 14313 will<br><br>give 14.313 MHz, not 14.313 kHz (which is below the Funcube's range).<br><br><br><br>Other ka9q-radio Modules<br><br><br>Other modules provide either miscellaneous functions or begin more<br><br>complex planned features. None of them have especially complex user<br><br>interfaces; most take only a few command line arguments and can run as<br><br>background daemons.<br><br><br>'Funcube'<br><br><br>The 'funcube' module takes I/Q data from a locally connected Funcube<br><br>Pro+, multicasts it over the local LAN and accepts unicast commands to<br><br>tune the radio and set analog gain levels. It will also automatically<br><br>change gain levels to avoid A/D saturation. Similar modules will be<br><br>written for other SDR front ends such as the SDRPlay and RTL-SDR that<br><br>will either talk directly to the hardware or through "shimware" such<br><br>as SoapySDR.<br><br><br>'IQrecord' and 'IQplay"<br><br><br>The 'iqrecord' and 'iqplay' modules perform the functions suggested by<br><br>their names. 'iqrecord' accepts multicast I/Q and PCM audio streams<br><br>and writes them to disk. Gaps in the multicast stream due to lost<br><br>packets or silence suppression are seeked over in the recordingq to maintain the<br><br>correct sample count and playback timing.<br><br><br><br>I/Q streams are written into files named as 'iqrecord-xxxxxx-n' where<br><br>xxxxxx is the RTP SSRC (Stream Source Identifier) and 'n' is a number<br><br>incremented to avoid overwriting existing recordings. PCM streams are<br><br>written as 'pcmrecord-xxxxxx-n'. Both files are written as raw,<br><br>headerless 16-bit PCM with all meta information in extended file<br><br>attributes.<br><br><br>Most but not all modern file systems support extended attributes; a<br><br>notable exception is Microsoft's VFAT32 often used as a<br><br>least-common-denominator for file exchange between different operating<br><br>systems. Warning! Many file copy and archiving utilities do not<br><br>preserve extended attributes, at least not by default.<br><br><br>I/Q and PCM recordings have many uses. An I/Q recording preserves<br><br>everything fed to the 'radio' input regardless of modulation type or<br><br>bandwidth (provided it fits within the receiver passband). This is<br><br>useful for testing and for demonstrating the 'radio' program when an<br><br>antenna is not available.<br><br><br>I/Q recordings are especially useful as backups during events<br><br>difficult or impossible to reproduce, such as a satellite pass or<br><br>balloon flight. When made at or close to the SDR hardware they depend<br><br>only on the antenna, SDR hardware and I/Q multicast program<br><br>(e.g. 'funcube').  This can guard against bugs (or the outright<br><br>failure) of more complex elements in the downstream signal path, e.g.,<br><br>a digital data demodulator. After the demodulator is fixed, the<br><br>recording can be played back to recover the data.<br><br><br>'iqrecord' is an excellent example of multicasting's versatility; it<br><br>can just sit quietly in the corner recording the same I/Q data stream<br><br>being processed by a real-time software receiver or telemetry decoder<br><br>without impairing its function in any way.<br><br><br>The 'iqplay' module plays back I/Q recordings (only -- no PCM support<br><br>at present) using the metadata contained in the external file<br><br>attributes. It can also read a raw stream from standard input to<br><br>simulate SDR front end hardware.<br><br><br>'Opus'<br><br><br>The 'opus' module was described earlier as an optional "transcoder"<br><br>that accepts uncompressed PCM (either mono or stereo) and produces a<br><br>lower bit rate compressed version with the Opus codec. Options include<br><br>a range of blocksizes from 2.5 milliseconds to 120 ms. The larger<br><br>blocks are useful only to reduce packet rate and header overhead; they<br><br>provide no additional compression and are supported only by more<br><br>recent versions of the Opus library. The default is 20 ms, which is<br><br>long enough to give good compression but short enough to be<br><br>essentially unnoticeable.<br><br><br>The compressed output data rate is specified by a command line<br><br>parameter; it defaults to 32 kb/s which produces surprisingly good<br><br>audio even on stereo music.<br><br><br>The Opus codec also supports a VOX-like "discontinuous" mode well<br><br>suited to half-duplex push-to-talk amateur operation. When silence is<br><br>detected, it automatically drops to sending "comfort noise" at only 3<br><br>packets per second.<br><br><br>"Packet"<br><br><br>This module is my first digital demodulator module for the ka9q-radio<br><br>package. It accepts PCM audio from the 'radio' program and demodulates<br><br>and decodes standard 1200 bps AX.25 frames using the ancient Bell 202A<br><br>AFSK modem. The decoded AX.25 frames are multicast in UDP packets that<br><br>do not currently have RTP headers; this will probably change. The<br><br>decoded frames can also optionally be displayed on the<br><br>console. Otherwise the module can run as an unattended daemon.<br><br><br>"APRS"<br><br><br>This unfinished module accepts decoded AX.25 frames from the "packet'<br><br>module, extracts APRS position data from a selected station, computes<br><br>the azimuth, elevation and range to that station from a specified<br><br>point, and commands antenna rotors to point at the transmitting<br><br>station. This was written to automatically track high altitude<br><br>balloons.<br><br><br><br>Footnotes and Sidebars<br><br><br>Sample Rates and Decimation<br><br><br>The I/Q input sample rate must be an integer multiple of the 48 kHz<br><br>audio output rate.  Decimation is performed as a byproduct of the fast<br><br>correlator used for pre-detection filtering. Since the input FFT in a<br><br>fast correlator executes at the input sample rate, CPU loading will<br><br>increase.  Faster and simpler decimators are in the works.<br><br><br>By default the filter decimates the Funcube 192 kHz A/D input sample<br><br>rate by a factor of 4 to a 48 kHz audio output.  Other SDR front ends<br><br>with higher sample rates will require correspondingly higher<br><br>decimation ratios.  Although 48 kHz may seem excessive for<br><br>communications-grade audio, I don't recommend reducing it. 48 kHz is<br><br>supported by nearly every audio D/A, and it still uses only 0.154% of<br><br>a gigabit Ethernet link.<br><br><br>More importantly, the Opus codec strongly prefers 48 kHz stereo even<br><br>for narrowband mono voice, and there seems to be no advantage to mono<br><br>or a lower sample rate (i.e., the compressed data rate is not reduced<br><br>nor is audio quality improved at a given rate.) So if the audio bit<br><br>rate is a concern, just use Opus; don't reduce the PCM sample rate.<br><br><br>Digital demodulators are best run on computers with fast local network<br><br>connections to the radio program so they can be given uncompressed<br><br>PCM.  (Audio compression works by eliminating signal components<br><br>inaudible to the human ear, but which may be very important for a<br><br>digital demodulator.)<br><br><br>Filter Tradeoffs<br><br><br>Simultaneously improving both filter rolloff and stop-band attenuation<br><br>requires a longer FIR impulse response, which implies greater latency<br><br>and somewhat increased CPU loading.  Currently, the filter blocksize<br><br>and FIR length can only be specified on the command line or in the<br><br>startup file, i.e., they cannot be changed without restarting the<br><br>program. (Note: the length of the FFT executed by the filter is equal<br><br>to the sum of the blocksize and FIR length minus one. The default<br><br>blocksize of 3840 corresponds to 960 samples after 4:1 decimation to<br><br>48 kHz; this is the number of samples in a 20 ms Opus frame. 3840 +<br><br>4353 - 1 = 8192, i.e., the FFT has 8k points. While the FFTW package<br><br>can handle any number of points, a power of 2 is more efficient. I've<br><br>found the default parameters to be suitable for most purposes.)<br><br><br>Correcting Fractional-N Frequency Synthesizer Artifacts<br><br><br>Because the first LO in the Funcube dongle is an analog hardware with<br><br>the usual synthesizer tuning artifacts, it is retuned only when<br><br>necessary to contain the desired signal in the first IF, i.e., between<br><br>-Fs/2 and +Fs/2. Otherwise tuning is with the second (software) LO<br><br>because it can be smoothly and instantly tuned without any<br><br>glitches. This is especially important with open-loop Doppler<br><br>correction.<br><br><br>Like most modern radios, the Funcube uses fractional-N frequency<br><br>synthesis with inherent restrictions on the actual set of frequencies<br><br>that can be produced. Although its programming interface advertises 1<br><br>Hz steps, the actual tuning step size varies with frequency; in the HF<br><br>and VHF range it is 1000/2048 = 0.48828 Hz so it cannot produce exact<br><br>1 Hz frequency steps.<br><br><br>The 'radio' program works around this in two independent ways. First,<br><br>the hardware synthesizer programming formulas and constants from the<br><br>Funcube firmware are used to determine the actual frequency for any<br><br>requested frequency so the discrepancy can be corrected by the second<br><br>LO. Second, only frequencies that the synthesizer can exactly produce<br><br>are selected; the step size varies with frequency so the worst<br><br>(largest) value of 125 Hz is always used, with the difference again<br><br>absorbed by the second LO. Although these two fixes are specific to the<br><br>Funcube dongle, other SDRs undoubtedly have the same problem subject<br><br>to the same workarounds -- if I can get the necessary details.<br><br><br><br><br>
</div></div>
<br>______________________________<wbr>_________________<br>
Ground-Station mailing list<br>
Ground-Station@lists.<wbr>openresearch.institute<br>
<a href="http://lists.openresearch.institute/mailman/listinfo/ground-station" rel="noreferrer" target="_blank">http://lists.openresearch.<wbr>institute/mailman/listinfo/<wbr>ground-station</a><br>
<br></blockquote></div><br></div>