Hi Alberto! > 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. >>
Basically, what I have are absolutely similar ASIO projects for Winrad, but with different sampling frequencies. Like I said, the 48kHz and 96kHz works fine. I don't believe that the change of the sampling frequency is changing the ASIO channel routings. Of course this might be something with my setup and there isn't necessarily a bug in the Winrad, I thought that this might be important and wanted to report this! >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. This is a thing I've noticed and I'm gonna incorporate it with my own hardware controller software, nice feature! >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... Here's an idea and I don't deny that I would not benefit from this: If you could just simply control the channel skew parameters from outside through the DLL, many hams like I, that do a bit software themselves too, could do the image rejection mapping outside the winrad. For example: I'm using a simple software to control my DDS, bandpass filters, RX/TX routines etc. It would be really easy to incorporate an image rejection map to my software. I could test image rejection values with Winrad for example for every MHz between 1-30 and make "public constants" that would be send to winrad through the DLL. Of course you can do the mapping even with every 100kHz, hi. I understand that my need isn't enough for a change in software, but I think that those parameters are easy to add to the DLL and few others might benefit from this too? And it doesn't make any visible changes that would make confusion to other users. >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. Oh, this is interesting! I haven't heard about automatic rejection algorithm! Gotta study about that! >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. Yeah, I've noticed the same thing, people are moving towards to ADCs. But isn't there gonna be tayloe & other IQ samplers around for a while? I think even many SRD-1000 users user winrad for reception. But yeah, ADC is the future. Too bad it's too complex for me :) Gotta study that too! >Things would be a bit different if TX also is contemplated, but then the problems are different, and so the solutions. >Enjoy Winrad ! > I do, I really do :) > 73 de Janne, OH1GTF _______________________________________________ Winrad mailing list [email protected] http://winrad.org/mailman/listinfo/winrad_winrad.org
