Could a 80.000 MHz clock be used?

[in3otd]

Hello,
googling around I saw this nice project
http://pavel-demin.github.io/red-pitaya-notes/sdr-transceiver-hpsdr/
where a Red Pitaya is programmed to work with the HPSDR protocol, so that it can be used with the common SDR SWs.
The interesting thing is that the ADC there is clocked at 125 MHz, which is not an integer multiple of 384 kHz, so that polyphase FIR filters are used for resampling to obtain the desired final sampling rate.

I was wondering if a similar thing could be done for H-L in order to use a more common clock frequency, which could have some advantages, e.g.:
- when using a 80 MHz oscillator:
  - there are +/- 10 ppm oscillators that cost less (2.24 USD @ qty 1) than the +/-30 ppm Si510
  - for the ultimate stability, there are (VC)TCXO with +/-1 ppm stability for about 30 USD
  - could be easy to lock to a GPSDO-derived 10 MHz (or to use a multiplier directly)
-or using a 40 MHz oscillator:
  - has the disadvantage that the AD9866 internal PLL must be used, so that the phase noise will be worse
  - there are (VC)TCXO with +/-1.5 ppm (temp. only) stability for 3.29 USD @ qty 1 (!!)
  - could of course also be locked to an external 10 MHz

73 de Claudio, IN3OTD / DK1CG

[James Ahlstrom]

Hello Claudio,

Yes, an 80 MHz oscillator could be used.  For example, the FPGA could decimate by 250 to get a rate of 320k and send the data to the PC.  Then the PC could divide by 10, multiply by 3 and divide by 2 to get 48k for demodulation and playback.  But the 320k rate is not a rate defined by the Hermes specification and it is not clear whether PowerSDR will understand it.

So the fractional conversion can be done in the FPGA.  That is how Red Pitaya does it, although I don't know the details.  The key is to multiply (interpolate) the rate by 3, and then divide (decimate) the rate by 2 or 5.  For example, 80000k divided by 625 is 128k, then times 3 and divided by 2 gives 192k, a standard rate.

Jim

N2ADR

[Steve Haynal]

Hi Claudio,

The Red Pitaya has a lot going for it - 14bit 125 MSPS dual ADC, Zynq that runs Linux, cost of $239 on Mouser.  I was watching it closely just before it went on kickstarter. I tried to see what clock they are using for their ADC/DAC but the schematic is not opensource...

The fractional FIRs used in the example you linked are interesting. We could try something like that with the Hermes-Lite. Jim's approach could also work. For v2, I'd like to keep a common footprint for the ADC oscillator so that we can use what is known to work and also experiment with other oscillators.

I took a quick look on DigiKey and think I found the $2.24 80 MHz part you referenced. The phase specs weren't that great on the one I found. What one were you looking at?

The Si510 is fairly low jitter. There is no guidance in the AD9866 datasheet, and I have never done the analysis to know at what value jitter becomes a problem in the Hermes-Lite. This would be an interesting data point to have.

73,

Steve

KF7O

[in3otd]

Hello Steve,
yes, the Red Pitaya is an interesting platform, but I didn't even think to buy one, as I know I wouldn't have the time to play with it, hi.
The resampling FIR should be in the FPGA, so the actual output rate matches what is expected by the common SDR SWs. I understand it can be implemented there, but I have no idea of the complexity/resources needed compared to the current RX downsampling/filtering chain.

I think you found the oscillator I was referencing, Digi-Key Part Number 535-11114-1-ND; it's true that it has worse specs regarding the jitter, about 15 dB higher w.r.t. the Si510. But, as you said, the Si510 is quite good there and we do not have numbers regarding the actual noise at the AD9866 output so we do not know how much noise is added by it.
There is a good discussion about the output noise for transmitter with some numbers here http://www.sm5bsz.com/dynrange/dubus313.pdf ; the Si510 alone will be better than the best TX there...

For the RX, the jitter/phase noise will mainly affect the reciprocal mixing performances, the results of the test done by AB4OJ some time ago were good in that respect, limited by the measurements setup, if I understood correctly, so a less performing oscillator *might* be suitable anyway.

73 de Claudio, IN3OTD / DK1CG

[Steve Haynal]

Hi Claudio,

Thanks for the link. It would be interesting to understand better just how low performing of an oscillator we can get by with. One of the first builders of a Hermes-Lite used an 80 MHz crystal as that is what he had on hand. He said receive worked to some extent, although the firmware was not adjusted.

Although I am not a fan of Xilinx software tools, one plus for Xilinx is that more of their DSP IP is free compared to Altera. I suspect that the design you referenced just used this ip which has resampling. Unfortunately, the standard NCO IPs do not support the type of distortion I am playing with.

73,

Steve

KF7O

[in3otd]

Hello Steve,
it will be difficult to determine how noisy the oscillator can be, the LO of a good spectrum analyzer is usually noisier than the average HF radio. If one has a good direct-sampling SDR it might be suitable for the task, though,

As you suspected, the Red Pitaya SDR uses the Xilinx FIR compiler, see e.g. here
https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr_transceiver_hpsdr/rx.tcl

IMHO, it could make sense anyway to target a 80 MHz oscillator, the Si510 could still be used for the best noise performances and it will make easier to lock a suitable oscillator to an external reference. But I understand that currently the priority is on improving the TX side.

73 de Claudio, IN3OTD / DK1CG

[James Ahlstrom]

Hello Claudio,

