[Flexradio] Image Rejection
All, I have just been reading a review on the SDR-1000 by Peter Hart, G3SJX, in the June 2006 issue of RadCom. He is generally upbeat, but he has a concern about image rejection. He is talking about v1.6.0 of the software, so maybe things have improved since then. He says: ~~ A potential weakness of the SDR-1000 architecture is that there is a receive image 44kHz above the tune frequency. The only protection against spurious responses is the balance achieved in the image rejection mixer. This really needs to be better than about 70dB, or higher than 90dB for a top flight receiver. As received, without further calibration, the SDR-1000 [under review] achieved about 60dB image rejection at 1.8MHz, reducing to around 40dB at 30MHz and 32dB at 50MHz. By tuning in a strong signal on the image frequency, or more conveniently by using a signal generator, the image signal can be nulled down to better than 80dB. However, the nulling does not hold across different bands or for substantial changes in frequency. Nulling to a depth of 80dB on 14.2MHz was reduced to 65dB at 14.0 and 14.4MHz and about 50dB at 1.8 and 30MHz. Image nulling can be performed automatically but it is fairly slow and not that accurate. Manual null adjustment is usually quicker and more accurate. There is room for improvement of the nulling algorithm and possibly also a means of storing null settings for different frequencies and bands in a look-up table for automatic recall. Similarly on transmit there is also an image. This can be separately nulled but a second receiver or preferably a spectrum analyser is needed. ~~ I don't have any SDR hardware (yet), so I'm not able to see these defects. However, it does raise some questions in my mind: 1. Is it really a matter of having to automatically/manually null the image every time you change band or move through a large frequency increment? 2. Do you really need a second receiver/spectrum analyser to make sure you're not transmitting an unacceptably high-level image? Do you have to keep checking every time you change transmit frequency? 3. Is there any plan to have a frequency-based look-up table for optimum rejection, both on receive and transmit? (Similar, I guess, to automatic ATU tuning). 73 Ian, G3NRW ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] One Shoe Will Not Fit All
I have now implemented 2 (VERY) prototype GUIs running on Linux with DttSP2. http://microsat.homelinux.org/dttsp/gsdr http://microsat.homelinux.org/dttsp/gbeppe gsdr implements the look and feel of PowerSDR and gbeppe implements the look and feel of Beppe's design. In implementing both I am trying to abstract out the common code into a library so that the 'skin' designer just has to think about the look and feel and not all the underlying code necessary to support the interface to DttSP, and eventually the hardware, and manage state saving and restore and configuration information. What I want to get to is that when, for instance, a band is selected the skin code simply calls a function that will set everthing up correctly, including handling band stacking. However, it will be up to the skin code to decide how to modify the UI to show how it is shown that the band is selected (or deselected). Also there will need to be either a callback or a structure passed back to the GUI so that all the other displays/buttons related to the band change can be updated (i.e. mode, filter, etc). However, it should not be underestimated how much code is required to implement just the GUI portion of the code, but of course this could be helped by using a good IDE. Regards, John g0orx/n6lyt ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
[Flexradio] VAC flexablity
I think there needs to be greater AC flexablity specifically the ability to automatically switch between mic input and vac input... In the case of and SSB contest, some transmissions originate from the MIC and others from a DigitalVoiceKeyer ( which could be part of a logging program). In the case of SSTV and digital SSTV, it is not unusual to send and picture and then talk about what was just sent, etc. . It would seems to me that it could be arranged to have a PTT that originates from the mic (and indicating the desire to transmit mic audio ) should force a temporary override of the VAC input. Another consideration, in the DVK case you may wish to use the mic audio profile for the VAC input, but in the SSTV case you would want the digital profile for the VAC input. In all cases you should get the current mic profile for the mic input. There may be additional VAC flexablity arguments for CW and CW contest logging programs. AL, K0VM ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] VAC flexibility
Al, While it would be possible to put a VAC "engage" option on the phone mode specific operating controls, why can't you just use the band stack feature and switch from SSB to a digital mode (VAC)? The different parameters you would like to use, such as different filtering are easily handled using this method. A small change to link the TX profile state with a band stack register setting would solve all your requests. Also, there is an enhancement request to add a DVK in the PowerSDR software eliminating the need for third party programs and a way to key the rig assuming you don't use VOX. -Tim --- Tim Ellison Integrated Technical Services -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Sent: Friday, August 25, 2006 9:02 AM To: flexradio@flex-radio.biz Subject: [Flexradio] VAC flexablity I think there needs to be greater AC flexablity specifically the ability to automatically switch between mic input and vac input... In the case of and SSB contest, some transmissions originate from the MIC and others from a DigitalVoiceKeyer ( which could be part of a logging program). In the case of SSTV and digital SSTV, it is not unusual to send and picture and then talk about what was just sent, etc. . It would seems to me that it could be arranged to have a PTT that originates from the mic (and indicating the desire to transmit mic audio ) should force a temporary override of the VAC input. Another consideration, in the DVK case you may wish to use the mic audio profile for the VAC input, but in the SSTV case you would want the digital profile for the VAC input. In all cases you should get the current mic profile for the mic input. There may be additional VAC flexablity arguments for CW and CW contest logging programs. AL, K0VM ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] SVN 653
Dan, K6KDK, wrote: > One of the reasons this is important is that there is really > no such thing as RF Gain any way in a DSP radio. Good point. And this actually raises an interesting question regarding the naming of controls... >From my perspective, the SDR1K has, essentially, two gain controls. Conceptually, from the point of view of signal flow, I picture these two gains as "pre-agc gain" and "post-agc gain." That is, the gain applied to a signal *before* it's attenuated by AGC, and the gain applied to a signal *after* it's been attenuated by AGC. The post-agc gain control is called "AF Gain," and, intuitively, we all understand what it does, because we've all operated radios that have a knob called "AF Gain." In other words, any ham in the world can walk up to the SDR1K's console and immediately understand what the AF Gain control does, without having to read the manual. The SDR1K's pre-agc gain control is called "Max AGC Gain," and in earlier consoles this control was buried in the Setup menues. The problem with the name "Max AGC Gain", though, is that many hams might not know how to use this control without first reading the manual. It isn't obvious how it relates, or if it relates at all, to receiver controls that they're familiar with, nor is it clear how they should use it. What's interesting, though, is that if you look at the AGC code, it becomes quickly apparent that "Max AGC Gain" is *functionally* equivalent to the "RF Gain" control that hams are familiar with on non-SDR radios. That is, both set the maximum amount of gain that is applied to a signal before that signal is attenuated by AGC (i.e. pre-agc gain). The functional similarity between "Max AGC Gain" and the familiar "RF Gain" control raises an interesting question - is it better give a control a name that accurately represents what it does in the code (such as "Max AGC Gain") but that may be confusing to anyone who hasn't read the manual (or have a PHD in Gizmotronics), or to give the control a name that represents the control's function in terms that the user is familiar with and lends itself to an intuitive understanding of how to use the control? "Max AGC Gain" is more accurate from the point of view of the code itself, but (at least to me) "RF Gain" is more intuitive. Or, perhaps more importantly, if there was a control on the front panel labeled "Max AGC Gain," would this turn-off, rather than attract, potential buyers of the radio? I don't know the answer to these questions. Just wondering... - Jeff, K6JCA ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] SVN 653
From: Jeff Anderson <[EMAIL PROTECTED]> Date: Fri, 25 Aug 2006 Time: 06:38:49 >The functional similarity between "Max AGC Gain" and the familiar "RF Gain" >control raises an interesting question - is it better give a control a name >that accurately represents what it does in the code (such as "Max AGC Gain") >but that may be confusing to anyone who hasn't read the manual (or have a >PHD in Gizmotronics), or to give the control a name that represents the >control's function in terms that the user is familiar with and lends itself >to an intuitive understanding of how to use the control? "Max AGC Gain" is >more accurate from the point of view of the code itself, but (at least to >me) "RF Gain" is more intuitive. > Using the word "Max" in the name implies to me that this is a fixed level. How 'bout calling it "AGC Threshold" instead? To me, this implies I have some control over the point where AGC cuts in. A big incoming signal requires a lower threshold, so I turn the control down, just like an RF Gain control. And, as I understand it, the name "AGC Threshold" would relate exactly what the software actually does. 73 Ian, G3NRW ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] Image Rejection
At 12:24 AM 8/25/2006, Ian Wade wrote:
>All,
>
>I have just been reading a review on the SDR-1000 by Peter Hart, G3SJX,
>in the June 2006 issue of RadCom.
>
>He is generally upbeat, but he has a concern about image rejection. He
>is talking about v1.6.0 of the software, so maybe things have improved
>since then. He says:
>
>~
>Similarly on transmit there is also an image. This can be separately
>nulled but a second receiver or preferably a spectrum analyser is
>needed.
>~~
>
>I don't have any SDR hardware (yet), so I'm not able to see these
>defects. However, it does raise some questions in my mind:
>
>1. Is it really a matter of having to automatically/manually null the
>image every time you change band or move through a large frequency
>increment?
It's actually a bit more complicated than that... But, overall, you're right..
-> The SDR1000 isn't like a microwave radio or cellphone with an sub-octave
bandwidth analog image reject mixer, where you can tweak it once and have
it work everywhere. Think of it more like two separate receivers, fed with
Local Oscillators that are (approximately) 90 degrees out of phase, with
each receiver having slightly different IF characteristics. You need to
calibrate both the LOs and the IFs for each, and both have a multi-octave
(if not multi-decade) bandwidth.
Also, to get 80 dB image rejection, you need a pretty impressive
phase/amplitude match: approximately arctan(0.0001) (0.005 degrees). 20 dB
only takes 6 degrees, 40 dB about 0.6 degree, so to get those last 10 dB is
definitely down in the gnat's eyelash territory
The I and Q Local Oscillator signals run through different low pass filters
(between DDS output and QSD/QSE), so their relative phases and amplitudes
change (slightly) as the frequency changes over a multiple octave range
(just because of component tolerances, if nothing else). This effect is
fixed, and could be calibrated over frequency once. For any given "DDS
tuning frequency" there's a few calibration parameters that could
automatically be applied. Based on my measurements, I think that the Tx and
Rx sides are pretty consistent here (with a fixed offset between Tx and
Rx), so one lookup table (LO cal parameter vs LO frequency) would
do. {There's a temperature dependence too, but for amateur applications at
room temp, you can ignore it}
Then, the I/Q audio signals run through separate channels, so there's a
"audio frequency" dependent variation between I and Q. This is fairly
fixed, independent of frequency, but is also not particularly well
represented by a single phase/amplitude calibration value (as currently
used in PowerSDR), especially when used with wideband audio interfaces
(e.g. 96 kHz sampling, etc.). The audio interface manufacturers do a
fairly good job keeping phase and amplitude matched beween channels in the
middle ranges (say, 100 to 10 kHz), but not so wonderful farther out: their
primary criteria is making sure it "sounds right" and phase/amplitude
problems in the lower end of the range would result in "stereo imaging"
artifacts {Phase difference between L and R being one of the big cues for
how you tell what direction a sound is coming from}.
I don't want to give the impression that all is lost and hopeless, because
the matching between channels is quite good, just because they are
identical components from the same lots assembled together and operating in
the same environment.
The simple single point calibration that's currently used works pretty
well. It's just not perfect.
>2. Do you really need a second receiver/spectrum analyser to make sure
>you're not transmitting an unacceptably high-level image? Do you have to
>keep checking every time you change transmit frequency?
Not as a practical matter. Recall that (in the U.S. at least) the
spurious emission requirement is only 40 dB. From on-air observations of a
variety of signals from a variety of transmitters, there's an awful lot of
ham signals that do NOT meet that requirement, mostly because of
overdriving or misadjusted equipment.
Fortunately, most of the signals that *I* receive are only about 20-30 dB
over the noise floor, so I can't see those spurious emissions. {Cynically,
I would comment that the current obssession with low receiver LO phase
noise is superfluous, because the transmitted signals have terrible "far
out" noise skirts that completely mask a quiet receiver}.
If a more sophisticated calibration/compensation process were used in
PowerSDR, the LO side would be calibrated once (and could be checked
periodically) using the receive side only, and that would probably hold for
the transmit chain as well. The audio part is different between Tx and Rx,
so independent correction is needed, and there's a slight complication
here, because part of the chain is inside the audio interface and part is
in the SDR1000. You can calibrate the audio interface part by
Re: [Flexradio] Image Rejection (missing important word)
At 07:03 AM 8/25/2006, Jim Lux wrote:
>Then, the I/Q audio signals run through separate channels, so there's a
>"audio frequency" dependent variation between I and Q. This is fairly
>fixed, independent of
DDS frequency (not audio frequency.. it varies a lot with audio frequency)
>, but is also not particularly well
>represented by a single phase/amplitude calibration value (as currently
>used in PowerSDR), especially when used with wideband audio interfaces
>(e.g. 96 kHz sampling, etc.). The audio interface manufacturers do a
>fairly good job keeping phase and amplitude matched beween channels in the
>middle ranges (say, 100 to 10 kHz), but not so wonderful farther out: their
>primary criteria is making sure it "sounds right" and phase/amplitude
>problems in the lower end of the range would result in "stereo imaging"
>artifacts {Phase difference between L and R being one of the big cues for
>how you tell what direction a sound is coming from}.
Jim
___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] Shuttlepro and SVN 563
This may have to do with which .exe you associate the profile. I would hope that it would just respond to any PowerSDR.exe process that runs, but it may be more specific than that requiring you to reassociate it when you run a console out of a different directory. Eric Wachsmann FlexRadio Systems > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > radio.biz] On Behalf Of [EMAIL PROTECTED] > Sent: Thursday, August 24, 2006 10:28 PM > To: FlexRadio@flex-radio.biz > Subject: [Flexradio] Shuttlepro and SVN 563 > > Well, I apologize for the bandwidth. > I don't know why, but when I upgraded to SVN 563 for some reason it messed > up the shuttlepro. > Did not happen when I had upgraded to SVN 562. > I reprogrammed it and all is well now. > Strange, but then agn, that is an often occurrance with me ... hihi. > 73/Crit/K4BXN ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] SVN 653
Jeff, >>From my perspective, the SDR1K has, essentially, two gain controls. > Conceptually, from the point of view of signal flow, I picture these two > gains as "pre-agc gain" and "post-agc gain." That is, the gain applied to > a > signal *before* it's attenuated by AGC, and the gain applied to a signal > *after* it's been attenuated by AGC. > Well, sort of true. But it is more subtle than that. In a DSP engine it is possible to adjust many aspects of the AGC in a way that was not possible before. You simply have to re-think the concepts of RF Gain when working with DSP. It is just way to involved to try and discuss here on the reflector. I suggest two things. First read the TT description of DSP AGC on page 44 to page 48 of this document. They have titled it Weak Signal and Contest Operation, but it is really a discussion of how DSP engine AGC parameters interact: http://radio.tentec.com/cms-files/566_manual_release3_0306.pdf. Then I would like to hear from Frank and Bob on this topic and get their take on all this. I suspect that they have implemented the AGC functions in much the same way as Doug Smith did, and that the reference I quoted applies most directly to the Flex as well as to the Orion. >"RF Gain" is more intuitive. > > Or, perhaps more importantly, if there was a control on the front panel > labeled "Max AGC Gain," would this turn-off, rather than attract, > potential > buyers of the radio? > Well, by this time, everyone knows where I stand on this sort of discussion. To me, this is not a marketing issue. We are talking about how to allow users of the rig (that have already bought and paid for it) to extract the maximum performance from the system. You are only going to get maximum AGC performance in critical listening situations by having ready access to and understanding, technically, how to adjust all the DSP engines AGC parameters. It is that simple. I wish that you could, in fact, put a simple control on the front panel, call it RF Gain, and have it perform some sort of magic in all situations. But that isn't going to happen. As far as the "more intuitive", my response is that we all must keep learning new things until the day we die. When I learned to drive it was with a stick shift. When I bought my first car with an automatic transmission it was not intuitive to operate a car with out a clutch, but I learned. Hams new to DSP radios are going to have to learn a few new things. The intuitive part comes with practice. -Dan ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] SVN 653
Dan, We have done our darndest to combine the best of both worlds: the familiar world of recognizable control names (on one hand) with the technically and precisely correct names (on the other). As you will notice, if you hover over the RF control on the front panel (and nearly all other controls), you will get a tooltip pop-up that gives more information about the control. In this tooltip, it notes that this control really is controlling the "Max AGC Gain." Three years ago, we may not have made that same decision as we were selling primarily to technical experimenters. Today, we are moving into more of a mainstream market and must make changes to accommodate such a market that are in the best interest of our business (so we can keep bringing you software). Again this serves to point out the fact that there are numerous opinions about what a console should and should not be/look like/act/etc. All the more reason to continue down the path to simplify custom customer created consoles (4 C's --- hmmm). :) Eric Wachsmann FlexRadio Systems > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > radio.biz] On Behalf Of [EMAIL PROTECTED] > Sent: Friday, August 25, 2006 1:50 PM > To: Jeff Anderson; FlexRadio@flex-radio.biz > Subject: Re: [Flexradio] SVN 653 > > Jeff, > > >>From my perspective, the SDR1K has, essentially, two gain controls. > > Conceptually, from the point of view of signal flow, I picture these two > > gains as "pre-agc gain" and "post-agc gain." That is, the gain applied > to > > a > > signal *before* it's attenuated by AGC, and the gain applied to a signal > > *after* it's been attenuated by AGC. > > > > Well, sort of true. But it is more subtle than that. In a DSP engine it is > possible to adjust many aspects of the AGC in a way that was not possible > before. You simply have to re-think the concepts of RF Gain when working > with DSP. It is just way to involved to try and discuss here on the > reflector. I suggest two things. First read the TT description of DSP AGC > on > page 44 to page 48 of this document. They have titled it Weak Signal and > Contest Operation, but it is really a discussion of how DSP engine AGC > parameters interact: > http://radio.tentec.com/cms-files/566_manual_release3_0306.pdf. Then I > would like to hear from Frank and Bob on this topic and get their take on > all this. I suspect that they have implemented the AGC functions in much > the > same way as Doug Smith did, and that the reference I quoted applies most > directly to the Flex as well as to the Orion. > > >"RF Gain" is more intuitive. > > > > Or, perhaps more importantly, if there was a control on the front panel > > labeled "Max AGC Gain," would this turn-off, rather than attract, > > potential > > buyers of the radio? > > > > Well, by this time, everyone knows where I stand on this sort of > discussion. > To me, this is not a marketing issue. We are talking about how to allow > users of the rig (that have already bought and paid for it) to extract the > maximum performance from the system. You are only going to get maximum AGC > performance in critical listening situations by having ready access to and > understanding, technically, how to adjust all the DSP engines AGC > parameters. It is that simple. I wish that you could, in fact, put a > simple > control on the front panel, call it RF Gain, and have it perform some sort > of magic in all situations. But that isn't going to happen. > > As far as the "more intuitive", my response is that we all must keep > learning new things until the day we die. When I learned to drive it was > with a stick shift. When I bought my first car with an automatic > transmission it was not intuitive to operate a car with out a clutch, but > I > learned. Hams new to DSP radios are going to have to learn a few new > things. The intuitive part comes with practice. > > -Dan > > > > ___ > FlexRadio mailing list > FlexRadio@flex-radio.biz > http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz > Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ > FlexRadio Homepage: http://www.flex-radio.com ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] SVN 653
At 11:49 AM 8/25/2006, [EMAIL PROTECTED] wrote: >Jeff, > >Well, by this time, everyone knows where I stand on this sort of discussion. >To me, this is not a marketing issue. We are talking about how to allow >users of the rig (that have already bought and paid for it) to extract the >maximum performance from the system. Mind you, you bought and paid for the hardware, and some level of software as it was.. And, you have good hardware documentation: all the registers are defined and their behavior follows the description, and it's not likely to change. (at least for the pre RFE version.. I haven't looked at the post RFE version, since I don't have any of those, but we're not talking huge changes here.. a few lines on a port to do one thing or another). You also have example source code (albeit a tad obscure) that achieves some fairly decent performance, within a "usage model" that is similar to conventional radios (i.e. RF gain,AF gain, filter passbands) with a conceptual interface that follows a conventional superhet analog radio model. There's a control interface for this model using a modified version of the Kenwood CAT comamnds that is well documented (although, the date on the current software modules that handle CAT is quite a bit later than the date on the docs, but it's probably "reasonably" close) And, there is a relatively undocumented, but open (in the sense that all the calls and parameters are visible, albeit with no explanations) interface to the dttsp engine. There's also a better documented interface for PortAudio, PortIO, and pthreads. And, let us not forget that there's the software interface to the Windows environment (all gazillion entrypoints) which is documented at varying levels: the call syntax is very well documented, how to hook the calls together, less so. But, I suspect what YOU want (and I want, too, and probably others) is an abstract interface at a level between the "here's 200 DLL entry points in 5 different DLLs that mutually interact in an undocumented way" and the "CAT style interface". That is, you'd like the ability to use the flexibility inherent in either the current dttsp chain or an alternate processing chain, but with a reasonably nice, abstracted, and stable interface. This is not unique to the SDR1000 and PowerSDR, by the way. What that interface should look like as well as what features it should provide is the subject of much discussion. Heck, even a standardized way to describe the radio processing architecture is a subject of much discussion in the SDR world in general. (the idea is.. I have some sort of thing I want to do with a software radio, what kind of description of that radio would tell me whether what I want to do is possible.) This sort of thing, aside from everyone kind of wanting a different manifestation, is not something that anyone has signed up to do for the SDR1000. I personally feel that there are some significant structural, logistical, and organizational impediments in the way of anyone who *would* want to do this, but nothing that is impossible. It would go a long way from turning a fairly generalized and flexible hardware platform (the SDR1000) into a generalized software radio platform. So, to extracting maximum performance (which, of course, is different for everyone) is either by virtue of your own toil or the kindness of others. I think that the discussions of "how do we expose radio functionality", of which the "gain" discussion is but one facet are quite useful. Even if nobody is going to be developing code to support the concepts discussed, they at least provide a context to frame the discussion about the development that *is* being done, such as it is. Even better is that people, like yourself, are bringing comparative concepts into play. Hams are kind of a unique "consumer" of a software radio, because their needs and requirements span such a huge variety of use cases, and hence, require a lot of different "conceputal models" for the radio. It's not like a cellphone radio designer, where you know, a priori, what the modulations, bandwidths, functions, etc. need to be. This is why I like the idea of different interfaces (at a software AND UI level) to the radio for different modes. The kinds of high level controls one might want to manipulate from your UI are different for a CW radio than for a SSB radio than for a SSTV radio. By controls here, I don't mean "knobs and sliders on the screen" but, rather, the functions that the UI calls, after you mouse, or turn, or click, or press the key. >You are only going to get maximum AGC >performance in critical listening situations by having ready access to and >understanding, technically, how to adjust all the DSP engines AGC >parameters. It is that simple. I wish that you could, in fact, put a simple >control on the front panel, call it RF Gain, and have it perform some sort >of magic in all situations. But that
Re: [Flexradio] Image Rejection (missing important word)
From: Jim Lux <[EMAIL PROTECTED]>
Date: Fri, 25 Aug 2006 Time: 07:10:29
>At 07:03 AM 8/25/2006, Jim Lux wrote:
>
>>Then, the I/Q audio signals run through separate channels, so there's a
>>"audio frequency" dependent variation between I and Q. This is fairly
>>fixed, independent of
>
>DDS frequency (not audio frequency.. it varies a lot with audio frequency)
>
>>, but is also not particularly well
>>represented by a single phase/amplitude calibration value (as currently
>>used in PowerSDR), especially when used with wideband audio interfaces
>>(e.g. 96 kHz sampling, etc.). The audio interface manufacturers do a
>>fairly good job keeping phase and amplitude matched beween channels in the
>>middle ranges (say, 100 to 10 kHz), but not so wonderful farther out: their
>>primary criteria is making sure it "sounds right" and phase/amplitude
>>problems in the lower end of the range would result in "stereo imaging"
>>artifacts {Phase difference between L and R being one of the big cues for
>>how you tell what direction a sound is coming from}.
>
>
Jim,
Many thanks for all your comments. I found them most helpful and
encouraging.
73
Ian, G3NRW
--
Ian Wade
___
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] SVN 653
Jim, >>You are only going to get maximum AGC >>performance in critical listening situations by having ready access to and >>understanding, technically, how to adjust all the DSP engines AGC >>parameters. It is that simple. I wish that you could, in fact, put a >>simple >>control on the front panel, call it RF Gain, and have it perform some sort >>of magic in all situations. But that isn't going to happen. > > Hmm.. but I propose a slightly different model. In my model, you have an > interface that lets you turn every little inside knob, but, you also have > an interface that lets someone else abstract those to a higher level. > Yes, well, funny you should say that, because as I wrote the paragraph I was exactly thinking the same thing. I was thinking, it would be possible to code a learning response into the software. What I had in mind was that the way it might work is when the user does, in fact, go to the set up menu and twiddle with the 5 available DSP/AGC parameters the software looks at other related settings and attempts to remember or add it to a Bayesian system, so next time you get 'near' these types of settings the software attempts to preconfigure your 5 parameters for you. Well anyway, looks like am getting a little beat up and battle weary on this thread so I guess I'll go back to camp now. Get me the well documented calls and the API and I'll dust off the old text editor and see what we can do. I think you know the feeling eh Jim? You got beat up pretty bad on the last go round with Frank. Problem is, relating that to this current topic, is that there seems to be some uncertainly about this issue of documentation , API and so forth. Eric just said: >Again this serves to point out the fact that there are numerous opinions >about what a console should and should not be/look like/act/etc. All the >more reason to continue down the path to simplify custom customer created >consoles (4 C's --- hmmm). :) So this is encouraging. I am looking forward to the API and docs "any time soon now" . -Dan PS: to Eric, so I don't have to open a new thread. Thanks for working on the CPU load issue on recent versions. ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
[Flexradio] Date fixing
I managed to change enough files using "ftweak" on Windows XP to allow the Quartus Web edition to compile all of projects. That was really painful to figure out. Somehow, sometime, a bunch of my files got dated October 6, 2006 and the web license must be renewed after 150 days. It used the modify time to figure this out. I really do wish Altera would release a Linux web edition. Bob -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." - Einstein ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] Console Graphics
[EMAIL PROTECTED] wrote: > > Slow down! Not so fast! > > The skins do look great, but if I want to operate a radio that looks like my > FT 1000, I'll turn off my SDR-1000 and turn on the black box. > > I'm tired of the old paradigm. The SDR is new, fresh and unconventional. > Don't make it like all the others. > > For those that want the skins, OK.. But I don't want to go back to the > conventional. > That is the point. We want to have our cake and eat it to. You will be able to do things in an unconventional way using the separated process models and those who want the fancy GUIs will be able to get them as "after market" add-ons (for free of course). I even suspect we might find ourselves having for pay front ends eventually since it will be quite easy indeed to add that kind of support in our next major "paradigm" shift. Bob N4HY > > Bob > K8MLM > Happy Flex user since MAY 05 > > -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." - Einstein ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] First SDR1000 to SDR1000 EME Contact Made on Two Metersbetween W5UN and W0VB on August 16, 2006
Joel Harrison wrote: > NO! > > 73 Joel W5ZN > It is possible to read the rules with a "guilty conscience" and see them saying that. I agree with your interpretation since every contester or paper hanger on the planet would be in the illegal camp at least once. Bob N4HY > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Mike Naruta > Sent: Sunday, August 20, 2006 6:39 PM > To: Christopher T. Day > Cc: Terry - W0VB; flexradio@flex-radio.biz > Subject: Re: [Flexradio] First SDR1000 to SDR1000 EME Contact Made on Two > Metersbetween W5UN and W0VB on August 16, 2006 > > Would revealing the details of the contact > invalidate the contact, by the ARRL rules? > > > Mike - AA8K > > > -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." - Einstein ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] [RECOVERED] Re: [OT] First SDR1000 to SDR1000 EME Contact Made on Two Metersbetween W5UN and W0VB on August 16, 2006
Mike wrote: >> Please, do not misunderstand Dave. I recognize >> and laud your historic QSO. >> >> >> My caution was about revealing the details of >> the QSO because of the recent ARRL prohibition. >> I think the issue was dealt with. W5ZN gave you a single word answer and as President of the ARRL, and a big time VHF contester, I hope he knows the rules. This is not a busted QSO getting fixed afterwards. No one is going to accuse Terry and Dave of cheating if they are in their right minds. Bob N4HY >> -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." - Einstein ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] AGC
You need to set the gain for CW. On the DSP setup tab, if you have Block LMS checked, dial down the gain to single digits. Bob N4HY [EMAIL PROTECTED] wrote: > Tnx Eric and Gerald for your prompt response. > > Running SVN 652 (problem is not there when I go back to 1.6.2.). > Dialed in Gerald's settings on custom AGC and still the same. > Seems as if no AGC action taking place. > > While at it ... my NR on CW makes it almost uncopiable ... but thought I read > somewhere that NR is for SSB mode mostly, correct? > > 73/Crit/K4BXN > > > ___ > FlexRadio mailing list > FlexRadio@flex-radio.biz > http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz > Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ > FlexRadio Homepage: http://www.flex-radio.com > > -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." - Einstein ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] Console Graphics - maybe mode-specific?
Frank Brickle wrote: > On Wed, 2006-08-23 at 08:37 +0100, Bob Cowdery wrote: > >> On Tue, 2006-08-22 at 22:54 -0700, Jim Lux wrote: >> >> >>> I've been waiting for the long >>> anticipated UI/backend split with a well defined interface, as announced, >>> gosh, several times over the past couple years... >>> >>> >> Am I the only one that doesn't understand this. As far as I can see >> there *is* a good split between the DSP and the rest of the radio. >> > > *I* thought so too ;-) > > >> I >> avoid saying UI because there is a heck of a lot of code which is >> neither DSP nor UI. This not inconsiderable wadge of code is what I am >> incorporating into a middle tier with a defined interface to the UI. >> > > Just to be explicit, this wadge of code is exactly the "radio kernel" > we've been talking about. Bob (this Bob!) has done quite a bit of work > in the area already, very illuminating work one might add. There has > been another experimental version of this, done up in python, for over a > year now, as an item -- a "virtual radio" -- to contemplate and meditate > over, for merits and defects. > I have not found a pitfall yet. It has taken me time to get my old "write iterative C/C++" code out of my brain and shifted into recursive, functional list processing but it has been worth every single hard step. This code is VERY compact. I really do hope we do not run into any serious performance issues but so far, on Linux, Windows, and Mac OS/X, erlc writes good code and the foreign language interface/ interop to C/C++ is quite functional. Very very few people will need to write erlang. It will be switching station for messages essentially between distributed things where the core is required to learn and preserve state while parsing/passing commands. Bob > >> This interface will be defined in terms of JSON (www.json.org). Whether >> anybody else is interested in this approach is academic. I just wanted >> to point out I don't follow the line of thought. >> > > FWIW, the DttSP radio kernel is being developed and implemented in > erlang. Barring unforeseen potholes, erlang will be the platform for the > virtual radio. > > A nice side-effect of this is the relative simplicity of talking to the > kernel in any old language you choose. Another nice side-effect is the > way erlang makes it possible to demonstrate (if not prove formally) the > correctness of the kernel. > I have seen some really serious papers on "proof of correctness" for Erlang state machines. They are fascinating (if of limited relevance to our ultimate purposes). > Although it might not be obvious, we went to considerable lengths to > show the correctness of the concurrency in DttSP. It's taken awhile to > clear away the weeds around the underlying model, however. Exactly the > analogous process is now taking place in connection with the kernel. > > >> Incidentally I agree with the mode separation. The state machine I am >> using in the middle tier is largely based on mode state, separately in >> RX and TX. This gives the ability to finely control what happens in >> different modes. >> > > Thank you. This is the far and away best justification for > one-size-doesn't-fit-all that's yet come to the fore. > > >> However I do believe the request has more to do with the ability to have >> control over the DSP configuration, to re-sequence blocks and insert >> user defined blocks aka GNURadio style than it is to do with separating >> DSP and UI. If I'm way off track tell me. >> > > ...which is exactly what gnuradio is for! > > Except for hardware control, there's nothing standing in the way of > using gnuradio with the SDR1K. It would be great if somebody would > pursue it. > > 73 > Frank > AB2KT > > > ___ > FlexRadio mailing list > FlexRadio@flex-radio.biz > http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz > Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ > FlexRadio Homepage: http://www.flex-radio.com > > -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." - Einstein ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] No ACL Output? What if the Linear requires an output
Gerry: Amplifier ALC's are OUTPUTS to the transceiver/transmitter. The voltage tells your transmitter/driver to turn down the wick. You may have meant this but your note does not read this way. The ALC inside the SDR-1000 on TX is just outstanding. Adjust the power and you will not be unhappy. With the SDR-1000, I get the highest average, undistorted power out of my Ameritron AL-1200 I have ever gotten with a "100w" radio. Bob N4HY Gerald Capodieci wrote: > I'm considering linears from Ameritron (AL82) or an HF2000 from ROQ. Both > have inputs from an ALC output from the transceiver. SDR1000 has none. Is > there a safe way to provide the ALC output to properly run linears? > Jerry > -- next part -- > An HTML attachment was scrubbed... > URL: > /pipermail/flexradio_flex-radio.biz/attachments/20060824/3a916793/attachment.html > > ___ > FlexRadio mailing list > FlexRadio@flex-radio.biz > http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz > Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ > FlexRadio Homepage: http://www.flex-radio.com > > -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." - Einstein ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] Image Rejection
Jim Lux wrote:
> At 12:24 AM 8/25/2006, Ian Wade wrote:
>
>> All,
>>
>> I have just been reading a review on the SDR-1000 by Peter Hart, G3SJX,
>> in the June 2006 issue of RadCom.
>>
>> He is generally upbeat, but he has a concern about image rejection. He
>> is talking about v1.6.0 of the software, so maybe things have improved
>> since then. He says:
>>
>>
>
>
>
>
>> ~
>>
>
>
>
>
>> Similarly on transmit there is also an image. This can be separately
>> nulled but a second receiver or preferably a spectrum analyser is
>> needed.
>> ~~
>>
>> I don't have any SDR hardware (yet), so I'm not able to see these
>> defects. However, it does raise some questions in my mind:
>>
>> 1. Is it really a matter of having to automatically/manually null the
>> image every time you change band or move through a large frequency
>> increment?
>>
>
> It's actually a bit more complicated than that... But, overall, you're right..
>
> -> The SDR1000 isn't like a microwave radio or cellphone with an sub-octave
> bandwidth analog image reject mixer, where you can tweak it once and have
> it work everywhere. Think of it more like two separate receivers, fed with
> Local Oscillators that are (approximately) 90 degrees out of phase, with
> each receiver having slightly different IF characteristics. You need to
> calibrate both the LOs and the IFs for each, and both have a multi-octave
> (if not multi-decade) bandwidth.
>
> Also, to get 80 dB image rejection, you need a pretty impressive
> phase/amplitude match: approximately arctan(0.0001) (0.005 degrees). 20 dB
> only takes 6 degrees, 40 dB about 0.6 degree, so to get those last 10 dB is
> definitely down in the gnat's eyelash territory
>
> The I and Q Local Oscillator signals run through different low pass filters
> (between DDS output and QSD/QSE), so their relative phases and amplitudes
> change (slightly) as the frequency changes over a multiple octave range
> (just because of component tolerances, if nothing else). This effect is
> fixed, and could be calibrated over frequency once. For any given "DDS
> tuning frequency" there's a few calibration parameters that could
> automatically be applied. Based on my measurements, I think that the Tx and
> Rx sides are pretty consistent here (with a fixed offset between Tx and
> Rx), so one lookup table (LO cal parameter vs LO frequency) would
> do. {There's a temperature dependence too, but for amateur applications at
> room temp, you can ignore it}
>
> Then, the I/Q audio signals run through separate channels, so there's a
> "audio frequency" dependent variation between I and Q. This is fairly
> fixed, independent of frequency, but is also not particularly well
> represented by a single phase/amplitude calibration value (as currently
> used in PowerSDR), especially when used with wideband audio interfaces
> (e.g. 96 kHz sampling, etc.). The audio interface manufacturers do a
> fairly good job keeping phase and amplitude matched beween channels in the
> middle ranges (say, 100 to 10 kHz), but not so wonderful farther out: their
> primary criteria is making sure it "sounds right" and phase/amplitude
> problems in the lower end of the range would result in "stereo imaging"
> artifacts {Phase difference between L and R being one of the big cues for
> how you tell what direction a sound is coming from}.
>
> I don't want to give the impression that all is lost and hopeless, because
> the matching between channels is quite good, just because they are
> identical components from the same lots assembled together and operating in
> the same environment.
>
> The simple single point calibration that's currently used works pretty
> well. It's just not perfect.
>
This is all correct. I presume that almost everyone is using some kind
of tuning aid to do this calibration. We can easily change this to do a
calibration across the IF band. It will be slow and tedious but it will
work well and we can model this with a small number of tap FIR. We
then reduce the number of taps in the bandpass filter by the equalizer
tap length and convolve them (multiply them in the frequency domain) to
return the filter to the full length. I just have not done this because
I want the impulse generator!!
I know everyone is awaiting the impulse generator work. There is an
issue. It is a hardware issue. There will need to be an ECO almost
surely to make this work right. After Gerald so kindly put the impulse
generator on the RFE when I requested it, I failed him in not telling
him some critical things he needed to know. This could have easily been
avoided. I will change my sig back to the "I am lazy sig" soon as
penance. If you have the RFE schematics, you will notice some missing
resistors in the impulse circuit that are meant to be attenuators. The
5 V pulses hitting the QSD (FIVE VOLTS!!) is entirely too high and
causes b
[Flexradio] synchronization of multiple audio streams/radios
Something to contemplate for future incarnations is the ability to synchronize the audio streams (I/Q and/or baseband) from multiple radios, preferably on separate computers, but even on the same computer. If one wants to do "interesting" things requiring coherent processing, like diversity combining or phased arrays, you need to be able to match up the received signal from one antenna/radio with others. The reason I point this out is that a friend mentioned to me that while there are lots of flexible audio support packages out there (PortAudio, Jack, ALSA, etc.) not all of them offer the ability to synchronize to an accuracy of one sample. In general, systems designed for multimedia (where you have to sync to video frames) are more likely to provide this, at least to milliseconds, although he was unsure if they were good to microseconds (i.e. 1 sample time at 96 ksps is about 10 microseconds). There are, of course, issues when the sample streams have slightly different underlying rates (as, for instance, if you are combining streams from two different audio interfaces), but that's a lesser problem than just making sure the buffers are lined up (or that they have a fixed and knowable offset). Or maybe this is something totally out of scope for PowerSDR and it's descendants.. Jim, W6RMK ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
Re: [Flexradio] Image Rejection
At 08:54 PM 8/25/2006, Robert McGwier wrote: >Jim Lux wrote: >>At 12:24 AM 8/25/2006, Ian Wade wrote: >> >>>A >> >>The simple single point calibration that's currently used works pretty >>well. It's just not perfect. >> > >This is all correct. I presume that almost everyone is using some kind of >tuning aid to do this calibration. We can easily change this to do a >calibration across the IF band. It will be slow and tedious but it will >work well and we can model this with a small number of tap FIR. We then >reduce the number of taps in the bandpass filter by the equalizer tap >length and convolve them (multiply them in the frequency domain) to return >the filter to the full length. I just have not done this because I want >the impulse generator!! Don't know why it would be all that slow. In fact, it shouldn't change the throughput at all, because you're already doing a transform to the frequency domain on every frame for filter and then transforming back. (or, at least that's what ovsv.c appears to do). One could also just do the equalization purely in the frequency domain. Capture the impulse, correct it for the LO I/Q imbalance (which is DDS frequency dependent) so you have the pure IF/baseband response, transform it, and then you've got your coefficients all ready to multiply (once, not every frame) with the existing set of frequency domain coefficients that get multiplied by every frequency domain data frame. One will want to do a bit of editing (you'll get icky stuff at the ends of the spectrum, so you can just set those bins to some convenient constant, like 1+j0). Establishing the DDS frequency dependent term is a bit more tedious, because you have to step through enough frequencies to determine the correction over the entire band. However, at least on the 5 instances of the SDR1000 that I've measured, it's a pretty smooth curve, and a dozen or so points should be more than sufficient, assuming you aren't trying to match multiple radios to each other (the band select LPFs have a lot more variability than the DDS LPF). So, say you measure the LO I/Q imbalance every MHz from 1 to 30, or, perhaps at the top and bottom of each ham band. When you change DDS frequency (by spinning the knob, as it were), you'd linearly interpolate the I/Q correction and set that into the existing correction code. The audio path gets corrected as described above. >I know everyone is awaiting the impulse generator work. There is an >issue. It is a hardware issue. There will need to be an ECO almost >surely to make this work right. One could, of course, just use an exernal impulse generator too, just like folks use the Elecraft calibrator. Based on my experience, the corrections are fairly stable over time (but not temperature), so you'd just hook up that pulse generator every once in a while and run a new set of data. It would be quite straightforward for the factory to offer it as a service: for a fee, they'd give you calibration data for your radio. Think of it like aligning the IF strip in an old receiver with double tuned IF transformers. There's a lot of very fast rise time pulse generator schematic around (any of the designs intended for a homebuilt TDR will work). Heck, you could probably just use a 555 driving a HCMOS gate. They have nanosecond kinds of transition times. That way, we wouldn't have to wait for ECOs: And, more interesting to me, those of us with older SDR1000s that don't have the impulse generator in any form could benefit too. Jim,W6RMK ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
