Hermes-Lite 2beta2 20170729 firmware released

[Steve Haynal]

Hi Group,

Firmware 20170729 for the Hermes-Lite 2beta2 is here. The RTL source has also been updated. This fixes the problem with bandscope not working with recent firmware. Also, the RTL and Quartus project are now structured to support beta2 and beta3 builds as two revisions.

73,

Steve

KF7O

[in3otd]

Thanks Steve,
bandscope seems to work fine now here;
I noticed that I have periodic lines on the bandscope spectrum, more evident without an antenna connected, at multiples of 76.8 MHz / 30.:



I tried to tune around the lines frequencies and I see that in general is difficult to hear/see them, especially the odd multiples, besides 15.36 MHz, but as you can see they show up quite nicely in the bandscope. Maybe we really lose something in the filter chain as we discussed some time ago?
When connecting an antenna those lines are still there, at least in the upper part of the spectrum where the noise/signals are not so high.

Do someone else see this with a H-Lv2b2 ?

73 de Claudio, IN3OTD / DK1CG

[Steve Haynal]

Hi Claudio,

I don't see these lines on my beta2 or beta3. I do some much fainter lines spaced a little more than 1 MHz apart across the entire spectrum. My noise floor was about the same as yours.

73,

Steve

KF7O

[in3otd]

Thanks Steve,
I'll try to see if having the H-L wit or without an enclosure makes a difference (capture above was with enclosure). Do you know if there is some clock at 76.8 MHz / 30 on some FPGA pins or internally?

73 de Claudio, DK1CG / IN3OTD

[in3otd]

Hello,
I've finally got a hold of my H-Lv2b3; up to now it seems fine, I've just started Quisk and checking the RX. I still see the same lines in the bandscope. I don't think is some local source as the lines strength does not change with or without the antenna.

73 de Claudio, DK1CG / IN3OTD

[Steve Haynal]

Hi Claudio,

Great news on you receiving your HL2beta3. For RX we have reports that 4/5 are working, Jason hasn't reported an RX problem but is working on setting up a 1Gbps network. For TX we have reports that 2/5 are working, others just have not tested yet. I'm feeling pretty good about Elecrow's part sourcing and assembly.

I will test my unit again for the RX lines. Maybe you can recommend some specific test (RX BW, frequency, LNA settings, etc.) so that are tests are as similar as possible. Do you think there may be some noise entering via the power supply or ethernet at your QTH?

73,

Steve

[Steve Haynal]

Also your Quisk slider settings (bottom right of Quisk screen) for the waterfall would be helpful. 

[Steve Haynal]

Hi Claudio,

You asked about clocks derived from 76.8 MHz. Here is a list of all slow clocks on the board:

I2C to Versa Clock Generator: 2.5/(2*4) = 312 kHz, derived from 25MHz Ethernet oscillator. Can be gated or spread.

I2C to ADC and external: 76.8/(48*4) = 400 kHz. Can be gated or spread.

SPI to AD9866: 76.8/4 = 19.2 MHz. Can be gated or spread.

Switching regulators free running have an internal frequency of ~900 kHz.

P4259s have a charge pump oscillator at ~950 kHz.

73,

Steve

KF7O

[in3otd]

Thanks Steve,
those faint lines are a bit weird, in that their amplitude seems to be the same for every line - if that was a clock harmonic I would have expected them to decrease with frequency. Unless they come from a very short sync pulse around.
Moreover, in Quisk I do see a line at 19.2 MHz in the normal spectrum graph window, not very strong but clearly above the noise. But when I look at the bandscope this line cannot be seen there (or maybe only a very faint trace).
Conversely those 76.8/30 MHz lines can be seen clearly in the bandscope here but most of them are at or below the noise level in the standard spectrum graph. Their relative amplitude does not depend much on the LNA gain, they are always just around the noise floor when seen in the bandscope.
I did try with a different power supply and with a few turns of the Ethernet cable around a FT240-31 toroid but saw no difference at all.