I agree an 80 MHz oscillator is interesting.  Looking at Digikey as an example, they stock the Connor Winfield TB522-080.0M, an 80 MHz TCXO (temperature compensated crystal oscillator).  A TCXO has excellent stability and very low phase noise.  It costs $30.  That is a lot, but some have stated that the stability of the Si510 for WSPR is inadequate.  I think a TCXO is adequate for any task at HF, and locking to an external reference should never be necessary.  And I expect that a pure crystal oscillator should out perform a PLL solution.  We could make PC pads to accept either the TB522-080.0M or a cheaper oscillator in the same 5x7 mm package.

The 535-11114-1-ND part you mentioned is a MEMS oscillator.  I don't know much about these parts.  I know they have greater phase noise than a crystal, but I don't know about their stability over temperature.

There should be a pure crystal oscillator solution available for 80 MHz.  I have always avoided programmable oscillators because it seems that the PLL must introduce noise, but maybe I am living in the past.

Jim

N2ADR

[Steve Haynal]

Hi Jim and Claudio,

Take a look at the jitter/phase noise specs of some of the PLL-based Silicon Labs, SiTimes, IDT or TI programmable oscillators and jitter attenuation or jitter cleaning devices. I wouldn't "clean" a signal with the PLL on an Altera MAX10, but these PLLs are designed for low jitter and do a good cost-effective job. This market has grown due to the demand for low jitter clocks in cell phones, etc.

Using a $30 oscillator with a $35 ADC strikes me as too unbalanced. What about this idea for v2. The ethernet chip needs a 25 MHz reference clock. The ethernet chip uses that clock to generate and provide the FPGA with a 125 MHz clock. Fortunately, there are inexpensive TCXOs just for this ethernet application. See this part with 2.5 ppm stability for $2.73. We use this clock to discipline the same low jitter Si510 device, or even one with worse temperature stability, that we are already using. I disagree that "locking to an external reference should never be necessary." To me the point of inexpensive SDR is to do as much as possible in software/firmware to minimize cost as well as simplify and eliminate hardware.

73,

Steve

KF7O

[in3otd]

Hello,
my main motivation for allowing locking to/using an external reference is that the main application I have in mind for a H-L is as an IF for a microwave transverter. Since it's relatively common to have a high-stability, GPS locked, 10 MHz reference to lock the transverters local oscillators, it will be nice to be able to use it also for the H-L.

I think it will be good if we could support several options for the reference clock, and having a common (or not so uncommon) clock frequency will help in this respect.
- we should have a "basic" configuration which works well for most applications , this could be the current Si510 at 80 MHz with a nearby temperature sensor (like this) and/or PTC for improving its stability. It might still be good enough for WSPR, some experiments are needed. Might be another MEMS oscillator, if stability/phase noise are good enough.
- this will allow (not *require*) to use a 80 MHz high-end TCXO. Might seem odd to use a clock costing as much as the ADC, but, well, seems not a issue to me, since it will be just a possibility (for those not having/wanting a GPSDO, see below, and looking for an even better stability)
- if there is already a high-stability 10 MHz reference available, this could be used to lock a 80 MHz VC(X)O. Or even multiplied directly x8, if the starting reference is clean enough.

I'm not sure I understand how you plan to use the 125 MHz clock to obtain the AD9866 reference clock; what I was thinking was actually the other way round, use the 80 MHz clock to generate the Ethernet PHY clock, if we have a spare PLL in the FPGA (not sure).

73 de Claudio, IN3OTD / DK1CG

[James Ahlstrom]

Hello Steve and Claudio,

I agree with everyone's comments.  This is a very interesting discussion and I just want to throw out some more ideas.

The 25 MHz oscillator is interesting.  It is cheap because there is a large market for 25 MHz.  Similarly, 100 MHz is cheap too. Look at the six dollar 100 MHz oscillator 1473-1293-ND from Digikey.  This is a MEMS though, and I just don't know much about MEMS.  But if we replace the AD9866 with AFE7225 as discussed by Steve, we could clock the ADC and FPGA directly, and obtain the 25 MHz from a divide by 4 chip.  It is also a VCTCXO, so it could easily be locked to a 10 MHz reference.

The trouble with 25 MHz is that we need a separate high quality clock for the ADC, so we need a second oscillator.  Better is a single high quality ADC clock with everything else sourced from it.  I am sympathetic with Claudio's wish for a more standard frequency.  If we use 80 MHz, the FPGA code becomes more complicated if we still want to present standard sample frequencies like 192 ksps to PowerSdr.  But we will be stuck with whatever clock we choose, so I think we should seriously consider an 80 or 100 MHz clock.

I see Claudio's point about a 10 MHz lock for VHF and higher.  But for HF, I still think any cheap crystal oscillator is more than adequate, except for the ARRL frequency measurement contest, and for WSPR.  I will have to take people's work for WSPR, as I don't use this mode.  So a PC pad that accepts a cheap XO for almost everyone, or an expensive TCXO for special applications makes sense to me even if the TCXO costs $30 or $50.

I still feel nervous about using a PLL-based oscillator instead of a pure crystal oscillator as the clock for an ADC.  I see the jitter specs, but a PLL has a wide noise pedestal.  I just don't know how jitter relates to real world performance of a radio.  But, as I said, I may be living in the past.

Jim

N2ADR

[Steve Haynal]

Hi Jim and Claudio,

Yes, thanks for the interesting discussion. 

