locked New firmware update for Airspy R2 and R0 with improved Phase Noise #airspyr2 #firmware #update -Issue with calibration #update #airspyr2 #firmware


f1hdi
 

Hi,

I just tried the following setup :

GPSDO Leobodnar locked on 145.000.000 MHz

Airspy R2 with latest improved firmware

a) without ext 10MHz ref -> running AirspyCalibrate, following the procedure -> getting -3,04ppm @145.000.000 -> starting sdr#, tuning to 145.0 -> the R2 is 15Hz apart (144.999.985)

b) with ext 10MHz ref locked GPSDO G3RUH -> running AirspyCalibrate, following the procedure -> getting 0,02ppm @145.000.000 -> starting sdr#, tuning to 145.0 -> the R2 is 15Hz apart, same as above

Is it normal what we should expect ?

With previous firmware and calibration I was 4Hz appart.

Kind regards

JM

Le 09/05/2020 à 20:43, prog a écrit :

Here's a complete tutorial video by TechMinds YouTube channel for checking the version number and flashing:

https://www.youtube.com/watch?v=cMm7vC4gklA


prog
 

On Fri, May 15, 2020 at 06:17 PM, f1hdi wrote:
GPSDO Leobodnar locked on 145.000.000 MHz
Why would you do that? Calibrate at 1500 MHz for the best resolution.
Set the GPSDO to 500 MHz and use the third harmonic.


f1hdi
 

I made it also at 800MHz (max of bodnar without using harmonics) same result exactly.

Le 15/05/2020 à 18:20, prog a écrit :

On Fri, May 15, 2020 at 06:17 PM, f1hdi wrote:
GPSDO Leobodnar locked on 145.000.000 MHz
Why would you do that? Calibrate at 1500 MHz for the best resolution.
Set the GPSDO to 500 MHz and use the third harmonic.


prog
 

On Fri, May 15, 2020 at 06:23 PM, f1hdi wrote:
I made it also at 800MHz (max of bodnar without using harmonics) same result exactly.
If you want to save time, just follow the recommendation.


f1hdi
 

Prog,

I am your guest,  I do !

Before the new cal @1,5GHz (note that a 40dB atten is put between the output of the bodnar and the R2to avoid saturation)

After the new cal (we went from -3,08 to -3,04)

Frequency measured by sdr# +20Hz , on my counter 500MHz is measured with accuracy better than 1Hz



What should I do next ?
Kind regards
Jean-Marc


Le 15/05/2020 à 18:23, prog a écrit :

On Fri, May 15, 2020 at 06:23 PM, f1hdi wrote:
I made it also at 800MHz (max of bodnar without using harmonics) same result exactly.
If you want to save time, just follow the recommendation.


prog
 

What is the new offset at 145 MHz?


jdow
 

I suspect it is R820T2 synthesizer step size related.
{o.o}

On 20200515 09:21:47, f1hdi wrote:
I made it also at 800MHz (max of bodnar without using harmonics) same result exactly.
Le 15/05/2020 à 18:20, prog a écrit :
On Fri, May 15, 2020 at 06:17 PM, f1hdi wrote:

GPSDO Leobodnar locked on 145.000.000 MHz

Why would you do that? Calibrate at 1500 MHz for the best resolution.
Set the GPSDO to 500 MHz and use the third harmonic.


prog
 

It is.


jdow
 

(It is - about +/- 7 Hz if I recall correctly.)

In theory a suitably manic and precision addicted developer for SDRSharp could provide the offset to the display and readout software by calculating the true synthesizer output frequency difference from the commanded frequency.

{^_-}

On 20200515 17:28:57, prog wrote:
It is.


prog
 

About half of that in at 145 MHz in the Airspy.
To compensate properly for this offset, the set frequency command should return the actual tuned frequency. This requires changing the command handling and breaking the compatibility.


jdow
 

You could generate a new API entry that does that. Then compatibility backwards and forwards would exist. (And it would shut up people who try to use exotic deep in the noise communications technology over satellites if the new technology involved was leveraged.)

{O.O}

On 20200515 17:51:10, prog wrote:
About half of that in at 145 MHz in the Airspy.
To compensate properly for this offset, the set frequency command should return the actual tuned frequency. This requires changing the command handling and breaking the compatibility.


