My AD9850 still hasn't arrived. I contacted the supplier and was given a prompt refund. At the moment, it seems as if both DDS modules are working with the Nano/Uno/Mega boards so I'm not going to re-order another one.

Out of interest, did you have to make the D0+D1 and D2 mods before it would work ? and did the manufacturer explain why the incorrect clock chip was fitted ?

The Trackgen code for the analyser and Arduino has been modified so a single hex file will cover both the AD9850 and AD9851. If time allows, I want to add basic support for the AD9910 as well.

Just changing the clock chip didn't do a lot initially, as I still had no control over the output frequency (and the waveforms suddenly became a lot like those from my blue board). When I checked the board more closely I found that pins D0 - D7 were just connected directly to the AD9851, and I realised that the board was set up only for parallel mode (which probably explains why it came with a 12-way ribbon cable). The mods were quick and easy, and after that everything was fine and it was working perfectly with Trackgen.

The seller has been very quiet except for the usual statement of denial after my third or fourth message to him. However, I did find in the AD9851 datasheet that a 125MHz clock can be used if Vcc is kept to 3.3v and the internal multiplier is disabled, but the output would obviously be restricted - but with parallel mode control it looks like the board would probably have worked to some degree as received (not that there's any indication of any of these requirements in the seller's photos or desriptions!). All in all, though, given the quality of the board - which is way above the usual ones, which sell for almost the same price - I'm still glad I bought this one. As you said a few days ago, "research time is never wasted", and in getting this one to work I learned a lot about the AD9850/51 chips which I wouldn't have otherwise have discovered. My next experiment, when the chips arrive, will be to put a 45MHz clock on the blue board to see if it will output at the correct frquencies under Trackgen (it ought to, but whether it will do anything about the distortion above 10MHz remains to be seen).

"Feedback for version 0.9" appears to have been completely taken over by the tracking generator discussion, primarily its hardware.
I have no interest in that, but I do come here to review actual suggestions for the software and check its progress.
Perhaps our moderators would care to create a "tracking generator" topic and return this discussion to feedback on the software, whence it came?

Hi, sorry I've not responded sooner but I've been away for a bit, and also tied up with work, so I've quoted the last post we had below in July.

SteveAndrew wrote:

alantlk wrote:V = V/num_FFT bins - is this part of the normalisation noted in the accepted answer here? - https://uk.mathworks.com/matlabcentral/ ... -operation or is that done in the first two terms? I'm not sure what this term is doing other than it must be some kind of averaging?

Sorry - I was a bit pushed for time and didn't answer your query as clearly as I should have done - and I left out an important step in the calculations

First, we carry out a Fourier transform on the IQ samples provided by the API, the transform returns these as real and imag arrays.

FFT algorithms scale the FFT output in various ways. Commonly the output is scaled by N , or N^2, where N is the number of FFT bins used. The algorithm I'm using scales by N, so each FFT result has been multiplied by N. We have to divide each result by N to get the actual ADC numerical value for each bin.

real = real/num_FFT bins
imag = imag/num_FFT bins

We now have the FFT output scaled back to the original ADC numerical levels. We need to normalise the FFT/ADC result so that instead of having a bunch of numbers that are the numerical representation of the ADC's binary output, we get a number in the range 0 to 1.0 that represent the ADC's normalised output from 0 to the numerical FSD of the ADC.

real = real * 1/32678
imag = imag * 1/32768

Equally, we could have done the above step like this, so that the result is directly scaled in Volts - 1.5 is the ADC FSD in volts.

real = real * (1/32678) * 1.5
imag = imag * (1/32768) * 1.5

Then get the magnitude of the vector

Vpk = sqrt [ (real * real) + (imag * imag) ]

We now multiply by the full scale deflection voltage of the ADC. The ADC used in the SDRplay modules has an FSD of 1.5 Volts. We can skip this step if ADC output has already been scaled to Volts as per the above.

Vpk = Vpk * 1.5

This is the step I forgot to include - where we convert Vpk to Vrms

Vrms = Vpk * 1 / Sqrt(2) (or Vrms = Vpk * 0.707 if you prefer)

Get the power in Watts into 50 Ohms

Pw = (Vrms * Vrms)/50

Convert to dB, add 30 to scale to dBm, and subtract the gain reported by the API to get actual dBm at the input.

I hope the above is a bit clearer than my initial offering. This gives results that are usually with 1.0 - 1.5 dB of that reported by SDRuno.

Edit: dB = Log10(Pw) changed to dB = 10 * Log10(Pw)

Noted on the extra math term, good to know I recognised something was missing, even if not quite the right thing!

I think the root of what I found is as follows:

1. The SDRPlay series are designed for 50 ohm systems. The RSP2 has an additional 1000 ohm input.

2. The SA code assumes the input is at 50 ohms by using that to calculate power, that's then displayed on screen.

3. In the case of the RSP2 balanced input at 1000 ohms that's unfortunately already wrong by a factor of 20. Furthermore in a typical measurement scenario, as opposed to receive from an antenna or properly designed signal generator, the system impedance involved is quite likely to be anything but 50 ohms!

The displayed power will therefore be incorrect, because 50 ohms is assumed in the SA maths, and is what I found with various very loose couplings.

Just a thought - I'd suggest maybe don't use power units on the display as the default, maybe use instead dBmicrovolts as they are what's actually being measured by the RSP? You could of course retain power units at user choice if they are in a known 50 ohm (or 1000 ohm) impedance system.

JJ_in_TN wrote:Feedback for version 0.9" appears to have been completely taken over by the tracking generator discussion, primarily its hardware.
I have no interest in that, but I do come here to review actual suggestions for the software and check its progress.
Perhaps our moderators would care to create a "tracking generator" topic and return this discussion to feedback on the software, whence it came?

PeteW wrote:Agreed. The TG discussion seems to warrant a thread of its own. It's polluting the general feedback.

Apologies for not responding earlier, various problems have kept me offline for the past couple of weeks. You are correct, I should have responded to the Trackgen queries in a separate thread. It looks as if somebody else has already done this so further discussion of tracking generators should be on a new thread.

Hopefully my system is back up and running - only one crash with Firefox while checking the forum today.

alantlk wrote:Hi, sorry I've not responded sooner but I've been away for a bit, and also tied up with work, so I've quoted the last post we had below in July.

I've also been off-line due to hardware and software problems at this end.

alantlk wrote:ust a thought - I'd suggest maybe don't use power units on the display as the default, maybe use instead dBmicrovolts as they are what's actually being measured by the RSP? You could of course retain power units at user choice if they are in a known 50 ohm (or 1000 ohm) impedance system.

I think this is a problem that has no definite solution. The user will either have to arrange correct impedance matching for the the selected RSP input, or be aware of the problem and make due allowance when reading the results. The updated system includes a uV/dBuV scale.

I read here that the problem of not being able to select sweep widths less than 1Mhz (in v0.9a)as 10Khz or 100Khz actually still scans 1Mhz or 20Khz/200Khz scanning 2Mhz was something to do with the region selected. I changed my region in windows 10 to UK and left my language as German but it made no difference not even after a system restart. Am I doing something wrong or must I wait for the new version ? Other than the sweep width problem I'm very impressed, a really useful utility.

Okay sweep and region don't have anything to do with each other but that's not what has been said in other posts. Also it's true some of the lower settings for sweep width are greyed out in 0.9a so obviously not yet available but 100Khz for example is not greyed out but as I said selecting it just puts the sweep width to 1Mhz or selecting 200Khz sets 2Mhz Looks like I will have to be patient and wait for the next version.