Ripples in the H-L v2b2 response

[in3otd]

Hello,
I was doing some RX test on the H-L v2b2 with an input signal at 19.5 MHz and -90 dBm; with the RX gain set at 29 dB, the Quisk S-meter shows the signal level at S3, around -72 dB. When I increased the gain to 30 dB, the S-meter reading decreased to about -75 dB.

I noticed that the level shown changed when I put a finger on the traces between the FPGA and the AD9866. It changed even more when I put the scope probe on the RX data lines going to the FPGA, so I measured the RX response over the HF band when placing the probe on each signal line:

the ripples change in amplitude and, slightly in position also, when a probe is placed on those data lines. This likely indicates that the ripples are due to some crosstalk between the digital output lines and the analog frontend of the AD9866.

I noticed also that the waveform on RX[4] is slightly different than on the other pins, the amplitude appears to be a little lower and less "clean".
Looking at the FPGA pinlist, the pin used for RX[4], pin 136, is an optional VREF pin for the bank (VREFB8N0), which can be used also as regular I/O.
The Cyclone IV Device Handbook says that "when VREF pins are used as regular I/Os, they have higher pin capacitance than regular user I/O pins. This has an impact on the timing if the pins are used as inputs and outputs" (page 126 of Volume 1).
The Cyclone IV Device Datasheet (page 10) indicates that the capacitance for the VREF pins, C_VREFTB, for the EP4CE22 device is 30 pF, while a regular pin is 7 pF or 8 pF (the CV A9 I used for the H-L v1.2 measurements has 6 pF per pin). I wonder if that pin with 4 times the normal capacitance may be (partially) responsible for the ripples.
Also, the measurements I did on the H-L v1.2 were done with a half-duplex FW, while for the v2b2 we are always in full-duplex, AFAIU. Would be interesting to try also a half-duplex FW, if still possible. Similarly, the AD9866 digital output drive strength can be increased, will be interesting to see if things become even worse with higher drive strength.

73 de Claudio, IN3OTD / DK1CG

[Alan Hopper]

Claudio,

I wonder if this could be a fpga/adc timing issue. Timing problems here have a surprisingly subtle effect on receiver output.  Do you have access to the bandscope packet (ep4) in Quisk? I found plotting this in the time domain with a single carrier can be quite revealing, the lower the frequency the easier it is to see problems.

Whilst I agree this is not a show stopper it does make things like rf agc more challenging.

73 Alan M0NNB

[in3otd]

Hello Alan,
not sure this can be a timing issue but it's difficult to understand what effect it could have on the received data spectrum.
I don't know if the bandscope packet is availabe in Quisk, maybe Jim can comment on this.

I think this "crosstalk" may have an effect also on the intermodulation performances but did not check yet. And, once again, the ripple may actually disappear in normal usage, where the "incidental dithering" makes the digital lines activity more random.

73 de Claudio, IN3OTD / DK1CG

[Alan Hopper]

Claudio,

my experience of timing issues in this area resulted in increased noise floor and level changes. There were no obvious spurs and you could easily not realize that there was an issue in normal use, I guess just like quantization noise, errors here tend to be spread smoothly over the whole bandwidth.
73 Alan M0NNB

[James Ahlstrom]

Hello Claudio,

Bandscope data is received by Quisk, but it is thrown away.  No use is made of it.

Jim

N2ADR

[in3otd]

Thanks Jim,
I see now in the Quisk code where the check is done for processing only the end point 6 data, I'll try to add something to dump the EP4 data to a file.

73 de Claudio, IN3OTD / DK1CG

[Steve Haynal]

Hi Claudio,

I repeated this experiment here. I had to setup a second HL for TX as the HL can't raise the LNA gain past 20 dB when transmitting in full duplex. I did not see the decrease you see from 29 to 30 dB at 19.5 MHz or 14.1 MHz. I tried a range of LNA gain settings and saw the expected fairly uniform changes in RX signal strength.

I was aware that RX[4] was not an optimal choice but went with it anyway as it really simplified routing. I reasoned we had seen worse capacitance with full duplex and the HL1.22 so this should still be okay. I really don't want to to have to rework the routing here as there are no easy options. Your probe on RX[4] doesn't appear to may a bigger difference than the others so hopefully it is not a big problem. What if you provide a signal of low enough amplitude that RX[4] and RX[5] don't toggle even when the LNA is at 29 or 30 dB? Do you still see the problem?

What do you think of adding a series termination resistor at least for RX[4] near the FPGA in the next revision?