Regarding doing comparative RX measurements, for those using Quisk we might prepare a simple script just saving to a file the relative amplitude seen at certain frequency or frequency bands (with the input terminated to 50 ohm), similarly to the script I normally use for testing here (I think I sent you and/or someone else a copy some time ago). We could then see if the apparent noise/spurs is the same for all boards.

73 de Claudio, DK1CG / IN3OTD

[Takashi K]

Hi Steve and Claudio,

Here is my result. I use firmware 20170809 now.

Rx input is terminated by 50 ohms dummy load and AGC setting is 0.000.

This line comes from digital processing in FPGA ?

73, Taka  ji1udd

[in3otd]

Hello Taka,
the spectrum you see there is very similar to what I see here; the lines frequency seems not the same, though, which is quite strange.
I assume those lines come from some internal signal, either in the AD9866 or the FPGA but I don't know for sure. The lines intensity changes only a little with the RxPGA gain so likely they do not enter thru the RxPGA path.

73 de Claudio, IN3OTD / DK1CG

[Steve Haynal]

HI Taka and Claudio,

If you pick the frequency of one of those lines, do you also see it in the narrow band waterfalls? I am wondering if it is an artifact of Quisk bandscope processing.

73,

Steve

KF7O

[Takashi K]

Hi Steve,

I chose and checked two lines near 40M and 20M band but I could not see them it in the narrow band waterfalls.

73, Taka  ji1udd

[Takashi K]

Hi Claudio,

> The lines intensity changes only a little with the RxPGA gain

It looks like analog issue. but  not only lines frequency but also their pitch are a bit different from yours.

I have no idea now.

73, Taka  ji1udd

[in3otd]

Hello Taka,
looking at the position of the lines and the maximum frequency shown on the bandscope I have the impression that you have the parameter rx_udp_clock in the quisk config file set the default 73728000 instead of 76800000 needed for the H-Lv2. If this is the case, the frequency you read on the bandscope may not be correct.

As described above, I can see the lines in the bandscope also in the normal waterfall (but not in the spectrum Graph) but also in this latter they are very weak while I would have expected to see them more clearly there, since the FFT bins are much narrower than in the bandscope window.

73 de Claudio, IN3OTD / DK1CG

[Takashi K]

Hi Claudio,

> I have the impression that you have the parameter rx_udp_clock in
> the quisk config file set the default 73728000 instead of 76800000 needed
> for the H-Lv2.

You are right. I forgot to change the setting for HLv2. I attached a new picture.

But still I cannot find any lines in normal waterfall.

73, Taka  ji1udd

[Alan Hopper]

Hi List,

I just put a dummy load on the antenna of my beta3 and slowly tuned over the full range. I don't see these lines and they don't appear in the Spark bandscope.  I only saw two tiny spurs above 1.4Mhz at 11.950068 and 19.200293, below 1.4Mhz there were a handful of tiny ones, With the antenna connected all spurs were invisible in the noise.  This was with an lna gain of 24 and uncased (but in the electrically quiet shack at the end of the garden).

I've just set it decoding wspr in competition with a HL1

73 Alan M0NNB

[in3otd]

Hello Alan,
I've also tried with Spark Radio and indeed I cannot see any of those lines there.

As an example, here it's how the line at 20.480 MHz looks like in Quisk



it can be see very clearly in the waterfall and sometimes also in the Graph display.
In Spark Radio nothing can be seen at that frequency. BTW, does v0.152 actually have a Bandscope? I've just looked at the standard waterfall display, did not see how to get the whole-spectrum bandscope.

73 de Claudio, IN3OTD / DK1CG

[Alan Hopper]

Claudio,

you can see the bandscope in spark just by zooming out either with mouse wheel or the -ve magnifier button, the bandscope fills in the spectrum that the ddc bit does not cover, the levels are not matched (yet).

The HL sends fewer consecutive packets of adc data than the HPSDR spec mentions, I take 2048 samples (4 packets) sync'd to the seq number%4 

73 Alan M0NNB 

On Wednesday, August 23, 2017 at 9:19:20 PM UTC+1, in3otd wrote:

Hello Alan,

[Alan Hopper]

Hi List,