The 125 MHz clock from the Ethernet wouldn't create the AD9866 clock (too much jitter through the FPGA) but could discipline the frequency generation. You'd still need a Si510 for the AD9866. You create two counters in the FPGA, one for each clock. After you reach a certain count you compare the two. If the 2.5 ppm clock from the Ethernet is considered golden, you can compute the ppm error of the AD9866 oscillator and dynamically adjust the constant that is multiplied by the frequency to compute the phase word. The two clocks wouldn't be synchronized, but the Radio frequency could be compensated.

Thanks for the temperature sensor link. That is a nice option.

To ease nervousness about PLL-based oscillators, see this discussion, especially the final solution at the end, regarding close-in and wide-band PLL noise. Also, this article discusses the clock choice for some of the Flex radios. The Si510 we are currently using uses SiLabs DSPLL technology. I feel comfortable with PLL or MEMS use where the PLL or MEMS is designed for low phase noise, low jitter clocks. I am not comfortable with using the MAX10's PLL or even its IOs for low jitter clocking.

There may be too much jitter for 1 GHz ethernet with a clock coming from a FPGA pin to eliminate the ethernet oscillator. If you look at the BeMicro CVA9 design, they used a 2.5 ppm 25 MHz oscillator just for the KSZ9021. 

I'm okay with a more generic footprint option for the oscillator so various ones can be used. I would like to settle on a frequency so that the firmware can stabilize.

To add another wrinkle, with v2 I want to be able to synchronize several Hermes-Lite receivers for diversity and beamforming. This requires distributing the same clock to several (1-3) other units. I cannot recover a clean enough clock from LVDS communication. The price of cleaning any recovered clock with a jitter attenuator is too much for me. I am leaning towards using a device like the Si53307 on the master to drive the local AD9866 and have 3 other outputs for 3 slaves. The slaves would not need this chip. This chip costs $2-$3. 

The idea to pursue the AFE7225 is interesting and something I'd support, but not something I can contribute much time to. I'd like to focus on the AD9866 for now.

I am happy to switch to a 80 MHz clock, especially if someone wants to take on the resampling FIR. The comments in the current polyphase FIR say it is based on your code Jim... Do you have any interest in converting this FIR to a resampling one? One option is a polyphase FIR filter that decimates by 5 and interpolates by 3. So with 80.000 MHz, we decimate by 125 (5*5*5) for 640 kHz and then apply the 3/5 FIR to produce 384 kHz. Adding additional factors of 2 gives the other common lower frequencies. Changing the 5*5*5 to 5*5*2, 5*5*3, 5*5*4 gives us 960kHz, 640kHz and 480kHz provided the polyphase can process fast enough. I'd actually like to stick with a filter that serializes some multiplications so that the max frequency supported by the FIR is just over 384 kHz to save on multiplier resources. Multirate Systems and Filter Banks by Vaidyanathan has an excellent description starting on page 127, section 4.3.3. In full parallel fashion, you have 15 "branches" compared to the 8 in the current polyphase, but if you serialize the 3 groups of 5 and run the filter at double speed (160 MHz), you can support up to about 820 kHz, 640 kHz being the closest match, and reduce the number of multipliers we currently use. I'd like to be able to fit 3 receivers on the CV...

I still don't like the high price of the 80 MHz oscillator. SiTime makes the SiT5001 MEMs oscillator (similar to the one Jim linked to) with low jitter and temperature stability options in the 1 to 5 ppm range. An 80MHz version with 5ppm stability is $3-$4 at verical. Mouser and Digikey have some at other frequencies but with better stability in the $5-$6 range. The SiTime site says they are available for any frequency from 1 to 80 MHz accurate to 6 decimal places. I will request quotes from Digikey and Mouser to see what it takes to get 80 MHz and 79.872  parts at 2.5 ppm or better stability in stock.

73,

Steve

KF7O

[James Ahlstrom]

On Saturday, November 21, 2015 at 1:59:27 AM UTC-5, Steve Haynal wrote:

I am happy to switch to a 80 MHz clock, especially if someone wants to take on the resampling FIR.

Yes, I will look into designing a resampling polyphase FIR.  The issue will probably be the number of multipliers required.

Jim

N2ADR 

[Steve Haynal]

Thanks!

73,

Steve

KF7O

[James Ahlstrom]

Hello,

I did some work on the 80 MHz clock, and I can see what the issues are.  The receive chain for a 73.728 MHz clock is a divide by 8 CIC filter, a divide by 3,6,12, or 24 CIC filter, and a divide by 8 FIR filter.  This gives final rates of 384, 192, 96 and 48 ksps.  Only the lowest frequencies in the CIC filter passband are valid; the upper frequencies are contaminated with images.  The FIR filter is used to reject all but the lowest 12.5% of the passband.  The key is that the FIR must decimate by about 10 times or more so it can pass only the valid part of the spectrum.

The only rates available in the Hermes protocol are 48 ksps  times 1, 2, 4, or 8.  For an 80 MHz clock, we need a 3/5 rate conversion to get to these rates.  But we can't have a 3/5 FIR filter because it accepts too much of the CIC filter spectrum.  We need to use a 3/25 FIR which accepts 12%, about the same as before.  Our design is therefore a divide by 5 CIC filter, a divide by 5,10,20 or 40  CIC filter, and a divide by 25/3 FIR filter.

At an output rate of 384k the current decimate by 8 FIR filter has 976 taps and runs at 3072k.  The 25/3 FIR would run at 3200k.  The 3X interpolation gives a filter rate of 9600k, and a 3X increase in the number of taps for the same transition width.  But almost all of the multiplications are by zero, and by avoiding these we can get it to work.