Just to make sure I understand, your hypothesis is that ringing or reflection on the RX lines driven by the AD9866 are reflecting back into the AD9866 and the crosstalk is happening internally?

The digital drive strength for the AD9866 is currently high, address 0x0e bit 7 is the default 0 value which means high drive strength. We can try low drive strength to see if that makes a difference. Also, we can adjust the bias for the LNA CPGA and SPGA amplifier stages as described in Table 24. 

Unfortunately, the HL2 only runs in full duplex. Do you have a HL1.22 that runs in full duplex? It would be interesting if you see the same with that.

73,

Steve

KF7O

[in3otd]

Hello Steve,
there is still be the possibility that some decoupling capacitor is not well soldered or broken, so my H-Lv2 could be more sensitive to the switching noise. I inspected again the board closely but did not see anything suspicious.
I thought that RX[4] and RX[5] will toggle also with low signal levels, since the data are transmitted in nibbles; I have anyway run tests at different input powers during the night, I still need to check the results.

After doing some more experiments, I'll try to add a series resistor on some lines, will do that later since I may well break something trying to solder a component on the lines there, hi.
My hypothesis was that the AD9866 I/Os current during switching generates some ground (supply?) bounce internally and this gets into the RxPGA, differently for the different stages and this is why the ripples depend on the gain step. But it may well be a simpler timing issue as Alan said. I don't think is radiated EMI from the lines, since adding a grounded copper tape over there does not make a difference.

Reading the AD9866 I got the impression that 0 at 0x0e was high drive strength, but description seems confusing to me, the bit is called "low drive strength" but the default 0 is described as high drive in the comment. Anyway, I'll try with the other setting and see if that makes a difference.

AFAIR, my H-Lv1.22 never ran properly with my test program in full duplex, no idea why since the H-L v2b2 runs fine. But it worked fine with Quisk so I can surely do some manual test there.

73 de Claudio, IN3OTD / DK1CG

[in3otd]

Hello,
I have done some more experiments but still it's not clear where the response ripple I see here is coming from.
Measuring with different input levels the ripple is practically still the same (below graph is for Pin from -80 dBm to -100 dBm)

I have done a quick and (very) dirty Quisk modification to show the ADC bandscope samples; while I still have some problem in joining correctly data block boundaries the sinewave I see at low frequency is quite clean, no jumps or obviously missing stuff. I've noticed that there is a significant change in the DC offset going from 29 dB to 30 dB of gain but this is the only difference I can see.

Alan, I quickly tried with Spark sdr since I wanted to compare with the bandscope there but I was not able to see any data. The SW detects the H-L v2b2, I can see its assigned IP but nothing is shown in the waterfall... ehm, is there a button to start the data acquisition, I did not see it.

[Alan Hopper]

Claudio

welcome to windows :) Did you click the little play button next to the ip address in the top bar of the program? Acquisition should start at that point, do you have a blank screen or do you have the basic radio controls shown?

If you get it running there is not currently a time domain bandscope display, you can see it in the frequency domain simply by zooming out the panafall display lots. You can save a histogram of the wideband samples in the radio settings menu (...) on the bar with the sample rate etc, described here https://groups.google.com/d/msg/hermes-lite/DTjFzi4KRXU/4_Q_RO6aBAAJ

I sometimes had to look at a surprising number of bandscope packets to spot errors, but, to me , your results indicate the problem is something different to the problems I had.

73 Alan M0NNB

[in3otd]

Hello,

welcome to windows :)

Thanks... it this how Windows users feel when they switch to Linux ? :)
 

Did you click the little play button next to the ip address in the top bar of the program? Acquisition should start at that point, do you have a blank screen or do you have the basic radio controls shown?

 
yes, I clicked that (otherwise the main window area is completely blank) but I get "just" all the controls (frequency, S-meter, buttons, etc.) on the left and a few sliders for TX on the left. No waterfall or other things. I think somehow I got two small receiver windows in the top left area but didn't seem to actually receive anything. BTW, OS here is Windows 10.

If you get it running there is not currently a time domain bandscope display, you can see it in the frequency domain simply by zooming out the panafall display lots. You can save a histogram of the wideband samples in the radio settings menu (...) on the bar with the sample rate etc, described here https://groups.google.com/d/msg/hermes-lite/DTjFzi4KRXU/4_Q_RO6aBAAJ

Ah, ok, I thought there was a time-domain bandscope amongst all the features, hi. I'll try a little more later.

[in3otd]

Hello Steve,

