Date   

Re: Transmission lines, Input match and Connectors #bestpractice #experiment

prog
 

On Fri, Oct 18, 2019 at 11:40 PM, jdow wrote:
While you are on the topic - is the AGC correction developed before or after any tuneable front end filtering Discovery may have? Symptoms I see here suggest that it is taken after the filtering. (160 meters with a very strong AM station at about 1.5 MHz out of the receiver band.) Adding attenuation mitigates the problem for the most part.

{^_^}
The AGC was always there. Now running with slightly different parameters.
The power detector for the RF AGC loop is located after the filters. How much attenuation is needed in your case?


Re: Transmission lines, Input match and Connectors #bestpractice #experiment

jdow
 

While you are on the topic - is the AGC correction developed before or after any tuneable front end filtering Discovery may have? Symptoms I see here suggest that it is taken after the filtering. (160 meters with a very strong AM station at about 1.5 MHz out of the receiver band.) Adding attenuation mitigates the problem for the most part.

{^_^}

On 20191018 10:52:01, prog wrote:
The internal IF AGC of the ADC will not allow any digital saturation to happen. It will silently adjust the level at the input of the ADC and keep the signals below 0 dBFS. The same applies to the RF AGC chain plus or minus the threshold level. This excludes many of the assumptions stated in the previous emails.
What could happen, however, is all these non-linearity problems that could be introduced by bad contacts (mostly in connectors), bad cables, and even rusty metallic structures surrounding the antenna that could mix signals and translate them into unexpected frequencies. Here's an example from the recent memory: https://www.pressreader.com/canada/windsor-star/20191009/281517932872802
I have seen this happen too many times to ignore it. Many experienced ops overlook these details. Even Leif found some noise humps (/similar to those we see in these screenshots which are unaffected by the attenuation level/) when testing the original HF+ and he traced them back to a faulty (leaky) attenuator. Once he replaced the attenuator, things went back to normal. At the same time, I am being realistic by not expecting everyone to have Leif's experience. Someone else would have just trusted his apparatus and produced a bogus appreciation.
This is the main reason I do not take anyone's tests on their face value. Understanding the phenomenons involved in the "bad" results and being able to reproduce them is proper engineering. The rest is, well... just noise.
</rant>


Re: Transmission lines, Input match and Connectors #bestpractice #experiment

jdow
 

