<div><span class="Apple-style-span" style="color: rgb(160, 160, 168); ">On nedjelja, 2. listopada 2011. at 06:59, Phil Harman wrote:</span></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span class="Apple-style-span" style="font-family: Arial; font-size: small; ">Your block diagram looks fine - a few
suggestions. There is already an I2C bus on the Atlas bus that will drive
an Si570, I tested this when prototyping Cyclops and it works just fine.
So instead of the Atmeg uP you can use an I2C addressable latch to directly
control the relays etc. That would remove one source of potential digital
noise off the board since I2C would only need to send data on a change of state.</span><span><div><div>
<meta content="text/html; charset=iso-8859-1" http-equiv="Content-Type">
<meta name="GENERATOR" content="MSHTML 8.00.6001.19120">
<div><font size="2" face="Arial"></font> </div></div></div></span></blockquote><div><br></div><div>I've been thinking about that… The original idea was to have the Atmega MCU as an "intermediary", as shown in the diagram, sitting between Atlas and the Si570 (and the relays). The reasoning behind it was, that it would reduce the amount of changes and logic needed in the rest of the system (all that would need to be communicated to the down-converter board would be the frequency "zone"). On top of that, it would simplify manual control for initial, experimentation purposes.</div><div><br></div><div>The noise impact probably wouldn't be too bad, as the plan was to use the internal Atmega xx8 oscillator, which can be clocked as low as 1 MHz, and use deep sleep modes whenever there's no activity on the bus (essentially behaving the same way as latch ICs would, as far as noise is concerned).</div><div><br></div><div>However, now that i think about it and after your remarks, maybe it might be a better idea to introduce a header for external control and a jumper that engages/disengages the direct Atlas I2C control. Hmmm.</div><div><br></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div>
<div><font size="2" face="Arial">As I mentioned in a previous post I breadboarded
your basic system using an ADF4350 instead of the Si570. The advantage of the
ADF4350 is that it goes to 4.4GHz, the disadvantage is that the lowest frequency
is about 137MHz and the phase noise at 1GHz is -100dBC at 1kHz. The Si570
goes down to 3MHz in practice I think (not that you need a down converter below
55MHz) has gaps in its coverage and drifts. The phase noise may be
better.</font></div>
<div><font size="2" face="Arial"></font> </div></div></div></span></blockquote><div><br></div><div>According to other people's measurements scattered about the web… The Si570 should be around -110 for the CMOS version, near -120 for LVDS and a bit better still for CML. The drift is about 1-1.5 Hz at room temperature, without an oven. The quasi-oven should help reduce that further. The frequency range is a more significant issue (at least i think). I don't care much about the spectrum above the 23cm band, but i would like to have the 2m band (and possibly air band) placed somewhere comfortably near the middle of the Mercury pass-band and far from the oscillator's/DDS's extremes of operation.</div><div><br></div><div>ADF4351, however, covers 35-4400 MHz. If i remember correctly, its phase noise figures are better and i think i remember seeing someone using it as a basis for an SDR. I've had that in mind as a possible "phase 2" if the Si570 works out (it does use a 3-wire interface, tho, so it's not quite a "drop-in" replacement).</div><div><br></div><div>Could the 10MHz reference off the Atlas bus be used with ADF435x?</div><div><br></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div>
<div><font size="2" face="Arial">With either solution you will need away to
eliminate the images that will occur. Analogue filters will be difficult
in the uWave region but image subtraction in software may work quite
well.</font></div>
<div><font size="2" face="Arial"></font> </div></div></div></span></blockquote><div><br></div><div>I'm probably misinterpreting something here, but… Shouldn't the 65 MHz LP filter (SXLP-65+) on the output take care of that? It has a loss of min. 40 dB in the stop-band above 96 MHz. Perhaps SXLP-45+, the 45 MHz version would be a better choice?</div><div><br></div><div><br></div><div>-- <br>Ante Vukorepa<br>Sent with <a href="http://bit.ly/sigsprw">Sparrow</a></div>