I repeated this experiment here. I had to setup a second HL for TX as the HL can't raise the LNA gain past 20 dB when transmitting in full duplex. I did not see the decrease you see from 29 to 30 dB at 19.5 MHz or 14.1 MHz. I tried a range of LNA gain settings and saw the expected fairly uniform changes in RX signal strength.

I forgot to point out that I did the experiment with the no-LPF version of the FW... for the regular one the frequency and gain setting may/will be different, I'll check later.

The digital drive strength for the AD9866 is currently high, address 0x0e bit 7 is the default 0 value which means high drive strength. We can try low drive strength to see if that makes a difference. Also, we can adjust the bias for the LNA CPGA and SPGA amplifier stages as described in Table 24. 

I tried to change the drive strength but did not see a difference; the recompiled code, with or without the modified DS seems to have different ripples anyway.
Just to be sure, I changed both this line and this line but should also the first bit changed to 1'b1 ? It is correct to have that at 0?

[Steve Haynal]

Hi Claudio,

Those are the correct lines to be changed but the first bit must also be changed to 1'b1 to enable the write of that location. Initarray cleanup is on my to do list.

73,

Steve

KF7O

[Alan Hopper]

Claudio,

I'm sorry it is not working for you, I've never seen this happen with a HL, I've seen it happen with a new protocol Orion and a powering down and up fixed it.  Any errors are logged in C:\Users\###Your Name###\AppData\Roaming\m6nnb\radio\settings\log.txt.  

73 Alan M0NNB

[Alan Hopper]

Claudio,

I'm very keen to find out why SparkSDR is failing, if you have the time it would be interesting to know if your older HL works. Is your network odd/special in anyway?  When you click the start button do the network leds indicate data is being sent?

73 Alan M0NNB

[in3otd]

Hello Alan,
I tried with the H-L v1.2 and behaviour was more or less the same; after several tries I got it working one time but did not play much with it since I wanted to try again with the H-Lv2b2.
Here also after trying a few times I finally got a connection and RX seemed to work, even if I need some time to get used to the UI, hi.
Otherwise, most of the times the network leds did not blink when SparkSDR was running and no waterfall was shown, I do not have a log.txt file in the directory you mentioned, just a few .xml files. Is there an option to enable logging?
Is there an order to be followed to connect/start up things? It seems that if I first start SparkSDR and then connect the radio this is not seen by the SW, I do not see its IP even after clicking "Refresh" a few times.
Now, after trying a few times more, seems to work fine all the times... is there something the OS/SW needs to "learn" about the system?? The "network" of the PC here is just the H-L v2b2 connected directly to the PC, there is nothing else connected (and no internet access).

73 de Claudio, IN3OTD / DK1CG

[Alan Hopper]

Claudio,

this sounds like it is to do with dhcp or lack of it or similar network magic. How is the radio getting it's ip address, are you using a fixed ip address?  I have always used a fixed ip when connected as you describe, I'll have a play and see what happens with non fixed ip. The log file only appears when an error is caught.

73 Alan M0NNB 

[in3otd]

Hello Alan,
I did not set up anything on Windows and I saw that SparkSDR was (almost) always showing an IP address for the H-L, even when reception didn't work - I assume the H-L got an address via DHCP or, IIRC, the H-L uses to a fixed IP in some cases but I do not really know.

73 de Claudio, IN3OTD / DK1CG

[in3otd]

Hello,
I changed the lines above to select the other the drive strength but did not see any effect, the RX response ripple remained the same and also the rise/fall times of the waveforms on the RX[] lines did not change.

On the H-Lv2b2 with the standard FW, could you please try with a 29 MHz input carrier and check the output level when changing the RxPGA gain from 23 dB to 24 dB; here it shows quite a large decrease.

I switched back to the H-L v1.22 and remeasured with a half-duplex FW (20160220):

which gave the usual results.

Loading then a (later) full-duplex one (20161207_FD ) the results are quite different:

it shows the large ripples seen on the H-Lv2b2.

The ripples are related to the activity of the output data lines from the AD9866; if you compare the measurement reported on the other thread on the H-Lv2b2 with a 73.728 MHz clock, the shape is the same but the peaks spacing is slightly different due to the different clock frequency. Placing a small loop probe over the AD9866 lines I can see a similarly shaped spectrum on the spectrum analyzer. Whether the crosstalk is due to the AD9866 digital output buffers current or some other internal crosstalk source is not clear.

73 de Claudio, IN3OTD / DK1CG

[Alan Hopper]

Claudio,