(warning - smartass reply) Luke was told to use the force. You are being told to use the AGC. (I believe it has a readback which can be used to provide at least roughly calibrated displays on software which uses AGC.) The AGC will keep the strongest signal near but below the top of the display giving you the best usable instantaneous dynamic range the device can deliver. (This is still not enough dynamic range to recover a week signal when your buddy fires up 100 Watts on the voice portion of the band when you are in the CW portion. Heck, the AGC might not even handle that case gracefully at all. But it will try. Suggest your buddy go for QRP points and it'll probably work out nicely.)

{^_-}

On 20191018 10:27:38, David Eckhardt wrote:
For the results of the tests presented:  The tests and data have nothing to do with input filtering or very little with input match.  Everything within each data set is within the same band.   Of course, any input filtering will pass all signals close to the target signal.
Another point seen especially in data sets Airspy7_0dB.jpg and to a lesser extent in data set Airspy 9_0dB.jpg:  At issue may be digital saturation.  In an SDR when all available bits are utilized as with possible reception of a strong signal, the output becomes garbage and unpredictable.  This is highly evident in the Airspy7_0dB.jpg.  Attenuation between the antenna feedline and the input to the receiver, in this case, is mandatory.  I wrote an article some 4 or five years ago in the Journal of the Society of Amateur Radio Astronomers (SARA) addressing this issue for reception around 20 MHz (when solar conditions were pretty much the best of Cycle 24).
The issue of 'bogus' signals in the FM broadcast band:  This is common in nearly all receivers be they the older technology or the newer digital receivers like the Airspy and others.  The problem is that within the 88 to 108 MHz FM broadcast band, there are many truly strong signals, especially true in or near large cities.  This is required to minimize the noise and maximize the level of quieting in detection of a wideband signal.  The input stage(s) (front end) acts as a mixer as its driven into unintended non-linearities by all the strong stations within that 20 MHz of spectrum.  The strong stations mix with each other to produce bogus or false signals.  Again, too much signal requires either a stopband filter (if you're not interested in receiving FM), or insertion of an appropriate amount of attenuation between the antenna feedline and the input of the receiver.  Any input passband filter present for the FM band, specifically, will aim at passing the whole band on to the mixer or ADC.  Again, an attenuator is required due to too much in-band strong signal levels.
The suggestion has been made to understand how receivers are tested and the basics of their internal design.  The information is on the Internet, so you don't have to visit a library.  For proper evaluation of the newer SDR technology, to properly design tests and evaluations of the item, a knowledge far deeper than just the basics of the design will be required.
In conclusion, your measurements and data do not address input filtering and/or input match.  To properly conduct the tests you desire, you must first understand what you are evaluating.
Dave - WØLEV
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Oct 18, 2019 at 5:07 AM jdow <jdow@earthlink.net <mailto:jdow@earthlink.net>> wrote:
Please look at "https://en.wikipedia.org/wiki/Radio_noise". It is a simple
discussion. Then explain to me why you insist on NOT using an attenuator at MW
as a matter of course? If you had a SMALL antenna like one of those telescoping
whips the low noise figure of the HF+ would be really good for you. But with an
antenna such as you describe in an environment with a "typical" level of man
made noise a 30 dB attenuator would do you no ill and probably a 40 dB
attenuator would do you no ill. Look at Wikipiddle er Wikipedia for a perhaps
over-simplified discussion of noise figure to see how it works.
Now, knowing the input impedance of the HF+ input may help you optimize a
filter
to reduce signals in the MW broadcast band when you are working elsewhere. But
that would probably be for one tuning setting. The input impedance may vary
with
the frequency to which HF+ is tuned.
My purpose in trying to drive this home is to help you optimize your time and
efforts to best effect. I am trying to boost your game not deride you. Too many
years in a very male oriented occupation has left me a tad abrasive. Please
forgive.
{o.o}
On 20191017 10:23:46, Wes Stewart via Groups.Io wrote:
> On Thu, Oct 17, 2019 at 07:45 AM, prog wrote:
>
>     Let's be more pragmatic. What is the real world performance using an
antenna?
>
> Thank you for asking.  Let me preface the following by explaining the
> environment.  The antenna is a 55 foot vertical over ground radials,  For
the
> results that follow, the antenna is connected to the Airspy through a
Telonic
> Industries Model TG-950 stepped attenuator.  Although not a traceable
device I
> have verified its performance with my DG8SAQ VNWA. I have several plots, all
> taken during the same session, which are screen grabs of the SDR#
program.  The
> model, serial number, firmware and software versions are all obvious.
This unit
> is as received a few days ago.
>
> I'm not sure I can intersperse comments between the attachments so I will
> summarize them here.  The image "Airspy_1_40db" is of a local MW station
with
> the inline attenuator set to 40dB.  The image  "Airspy_2_20db" is the
same as
> before except the attenuation has been reduced to 20 dB.  It was
pointless to go
> to 0 dB.  Images "Airspy_3_40dB" and "Airspy_4_20db" are similar but of a
> different station.
>
> The next set, "Airspy_5_20db", "Airspy_6_10db" and "Airspy_7_0db" show
station
> WWV being received on 10 MHz with 20, 10 and 0 dB attenuation respectively.
> Note that with 0 dB attenuation, the Airspy is essentially useless.  The
next
> set,  "Airspy_8_10db" and "Airspy_9_0db" show station WWV being received
on 15
> MHz with 10 and 0 dB attenuation respectively.  Same situation.  Now you
might
> understand my interest in knowing the performance of the input filtering
because
> obviously it isn't up to the task.
>
> But it gets worse.  Image "Airspy_10_Spurious_of_88_1_0db" shows an FM
broadcast
> signal, fully readable so I could identify it, that doesn't exist.  Image
> "Airspy_11_Spurious_of_88_1_20db" shows the same spectrum with 20 dB of
> attenuation inline. The non-existent station disappears.
>
>
> AIrspy_1_40db.jpg
>
>
> AIrspy_2_20db.jpg
>
>
> Airspy_11_Spurious_of_88_1_20db.jpg
>
>
> Airspy_3_40db.jpg
>
>
> Airspy_4_20db.jpg
>
>
> Airspy_5_20db.jpg
>
>
> Airspy_6_10db.jpg
>
>
> Airspy_7_0db.jpg
>
>
> Airspy_8_10db.jpg
>
>
> Airspy_9_0db.jpg
>
>
> Airspy_10_Spurious_of_88_1_0db.jpg
>
--
*Dave - WØLEV
*
*/Just Let Darwin Work/*
*/Just Think/*


Airspy R0/R2/Mini Sample scaling

prog
 
Edited

On Fri, Oct 18, 2019 at 10:01 PM, David Eckhardt wrote:
We have fed the antenna port with broadband noise well below the 12-bit limit and well over the 12-bit limit for saturation.  Even with the low input we see raw I/Q values in excess of what should be spit out with a 12-bit system.  With the well into saturation, we see many more raw I/Q values well in excess of saturation for a 12-bit system.  These are raw I/Q values grabbed on the USB output.  We discovered this some 1.5 years ago when we were attempting to put the 'nominal' output from our H1 telescope no more than 3 to 5 bits above the bottom of the bit stack.  We asked more questions that we were able to answer, as a result, and are still scratching our heads as to how this can occur.  We were seeing values upwards of roughly 2X that of the +/- 33k values (for a 16-bit system).  If its a true 12-bit system without attempting to internally adjust the position of the signal within the bit stack in the airspy FW, how can this occur?   
 
Dave - WØLEV
toggle quoted messageShow quoted text

 


On Fri, Oct 18, 2019 at 7:23 PM prog <info@...> wrote:
On Fri, Oct 18, 2019 at 09:14 PM, David Eckhardt wrote:
It appears it is not a true 12-bit system as we are getting raw I/Q values well in excess of that permitted by a strictly 12-bit system.
The output is scaled to fill a 0 dBFS unit. It can be either float (-1 .. +1) or a 16bit signed integer (-32768 .. +32767). You also have some DSP running in the library to convert the RAW samples into IQ.
Speaking of the RAW samples, the 12bit data is stuffed in the LSB bits of the unsigned 16bit samples and no further processing is done. You can read the code of the library for the details.

Not sure what you are doing, but I recommend you check your math. You can't get more resolution than what the device is giving.

 

 


--
Dave - WØLEV
Just Let Darwin Work
Just Think
I think this all has to do with the sample scaling. Basically, these lines:
https://github.com/airspy/airspyone_host/blob/master/libairspy/src/airspy.c#L300
https://github.com/airspy/airspyone_host/blob/master/libairspy/src/airspy.c#L312
and
https://github.com/airspy/airspyone_host/blob/master/libairspy/src/airspy.c#L57


Re: Transmission lines, Input match and Connectors #bestpractice #experiment

W0LEV
 

We have fed the antenna port with broadband noise well below the 12-bit limit and well over the 12-bit limit for saturation.  Even with the low input we see raw I/Q values in excess of what should be spit out with a 12-bit system.  With the well into saturation, we see many more raw I/Q values well in excess of saturation for a 12-bit system.  These are raw I/Q values grabbed on the USB output.  We discovered this some 1.5 years ago when we were attempting to put the 'nominal' output from our H1 telescope no more than 3 to 5 bits above the bottom of the bit stack.  We asked more questions that we were able to answer, as a result, and are still scratching our heads as to how this can occur.  We were seeing values upwards of roughly 2X that of the +/- 33k values (for a 16-bit system).  If its a true 12-bit system without attempting to internally adjust the position of the signal within the bit stack in the airspy FW, how can this occur?   

Dave - WØLEV


On Fri, Oct 18, 2019 at 7:23 PM prog <info@...> wrote:
On Fri, Oct 18, 2019 at 09:14 PM, David Eckhardt wrote:
It appears it is not a true 12-bit system as we are getting raw I/Q values well in excess of that permitted by a strictly 12-bit system.
The output is scaled to fill a 0 dBFS unit. It can be either float (-1 .. +1) or a 16bit signed integer (-32768 .. +32767). You also have some DSP running in the library to convert the RAW samples into IQ.
Speaking of the RAW samples, the 12bit data is stuffed in the LSB bits of the unsigned 16bit samples and no further processing is done. You can read the code of the library for the details.

Not sure what you are doing, but I recommend you check your math. You can't get more resolution than what the device is giving.



--
Dave - WØLEV
Just Let Darwin Work
Just Think


Re: New SDR# release r1730 with High DPI support #software #announcements

prog
 

Quick update: I added a "Snap To Peak" feature that helps clicking more precisely on very narrow signals.
You can now use the Control key when hovering a signal with the mouse to snap to it, then you can click.
This feature is compatible with "Snap To Grid". Which means, if you enable a certain step size, the Control + Hover will snap to multiples of the step size.

Download as usual from: https://airspy.com/download


Re: Transmission lines, Input match and Connectors #bestpractice #experiment

prog
 

On Fri, Oct 18, 2019 at 09:14 PM, David Eckhardt wrote:
It appears it is not a true 12-bit system as we are getting raw I/Q values well in excess of that permitted by a strictly 12-bit system.
The output is scaled to fill a 0 dBFS unit. It can be either float (-1 .. +1) or a 16bit signed integer (-32768 .. +32767). You also have some DSP running in the library to convert the RAW samples into IQ.
Speaking of the RAW samples, the 12bit data is stuffed in the LSB bits of the unsigned 16bit samples and no further processing is done. You can read the code of the library for the details.

Not sure what you are doing, but I recommend you check your math. You can't get more resolution than what the device is giving.


Re: Transmission lines, Input match and Connectors #bestpractice #experiment

W0LEV
 

My article in the SARA Journal was based on the Airspy 1.  A lot has changed in the interim.

I should comment that every time Terry and I try to "discover" what makes the Airspy tick inside, we're frustrated - completely.  It appears it is not a true 12-bit system as we are getting raw I/Q values well in excess of that permitted by a strictly 12-bit system.  The Airspy is utilized in our H1 line telescope at the Little Thompson Observatory where both Terry and I volunteer.  I would be "rather" useful in this application to take the lid off the little box!!!!!

Dave - WØLEV


On Fri, Oct 18, 2019 at 5:53 PM prog <info@...> wrote:
The internal IF AGC of the ADC will not allow any digital saturation to happen. It will silently adjust the level at the input of the ADC and keep the signals below 0 dBFS. The same applies to the RF AGC chain plus or minus the threshold level. This excludes many of the assumptions stated in the previous emails.
What could happen, however, is all these non-linearity problems that could be introduced by bad contacts (mostly in connectors), bad cables, and even rusty metallic structures surrounding the antenna that could mix signals and translate them into unexpected frequencies. Here's an example from the recent memory: https://www.pressreader.com/canada/windsor-star/20191009/281517932872802
I have seen this happen too many times to ignore it. Many experienced ops overlook these details. Even Leif found some noise humps (similar to those we see in these screenshots which are unaffected by the attenuation level) when testing the original HF+ and he traced them back to a faulty (leaky) attenuator. Once he replaced the attenuator, things went back to normal. At the same time, I am being realistic by not expecting everyone to have Leif's experience. Someone else would have just trusted his apparatus and produced a bogus appreciation.
This is the main reason I do not take anyone's tests on their face value. Understanding the phenomenons involved in the "bad" results and being able to reproduce them is proper engineering. The rest is, well... just noise.
</rant>



--
Dave - WØLEV
Just Let Darwin Work
Just Think


Re: Transmission lines, Input match and Connectors #bestpractice #experiment

prog
 

The internal IF AGC of the ADC will not allow any digital saturation to happen. It will silently adjust the level at the input of the ADC and keep the signals below 0 dBFS. The same applies to the RF AGC chain plus or minus the threshold level. This excludes many of the assumptions stated in the previous emails.
What could happen, however, is all these non-linearity problems that could be introduced by bad contacts (mostly in connectors), bad cables, and even rusty metallic structures surrounding the antenna that could mix signals and translate them into unexpected frequencies. Here's an example from the recent memory: https://www.pressreader.com/canada/windsor-star/20191009/281517932872802
I have seen this happen too many times to ignore it. Many experienced ops overlook these details. Even Leif found some noise humps (similar to those we see in these screenshots which are unaffected by the attenuation level) when testing the original HF+ and he traced them back to a faulty (leaky) attenuator. Once he replaced the attenuator, things went back to normal. At the same time, I am being realistic by not expecting everyone to have Leif's experience. Someone else would have just trusted his apparatus and produced a bogus appreciation.
This is the main reason I do not take anyone's tests on their face value. Understanding the phenomenons involved in the "bad" results and being able to reproduce them is proper engineering. The rest is, well... just noise.
</rant>


Re: Transmission lines, Input match and Connectors #bestpractice #experiment

W0LEV
 

For the results of the tests presented:  The tests and data have nothing to do with input filtering or very little with input match.  Everything within each data set is within the same band.   Of course, any input filtering will pass all signals close to the target signal. 

Another point seen especially in data sets Airspy7_0dB.jpg and to a lesser extent in data set Airspy 9_0dB.jpg:  At issue may be digital saturation.  In an SDR when all available bits are utilized as with possible reception of a strong signal, the output becomes garbage and unpredictable.  This is highly evident in the Airspy7_0dB.jpg.  Attenuation between the antenna feedline and the input to the receiver, in this case, is mandatory.  I wrote an article some 4 or five years ago in the Journal of the Society of Amateur Radio Astronomers (SARA) addressing this issue for reception around 20 MHz (when solar conditions were pretty much the best of Cycle 24).

The issue of 'bogus' signals in the FM broadcast band:  This is common in nearly all receivers be they the older technology or the newer digital receivers like the Airspy and others.  The problem is that within the 88 to 108 MHz FM broadcast band, there are many truly strong signals, especially true in or near large cities.  This is required to minimize the noise and maximize the level of quieting in detection of a wideband signal.  The input stage(s) (front end) acts as a mixer as its driven into unintended non-linearities by all the strong stations within that 20 MHz of spectrum.  The strong stations mix with each other to produce bogus or false signals.  Again, too much signal requires either a stopband filter (if you're not interested in receiving FM), or insertion of an appropriate amount of attenuation between the antenna feedline and the input of the receiver.  Any input passband filter present for the FM band, specifically, will aim at passing the whole band on to the mixer or ADC.  Again, an attenuator is required due to too much in-band strong signal levels.

The suggestion has been made to understand how receivers are tested and the basics of their internal design.  The information is on the Internet, so you don't have to visit a library.  For proper evaluation of the newer SDR technology, to properly design tests and evaluations of the item, a knowledge far deeper than just the basics of the design will be required. 

In conclusion, your measurements and data do not address input filtering and/or input match.  To properly conduct the tests you desire, you must first understand what you are evaluating.  

Dave - WØLEV  
 

Virus-free. www.avast.com


On Fri, Oct 18, 2019 at 5:07 AM jdow <jdow@...> wrote:
Please look at "https://en.wikipedia.org/wiki/Radio_noise". It is a simple
discussion. Then explain to me why you insist on NOT using an attenuator at MW
as a matter of course? If you had a SMALL antenna like one of those telescoping
whips the low noise figure of the HF+ would be really good for you. But with an
antenna such as you describe in an environment with a "typical" level of man
made noise a 30 dB attenuator would do you no ill and probably a 40 dB
attenuator would do you no ill. Look at Wikipiddle er Wikipedia for a perhaps
over-simplified discussion of noise figure to see how it works.

Now, knowing the input impedance of the HF+ input may help you optimize a filter
to reduce signals in the MW broadcast band when you are working elsewhere. But
that would probably be for one tuning setting. The input impedance may vary with
the frequency to which HF+ is tuned.

My purpose in trying to drive this home is to help you optimize your time and
efforts to best effect. I am trying to boost your game not deride you. Too many
years in a very male oriented occupation has left me a tad abrasive. Please forgive.

{o.o}

On 20191017 10:23:46, Wes Stewart via Groups.Io wrote:
> On Thu, Oct 17, 2019 at 07:45 AM, prog wrote:
>
>     Let's be more pragmatic. What is the real world performance using an antenna?
>
> Thank you for asking.  Let me preface the following by explaining the
> environment.  The antenna is a 55 foot vertical over ground radials,  For the
> results that follow, the antenna is connected to the Airspy through a Telonic
> Industries Model TG-950 stepped attenuator.  Although not a traceable device I
> have verified its performance with my DG8SAQ VNWA. I have several plots, all
> taken during the same session, which are screen grabs of the SDR# program.  The
> model, serial number, firmware and software versions are all obvious.  This unit
> is as received a few days ago.
>
> I'm not sure I can intersperse comments between the attachments so I will
> summarize them here.  The image "Airspy_1_40db" is of a local MW station with
> the inline attenuator set to 40dB.  The image  "Airspy_2_20db" is the same as
> before except the attenuation has been reduced to 20 dB.  It was pointless to go
> to 0 dB.  Images "Airspy_3_40dB" and "Airspy_4_20db" are similar but of a
> different station.
>
> The next set, "Airspy_5_20db", "Airspy_6_10db" and "Airspy_7_0db" show station
> WWV being received on 10 MHz with 20, 10 and 0 dB attenuation respectively. 
> Note that with 0 dB attenuation, the Airspy is essentially useless.  The next
> set,  "Airspy_8_10db" and "Airspy_9_0db" show station WWV being received on 15
> MHz with 10 and 0 dB attenuation respectively.  Same situation.  Now you might
> understand my interest in knowing the performance of the input filtering because
> obviously it isn't up to the task.
>
> But it gets worse.  Image "Airspy_10_Spurious_of_88_1_0db" shows an FM broadcast
> signal, fully readable so I could identify it, that doesn't exist.  Image
> "Airspy_11_Spurious_of_88_1_20db" shows the same spectrum with 20 dB of
> attenuation inline. The non-existent station disappears.
>
>
> AIrspy_1_40db.jpg
>
>
> AIrspy_2_20db.jpg
>
>
> Airspy_11_Spurious_of_88_1_20db.jpg
>
>
> Airspy_3_40db.jpg
>
>
> Airspy_4_20db.jpg
>
>
> Airspy_5_20db.jpg
>
>
> Airspy_6_10db.jpg
>
>
> Airspy_7_0db.jpg
>
>
> Airspy_8_10db.jpg
>
>
> Airspy_9_0db.jpg
>
>
> Airspy_10_Spurious_of_88_1_0db.jpg
>





--
Dave - WØLEV
Just Let Darwin Work
Just Think


Re: Transmission lines, Input match and Connectors #bestpractice #experiment

doug
 

On 10/17/2019 07:45 PM, jdow wrote:

/skipped/

Too many years in a very male oriented occupation has left
me a tad abrasive. Please forgive.

{o.o}
You're right. In all my years in that business, I never saw a female engineer. At one place, we took on a young female summer aide who
apparently wanted to be an RF engineer, but that's as close as I ever came to one.
(On the other hand, we had a very competent female software engineer on the projects I worked on at my last place, from which I retired in 2003.
I tried to get her to learn to read schematics, but she wasn't having any.)

--doug, WA2SAY, retired RF engineer


Re: Airspy driver for Raspberry Pi4

Al Holt
 

On Thu, Oct 17, 2019 at 05:30 PM, Martin Smith wrote:
Did you use a branch of gr-osmosdr that supports the Airspy HF+
http://gqrx.dk/supported-hardware#airspyhf

Official support in gr-osmosdr may take a while (ref: http://lists.osmocom.org/pipermail/osmocom-sdr/2019-October/001989.html )
Although you could also use soapy ( https://github.com/pothosware/SoapyAirspyHF ) which is supported with the official gr-osmosdr
Martin,
I thought I replied to your message earlier, but it hasn't shown up. The gist of it was I just installed from the Pi4's "Add/Remove Software" section of  "Preferences" and that version of GQRX did not come with any Airspy support. I got the impression Airspy was supported in all builds, but I guess not.

Thanks for the links, I'll have a look at them. For now GQRX is working with the Airspy and working pretty well.

--Al


Re: Airspy driver for Raspberry Pi4

Al Holt
 

On Thu, Oct 17, 2019 at 05:30 PM, Martin Smith wrote:
Did you use a branch of gr-osmosdr that supports the Airspy HF+
http://gqrx.dk/supported-hardware#airspyhf

Official support in gr-osmosdr may take a while (ref: http://lists.osmocom.org/pipermail/osmocom-sdr/2019-October/001989.html )
Although you could also use soapy ( https://github.com/pothosware/SoapyAirspyHF ) which is supported with the official gr-osmosdr
Martin,
I don't know. I'd have to do some checking. I just went to the "Add Software" section of the Pi4's "Preferences" menu, typed in GQRX and installed it. 

I'll assume it's just part of the Debian Buster repository.

I hope that helps!

--Al


Re: Transmission lines, Input match and Connectors #bestpractice #experiment

jdow
 

Please look at "https://en.wikipedia.org/wiki/Radio_noise". It is a simple discussion. Then explain to me why you insist on NOT using an attenuator at MW as a matter of course? If you had a SMALL antenna like one of those telescoping whips the low noise figure of the HF+ would be really good for you. But with an antenna such as you describe in an environment with a "typical" level of man made noise a 30 dB attenuator would do you no ill and probably a 40 dB attenuator would do you no ill. Look at Wikipiddle er Wikipedia for a perhaps over-simplified discussion of noise figure to see how it works.

Now, knowing the input impedance of the HF+ input may help you optimize a filter to reduce signals in the MW broadcast band when you are working elsewhere. But that would probably be for one tuning setting. The input impedance may vary with the frequency to which HF+ is tuned.

My purpose in trying to drive this home is to help you optimize your time and efforts to best effect. I am trying to boost your game not deride you. Too many years in a very male oriented occupation has left me a tad abrasive. Please forgive.

{o.o}

On 20191017 10:23:46, Wes Stewart via Groups.Io wrote:
On Thu, Oct 17, 2019 at 07:45 AM, prog wrote:
Let's be more pragmatic. What is the real world performance using an antenna?
Thank you for asking.  Let me preface the following by explaining the environment.  The antenna is a 55 foot vertical over ground radials,  For the results that follow, the antenna is connected to the Airspy through a Telonic Industries Model TG-950 stepped attenuator.  Although not a traceable device I have verified its performance with my DG8SAQ VNWA. I have several plots, all taken during the same session, which are screen grabs of the SDR# program.  The model, serial number, firmware and software versions are all obvious.  This unit is as received a few days ago.
I'm not sure I can intersperse comments between the attachments so I will summarize them here.  The image "Airspy_1_40db" is of a local MW station with the inline attenuator set to 40dB.  The image  "Airspy_2_20db" is the same as before except the attenuation has been reduced to 20 dB.  It was pointless to go to 0 dB.  Images "Airspy_3_40dB" and "Airspy_4_20db" are similar but of a different station.
The next set, "Airspy_5_20db", "Airspy_6_10db" and "Airspy_7_0db" show station WWV being received on 10 MHz with 20, 10 and 0 dB attenuation respectively. Note that with 0 dB attenuation, the Airspy is essentially useless.  The next set,  "Airspy_8_10db" and "Airspy_9_0db" show station WWV being received on 15 MHz with 10 and 0 dB attenuation respectively.  Same situation.  Now you might understand my interest in knowing the performance of the input filtering because obviously it isn't up to the task.
But it gets worse.  Image "Airspy_10_Spurious_of_88_1_0db" shows an FM broadcast signal, fully readable so I could identify it, that doesn't exist.  Image "Airspy_11_Spurious_of_88_1_20db" shows the same spectrum with 20 dB of attenuation inline. The non-existent station disappears.
AIrspy_1_40db.jpg
AIrspy_2_20db.jpg
Airspy_11_Spurious_of_88_1_20db.jpg
Airspy_3_40db.jpg
Airspy_4_20db.jpg
Airspy_5_20db.jpg
Airspy_6_10db.jpg
Airspy_7_0db.jpg
Airspy_8_10db.jpg
Airspy_9_0db.jpg
Airspy_10_Spurious_of_88_1_0db.jpg


Re: Transmission lines, Input match and Connectors #bestpractice #experiment

jdow
 

On 20191017 10:34:41, Dana Myers wrote:
On 10/17/2019 9:45 AM, Wes Stewart via Groups.Io wrote:
Of course it's moderated.  It says so every time I post.
I read/post via email, rarely look at the web interface and just learned
that posts are moderated. I've never noticed that; I learned something
today, thanks.
I had that picked up based on some of the delays between hitting send and seeing the post come back from the group. {^_-} I don't mind at all. It keeps it saner in here.

Whatever, they could just identify themselves.
Sure, they could, but how would that change the discussion? Physics
doesn't care who we are :-)
But the dose might be different for differen... OH THAT kind of physics not what my grandmother took when she was, well, you know - too much cheese perhaps?

Youssef has described his goals in the design of the HF+ Discovery,
it's not intended as a well-defined 50-ohm match. If someone needs
that, something like a narrow-band matching network or the trusty
stand-by, a resistor pad, is called for.
That is specifically why I mentioned my experience with that DowKey preamp.

Joanne has "helped out" as she often does :-).
I discovered there is a bit of a teacher in me that has to be let out form time to time.

{^_-}


Re: Transmission lines, Input match and Connectors #bestpractice #experiment

jdow
 

I am NOT a principle or anything else for AirSpy except a user. I am a 3/4 century old retired engineer with a background in both RF (high dynamic range receivers, exotic frequency synthesizers, GPS, and SatCom) and software (device drivers, broadcast live video effects/channel branding, and some GUI work pushing boundaries of MS supplied libraries.) Um, in the '70s I was building fast Hedy Lamar transceivers, various segments of the GPS satellites, and such exotica as a martini olive equivalent for satcom for an unnamed government agency. (The famn dool thing actually came together and worked! I did the RF part of it.) My ham license is about .6 centuries old.

My name is Joanne. I've been cyberstalked (one of the very first) in the 1985-1986 online era. I used to include my ham call letters with my online information. I learned not to. I received repeated VERY graphic threats of rape and dismemberment. I took down all but vague references to where I live (Southern California sort of near KONT). During the episode I learned to use and care for a .38 police special which I ended up illegally carrying while the threats were coming in. (My gun was seconds away while the police were 10 minutes or more away and could admire the dead and dismembered body.) As soon as the threat was over (that in itself is a long story) I stored the gun. It's my reminder of some nasty days, over 365 of them.

If you cannot guess my last name from the ID, well, you need some help with solving simple puzzles, right?

Note that Moonbounce problems' relationship to HF problems is at an exceptionally tenuous generic level.

{o.o} Joanne

On 20191017 07:40:33, Wes Stewart via Groups.Io wrote:
On Wed, Oct 16, 2019 at 10:43 PM, jdow wrote:
Well, for what it is worth I will reiterate what Youssef said. In general the
input match on the receiver does not matter.
In specific, however, there is an issue with filters attached to the input of
the receiver. Their passband shape will be distorted. If this is a problem for
you then put up a little more wire and add an attenuator to the receiver front
end. The attenuation won't matter and the attenuator will make the filter happy.
For what it is worth for most circuit configurations (Leif appears to have
exception) an input match gives you an absolute minimum noise figure of 3 dB.
However, if you mismatch the inputs creatively you can get a noise figure well
below 3 dB. All devices have an input noise current in shunt with the input and
an input noise voltage in series with the input. The optimum match is
(obviously) En/In, which isn't a neat 1:1 SWR at any impedance. You can,
however, do startling things with extreme mismatches so that En or In are
immaterial. You do not get the optimum possible noise figure. But, you do get a
very very good one.
All that said, what matters in the end is the signal to noise power ratio at
the
demodulator. And at HF the single largest source of noise is external to your
system. This is why you can put in a 30 dB attenuator from a 160 meter dipole
and still copy all the weak signals you can find. That is why I declare if
input
match is critical to a filter you have designed, then put in a 10 dB pad to
make
it happy. I learned this the expensive way as a teenager. I was on 15 meters at
the time in about 1960. I was displeased with SNR on received signals. DowKey
made a super low noise preamp. I scraped up the money (never smoking helped me
save the money) and bought it. If anything the results were worse due to
increased IMD. In college some extra-curricular reading led me to an excellent
book, long out of print, on noise figure. And the old Terman
handbook/textbook I
found used filled in the galactic and other noise sources picture for HF
through
2 meters where it becomes nearly negligible. Noise figure cannot be reduced
from
what your antenna presents your radio. It's something about thermodynamics, the
"you can't win" law. It was some years later that I learned about IMD, the
other
slab of bread surrounding the signal sandwich. Gain can help front end noise
mask noise from succeeding stages; gain also puts you closer to overload. (And
the really stinky part of this is that AGC systems may reduce signal level;
but,
most ways you can do it also reduce the large signal handling ability.)
So, Wes, at the risk of being overly blunt, for the most part your excellent
efforts were a misinformed waste of time. Sorry for hammering the so many nails
in this coffin; but, this ex-cathedral pontificating finally got to me.
{^_^} Joanne
Well, let me be blunt and see if my comments get past the moderator.  First, I feel a distinct disadvantage because I don't know who I'm discussing this with. Two of you hide behind screen names but I assume that you are the principals in Airspy.  My name, and amateur callsign, is in the clear and you can look me up on QRZ.com if you wish and get a clue about my capabilities.  Note that I was communicating via moonbounce way back in the 1970s and was building my own equipment.  I know a bit about noise figure, so don't need any lessons.  I also did this stuff professionally but I won't go into that here.
The reason that I chose to measure input matching is because that is the only thing readily accessible to me; I have one coax connector to look at.  If I'm allowed, I can post screenshots of my unit operating in my local environment which would make evident my concern about the performance of the input filtering.


Re: Airspy driver for Raspberry Pi4

Martin Smith
 

Did you use a branch of gr-osmosdr that supports the Airspy HF+
http://gqrx.dk/supported-hardware#airspyhf

Official support in gr-osmosdr may take a while (ref: http://lists.osmocom.org/pipermail/osmocom-sdr/2019-October/001989.html )
Although you could also use soapy ( https://github.com/pothosware/SoapyAirspyHF ) which is supported with the official gr-osmosdr


Marcus D. Leech
 

On 10/17/2019 10:58 AM, iz5dkm@... wrote:
Yes, the visible signal is certainly generated by interstellar material belonging to our galaxy.
_._,_._,_


The aggregate M31 signature is at a redshift of roughly -500km/sec, or centered at about 1422.77MHz -- which is off your chart.



Airspy driver for Raspberry Pi4

Al Holt
 

Hello from a new member to the group, owner of an Airspy HF+ Discovery, and slightly experienced Linux user.

I like using GQRX SDR radio software on Linux, but after installing in from the repository I did not get the option to use an Airspy radio.

Is there a preferred method of installing Airspy drivers on a Raspberry Pi4? I've been able to get the Pi4 running GQRX with the HF+ by following this method by G4WNC, Mike Richards: 
https://photobyte.org/running-spyserver-raspberry-pi-3/ 
  1. Open a terminal session and enter: cd /home/pi
  2. Enter: wget https://github.com/airspy/airspyhf/archive/master.zip
  3. Now unzip the archive by entering: unzip master.zip
  4. Change to the new directory: cd airspyhf-master
  5. Make a new directory for the build: mkdir build
  6. Change to the new directory: cd build
  7. Make the driver with: cmake ../ -DINSTALL_UDEV_RULES=ON
  8. Complete the make with: make
  9. Move the installed files to the correct destination: sudo make install
  10. Rebuild the search path so the driver can be found: sudo ldconfig


What I've seen on the Airspy website seems to relate more to SpyServer operations.

Also, this webpage is very helpful installing other ham radio related programs:
https://dl1gkk.com/setup-raspberry-pi-for-ham-radio/
 
Thanks!

--Al
WD4AH


 


Re: New SDR# release r1729 with High DPI support #software #announcements

michaeld
 

 Looks very nice, thanks for your efforts.  Like the skins. 

On Thu, Oct 17, 2019 at 12:08 prog <info@...> wrote:

[Edited Message Follows]

This update has been pending for quite some time. Now the application can detect and adapt to the DPI of the attached monitor with support for High DPI.
A few other tweaks for the RAW mode when streaming digital data.
Note that this will require .NET 4.8 to work, but the application can still run just as before with .NET 4.6.
The downloads are available as usual at: https://airspy.com/download

Enjoy!

9741 - 9760 of 42180