The benefit is that 80 MHz oscillators are readily available.  Digikey has a standard one for $1.56 and a wide variety of others including VCTCXO.  The 80 MHz is easily locked to a 10 MHz reference, and maybe you could just multiply the 10 MHz reference to get it.

Next I will write the filter and see if I can get it to be fast enough without demanding too many resources.  We also need a second filter, a 25/3 interpolating filter for transmit.

Jim

N2ADR

[Steve Haynal]

Hi Jim,

Thanks for looking into this. I also wondered if the 3/5 FIR might be problematic. Final resource usage will be interesting.

73,

Steve

KF7O

[James Ahlstrom]

Hello Group,

I am still working on a 3/25 rate change filter that will enable sample rates of 48, 96, 192, 384 ksps with an 80 MHz clock.  The 80 MHz clock is cheaper and easier to obtain.  And TCXO and VCTCXO versions are available.

The first version I tried used too many resources, and failed to fit into the BeMicroSDK with the default number of receivers.  I am working on a new version now.  It fits into the FPGA, but doesn't work yet.  I find FPGA code difficult to write and especially to debug.  I will keep you posted.

Jim

N2ADR

[Alan Hopper]

Jim,

I have recently developed a great respect for anyone who writes any significant fpga code! I believe there is value in moving some of the down conversion to the pc especially for smaller fpgas, There is obviously a network bandwidth/fpga resource/pc resource trade off here. For this to work without excessive network load the final stage ideally needs to be only 2x or 4x decimation, is this practical or helpful with the 80MHz clock? I very much like the option of a cheap high quality clock.

73 Alan M6NNB

[James Ahlstrom]

Hello Alan,

The decimation in the FPGA uses CIC filters followed by a FIR filter.  Only the lower 10% or so of the CIC filter output is valid data, so a 1/10 or so FIR filter is used here to select the bottom 10%.  We could eliminate the FIR filter in the FPGA and implement it on the PC.  But then we waste 90% of our network bandwidth sending data destined to be thrown away.

We could use the current 1/8 FIR filter in the FPGA.  I tested this, and it works fine with Quisk.  But the rates we send to the PC are 50, 100, 200, 400 ksps.  These rates are not part of the Hermes protocol, so we break protocol compatibility.  And I don't think many clients like PowerSDR could deal with these rates.  Most everyone expects 48, 96, 192, 384 ksps.

Using less decimation on the FPGA doesn't work because it causes the final FIR filter to work at a higher sample rate, and it is already tough to get it to calculate fast enough.

So most sensible people use clock frequencies like 122.88 MHz that are multiples of 48 kHz so they don't need fancy filters.  Obviously, we are not sensible people!

Jim

N2ADR

[Alan Hopper]

Jim,

sensible is overrated! At the moment  I understand that compatibility with existing software is important but I suspect that as this project grows so will software support( it is already supported by more software than Hermes).  I'm happy to support different rates in my code.   With the hpsdr move to the new protocol there is an opportunity to get support for odd rates to be built into the standard so it may not be an issue.  As the effort of developing fpga code is significantly higher than pc code I think we should be bolder in making the pc work for us.  The latest hpsdr code has higher order cics and a final /2 fir but these cics are more resource greedy and currently nullify the gains of moving the fir to the pc, maybe there is some mathematical truth here that means we can't win.

73 Alan M6NNB  

[Steve Haynal]

Hi Jim and Alan,

Using an additional 7x of the new gigabit link bandwidth per RX to do the FIR on the PC and reduce the cost/size/complexity of the FPGA actually sounds like a reasonable trade-off to me . :) Especially if we go to narrow "true data" channels of ~12 kHz (not much more needed for HF, 96 kHz preFIR) and send snapshots of higher bandwidth for visualization. A full 384, 480, 960 kHz or more data stream just to display ~2000 pixel wide data updated every 60th of a second is not needed when a 0 IF single receiver is used. Phil Harman, VK6PH, is taking it even further by sending raw DAC/ADC data to the PC for processing with GPGPU.

I've been looking at clock generators and am seriously considering using this versaclock 6 in v2 for these reasons:

• Phase noise is a bit lower than the current Si510.
• Allows inexpensive frequency-choice temperature compensated oscillators to be used. This will reduce drift.
• Allows for generation of 73.728, 79.872 and 80.000 MHz ADC clocks.
• Two independent frequency outputs eliminates the need for a second oscillator for the 1 GBe interface, which also must be fairly low jitter.
• Two inputs allows us to select to use the onboard oscillator or an external reference for microwave, synchronizing multiple receivers, etc. And since the generator is programmable, any external reference frequency can be used.
• The outputs are differential. For the ADC we require only single-ended. The other half of the differential output can be used to drive a single-ended clock for the next receiver in a synchronized chain.
• One output is bypassable and can connect directly to the source oscillator. This can be used for the AD9866 to satisfy those who do like going through a quality PLL, although additive jitter may be a factor.
• Total cost is under $10 for all AD9866 and Ethernet clocking.

73,

Steve

KF7O

[James Ahlstrom]

Hello Alan,

I appreciate your comments and I mostly agree.  But there are further problems in moving to rates other than 48, 96, 192 ksps.  Even in a PC, some rates are troublesome.  For example, the /5/5/8/8 decimation from 80 MHz gives 50 ksps.  The PC would then need a 24/25 rate converter to get to 48 ksps.  This would run at 1.2 MHz and require a filter with thousands of taps.  Possible, but best avoided.