if the pc and the HL are the only things connected I guess they both made up their own IP using APIPA I'm no expert on this but think there can sometimes be delays in this happening, I wonder if the HL will respond to the broadcast discovery before it has properly sorted out its ip and then fails to respond to the start command sent directly to it. I'll investigate further as this is a obvious setup for field work.

73 Alan M0NNB 

On Sunday, February 26, 2017 at 8:35:12 PM UTC, in3otd wrote:

Hello Alan,

[Steve Haynal]

Hi Claudio,

I did not see anything unusual when increasing the LNA gain from 23 to 24 dB while observing a carrier at 29 MHz. However, I did see an increase of 4.5 dB when increasing the LNA gain from 29 to 30 dB and a decrease of -0.6 dB when increasing the LNA gain from 35 to 36 dB. This is good as it is the first time I've been able to replicate the issue you are seeing. Note that the problematic increase in the LNA gain always ends with a number divisible by 6 because of the 3 stage architecture of the LNA.

I was wrong when I said you were changing the correct lines to lower the AD9866 digital drive strength. The change needs to be made to initarray_disable_IAMP in hermeslite.v. With the lower drive, there was a slight improvement, the big increase went from 4.5 to 3.6 dB and the decrease went from -0.6 to -0.4 dB.

There is an option to use the RXCLK negative edge for activity instead of the positive edge. I enabled this to spread out the time over which digital activity occurs. This made a bigger difference. The big increase went fro 3.6 to 0.9 dB and the decrease of -0.4 changed to an increase of 0.5 dB. Low drive strength was still enabled. This change to negative edge and lower drive strength may affect timing. I didn't see any issues with my unit, but different FPGAs and different environments may expose some timing issue. I think we can fix that though.

 

Next, I disabled the internal LPF. This changed things a bit but not always for the better. Now the LNA change from 29 to 30 dB results in a 0.4 dB signal increase and the the LNA change from 35 to 36 dB results in a 1.0 dB  signal increase. I left the LPF disabled as doing that appeared better in some of your earlier results.

There is an updated bitfile in the normal place with these changes. Hopefully this improves the situation everywhere and I have not just moved the problem to another frequency.

I also made a few other changes related to disabling all parts of the IAMP and shutting down a TX clock when not transmitting. These didn't affect the issue you report but the AD9866 seems to run cooler now.

When incrementing the LNA, I see the same noise floor rise pattern every 6 dB that you reported here and is seen in the datasheet figures 6,7 and 8. For maximum SINAD during RX, it would seem people should stick with +6, +12, +18 or +24 dB setting of the LNA. This also corresponds to the worst THD though. What LNA gain settings would you suggest as best for radio RX purposes? For radio RX, I'm not convinced we really need granularity of 1 dB with the LNA.

73,

Steve

KF7O

[in3otd]

Hello Steve,
it's strange that the gain steps showing the issue on your H-Lv2b2 are not the same as here, I still wonder if there is some board or sample dependency. It will be nice to control the frequency and amplitude of a second H-L used as signal generator via Quisk so you could sweep all the HF; I don't know if/how the Quisk code can be modified to talk to more than one radio at the same time.
Or can  the second output of the VersaClock be used here ? (ok, will need more changes to the FW...)

Good to see that some improvement can be seen by changing the drive strength register and even more by changing the active clock edge; I'll test the new FW later. I still would like to test with series resistors on the data lines, if the data waveforms still look good at the lower drive strength.
Disabling the internal RX LPF apparently changes the internal coupling, so the affected gain steps are different. I 'll try to check again with both settings.

I agree that the RX LNA steps of 1 dB are not really needed in practice. I'll tend to leave only the ones showing less IMD.

73 de Claudio, IN3OTD / DK1CG

On Monday, February 27, 2017 at 7:13:03 AM UTC+1, Steve Haynal wrote:

Hi Claudio,

[in3otd]

Hello Steve,
the new FW works great; the ripples have practically disappeared:

As noted before (by Alan, I think), the gain drops more at high frequencies for the higher gains. I do not have a firm explanation for this, but I noticed that the RX input impedance changes a little with the highest gain settings and this may load the on-board RX input filter differently and change its response.

The noise floor is also looking good; there is maybe 1 dB more noise for the highest gain settings but it's not so important.

I'd be curious to understand which modification had the most effect but I'll leave more experiment for later, hi.

73 de Claudio, IN3OTD / DK1CG

On Monday, February 27, 2017 at 7:13:03 AM UTC+1, Steve Haynal wrote:

Hi Claudio,

[Steve Haynal]

Hi Claudio,

