It looks very similar to other Silicon Lab products like the Si571, Gian. The jitter of the 549 is about 1/4 of the Si571, though, and the phase noise numbers are really good. Mouser says they have them in stock for about $15 apiece. The factory gets involved and quantities would be required to have a specific DEFAULT startup frequency. But in a ham rig, where you want to tune it with a micro, any startup frequency would be OK. So the $15 part from Mouser would do the trick. Ciao - Bill W7AAZ
| 14530
| 2018-02-10 14:38:44
| Bill Carver
| Re: Silicon Labs Si549
|
Ah....but Mouser says they have 50 in stock, and the minimum order is 50!
Bill
|
| 14531
| 2018-02-10 18:44:10
| John Sutter w1jds
| Re: Silicon Labs Si549
|
They can be sampled. I was going to make a request, but I have to think of some useful startup frequency, though it really doesn't matter for much I'd do at this point. That and I hesitate to start yet another project... -- John
| 14532
| 2018-02-11 07:27:59
| Bill Carver
| Re: Silicon Labs Si549
|
I made a PCB with Si570 pads and H-mode mixer. I'll have to see if the pads match the Si549. W7AAZ
| 14533
| 2018-02-13 12:56:18
| i7swx
| Re: Silicon Labs Si549
|
Ciao Bill,
OK quantity minimum 50 ... maybe sample could be available. Yes, it looks interesting for the phase noise for H-Mode Mixer and also as a clock for sdr converters.
If you compare the pads size of the two, probabli the 549 maybe solderable at the limit of pcb pads.
549 5x7mm vs 570 7,30x8,20
73
Gian
I7SWX
|
| 14534
| 2018-02-14 08:57:09
| drmail377
| Re: Silicon Labs Si549
|
Wow...
Oscillator Phase Noise Look-Up Tool (with real plots):
https://www.silabs.com/tools/pages/oscillator-phase-noise-lookup-tool.aspx
Si570, Fo = 125 MHz CMOS, PN = -129.5621 dBc/Hz @ 10 kHz
Si570, Fo = 125 MHz LVDS, PN = -132.2385 dBc/Hz @ 10 kHz
Si545/7, Fo = 125 MHz LVDS, PN = -141.3169 dBc/Hz @ 10 kHz
N.B., The Si549 is not in the Oscillator Phase Noise Look-Up Tool (yet), but the Si545/7 have the very similar Phase Jitter specifications compared with the Si549. See this page:
https://www.silabs.com/products/timing/oscillators/ultra-series
That's almost a 10 dB improvement!
The inferior Si5351 clock that many in the Amateur community are addicted to doesn't even appear on the Oscillator Phase Noise Look-Up Tool.
When (and if) the Si549 is available in unit quantity (instead of qty.-50 minimum), it looks to me like the Si570 (P/N 570CAC000141DG) and Si549 (P/N 549CAAC000111BBG) should run at about the same $18 each unit price for the 50 ppm/CMOS versions from Mouser. But the 50 ppm/CMOS version Si570 will only (officially) cover 10 to 160 MHz, while the same grade Si549 will cover 0.2 to 250 MHz (50 kHz to 62.5 MHz after quadrature division).
For serious HF and all higher frequency radio work, the Si545/7 & Si549 look like the stand-alone agile clock parts to use now instead of the Si570. (Or am I calling the game too quickly?) BTW, I see no new part to replace the externally clocked Si571 though.
For comparison purposes, the Si570 part may be found here:
https://www.silabs.com/products/timing/oscillators/xo-low-jitter/device.Si570
All SiLabs clocks can be found here:
https://www.silabs.com/products/timing/oscillators
73's, David WB4ONA
|
| 14535
| 2018-02-14 08:59:02
| drmail377
| Re: Silicon Labs Si549
|
One advantage the Si570 has over the Si549 is wider "glitchless" tuning range, +/–3500 ppm for the Si570 vs. +/–950 ppm for the Si549. This implies a tighter loop bandwidth with the Si549 which makes sense given the lower close-in phase noise. This also forebodes longer lock times as well. So as you "tune" the Si549, more loop locks required and each lock takes more time than with the Si570. And the problem gets worse as you go lower in frequency. This may be a deal killer for using the Si549 as an HF L.O., especially if you don't divide the output (to get I/Q for-example).
73's, David WB4ONA
|
| 14536
| 2018-02-14 17:04:22
| jgaffke
| Re: Silicon Labs Si549
|
Nice part!
If we program it for 7.15mhz in the middle of 40 meters, increasing by 950ppm gives us 7.15*1.000950 = 7.1567825mhz and decreasing by 950ppm gives 7.15*0.999050 = 7.1432075mhz. So when tuning across the dial there must be a tic at least once every 13.585khz Make it an even 10khz (perhaps with some hysterisis) and it's a feature, you will know the frequency without looking at the display. Output is squelched for up to 10ms when exceeding that 950ppm. At the max i2c clock rate for the si549 of 1mhz, the registers could be programmed in around 0.2ms. So even with an i2c clock rate of 100khz, the si549's 10ms (max) settling time likely predominates. Could be that short jumps of around 950ppm settle out much faster than their 10ms worst case. Page 18 of the datasheet mentions "FCAL" (Frequency CALibration?), it also shows up in the register description but with no real explanation. Can anybody give some insight as to exactly what's going on here? A google for "si549 fcal" finds nothing but the datasheet. My best guess would be that it has something to do with tuning the PLL filter to meet the needs of the new vco frequency.
The si549 can do 180 degree out of phase CMOS outputs. Unfortunate they couldn't add a wee bit more logic to give us quadrature CMOS outputs.
Datasheet is quite nice by SiLabs standards, very readable with a few minor anomalies. The example on page 16 gives a refosc frequency of 55.05mhz in step 5, that number never shows up elsewhere in the document. Refosc frequency for the si549 is fixed at 152.6mhz. Unlike the si570, the refosc frequency is factory calibrated. On the si570 you had to be told the powerup output frequency it had been factory programmed for in order to make use of the factory calibration of the refosc. A real pain if something else was suddenly easier to buy.
The value of fbdiv can take on fractional values of 60.0-2048.0. Given the vco range of 10800-12552mhz and the 152.6mhz reference oscillator, fbdiv is actually confined to values between 10800/152.6= 70.77 and 12552/152.6=82.26. This plus the 55.05mhz example refosc mentioned earlier suggests to me that the silicon die is meant to be used with a range of reference oscillator frequencies, and that the silicon may be made available more cheaply in a version without the 152.6mhz reference oscillator. (15 years ago, the si570 was preceded by similar parts where you supplied the refosc.) I'd prefer this, a single refosc across all frequency generation devices can greatly simplify system calibration.
I'm sure there will be lots of code for this part that sucks in a double precision floating point library for use in calculating the 43 bit fixed point value for fdiv = fvco/frefosc. However, note that the integer part of fdiv is confined to be between 70 and 82, fitting easily in 7 bits. That leaves room for 25 fractional bits if we do this calculati
| 14537
| 2018-02-14 20:44:25
| aa0zz
| Re: Silicon Labs Si549
|
Hi, I agree, the Si549 looks great and I'm very anxious to try it. There is one factor in which the Si570 still seems to beat it, however. The Si570 has three different types with different temperature and total stability values. The three are 7ppm.temperature (20ppm total), 20ppm temperature (31.5ppm total) and 50ppm temperature (61.5ppm total). It appears that there's only one Si549 type and it's 20ppm temperature (50ppm.total). The 7ppm Si570 has to be handled in a somewhat crazy way with parameters in different registers than for the other two types but it's "just software" and the result is very nice and stable. I'm also a bit confused about how the user determines the actual frequency of the on-board crystal of the Si549. I know it has a nominal 152.6 MHz crystal (vs 114.285 MHz for the Si570) but it's almost never exactly that frequency. Having a factory calibrated start-up frequency in the Si570 gives the user a chance to read the values out of non-volatile memory, run the frequency-determining algorithm "backwards" and thereby calculate the actual crystal frequency.(within tolerance limits). Then this actual crystal frequency can be used in subsequent calculations to generate very accurate frequencies. If the user is going to be setting the start-up frequency, the factory must not be calibrating them. How does the user determine the actual crystal frequency. Does this mean we are back to calibrating against an external frequency standard? In my Si570 signal generators, when using the nominal crystal frequency the generated frequency is often off by 15-20 kHz at 7 MHz but it's "right on" (within tolerance limits) after the calibration routine is executed. 73, -Craig, AA0ZZ
|
| 14538
| 2018-02-14 21:50:13
| jgaffke
| Re: Silicon Labs Si549
|
I've always found it silly that the si570 has you do all the math backwards to find the actual reference oscillator frequency given the register contents and the startup frequency you think it might have been factory programmed with. Too bad they could not have given us a few more read-only register bits to just tell us what the fool reference oscillator frequency actually is.
A thorough read of the programming procedure for the si549 finds that they just assume the reference oscillator is exactly 152.6000000000000000000mhz. So I'll just assume that they have somehow factory calibrated it to be so until we find out otherwise.
As I recall, the 7ppm si570 came out much later than the initial part. Perhaps a 7ppm version of the si549 is planned.
To compute the 32 bit value for fvco/152.6mhz on some minimalist microcontroller, first precompute the reciprocal of 152600000. Here we find a 32 bit fixed point value for that reciprocal, the radix point is 47 bits to the left of the lsb: recip_refosc = int(1.0/152600 * 2**(17+32) + 0.5) = 3689056051 This 32 bit value can be a magic number precompiled into the program.
Let's just leave the vco freq in hz for now: fvco = 12511900
Multiplying the two values in a 32x32 multiplier gives a 64 bit result, which we then downshift by 17+8 bits to obtain a 32 bit result with the 8 integer bits in the msb's plus 24 fractional bits: fbdiv = (fvco * recip_refosc) >> (17+8)
A typecast to (long long unsigned int) can create a temporary 64 bit integer to help a C compiler figure this out, something like: fbdiv = ((long long unsigned int)fvco * recip_refosc) >>(17+8)
The integer part of the final result only needs 7 bits, but this way (with 8 integer bits) the algorithm is easier to visualize and debug (if viewing in hex). Likewise, the value for fvco could have 8 fractional bits for additional precision, as the vco value in hz only takes 24 bits. Adjusting the calibration can be done by blindly moving the value for recip_refosc a little bit until zerobeat with a known standard is achieved.
We could add up to 8 fractional bits to fvco for more accuracy, and buy one more fractional bit in the final
Of course, if on something bigger than an ATMega328P, you can just borrow the example code from SiLabs and do it all in double precision floating point.
Jerry, KE7ER |
| 14539
| 2018-02-15 09:33:37
| jgaffke
| Re: Silicon Labs Si549
|
I previously wrote: > To compute the 32 bit value for fvco/152.6mhz on some minimalist microcontroller, > first precompute the reciprocal of 152600000.
First off, you can ignore this if on a reasonably large processor that does double precision floating point. But on a small microcontroller, bringing in a library for either floating point or 64 bit integer math can consume all the available flash. There might be a more obvious way to do this using 32 bit divides but multiplies are often better supported, especially in something like an FPGA.
There were a few errors in that hasty post last night, here's a working example in python of the fixed point integer math needed to compute the integer and fractional parts of fbdiv when given the desired fvco (around 12ghz) and the reference oscillator frequency fref (nominally 152.6mhz). In case anybody cares.
######################################################################## # The reciprocal of 152600000 hz in fixed point, radix is 59 bits to the left of LSB # In final code, the value 3777593396 can be hard coded as a funny number # User could make small changes to fref_inv to calibrate the nominally 152.6mhz reference fref_inv = int(1.0/152600000 * 2**(27+32) + 0.5) # result is: 3777593396
# An example of a desired fvco in hz, but shifted down 2 bits so fits in 32 bits fvco=12511900000>>2
# Compute fvco/frefosc by multplying by the reciprocal, integer part of hsdiv is in 7 msb's # Shift down 27 bits because of the (32+27) shift in forming recip_refosc # Shift down by 7 because we want 7 bits of integer in the MSB's # Shift up by 2 because we truncated 2 LSB's of fvco fbdiv = (fvco * fref_inv) >>(27+7-2) fbdiv_int = fbdiv >>(32-7) fbdiv_fract = fbdiv & 0x1ffffff
print fbdiv_int, fbdiv_fract # result is: 81 33268581
# Check the result: 152600000 * (81 + 33268581.0/(2**25)) # result is: 12511899996.989965
# In C code, this line: fbdiv = (fvco*recip_refosc) >>(27+7-2) # might look like this: fbdiv = ((uint64_t)fvco * recip_refosc) >>(27+7-2); # The typcast of fvco to 64 bits tells the compiler to keep the entire 64 bit # product of the 32x32 multiply around long enough to shift it down by 27+7-2 bits. # As I recall from a few years ago, this trick worked as hoped under gcc # for the MSP430, performing a single 32x32 multiply, then storing the shifted 64 bit # product into the 32 bits of fbdiv. ########################################################################
Jerry, KE7ER
|
| 14540
| 2018-02-15 14:30:48
| aa0zz
| Re: Silicon Labs Si549
|
Jerry, The calculations CAN be done in a little PIC with no libraries. I do a 40 x 32 bit division in a 16F88 PIC in my Si570 app to generate the parameters. All in ASM, of course. 73, -Craig, AA0ZZ |
| 14541
| 2018-02-15 16:12:49
| jgaffke
| Re: Silicon Labs Si549
|
Might be interesting to compare si549 results someday. I think I have the full si549 algorithm fleshed out, just a few standard 32 bit operations, and should give better than 1ppb accuracy for any desired fout.
I must say, the si549 has a much cleaner register interface than earlier clock-gen chips. The register interface is quite straightforward, perhaps they have an arm-m0 buried in there to take care of the rough edges.. ---In emrfd@yahoogroups.com, wrote :
Jerry, The calculations CAN be done in a little PIC with no libraries. I do a 40 x 32 bit division in a 16F88 PIC in my Si570 app to generate the parameters. All in ASM, of course. 73, -Craig, AA0ZZ |
| 14542
| 2018-02-16 09:28:14
| jgaffke
| Re: Silicon Labs Si549
|
I'm now convinced the Si549 has a well calibrated 152.6mhz reference oscillator. Evidence of this if found on page 19 of the datasheet where the ADPLL is described, which allows excursions of +/- 950ppm from the previously programmed frequency.
To use it, you load the signed 24 bit integer ADPLL_DELTA_M into three i2c registers, takes effect after writing to the third register. That integer moves the output freq in steps of 0.0001164 ppm, or 0.1164ppb. Writing a value of 0 to ADPLL_DELTA_M returns the output to the originally programmed frequency. This same mechanism could easily be used to factory calibrate the 152.6mhz reference oscillator by programming an offset value that gets added to your 24 bit ADPLL_DELTA_M. The datasheet states that their "Total Stability" spec of 50ppm includes initial accuracy, plus temperature, power supply, load, and aging variations. It does come calibrated.
The unfortunate thing is that the only obvious way to compute 1e9*0.0001164*(F1-F0)/F0 (where F0 is the programmed output frequency, and F1 is the desired new frequency) is by using double precision floating point. The reciprocal of F0 could be found through Newton Raphson iteration and then it is straightforward fixed point calculations, but finding that reciprocal is a PITA. Perhaps table lookup is sufficient for the reciprocal (with interpolation), especially if operating only in a few narrow bands of frequencies. In many applications you could simply nudge the ADPLL_DELTA_M value around, and use some independent means to determine the actual operating frequency. The 24 bits available almost exactly confine such excursions to +/-950ppm, so no need to do much math to stay within safe limits. Of course this is no longer 1980, we have some really nice ARM microcontrollers out there for cheap capable of supporting double precisi
| 14543
| 2018-02-16 09:50:06
| jgaffke
| Re: Silicon Labs Si549
|
Single precisi
| 14544
| 2018-02-16 09:58:32
| jgaffke
| Re: Silicon Labs Si549
|
The computation for the ADPLL value (could use single precisi
| 14545
| 2018-02-16 14:02:37
| aa0zz
| Re: Silicon Labs Si549
|
Jerry and group, It looks to me like it's worse than that. The Si549 spec says you can go 950 ppm in either direction from the last stable frequency without needing a resynch. Thus, 950 parts per million * 7.15 million = 6792 parts (Hz). Moving 6.7 kHz in EITHER direction will require the resynch and thus a 10mS glitch. Continuing to move in the same direction, you can go another 6.7 kHz and then it will require another resynch. Am I missing something here? On the other hand, the Si570 can move 0.35% without needing a resynch so 7,150,000 * 0.0035 = 25.025 kHz. That's 3.7 times as far. 73,
-Craig, AA0ZZ |
| 14546
| 2018-02-16 15:10:46
| jgaffke
| Re: Silicon Labs Si549
|
When you say "worse than that", do you mean worse than my claim of a 13.585khz range at 7.15mhz? Assume we're at 7.15mhz, and know that the trend is up in frequency. So program the si549 for 7.155mhz and immediately use the ADPLL feature to jump back by 5khz. Those ADPLL registers will take affect long before the si549 comes out of the 10ms squelch from the initial programming. Use ADPLL to advance in frequency till we reach 7.160mhz and do it all again.
Regarding that ADPLL computation I'm currently obsessing with, we can do it in integer math. In these examples, adpll, f0, f1 are all 32 bit integers. f0 is the initial frequency, f1 is the updated frequency, and adpll is the 24 bit result.
First, here it is in double precision floating point, correct as can be: adpll = (1e6L/0.0001164L)*(f1-f0)/f0 + 0.5;
This integer math solution has a 64 bit dividend, the divisor and quotient are 32 bits, the result is within 1 (within 0.0001164 ppm) of the above floating point result. adpll = 8591065292LL*(f1-f0)/f0;
Backing off to a 32 bit dividend with 16 bit divisor and quotient is still quite good. Worst case seems to be an error of about 0.01ppm when out at + or - 915ppm: uint32_t fs0, fsh; fs0=f0; fsh=0; while (fs0&0xffff0000) {fs0>>=1; fsh+=1;} adpll = (((0x8004L*df)<<18)/fs0)>>fsh;
When specifying frequencies, they are normally in hz. To give better precisi
| 14547
| 2018-02-16 16:47:25
| aa0zz
| Re: Silicon Labs Si549
|
Sorry, I wasn't clear and wrote an ambiguous sentence.Yes, I mean the frequency range between required resynch operations. The way I read the spec the "distance" between 10 ms glitches at 7.15 MHz is only 6.792 kHz instead of 13.585 kHz. Assuming you are continually tuning UP in frequency you will have to do a "freeze" every 6.792 kHz, causing a 10 ms glitch each time. Even if you can do additional calculations during the 10ms glitch you will not be hearing anything in the RX during the glitch and you will hear a "pop" in the RX audio when it comes out of the glitch. Before every frequency update you need to test how far you are moving since the last resynch and, if greater than 950 ppm (6.792 kHz at 7.15 MHz), you will need to do the resynch in order to keep the PLL running. 73, -Craig
|
| 14548
| 2018-02-16 18:27:25
| jgaffke
| Re: Silicon Labs Si549
|
Craig,
Yes, once you initially program the part, ADPLL only allows you to move +/-915ppm = 6.7khz@7.15mhz. However you might re-read my previous post. Summary: To scan up from 7.15 to 7.16 mhz, program for 7.155mhz and make use of both the negative and positive ADPLL range.
In many applications an occasional 10ms of squelch when tuning will be acceptable. If not, then this may not be the right part. Though we might try ignoring their programming recommendations on page 18, skip over the FCAL-disable and/or output-disable steps. I doubt that will be clean, though the si5351 managed to give us a very nice easter egg in that regard.
The +/- 950ppm is a fairly hard limit, enforced by the 24 ADPLL register bits available.
MSB is a sign bit, so absolute max is 0.0001164*(2**23-1) = 976.4338548ppm. But they might need that last 26ppm to factory calibrate the 152.6mhz reference.
In a previous email I wrote: Backing off to a 32 bit dividend with 16 bit divisor and quotient is still quite good. Worst case seems to be an error of about 0.01ppm when out at + or - 915ppm: uint32_t fs0, fsh; fs0=f0; fsh=0; while (fs0&0xffff0000) {fs0>>=1; fsh+=1;} adpll = (((0x8004L*df)<<18)/fs0)>>fsh; That's all kind of half baked, probably won't work (yet) across the entire freq range, and allocati
| 14549
| 2018-02-17 10:55:38
| Gary Winblad
| Re: Silicon Labs Si549
|
Craig and Jerry, You guys are real scientists! Keep up the good work. I for one am reading and hoping you guys find good solutions we can all use! The tuning glitches are a real negative for using these parts. Here's my will ass idea... Could two of the devices be used. Keep programming the first one, and program the second just at the glitch limit of the first one. When you get the first one to the glitch point, quickly (maybe external hardware?) switch on the second one and switch off the first one. There will still be a glitch but should be much shorter. 73, Gary WB6OGD
| 14550
| 2018-02-17 12:37:25
| jgaffke
| Re: Silicon Labs Si549
|
Yes, switching between two si549's would avoid the squelch if you're ok with double the price. Use an external analog switch, or a digital 2-to-1 mux of the appropriate logic family. There will be a quick discontinuity when switching, I'd guess barely perceptible in a receiver, certainly less intrusive than 10ms of squelch. In some applications that discontinuity will be a deal breaker though, and I don't see a good way around it.
Regarding my previous email, this C code can't be made to work well enough to bother adpll = (((0x8004L*df)<<18)/fs0)>>fsh;
This works fine, but costs an integer divide with a 64 bit dividend, 32 bit divisor: adpll = 8591065292LL*(f1-f0)/f0;
For absolute minimal processor resources, just jog the 24 bits of adpll around till fout is what you want without bothering with any math. Or ignore adpll entirely and live with a squelch each change in frequency.
Jerry ---In emrfd@yahoogroups.com, wrote :
Craig and Jerry,
You guys are real scientists! Keep up the good work.
I for one am reading and hoping you guys find good solutions we can all use!
The tuning glitches are a real negative for using these parts.
Here's my will ass idea...
Could two of the devices be used. Keep programming the first one, and
program the second just at the glitch
limit of the first one. When you get the first one to the glitch point,
quickly (maybe external hardware?)
switch on the second one and switch off the first one. There will still
be a glitch but should be much shorter.
73,
Gary
WB6OGD
|
| 14551
| 2018-02-17 14:46:39
| Bill Carver
| Re: Silicon Labs Si549
|
A transceiver with two Si549s? Interesting to consider the concept, and algorithms to be able to alternate between two moving Si549's. There would only be an instantaneous phase discontinuity, doubt detectable. Also amusing to think about the "double the cost". What has this world come to: two Si549s are less than the cost of one cut-to-frequency crystal used to be, when you could still get someone to make it. W7AAZ
| 14552
| 2018-02-17 16:18:40
| aa0zz
| Re: Silicon Labs Si549
|
I agree - it's a fascinating idea. The cost would be insignificant for individuals although may it be significant for products produced to sell in large volume at low prices. One processor could handle it all - writing to both devices and controlling a switch which selects which device is active in producing the RF. Do all "resynch" operations as background activities when the device is not active. Neat idea! 73, -Craig, AA0ZZ |
| 14553
| 2018-02-18 10:24:52
| Gary Winblad
| Re: Silicon Labs Si549
|
Is there any way to switch the output through the registers? The Si5351 can be switched at >50 WPM CW. 73, Gary WB6OGD
| 14554
| 2018-02-18 11:52:38
| jgaffke
| Re: Silicon Labs Si549
|
Bit 0 of register 17 "synchronously disables" the device, though not clear if the output is left in a zero state or tristated. The Si549 supports i2c writes with an i2c clock of up to 1mhz, though most uC's run the i2c bus at perhaps 100khz. So around 24 bits*1/100khz = 240us to write to register 17, and thus a significant glitch unless you simultaneously do i2c writes to both, turning one on and the other off.
Page 2 of the datasheet shows how to assemble a part number. All pinout options except option J include an OutputEnable pin. However, it is either on pin 1 or on pin 2, and either active high or active low depending on which part variant you wind up with. But that OutputEnable apparently does tristate the output pins. So could just wire the clock output pins together across the two devices, use the OE pins to select one or the other part using two GPIO pins from the uC.
However, using an external multiplexer can happen much faster than using the OE pin. Si549 Output Enable times are spec'd to be a max of 20us
| 14555
| 2018-02-18 14:44:41
| Bill Carver
| Re: Silicon Labs Si549
|
Keep BOTH Si549's active......just switch the outputs with external logic as Jerry says. Two Si549, two outputs.....one for RX, the other for TX. But make it function like a "crossbar" kind of a switch that can send either Si 549 to either transmitter or receiver. While tuning around the band use both Si549's alternately for the receiver: switching between the outputs will be essentially instantaneous and the lack of phase continuity would be undetectable IMHO. When you stop tuning in wide swaths, then repurpose the second Si549 to the transmitter. This allows essentially instantaneous glitchless switching even if operating splits....or I suppose even operating crossband. W7AAZ
| 14556
| 2018-02-18 15:13:39
| jgaffke
| Re: Silicon Labs Si549
|
A minor correction, where I wrote: < An external PECL or LVDS multiplexer could switch clocks in perhaps 0.001us. < A CMOS multiplexer should be fine HF, could switch in 2 or 3 us
That's not giving CMOS much credit, was thinking 2-3 nanoseconds and wrote microseconds. PECL/LDVS can be be an order of magnitude faster with modern parts. ---In emrfd@yahoogroups.com, wrote :
Keep BOTH Si549's active......just switch the outputs with external logic as Jerry says. Two Si549, two outputs.....one for RX, the other for TX. But make it function like a "crossbar" kind of a switch that can send either Si 549 to either transmitter or receiver. While tuning around the band use both Si549's alternately for the receiver: switching between the outputs will be essentially instantaneous and the lack of phase continuity would be undetectable IMHO. When you stop tuning in wide swaths, then repurpose the second Si549 to the transmitter. This allows essentially instantaneous glitchless switching even if operating splits....or I suppose even operating crossband. W7AAZ
| 14557
| 2018-02-20 14:18:12
| Gary Winblad
| Re: Silicon Labs Si549
|
Yes, the main oscillator is one of the main blocks I need to finish in my Picastar transceiver. The cost would be minimal compared to a high end DDS with all its support circuitry, while minimizing size and power consumption. I really hate the spurs from the AD9851 I am using now... Using 10Hz tuning steps is a discontinuity already and is acceptable. 73, Gary WB6OGD
| | | | | | | | | | | | | | | |