Quisk currently uses fractional resampling to accommodate the odd rates of the SDR-IQ.  This doesn't use N/M filters; it resamples directly so uses fewer resources.  It is acceptable for listening to the radio audio, but it destroys I/Q balance in digital signals.  This makes the SDR-IQ troublesome to use with external digital programs like fldigi which generally require 48 ksps and clean I/Q balance.

Quisk is popular for use on single board computers like raspberry pi because it is efficient and open source.  We can't assume everyone has a 3GHz i7.  Sending troublesome rates will cause the ARM processor people problems.

I do agree that we need to think again about those who want multiple receivers to monitor beacons on multiple bands.  We could send raw CIC output at low rates with the understanding that the receivers would tune to 0 Hz where the spectrum is valid.  But AFAIK, the 48 ksps or sub-multiple sample rate is required by most digital software.

Jim

N2ADR

[Alan Hopper]

Jim,

I had just wondered if your work on odd decimation might throw up an opportunity for a different division of labour between fpga and client that hadn't been considered yet.

It is a very good point about low powered clients. I guess there might be a case for different firmware for different uses eg.

DAC only for dfc jetson users.

Minimal fpga processing with many receivers for powerful clients and good networks.

More fpga processing at the cost of fewer receivers for low powered clients.

I agree the resampling is not trivial and would be best avoided.

73 Alan M6NNB

[James Ahlstrom]

Hello Steve,

I agree that the versaclock 6 is interesting.  If it can use a 10 MHz oscillator, and make both the 79.872 MHz clock and the GigEth clock, and if the phase noise is low enough, then I believe it is a better solution than the 3/25 filter and 80 MHz clock.

Jim

N2ADR

[Steve Haynal]

Hi Jim,

Okay, sounds good. I will buy an evaluation board to see if phase noise changes. Although the evaluation board is for the versaclock 5, its phase noise is similar to the si510 and the versaclock 6 can only hopefully be better.

73,

Steve

KF7O

[James Ahlstrom]

Hello Group,

On Wednesday, December 9, 2015 at 12:38:32 PM UTC-5, James Ahlstrom wrote:

I agree that the versaclock 6 is interesting.  If it can use a 10 MHz oscillator, and make both the 79.872 MHz clock and the GigEth clock, and if the phase noise is low enough, then I believe it is a better solution than the 3/25 filter and 80 MHz clock.

I stopped working on the 3/25 filter because it seems we will use a VersaClock instead, and with a cheaper TCXO it will cost less than the expensive 80 MHz VCTCXO.  But if the VersaClock doesn't work, I can finish the 3/25 filter and we can use the 80 MHz clock.  The VersaClock phase noise may or may not be a problem.

If we wind up using the 80 MHz clock, the 80 MHz XO for $4.46 should be more than sufficient for most users. For more demanding applications, the VCTCXO is $29.25.  Both oscillators are by Connor-Winfield are are high quality.

I learned a few things about a 3/25 filter.  The filter needs a lot of taps, and is noisy.  The noise can be reduced by using more taps and perhaps more bit width.  I was able to create filters that used FPGA resources comparable to the current 1/8 filter, and so it was not necessary to reduce the number of receivers to make the new code fit.  So I consider the 3/25 filter promising and possible, but not finished.

Jim

N2ADR

[Steve Haynal]

Hi Jim,

Thanks for the work on the 3/25 filter. I can add it to github if you like as someone else may want to use it. I have my ram-based NCO models on github even though they are not finished but in case I want to work on them again in the future.

The Si510 datasheet specifies -86dBc/Hz for close in 100Hz noise, the VersaClock5 -100dBc/Hz at 100Hz and the VersaClock6 -110dBc/Hz at 100Hz.  I wouldn't be surprised if the measurements are done for the "best" combination of PLL settings so should be checked. I am looking for simple ways to measure phase noise. Any suggestions? The reference clock in my 100 MHz oscilloscope is probably not sufficient to make any meaningful measurement. I do have access to a higher quality 300 MHz scope at work that I should be able to estimate jitter with. I have no high quality spectrum analyzer. Also, from this document and this document, we could see an increase in the noise floor when the RX frequency is increased and when terminating the RX input with a resistor. In the past, some people reported such a noise increase of 3 to 4 dB, maybe because all Si510s do not use the same PLL multiply/divide values but tune these values for whatever frequency the internal crystal happens to be. I've ordered my VersaClock5 evaluation board and hope to receive it and do some tests over the long New Year's weekend.

73,

Steve

KF7O

[in3otd]

Steve,
as you know, measurement of low phase noise sources is tricky. Even if you had a good spectrum analyzer it won't probably good enough to characterize the Versaclock or the Si510.
SM5BSZ has some pages about measuring phase noise on his site. You could also look at the time-nuts list archive or ask there for more info.

73 de Claudio, IN3OTD / DK1CG

[James Ahlstrom]

Hello Steve,

The trouble with measuring phase noise is that you need a receiver with its own phase noise to measure it, and you need to get rid of the fundamental frequency to be able to view the noise.  My spectrum analyzer is hopeless, and I don't know of any that would work.  The ARRL once published its method, and I often thought about trying it.  They make a direct conversion receiver with a high quality crystal oscillator and a diode double balanced mixer.  The signal source is tuned to exact zero beat.  A series capacitor removes the DC carrier, and a computer sound card looks at the sidebands; that is, the phase noise.  The trick is to use the zero in the series capacitor filter to remove the very strong carrier frequency.

My response to the difficulty of measuring phase noise is to buy very expensive pure crystal oscillators and avoid PLL clock solutions.  Not ideal, I guess, and often not convenient.

Jim