Great news! One more related item I want to eventually do is turn of the TXDAC and interpolation filter if not in FDX during RX. Essentially emulate half duplex even though the interface is running at full duplex rate. This will at least save power during extended RX and might descrease internal noise a bit.

73,

Steve

KF7O

[Dani EA4GPZ]

El 27/02/17 a las 08:54, in3otd escribió:

> I agree that the RX LNA steps of 1 dB are not really needed in practice.
> I'll tend to leave only the ones showing less IMD.

Hi Claudio,

Which are the which show less IMD?

I'm taking a look at
http://www.qsl.net/in3otd/ham_radio/Hermes-Lite/RX_meas.html

But the IMD graphs for different LNA settings are not very clear for me
(although it's difficult to present the information given the large
number of LNA settings).

As I understand, the noise figure is more or less the same for each 6dB
step, so for instance 18, 19, 20, 21, 22 and 23dB have all roughly the
same noise figure. I get that these 6 settings differ slightly in their
IMD, but which one has better performance?

73,

Dani.

[Steve Haynal]

Hi Claudio,

The changes to the firmware are now causing some "bouncing" of TX when observed with a scope. I changed TX to use a negative edge clock too and the bouncing went away. I spot checked at 29 MHz and RX LNA gains still look fairly uniform, but it would be good if you could check again. There is no firmware 20170228 posted.

73,

Steve

KF7O

[in3otd]

Hello Steve,

did not yet measure the FW 20170228, the previous one looks anyway also fine in TX.

Here is the driver output power vs frequency:

the 3rd and 5th harmonics increase a lot for the frequencies is slightly above 20 dBm, maybe increasing the power supply a bit could help here; this was not seen on the frontend v1.4 with a 10 V supply. At lower power level also these harmonics look fine.

73 de Claudio, IN3OTD / DK1CG

On Wednesday, March 1, 2017 at 7:06:27 AM UTC+1, Steve Haynal wrote:

Hi Claudio,

[in3otd]

Hello Dani,

 

Which are the which show less IMD?

honestly,  I don't know, hi. I agree there is to much data on the graphs and moreover even inside every 6-step group the IMD curve may have a different shape. Also the IM2 and IM3 may behave differently. I need to take a closer look at the measurement and see if a general rule for setting the gain can be derived.

[Graeme Jury]

Hello Claudio,

I notice that there is a slight ripple on the fundamental frequency which corresponds to the odd harmonics noticeable ripple i.e. 1.4e+07 and 2.7e+07. I wonder if the power was reduced so that the fundamental ripple frequencies power was equal to its power at 2e+07 if the odd harmonics level would also reduce to that at 2e+07? The ripple on the odd harmonics (and to a much lesser extent on the even) may be directly related to power out and as you suggest be improved with higher Vcc.

73, Graeme zl2apv

--
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.

[Steve Haynal]

Hi Claudio,

Was this measured with the PE4259s in the chain? Did your v1.42 measurements include the PE4259s? I'm wondering if they are having any impact.

A few days ago Jim wanted to enable U12 always for 10V to the op amp. If the PA is an option for end users to add, I don't want them to have to take off U8 and add U12 if they want to use higher voltage TO-220 devices, so maybe always using U12 and having a builder add U8 for low voltage PAs is the easiest build option. This would allow us to run the AFT05MS003 devices at a safer 7.5V too. This would provide a small bit of current relief to U8 which can run hot. 

Do you have U12? Can you test the op-amp at 10V? Unfortunately, U12 Vin is connected to Vpa which is below 10V as I was always expecting Vpa to be >=12V when U12 was present. It looks like a doable mod to connect Vin of U12 to the protected Vin. I may try this and look at the harmonics on my SA.

73,

Steve

KF7O

[in3otd]

Hello,

Was this measured with the PE4259s in the chain?

Yes.
 

Did your v1.42 measurements include the PE4259s?

No.
 

I'm wondering if they are having any impact.

Me too :). I'll try to bypass them later and see if they have any effect.

A few days ago Jim wanted to enable U12 always for 10V to the op amp. If the PA is an option for end users to add, I don't want them to have to take off U8 and add U12 if they want to use higher voltage TO-220 devices, so maybe always using U12 and having a builder add U8 for low voltage PAs is the easiest build option. This would allow us to run the AFT05MS003 devices at a safer 7.5V too. This would provide a small bit of current relief to U8 which can run hot.