after 12 hours the HLv2 beta3 spotted 2.4% more wsprs on 20 m than my HLv1.1 so it looks like the receive side is working well. It was not a very well thought out test as I just used the HL1.1 that happened to be in the shack, this had John's 2 band front end with bandpass filters and was running old non duplex firmware.  I only used ntp frequency correction on the v1.1 and the spots were all within 3Hz of each other so the frequency stability looks greatly improved (the shack temperature is not regulated).  The reported snr were generally the same, with the v2 occasionally 1 db better.  I used a lna gain of 24 for both. I'll repeat with Jim's frontend for a better comparison.  

73 Alan M0NNB

[Steve Haynal]

Hi Claudio,

I am finally able to see the lines you report! But only when a frequency such as 20.480 MHz is centered and -12 dB LNA gain as in your picture. If 20.480 MHz is still in the waterfall but not in the center, then I see no line. That is definitely an artifact of the DSP either in the FPGA or software. I haven't tried with SparkSDR yet, but that could tell us if it is the FPGA firmware or not. This is very much a corner case with -12 dB LNA gain and no antenna/dummy load attached. It would not be surprising if the small numbers produced in this case are generating artifacts in the computations. See below for my screenshots.

73,

Steve

KF7O

  

 

On Wednesday, August 23, 2017 at 1:19:20 PM UTC-7, in3otd wrote:

Hello Alan,
I've also tried with Spark Radio and indeed I cannot see any of those lines there.

As an example, here it's how the line at 20.480 MHz looks like in Quisk

[in3otd]

Thanks Steve,
I didn't notice that the line shows up in the waterfall only if the RX frequency is centered there. Indeed also here the line disappears from the waterfall if the RX is not centered on the line.
For the waterfall is certainly a corner case but the bandscope will be nicer without them, I can see the lines "comb" there at all LNA gains (see picture above), also with the antenna connected, where the noise floor is low enough.

73 de Claudio, IN3OTD / DK1CG

[Alan Hopper]

Steve, Claudio,

I can see this line in Spark at -12db 20.480. If I tune off slightly the line moves much further than the tuned amount. It will behave differently if you happen to have a second virtual receiver on the same band as the tuning is then done on the pc and the line moves as expected. I still can't see anything in the bandscope.

73 Alan M0NNB

[Steve Haynal]

Hi All,

This is a problem I'll have to look at at a later time. Since it is frequency dependent, it must be related to DSP in the FPGA or software. If it were present in the values from the ADC, then I'd expect to always see it. Since Alan does not see it in this waterfall, I wonder if Quisk is assuming the larger packet size in the specification. As Alan mentioned earlier, the Hermes-Lite does send smaller amounts of bandscope data to save on memory. 

John Melton's software also support the Hermes-Lite bandscope. I discussed this difference in bandscope data amounts with him and he didn't think the smaller amount was a problem. Someone can try his software to see if the lines shows up. Also, CudaSDR supports bandscope with the Hermes-Lite. PowerSDR too.

73,

Steve

KF7O

[Alan Hopper]

Hi Steve,

It appears the line at 20.480 is generated by the cordic, I changed the extrabits in cordic.v to 6 and it can no longer be seen. I first tried keeping the output bits of the cordic at 18 but this caused a dc spur (wherever you tune), maybe there is a problem in the cordic rounding when the output width does not match WR.  I ended up increasing the input of the first cic to 19 bits but don't think it should be necessary (it already looks too big to me)  .These small cordic spurs are very visible with a synthetic (fpga) test signal and I guess this one just managed to pop above the noise.

73 Alan M0NNB

[Alan Hopper]

Steve,

here is a cordic.v with alternative rounding that appears to remove the spur without increasing the input width to the first cic. I wonder if we can actually reduce the input to the cic to save resources.

73 Alan M0NNB

[Steve Haynal]

Hi Alan,

Thanks for tracking this down and providing two alternate fixes! I will add this to the next firmware release, due shortly, which will also include Taka's ethernet LED changes. I'd like to fix my T3 and test before release.

It would be great if we can reduce the input to the CIC further. I am focused on the hardware right now but am eager to learn whatever you discover.

73,

Steve

KF7O