N2ADR

[Steve Haynal]

Hi Jim and Claudio,

My versaclock 5 evaluation board arrived and I have connected it to a Hermes-Lite. I've played with 61.44, 73.728 and 79.872 MHz ADC clocks and compared noise floors with and without (50 Ohm dummy load) antenna to the Si510 oscillators. I don't notice any differences. I see variation of maybe almost 1 dB for the noise floor at high frequencies (30 MHz) when experimenting with various multiply/divide ratios. Phase noise should have more impact for RX of higher frequences. Sometimes the Si510 is better, sometimes the versaclock 5. I also have access to a Si5338 evaluation board at my day job and tried that too. They all perform about the same.

I hope to attempt measuring jitter with a better oscilloscope at work following this app note. I will post later how that turns out. Claudio pointed me to this link. I may contact KE5FX to see if he is willing to measure phase noise on a loaner evaluation board in exchange for a Hermes-Lite PCB set. I don't think we'd find anything suprising though. As per the datasheets, the versaclock 5 is a little bit better than the Si510 (around -100 dBc vs -85 dBc at 100 Hz), and the versaclock 6 is a bit better than the vesaclock 5 (around -110 dBc vs -100 at 100 Hz). When one runs the numbers to see what impact there is on SNR as described in this document, there is little impact for the AD9866 12-bit ADC at top frequencies of 30 MHz. I am ready to commit to a versaclock 6 part as I like the flexibility, price and reasonable performance for a Hermes-Lite, and inexpensive SDR target. What exact specs/measurements would satisfy others?

73,

Steve

KF7O

[in3otd]

Hello Steve,
I understand that the VersaClock IC can provide more flexibility, but with a (slightly) higher cost and I am not convinced that everyone *needs* that flexibility for an H-L v2 *product*.
I mean, I expect the vast majority to build a v2 kit (or partially/fully assembled) as designed, using the provided clock source, and if this is really the case a solution with a Si510 (at whatever frequency is needed) and a XO for the GbE interface will be the least expensive - and "good enough" - solution. (BTW, the XO on the CV A9 board is relatively expensive, but apparently this one at 1.37 USD qty 1 should be fine also)

I was hoping that the code could be "easily" modified to support an 80 MHz clock since this would have provided more flexibility at a *lower cost*, but since the code changes are actually not that easy I think that the VersaClock should be only an option (on- or off- board, depending on the space) for those wanting to use an external clock.

On a more technical side, I would be interested in seeing the crosstalk between the two clock output of the VersaClock. For the TX we are chasing spurs which are between -55 dBc (IAMP worst case) to -77 dBc (TxDAC), I'm wondering if there will be a 25 MHz spur from the GbE clock output on the AD9866 clock output when both are active at the same time (maybe you can do a test with the evaluation board you have there?).

73 de Claudio, IN3OTD / DK1CG

[James Ahlstrom]

Hi Steve and Claudio,

Although I failed to finish the 3/25 rate change Verilog code, I know that a working version is possible if I polish the code and redesign the filter.  I can do this, but the Versaclock makes this unnecessary, and I don't want to make a filter that is not used.  But I will finish the filter if everyone decides to use a vanilla 80 MHz XO.

You did not say what reference oscillator you used with the Versaclock to get 79.872 MHz.  If this can be a cheap TCXO, then the Versaclock has a clear advantage over the Si510 in frequency stability.  This probably does not matter for HF except possibly for WSPR, but could be important for future digital modes or for transverter use.  And it adds sex appeal.  I do not think the increase in price for the Versaclock is significant.  If the reference for the Versaclock is 10 MHz, and if the board can support either a XO or TCXO reference, then that is good enough reason the use the Versaclock in my opinion.  But if the Versaclock reference has only the temperature stability of the Si570, the Versaclock has no advantage over the Si570.  Obtaining 25 MHz for the GigEth is not a sufficient advantage because cheap oscillators for this are available, and using one makes routing the board easier.  And the Versaclock requires programming by the FPGA.  So in my mind, the possible advantage of the Versaclock is frequency stability.

That darned 10 meter spur at 44 MHz is still causing me problems.  I would like the clock to be 79.872.

I don't think providing options for Versaclock or Si570 or various clock frequencies is a good idea.  The FPGA code has too many options for different frequencies, BeMicros etc., and now we need a further option for TxDAC use.  Just adding an 80 MHz clock made quite a mess of the Verilog code.  Version 2 should have NO options, just the best design IMHO.

Jim

N2ADR

[Steve Haynal]

I used the 25 MHz oscillator on the EVB. It can be a 10 MHz reference. Frequency stability depends on the reference. I tried various multiplier/divider settings to mimic what might be seen with a different reference. The $1.37 part does not have good frequency/temperature stability and see more stable parts (<2.5ppm) starting at around $2.50.

Frequency stability, board space, cost and ability to use an external source to synchronize receivers are important to me. We are comparing a price of $7.9+$2.5=$10.4 for versaclock 6 plus single txco with $5.62+$1.37=$6.99 for not as stable Si510 plus gigabit oscillator. I think the stability and option to have an external reference are worth the extra $3.41. I also think that eliminating the gigabit oscillator matters as it saves at least $1.37. Routing shouldn't be an issue.

I agree that we don't want too many options in the firmware. Supporting both 61.44 and 73.728 in the firmware has been a pain. 79,872 would be good for V2.0.

73,

Steve

KF7O

[in3otd]