I agree that having independent power supplies for the PA and driver makes sense.
I guess there will be just one pre-assembled board variant available, so I think we could have U8 always mounted and have something on the PCB to disable it (tying its enable to GND, removing L3 and/or a big enough jumper resistor in series).
BTW, still regarding U8; its maximum duty cycle is 0.85 so it needs at least 11.1 V to provide the 9.44 V output. It would be nice if the H-L could work also at a slightly lower voltage. Not sure of how many will use it in a portable setup with a 12 V battery but a bit more margin on the input supply would be nice. I saw that ST has another DC/DC converter in the same family, ST1S40, which is very similar but can go to 100% duty cycle. It cannot be synchronized but it seems we do not need that.

Do you have U12?

No, and I forgot to order it.
 

Can you test the op-amp at 10V? Unfortunately, U12 Vin is connected to Vpa which is below 10V as I was always expecting Vpa to be >=12V when U12 was present. It looks like a doable mod to connect Vin of U12 to the protected Vin. I may try this and look at the harmonics on my SA.

Yes, I can test it at 10 V; I'll remove J20 and connect an additional power supply.
I forgot why we use only 10 V for the OPA2677 supply and not 11 or 12 V; wasn't it originally also because we wanted to use also other OpAmps which had a 10 V max supply?

[Steve Haynal]

Hi Claudio,

I enabled the 10V U12 power supply on my build for the opamp. It is actually 10.6V and the resistor values to set the voltage need some tweaking. I see values similar to yours:

8.9V Vop 14.076@20dBm out:

3rd harmonic is 31.4 dBc

5th harmonic is 33.9 dBc

Reducing the power has significant effect:

8.9V Vop 14.076@18dBm out:

3rd harmonic is 45.3 dBc

5th harmonic is 54.9 dBc

8.9V Vop 14.076@16dBm out:

3rd harmonic is 57 dBc

5th harmonic is 64 dBc

Increasing Vop also helps:

10.6V Vop 14.076@20dBm out:

3rd harmonic is 41.7 dBc

5th harmonic is 49.9 dBc

Fortunately, I doubt it is the RF switches.

The OPA2677 only supports up to +12V single supply. Jim didn't feel comfortable running it at a higher voltage and hence the additional regulator. 10V is nice as you can still run with a 11V supply. The AP2204 is a LDO device. I want to try the AFT devices at 7.5V. I'm leaning towards always including the AP2204 for Vop and bias reference, and depedning on what PA a user wants to add, they can add the 7.5V supply. 

73,

Steve

KF7O

[James Ahlstrom]

Hello claudio,

The 10 volt supply was so we could run on batteries down to 10.4 volts or so. The more voltage the better up to 12 volts. But we must still remove the attenuator at the output of the opamp and reduce the gain. Then a lower supply voltage should be fine.

Jim
N2ADR

[in3otd]

Hello Steve,
thanks for the experiments. I also tried with different power levels and an external supply at 10 V and see the same effects. At 10.0 volt the output was practically as clean as the frontend v1.4.
As a side note, when using an external supply, I connected it to the J20 pad and at the beginning the results were bad, then I noticed there are no bypass caps near/under U9, so I added a 100 nF just below and then things were fine. May be good to add it anyway, even if the (relatively) long trace after J20 it seems to work. Will post the usual graphs later.

73 de Claudio, IN3OTD / DK1CG

[in3otd]

Hello,
did some measurements on the driver, all with the 20170228 FW, for (slightly) different power levels - changing the TX drive in Quisk in 0.5 dB steps down from the maximum for a few steps.

First one still using the internal 9.44 V (nominal) supply from the on-board DC/DC converter (actually 9.3 V on my board) to show the effect of adding a 100 nF bypass capacitor near the opamp supply pin.

note that the added bypass improves the distortion at high frequency (and apparently slightly degrades it at the low end) but the harmonic peaks still remain.

Then I've measured with a 10 V supply, with an external supply and then with the on-board DC/DC tweaked to increase its output:

the results are practically identical and also very similar to what has been measured on the v1.4 frontend (for this latter the output power was slightly lower due to a different filter design)

73 de Claudio, IN3OTD / DK1CG.

[Steve Haynal]

Hi Claudio,

Very nice find that a bypass cap near the op amp power makes such improvement. I've added the issue to github and will add one for the next revision.

Thanks and 73,

Steve

KF7O

[in3otd]

Hello,
the added bypass improves the performances but with a 10 V supply on the driver it's even better. There is apparently a slightly higher distortion at the lowest frequencies but I need to check whether it's a measurement artifact or not.

I have also measured the RX gain with the latest FW; results are fine, some gain setting is maybe more "wiggly" than with the previous one but nothing really bad.

