Janne Pulkkinen wrote:

> The 192kHz ASIO with my PCI E-MU 0404 don't seem to work. The software 
> does something unusual: No audio output and the S-meter drops kind of 
> "off". But it does great with 96kHz ASIO or 48KHz ASIO which I have 
> tested.

  Hi Janne,

   EMU cards are a bit peculiar, as each one seems to work a bit differently 
from the others. I have recently bought on 
eBay a second hand EMU-1212M, but never had the chances to install and to test 
it, so the 1-to-4 sample delay added in 
the V1.30 was tested by another OM who has this particular card, and he 
reported back that now, inserting a 4 sample 
delay when sampling at 192 kHz, he is able to perfectly null the image. Frankly 
I don't have enough information on your 
EMU-0404 to formulate any hypothesis, apart from what said by Jeffrey, i.e. 
that probably when using the ASIO driver the 
channel numbering is non-standard. I plan, in one of the next versions, to give 
the user the possibility to dynamically 
alter that channel assignment.
> 
>  Also a question about the DLL support. I think I didn't see a 
> possibility of chancing the "channel skew calibration" -parameters? I 
> think there are many designs that have a changing IQ balance depending 
> on the frequency. I can have -60db image rejection anywhere through 
> 100kHz to 30MHz (thanks for your 0-4 sample delay!) but I have to do it 
> manually now. Is there anyway to add some kind of frequency/image 
> rejection mapping? It would also be great to have those parameters on 
> DLL support.

Yes, I see your point. It would need two things :

1) The DLL is informed about a change of the Tune value on the Winrad screen. 
But this is already implemented, see the 
API TuneChanged in the document describing the DLL architecture.

2) The DLL has a mean to send back the parameters for the image rejection 
routine, relative to that frequency. This is 
not implemented presently, but it would not be much difficult to do. Of course 
the drawback is that, while the rejection 
would be almost perfect at the frequency of reception, it would become visually 
worse in all of the other points of the 
wideband spectrum/waterfall...

My personal opinion is this. First of all, an automatic rejection algorithm 
could be coded, there are examples already 
implemented and that work fairly well. Secondly, the need for am image 
rejection routine will be disappearing in time. 
Such a routine is needed only for RX architectures where the generation of the 
I/Q pair is done in the analog realm, 
like all the RX based on the Tayloe mixer or variants thereof (H-mode, etc.).  
But the present trend is to go more 
digital, i.e. the ADC is moved nearer to the antenna, see the SDR-14, SDR-IQ, 
Perseus and the new QuickSilver (and 
Mercury, when ready). In all of those receivers, the generation of the I/Q pair 
is done when the signal is already in a 
digital status, and as such, the I and Q components are already perfectly 
balanced, and no compensation is needed. So 
personally I see this balancing a thing where to spend some time, but not more 
than a given amount.

Things would be a bit different if TX also is contemplated, but then the 
problems are different, and so the solutions.

Enjoy Winrad !

73  Alberto  I2PHD


_______________________________________________
Winrad mailing list
[email protected]
http://winrad.org/mailman/listinfo/winrad_winrad.org

Reply via email to