uhm, I beg to differ, Steve, to me $3.41 for an SDR that should be under $100 for the basic configuration is significant. As Jim, I also see the main advantage of the Versaclock in providing a higher stability, yet I'm not sure most commercial radios provide such a stable oscillator or have an input for an external reference in their default configuration so I see providing these features by default a bit like a "second system effect", hi.

As you know, the frequency drift "issue" for the Si510 is due to the heating from the AD9866, if it could be moved a bit further away (and maybe cut a slot in the PCB around the Si510 to try to provide a higher thermal resistance toward the AD9866) it might be stable enough also for WSPR.

73 de Claudio, IN3OTD / DK1CG

[Joe]

  I agree with Claduio, using his firmware the spur issue on 10 and 12 meters is for practicable purposes is gone and the only 

remaining issue is WSPR temperature stability that I cured by removing the SI510 from the board mounting it in a small

block of foam and If you wan't icing on your cake a 50 ohm PTC running on 5 volts is all that is needed. Providing thermal isolation

is needed for short term stability as it's caused now by AD9866 temperature cycling between TX and RX.

Joe   wa9cgz 

[Steve Haynal]

Hi Claudio and Joe,

Thanks for the feedback. Perhaps we can have a build option such that the board can be stuffed in two different ways, but sometimes build options add complexity, so only if it turns out that the layout is simple.

I worry about the si510 and heat once the v2.0 is in a case with or near a PA. It may be hard to isolate the si510. I'd rather not have to worry about that much.

International builders have difficulty obtaining a Si510. The Si570 was recommended, but that costs more than a versaclock 6 solution and has more temperature instability. It also doesn't support an optional input. The versaclock 5 and 6 parts appear to be internationally available.

KE5FX has agreed to measure phase noise for us, so I am preparing a shipment with the versaclock 5 EVB and a Si510 test board for him. It will be interesting to see the results.

I am reserving ~10% of the approximately $100 budget for frills. The gigabit ethernet is another one. We are paying ~$5 extra for that as compared to a less expensive 100 Mb/s interface. Synchronized receivers via LVDS is something very interesting to me. I was working on that before I got sidetracked with the Hermes-Lite and want to be able to get back to it. It can also be viewed as a way to effectively increase the ADC bit resolution. At the end of the day, I'm just a guy in his garage building a radio that he wants to use. :) I sometimes get frustrated with a lot of "design by committee" type discussion...

73,

Steve

KF7O

On Sunday, January 3, 2016 at 11:54:45 AM UTC-8, Joe wrote:

  I agree with Claduio, using his firmware the spur issue on 10 and 12 meters is for practicable purposes is gone and the only 

remaining issue is WSPR temperature stability that I cured by removing the SI510 from the board mounting it in a small

block of foam and If you wan't icing on your cake a 50 ohm PTC running on 5 volts is all that is needed. Providing thermal isolation

is needed for short term stability as it's caused now by AD9866 temperature cycling between TX and RX.

Joe   wa9cgz 

On Sunday, January 3, 2016 at 1:07:10 PM UTC-6, in3otd wrote:

uhm, I beg to differ, Steve, to me $3.41 for an SDR that should be under $100 for the basic configuration is significant. As Jim, I also see the main advantage of the Versaclock in providing a higher stability, yet I'm not sure most commercial radios provide such a stable oscillator or have an input for an external reference in their default configuration so I see providing these features by default a bit like a "second system effect", hi.

As you know, the frequency drift "issue" for the Si510 is due to the heating from the AD9866, if it could be moved a bit further away (and maybe cut a slot in the PCB around the Si510 to try to provide a higher thermal resistance toward the AD9866) it might be stable enough also for WSPR.

73 de Claudio, IN3OTD / DK1CG

On Saturday, January 2, 2016 at 10:11:05 PM UTC+1, Steve Haynal wrote:

I used the 25 MHz oscillator on the EVB. It can be a 10 MHz reference. Frequency stabili ty depends on the reference. I tried various multiplier/divider settings to mimic what might be seen with a different reference. The $1.37 part does not have good frequency/temperature stability and see more stable parts (<2.5ppm) starting at around $2.50.

[Alan Hopper]

Just playing the devil's advocate, I like the versaclock option as long as it provides long term temperature compensation.  I'm sure short term tx/rx drift can be corrected either by thermal separation, firmware control of ad9866 heat output or software compensation.  Software compensation has lots of problems as not all software is likely to support it and it relies on some measurement or configuration of each build's thermal characteristics.  The long term (eg day to night on wspr) drift isn't fixed by separation of clock and ad9866 or firmware, it can be fixed by compensation by ntp or gps or spare rx tuned to frequency ref but all these rely on specific software and external connections that may not be there in field use. I reckon $3.41 is a bargain for this feature.

73 Alan M6NNB

[Glenn P]

I had a quick look at the versaclock 5 specs and it appears it requires an external 25MHz xtal. Is that correct? , Why is this part  better than current part?. . .......what am I missing here?

How does one program the device?

As for cost, Mouser list some variations around $6.00   For international users like myself, It's unlikely  this part would be available locally, even from an authourised distributor.  I would have to buy from Digikey or Mouser.  At our exchange rates that $6 becomes close to $9.00. Plus freight.



glenn

[in3otd]

Hello Glenn,
my understanding is that 25 MHz is a commonly used frequency (for all Ethernet ICs), so even the higher stability parts have a relatively low price compared to the less common frequencies.

Regarding programming the device, I think you have to do that via the I2C bus of the IC. Then, once the device has been programmed you can select this configuration as the default startup mode (and this startup configuration cannot later be changed, AFAIU).