73 de Claudio, IN3OTD / DK1CG

[in3otd]

Hello,
I've just repeated the same experiment described in the first message, this time measuring the second- and third-order IMD.
Not surprisingly, loading each digital RX line from the AD9866 has some effect on the intermodulation performance;

here is the graph for the third-order IM (with two input tones of equal power at 9.895 MHz and 9.905 MHz):

and here are the results for the second-order intermodulation (with two input tones of equal power at 8.1 MHz and 6.1 MHz; the intermodulation product measured is at the sum frequency of 14.2 MHz)

The measured the IM2/IM3 for all the gain settings - without any probe on the digital lines - is shown below:

these graphs can be compared with the similar ones done for the H-L v1; the H-L v2b2 seem slightly worse and the IMD curves shapes is a bit different.

[in3otd]

Hello,

I've measured the measured RX response up to 150 MHz to check the input filter response:

seems to match the simulations - at high frequency the attenuation is even a little higher.

[Steve Haynal]

Hi Claudio,

I'd like to come up with a list of all possible reasons for this difference. Here is mine so far:

1. Within normal device variation. Your newest AD9866 may just be more sensitive. The differences don't seem too big to me.

2. Full versus half duplex. I assume your HL1 tests were half duplex? The datasheet reports combined numbers for full and half duplex so not much difference is expected, but maybe we are seeing some.

3. 73.728 vs 76.8 MHz. The datasheet plots of distortion show some increase for increasing sampling frequency.

4. Power supply variations. From the datasheet, distortion appears slightly lower if the supply voltage is slightly high.

5. LPF is on in HL1 firmware, off in 0228 HL2 firmware. This may have some side effects. Even when on, the HL2 LPF hasn't been adjusted to the best frequency yet for 76.8MHz clock.

6. Digital drive strength is high in HL1 firmware, low in 0228 HL2 firmware. This should help, but maybe it is having an opposite impact.

7. Temperature variation. Maybe there was a significant difference in temperature between the two tests.

8. Not enough or bad bypass/decoupling on the HL2. Do you recommend any more?

9. Traces are too regular/length matched on HL2 so changes are reaching FPGA approximately at same time, aligned (and thus bad) current spikes.

10. Capacitance of RX[4] is too high due to being VREF pin. Your tests indicate this is a sensitive area. If you look at the other RX pins, the pin capacitance is roughly 7 pF and trace capacitance much smaller than this. For the Cyclone V, the BGA pins are ~6 pF, but the longer traces and Samtec connector will add more. The capacitance of the HL1 versus Hl2 for RX[*] pins other than RX[4] should actually be a bit more for the HL1. Even with the longer traces and Samtec connector, I don't think it ever approaches the 25 to 30 pF seen in HL2 on RX[4]. Do you think the sole (much) higher capacitance on RX[4] could be the only or prime contributor to the differences?

Here is what I think we can do fairly easily:

1. I have a plan to shift 8 wires by one pin on the FPGA so that RX[4] is no longer on the VREF pin. This doesn't require to much rip and PCB modification. The next version should have these changes.

2. Raise power supply to just above 3.3V.

3. Experiment more with digital drive strength.

4. Experiment more with LPF on/off and frequency settings. This and digital drive strength will eventually be accessible via software.

73,

Steve

KF7O

  

[in3otd]

Hello Steve,
I think that the differences are mainly due to the H-L v1 half duplex mode that I used for the earlier measurements and maybe also the increased clock frequency increased the distortion a bit. There are surely other details influencing the IMD, see e.g. below. I don't think that just the higher capacitance on RX[4] is responsible for all the different IMD behavior but surely it does not help. I still would like to add some series resistors on the RX[] lines to see if this has any effect but I'll need some time do do that. Up to now I do not have any evidence that the FPGA is injecting harmful noise on the supply, it would be interesting to add more logic toggling with the RX bus activity to see if this makes the IMD worse.
I looked at the AD9866 power supplies noise but didn't see anything bad, they look actually quite clean IMHO.

One experiment I did is to DC couple the AD9866 RX inputs to the transformer, as was done in the H-Lv1 and also to connect the RX input transformer center tap to ground. This latter seems not to have any effect, while DC coupling the inputs changes the IM2 somewhat, better at lower levels and worse for higher signals:

Don't know the reason for this behavior, I'll do more experiments.

73 de Claudio, IN3OTD / DK1CG

[in3otd]

I've remeasured the H-L v1 with the last FW which was available in both full-duplex and half-duplex versions (20160220_txdac) and indeed the mode used makes a difference:

the full-duplex mode IMD in the H-Lv1 is quite worse than in the H-Lv2b2...

[Steve Haynal]

Hi Claudio,

This makes more sense to me as the AD9866/FPGA connections are much worse on the HL v1. Your half-duplex data here is better than the previous half-duplex data from a year ago. For example, the old data is above the -120 IM3 line starting at -45, but the new data doesn't do that until around -35. 

 

For full-duplex, the HL2 looks much better than the HL1 full-duplex. I guess the question is how much better would the HL2 look in half-duplex. Unfortunately this can not be done give some FPGA pins used for the AD9866 are input only and those pins must be output if half-duplex mode. Since I am already probably going to do some pin reassignment in this area to avoid the high capacitance on RX[4], I am considering switching the RX PGA to use the TX lines for fast update and the SPI for slow update of the LNA gain. This would free up 5 pins, enough that we can configure the HL2 for half-duplex again. The only drawback (which is probably very minor) is that we couldn't do fast LNA gain setting changes during TX.

I created a firmware where I adjust the RX bias levels described on pages 41 and 42 of the AD9866 datasheet for the lowest THD levels at our sampling rate. I will send you this firmware and would appreciate if you can test if there is any improvement.

73,

Steve

KF7O 

[in3otd]

Hello Steve,

changing the RX bias changes the results but not (always) in the good direction:

73 de Claudio, IN3OTD / DK1CG

[Steve Haynal]

Hi Claudio,

That is interesting that there was such a large change from before. Maybe there is a bias setting that will be better overall. I am not 100% certain the datasheet is accurate as for one setting I lowered the current to the ADC as that setting was best according to their plots. The datasheet does say that an end user should test and pick the best bias settings for their application. How long does it take you to run this test? Maybe we can spot check at 5 to 10 Pin levels and quickly find a good setting. I will eventually expose the AD9866 bias settings to the protocol so you can quickly change them in Quisk for your tests.

There is an option to disable rxclock in the datasheet. There are not many details but I am hoping it disables the rxclock 76.8x2 MHz output and requires me to recreate that within the FPGA from the 76.8MHz clock. This should reduce digital current consumption in the AD9866. I experiment with this. It would also be nice for supporting half and full duplex.

73,

Steve

KF7O

[in3otd]

Hello Steve,
yes, the re quite a large difference in performance with this bias setting. I re-checked also with the current FW to see if anything got broken in the meantime but with the old FW I still get the usual curves, hi;
Measurements for one gain setting are quite fast, just a few minutes; if the bias values can be changed using Quisk that would be perfect as it will allow to check many (all?) settings.

73 de Claudio, IN3OTD / DK1CG

[in3otd]

Hello,

I was doing some more experiments on the RX input and noticed that probably the value of C55 needs to be corrected to compensate for the input capacitance of the AD9866. The differential input capacitance, from the datasheet, is 4 pF, which is then multiplied by 8 by the input transformer T2 so it looks like 32 pF on the 50 ohm side; this value needs to be subtracted from the theoretical 100 pF needed. We could then use 68 pF for C55 but for some reason things look a bit better when moving the whole capacitance after the transformer, removing C55 and placing 8.2 pF across the AD9866 RX inputs.

In the graph below is the measured wideband response for the default values (same as in the previous post) and when replacing C55 with 8.2 pF on the differential RX pins:

the notch moves a little higher in frequency (in the middle of the FM band) and the final rejection is a little higher, maybe because the transformer leakage inductance adds some filtering effect.

Looking at the passband response, there is a slight change on the upper end of the HF, maybe some fraction of a dB less loss at 30 MHz (as usual, ignore the small dips on the red trace, these were due to an issue in the measurement script)

the input impedance also looks a bit better, as the return loss above 10 MHz is improved:

[Steve Haynal]

Hi Claudio,

Okay. I'll make this change. It is hard to argue with your measurements! I seem to recall a similar discussion about capacitor placement before or after the balun but believe it was for TX.

73,

Steve

KF7O

[Steve Haynal]

Hi Claudio,

I am making this change. In your experiment, was the 8.2pF on the AD9866 side or the T2 of B83 and B84?

73,

Steve

KF7O

 

On Thursday, April 27, 2017 at 1:06:01 PM UTC-7, in3otd wrote:

[in3otd]

Hello,
the 8.2 pF capacitor was actually between pin 1 and 3 of T2; I think placing it across pins 37 and 38 of the AD9866 should not make any difference.

73 de Claudio, IN3OTD / DK1CG