Feedback for version 0.9a here

Information and discussions on Spectrum Analysis
SteveAndrew
Posts: 213
Joined: Thu Nov 16, 2017 11:06 pm
Location: Gold Coast, QLD, Australia

Re: Feedback for version 0.9a here

Post by SteveAndrew » Thu Jul 19, 2018 12:43 am

alantlk wrote:After mulling it all over on a train journey today I'm pretty sure the disparities in readings are being caused at least in part by parasitic or unbalanced capacitance to ground, and associated voltage nodes.
I've run several tests again using a signal generator and an RSP2, the indicated levels between SAS and SDRuno are usually within 1 or 2db of each other. I don't have a transmitter available so I'm not able to perform any tests under the conditions you've mentioned. My test setup consists of a signal generator connected directly into the RSP2. All equipment was bonded to a solid ground consisting of the usual ground rods. The connection from the ground rods to my equipment is around 2 metres, they are just outside my office window. The same test was carried out with my main ground disconnected, the results were the same. My USB cables are nothing special, and are not fitted with ferrite beads.
alantlk wrote:I don't understand why SAS and Uno measure differently in each setup? I assume those measurements are done a different way in each software?
The SDRplay API reports the current system gain and this is applied to the output from the FFT after the power calculation. I have to assume that I'm doing the calculations correctly as the correlation between my calculated dBm levels and those observed with SDRuno is very close when using a signal generator.

Pseudo code for the calculation is:

for each FFT bin:

real = real * 1/32678 // ADC normalisation
imag = imag * 1/32768
V = sqrt (real * real) + (imag * imag)
V = V/num_FFT bins
V = V * 1.5 // ADC FSD
P = (V * V)/50
db=Log10(P)
dBm = dB + 30 // scale to dBm
dBm = dBm - API_gain_value

The output level from my generator appears to be accurate as tests made by SDRplay with their own generator correlate very closely to the results I obtained. Perhaps somebody may be able to shed some light on this ?

Reason: No reason

tthames
Posts: 2
Joined: Thu Jul 19, 2018 9:34 am

Re: Feedback for version 0.9a here

Post by tthames » Thu Jul 19, 2018 9:41 am

Hello. I am new in this forum.
I tried to get a AD9850 working. I tried both Hex-files, nothing worked.
I connected the pins of the AD9850-module with the pins given by the software.
I got no output.
Then I used a terminal program as described to communicate.
I got the version back, also the used pins but no output at all.
Do you have an idea where i took mistakes?
Thank you in advance.
Last edited by tthames on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

PeteW
Posts: 4
Joined: Tue Jul 17, 2018 10:30 am

Re: Feedback for version 0.9a here

Post by PeteW » Thu Jul 19, 2018 11:57 am

SteveAndrew wrote:As to a timeline for the next release, I'm afraid it really is a case of watch this space. I can only say that if necessary, I'll release another alpha version to get further feedback before committing to a final beta version.
Thanks for the update Steve. Keep up the good work <thumbs up>.

Pete
Last edited by PeteW on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

SteveAndrew
Posts: 213
Joined: Thu Nov 16, 2017 11:06 pm
Location: Gold Coast, QLD, Australia

Re: Feedback for version 0.9a here

Post by SteveAndrew » Fri Jul 20, 2018 12:44 am

tthames wrote:Hello. I am new in this forum.
I tried to get a AD9850 working. I tried both Hex-files, nothing worked.
First, I suggest you check the posts made by Don-K9AQ. He has experienced similar problems. Don posted some code that works with his AD9850 module. If you have the Arduino IDE then I suggest you try that, at least you will be able to confirm whether or not your module is working.

I ordered an AD9850 module from Ebay about 3 weeks ago and I'm waiting for it to arrive, hopefully sooner rather than later. Once I have the module, I'll be able to do some tests and see why it doesn't work with the existing code. As soon as I have a solution, I'll post it in a new topic. In the meantime, I've included a photo of the module that I've ordered, it's the same format as the AD9851 module I'm currently using. Can you confirm whether this is the type of module you have ? - If it is not, perhaps you could post some information about the module you are using.
AD9850_Module.jpg
AD9850-AD9851 module
AD9850_Module.jpg (20.89 KiB) Viewed 3833 times

Reason: No reason

alantlk
Posts: 11
Joined: Tue Oct 31, 2017 1:07 pm

Re: Feedback for version 0.9a here

Post by alantlk » Sun Jul 22, 2018 10:38 am

I'm not familiar with the API and commenting on FFT pseudo code is pushing the boundaries of my maths! However on looking at that pseudo code I've got a few questions, perhaps more highlighting my own lack of knowledge but here goes anyway:

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?

V = V * 1.5 // ADC FSD - I assume the 1.5 is in the API because I'd intuitively expect to see 1.414 (sq root of 2) in a term like this?

P = (V * V)/50 - is a fixed 50 ohms the correct assumption for a power calculation? For example in my test with the balanced antenna connection on the RSP2Pro is it 1000 ohms as the manual states for that input? With my "bit of wire" as the pick-up it almost certainly wouldn't be anything like 50 ohms! (I wonder if this might be the core of the differences, because a signal generator input would of course be 50 ohms throughout?)