Steve, do you know if the Versaclocks can be factory (or Digikey) preprogrammed like the Si510 for a predefined startup configuration?

73 de Claudio, IN3OTD / DK1CG

[in3otd]

Hello Alan,
this reminds me I have to measure the actual Si510 temperature variation, to have an idea of how sensitive really is. My measurements shows that between RX and TX the drift, after the initial system warmup transient, was about 0.2 ppm which is quite good I think (will never be noticed operating SSB or CW), except that it happens to a bit too much for WSPR. I might try to record the drift over 24 hours in the next days.

I agree that the improved stability and ability of use an external reference will be a nice addition and a bargain for the modest price increase needed but the same could probably be said for other things, e.g. a little more output power will cost only another RD16HHF1 to make a push-pull. As usual, some trade-offs need to be made and I tend to favour the low-cost aspect here.

73 de Claudio, IN3OTD / DK1CG

[Steve Haynal]

Hi Claudio and Glenn,

The versaclock do have OTP memory so that they can have a default configuration without any programming. You can always write over this configuration via the I2C with new operating values. You may only have one shot at setting the default values. I don't think you can order this with the OTP programmed already though.

Depending on your logic family, you can use a reference oscillator from ~8 MHz up to 100s MHz. Some of the cheaper stable oscillators are 24 or 26 MHz. I'd like to make the dividers accessible through software so that the frequency is independent of the firmware and can be set by the user depending on an oscillator of their choice. The final frequency to the AD9866 should always be 79.872 MHz though.

73,

Steve

KF7O

[James Ahlstrom]

Hello Claudio,

If the heating issue is caused by the AD9866 when it changes to transmit, the effect will be reduced if we use the TxDAC directly since the IAMP will always be idle.  I think we have to use the TxDAC output anyway, since it reduces spurs.

But we still have the issue of what happens when the board is put in an enclosure with another board with a power amp.  Then the extra heat on Tx will be a problem.  Designing with a more stable reference seems worth the modest added cost to me.  So I have to agree with Steve here.

Jim

N2ADR

[Glenn P]

Thanks Claudio, understood.

I assume this then will be used on actual V2 versions.   Not pre-V2

glenn

[John Laur]

Is there still opposition to supporting an external clock input for
the minority of people who might need to experiment with improved LO
or alternate frequencies? Such solution could drive on-chip PLL or be
taken as the main clock and could be offered as optionally populated
components which brings added BOM costs near $0.

Is the current LO solution really bad enough that it is insufficient
to meet the price/performance requirement of the mass market? It is
very easy to start escalating the clock performance specs, but no
matter where you draw the line, the solution is going to have
insufficient performance for some applications and be overkill for
others. Extreme low power modes like CHIRP and experimental
applications involving concepts like group-time-of-arrival for
direction finding or synthetic aperture radar flat out require the
ability to lock to GPSDO or other high precision references.

All that being said, I am all for improving the LO, but I just dont
think there is terribly much difference in the $1-5 class parts. To me
phase noise is the #1 most important spec for direct sampling SDR
because it improves the dynamic range in proximity to strong signals
both turn Rx and Tx.

73, John K5IT

> --
> You received this message because you are subscribed to the Google Groups
> "Hermes-Lite" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hermes-lite...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Tony Abbey]

As a newbie on this group, could you confirm that you will be using a clock frequency high enough for us in Europe to use on the 70MHz band, please.
Happy New Year all. I am full of admiration for the time and effort you are putting into this.
Tony

[John Marvin]

Hi Tom,

Neither the Hermes-Lite or any OpenHPSDR based radio supports that
frequency without an external transverter. Hermes-Lite will only support
up to the 10m band. Hermes, and other OpenHPSDR radios support the 6m
band, but they cannot reach the 4m band, which would require a clockrate
> 140 Mhz. Unless undersampling is employed, you need a clockrate that
is at least twice (and it should be a little higher than that) the
desired frequency you want to operate on.

John
AC0ZG

[ZL2APV]

I wonder if sticking a small copper block etc. onto the oscillator would damp the thermal inertia and reduce the drift between tx and rx?

Graeme
ZL2APV

[in3otd]

Hello Steve,
a build option will be ideal, but I refrained from proposing that since it will mean one more additional variant to support and, as Jim said, we should try to limit that since it will mean even more work.

IMHO, you shouldn't worry too much about the opinions of the committee here, hi, I think that the more successful open SW(HW) projects do not try to please everybody - ending up in pleasing nobody - but follow the directions proposed, ehm, imposed by the "benevolent dictator" who "owns the project vision".
It's always interesting to read the different opinions and ideas about the project but that doesn't mean it must then necessarily satisfy the wishes of the vocal minority (or majority, for that matter) of the moment.

73 de Claudio, IN3OTD / DK1CG

[in3otd]

...it occurred to me that the Versaclock might allow an interesting "spurs avoidance" scheme: for the TX the actual DAC clock frequency could be dynamically selected so that the aliased harmonic(s) always fall far away from the TX frequency, e.g. when the TX is on the 12 m band use the 61.44 MHz clock, else use the 73.728 MHz.
This will of course require two sets of interpolation filters for the TX path but maybe these are less demanding/resource hungry than the RX filters (?).

73 de Claudio, IN3OTD / DK1CG

[Steve Haynal]

Hi Claudio,

That is a nice idea. I think I read about something similar "frequency planning" in some DDS application note. For DFC, we may need to use 61.44 MHz for receive too. The frequency flexibility may open up some other ideas...

73,

Steve

KF7O