Simon Brown
 

Just like I did yesterday for the Lime - Lime has up to 30 Hz steps sizes at 3.5 GHz ☹ .

Simon Brown, G4ELI
https://www.sdr-radio.com

-----Original Message-----
From: airspy@groups.io <airspy@groups.io> On Behalf Of jdow
Sent: 16 May 2020 02:16
To: airspy@groups.io
Subject: Re: [airspy] New firmware update for Airspy R2 and R0 with improved Phase Noise #airspyr2 #firmware #update -Issue with calibration

You could generate a new API entry that does that. Then compatibility backwards and forwards would exist. (And it would shut up people who try to use exotic deep in the noise communications technology over satellites if the new technology involved was leveraged.)

{O.O}

On 20200515 17:51:10, prog wrote:
About half of that in at 145 MHz in the Airspy.
To compensate properly for this offset, the set frequency command
should return the actual tuned frequency. This requires changing the
command handling and breaking the compatibility.


jdow
 

When the front end is all derived from one single oscillator for sample rate and synthesizer correcting for its error is very easy within the SDR software. And then synthesizer step size can be computed, if you know the algorithm, and that can be compensated by adding an RIT sort of offset. However, for ultimate accuracy that RIT offset must account for the sample rate error. (I believe that would be automatic. But, paranoia you know...)

{^_^}

On 20200515 22:38:52, Simon Brown wrote:
Just like I did yesterday for the Lime - Lime has up to 30 Hz steps sizes at 3.5 GHz ☹ .
Simon Brown, G4ELI
https://www.sdr-radio.com
-----Original Message-----
From: airspy@groups.io <airspy@groups.io> On Behalf Of jdow
Sent: 16 May 2020 02:16
To: airspy@groups.io
Subject: Re: [airspy] New firmware update for Airspy R2 and R0 with improved Phase Noise #airspyr2 #firmware #update -Issue with calibration
You could generate a new API entry that does that. Then compatibility backwards and forwards would exist. (And it would shut up people who try to use exotic deep in the noise communications technology over satellites if the new technology involved was leveraged.)
{O.O}
On 20200515 17:51:10, prog wrote:
About half of that in at 145 MHz in the Airspy.
To compensate properly for this offset, the set frequency command
should return the actual tuned frequency. This requires changing the
command handling and breaking the compatibility.


f1hdi
 

Yes, and it would be mint.

As Youssef said, the 'real' freq should be 'returned' when a set freq command is been sent. I don't know how complex it is to build this in the airpsy API, but it could turn the R2 serie into a lab grade equipment regarding freq meas.

This R2 toy' is so usefull for lots of use cases, it's here like a pen for HF purpose, just lacking in my case of a build in (poe) eth interface to make it even easier to remote use and move along.

BR

Jean-Marc

Le 17/05/2020 à 01:15, jdow a écrit :
When the front end is all derived from one single oscillator for sample rate and synthesizer correcting for its error is very easy within the SDR software. And then synthesizer step size can be computed, if you know the algorithm, and that can be compensated by adding an RIT sort of offset. However, for ultimate accuracy that RIT offset must account for the sample rate error. (I believe that would be automatic. But, paranoia you know...)

{^_^}

On 20200515 22:38:52, Simon Brown wrote:
Just like I did yesterday for the Lime - Lime has up to 30 Hz steps sizes at 3.5 GHz ☹ .

Simon Brown, G4ELI
https://www.sdr-radio.com

-----Original Message-----
From: airspy@groups.io <airspy@groups.io> On Behalf Of jdow
Sent: 16 May 2020 02:16
To: airspy@groups.io
Subject: Re: [airspy] New firmware update for Airspy R2 and R0 with improved Phase Noise #airspyr2 #firmware #update -Issue with calibration

You could generate a new API entry that does that. Then compatibility backwards and forwards would exist. (And it would shut up people who try to use exotic deep in the noise communications technology over satellites if the new technology involved was leveraged.)

{O.O}

On 20200515 17:51:10, prog wrote:
About half of that in at 145 MHz in the Airspy.
To compensate properly for this offset, the set frequency command
should return the actual tuned frequency. This requires changing the
command handling and breaking the compatibility.