Hope that might help and that I haven't shown up my ignorance too much! As you say with a bit of luck there's someone out there who might be able to shine a light on it. (Edited to spread the paragraphs out a bit)

Reason: No reason

glovisol
Posts: 662
Joined: Thu May 10, 2018 6:42 pm
Location: Piedmont, Italy

Who said 0.9a does not work with RSPduo?

Post by glovisol » Sun Jul 22, 2018 12:32 pm

Out of curiosity I improvised a quick test. Downloaded & started 0.9a, then turned RSPduo on & loosely coupled to a 10 MHz generator: it works! Excuse this quick & preliminary test. Screen pics enclosed.

Please carry on Steve, you are doing a great job for all of us!!

glovisol
Attachments
Spectrum Analyser 1.jpg
Spectrum Analyser 1.jpg (109.17 KiB) Viewed 3775 times
Spectrum Analyser 2.jpg
Spectrum Analyser 2.jpg (135.2 KiB) Viewed 3775 times

Reason: No reason

SteveAndrew
Posts: 213
Joined: Thu Nov 16, 2017 11:06 pm
Location: Gold Coast, QLD, Australia

Re: Feedback for version 0.9a here

Post by SteveAndrew » Tue Jul 24, 2018 5:10 am

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 :oops:

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.

dB = 10 * Log10(Pw)
dBm = dB + 30 (same as dB * 1000 to get mW)
dBm = dBm - API_gain_value


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)

Reason: No reason

DaveR
Posts: 25
Joined: Fri Jul 27, 2018 1:07 am

Re: Feedback for version 0.9a here

Post by DaveR » Fri Jul 27, 2018 2:01 am

Hi All - another new member here.

My AD9850 and AD9851 modules arrived a couple of days ago, so I tried out the four hex files Steve posted. All four files worked first time when uploaded to my Mega2560 and UNO boards, and the AD9850 works very well indeed. However, there is a problem with the AD9851 in that, although it functions ok under both Arduinos, the output from it is 2/3 that of the frequency set in RSP-SAS, eg setting a spot frequency of 24MHz only produces output at 16MHz, and doing a sweep around 30MHz produces nothing on the screen because the actual sweep is carried out at 20MHz! (I discovered this by connecting the AD9851 to an oscilloscope instead of my RSP-1A, after setting the parameters in RSP-SAS.)

Doing a search for info on this glitch, I quickly came across this thread on the Arduino.cc forum from someone who had found exactly the same behaviour with the AD9851:

https://forum.arduino.cc/index.php?topic=530929.0

Reading past the comments of those who couldn't be bothered to understand the OP's problem, a new AD9851 library file was posted in message #3 which is claimed in message #9 to solve the problem. If new AD9851 hex files are compiled and posted using the revised library, I'll be happy to try them out straight away and report back.

Many thanks go to Steve for his work - I can see this software developing into an extremely useful tool in the coming months!

Regards,
Dave
Last edited by DaveR on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

Kees_01
Posts: 24
Joined: Fri Jun 15, 2018 7:05 am

Re: Feedback for version 0.9a here

Post by Kees_01 » Fri Jul 27, 2018 11:36 am

Hi Dave,

Although it is not a one to one replacement for the hexfiles Steve has posted, but it might be worth to test your AD9851 board with a design of Clifford Heath. I have tried it with my Arduino UNO R3 and it works. It can be downloaded here> https://github.com/cjheath/AD9851. It has also a AD9851.h included.
It has a #defined frequency sweep (Fcenter, F deviation, Fspeed and Rate). You can change the #defined settings manually in the sketch.
And it has a calibration function build-in.
During developing a sketch to change these frequency settings from a Visual Basic app, I encoutered a limitation of the the Data Type Int(eger) which can handle a value between -32768 en 32767 when you have a 16 bits storage like an Arduino Uno (ATmega based board). I solved this limitation by using the data type Long instead of Int. Then you can extend to a range of -2,147,483,648 to 2,147,483,647. I am not so experienced with programming languages, but it may be causing the frequency shift you encounterd.

Reason: No reason

DaveR
Posts: 25
Joined: Fri Jul 27, 2018 1:07 am

Re: Feedback for version 0.9a here

Post by DaveR » Fri Jul 27, 2018 11:13 pm

Hi Kees_01,

Thanks for your suggestion. I tried the AD9851 Sweep sketch and got exactly the same result: whether I set the frequency to 30Hz, 75MHz, or anything in between, the output is always 2/3 of the set freq (give or take a tiny amount due to not bothering with the calibration adjustment). I wonder if some modules may have been fitted with 20Mhz XOs wrongly marked as 30MHz? (Mine definitely says 30.000 on the can.)

There are plently of sample sketches out there, so I'll try another couple to see if the results are consistent, then replace the XO to see what happens.

Regards,
Dave
Last edited by DaveR on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

Post Reply