Hi all, I am using the EMU 0202 USB without any problems !
Greetings and a prosperous 2008 Christoph DF9CY Am Dienstag, 8. Januar 2008 07:47 schrieb Janne Pulkkinen: > 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 -- Christoph Petermann www.df9cy.de | www.cpetermann.de Amateur Radio DF9CY | Astrophotography | Folkmusic _______________________________________________ Winrad mailing list [email protected] http://winrad.org/mailman/listinfo/winrad_winrad.org
