Date   

Re: New SDR# Release v1756 (2991c02) to follow Telerik Update #announcements

Magpie
 

Good morning. Can we consider v1756 as a final version for now or will newer versions appear soon?
--
Regards, Henk in NL
2 x Airspy R2, v1732


Re: Exact tuning calculations

David J Taylor
 

From: jdow

Look up the documentation for CuteSDR. Moe Wheatley did a good design document for it. It uses float or double. The results for float with regards to DSP performance rather than code performance suggest that unless double somehow magically saves you appreciable CPU resource float is just fine. I compute the VFO using double. Everything else is using float. I know float uses less CPU. And all other performance with float is more than good enough for everybody who is not AudioFeelie crazed. (No, gold plated wall sockets and plugs do not reduce noise and distortion in amplifiers.)

{^_^}
===================================

Do you have a link for that - I'd be interested.

Agreed that normal float should be fine for signal processing, but in algorithms requiring differences of large numbers you may need to be more careful (and perhaps choose a different algorithm!). In addition to the higher CPU of double, there's the extra memory fetch and save times.

Orbit calculations benefit from double - some of the numbers are to quite high powers - especially for planetary. Likely you know more about that than me. GPS - 1m accuracy from 20,000 km away?

73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


Re: Exact tuning calculations

David J Taylor
 

On a general-purpose CPU, especially with an FPU, sure. Frequency calculations
lend themselves well to fixed-point because they have well-defined/limited range
determined by the hardware at hand.

Dana K6JQ
==================================

I should note that I'm using exclusively x86 code, not embedded processors, so my view will be a little different. Quite a few have been caught out with 32-bit, though. "It doesn't work above 2 GHz...."

73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


Re: Help me debug my spyverter

jdow
 

Oh - shift - is the Shift tickbox checked?

{^_^}

On 20200926 19:06:17, Lyndxer wrote:
I'm wondering if there's any connection between my earlier problem of the Spyverter's being way off (30Khz) in calibration? 


Re: Help me debug my spyverter

jdow
 

That suggests a damaged connector. Look at the inner contacts to see that the male appendage end goes straight into the female socket part of the connector. A telltale hole beside the inner socket suggests a broken connector. You may also have a broken cable, either the interconnect to the R2 or from the antenna. If that antenna wire also receives on FM broadcast on bare R2 that would leave the interconnect. Do you have the 120 MHz birdie on hte Biast-T? If so it's not that either. (When I purchase gadgets like that interconnect cable I get three or more on the grounds that they are meant to be the expendable parts between two boxes.)

It could also be the Spyverter setting in SDRSharp is not turned on. (If you kept context I could see if you'd already addressed that.)

{^_^}

On 20200926 18:56:49, Lyndxer wrote:
I've connected/disconnected a few times, but am careful to connect in the correct direction.

Yes, I do see a massive birdy on 120Hhz.

The R2 is working well by itself.


Re: Help me debug my spyverter

Lyndxer
 

I'm wondering if there's any connection between my earlier problem of the Spyverter's being way off (30Khz) in calibration? 


Re: Help me debug my spyverter

Lyndxer
 

I've connected/disconnected a few times, but am careful to connect in the correct direction.

Yes, I do see a massive birdy on 120Hhz.

The R2 is working well by itself.


Re: Help me debug my spyverter

Lyndxer
 

Dave,

My Spyverter.does not have any indicator LEDs.


Re: Help me debug my spyverter

jdow
 

Do you connect and disconnect frequently? Backwards probably will not work.
If you tune to 120 MHz do you see a massive birdy from the Spyverter LO?
You have tested that the R2 itself is working? Simple testing on FM can show this.

{^_^}

On 20200926 12:46:35, Lyndxer wrote:
My Spyverter installation has suddenly become deaf. Here's what I did so far:
 1.Checked the connection between the Airpsy R2 and the Spyverter. (The Airspy runs fine on its own.)
 2. Opened the Spyverter to confirm that the connectors were not detached from the board.
 3. Checked the settings in SDR# 1732.. Checking or unchecking the Bias T box did not make a difference.
 4. Changed from the linear gain setting to the free gain and tried various combinations of settings.
 5. Connected the Bias T directly from the Spyverter to a USB port on my computer (Dell Inspiron 5000) via the micro USB port - no change 
 6. Connected Bias T directly to a wall wart. No change.
 7. Checked reception on my Funcube Pro+ with the same antenna I had connected to the Spyverter and there were plenty of signals on the AM and SW bands.
 
What did I miss?   What else can I check?


Re: Exact tuning calculations

jdow
 

On 20200926 11:02:16, David J Taylor via groups.io wrote:
From: Phil Karn

Same here. I do use single-precision FP for signal processing, for which
it's great. Most vector math instructions seem optimized for single
precision. They do double much slower if they do it all. But it's not
good enough when your operations tend to accumulate errors. The classic
example is a complex sinusoid generator where you're repeatedly
multiplying the phasor by a phase increment. Even with double precision,
repeatedly multiplying unit vectors will cause the amplitude to slowly
drift away from unity. I deal with this by renormalizing every N cycles,
where N can be in the tens of thousands for double precision. This
amortizes the expensive square root operation over many cycles. You can
still use single precision FP but you have to renormalize much more
often, and the quantization noise will be larger.

Phil
=================================

Fortunately the stuff is audio frequency, so speed isn't critical, although on today's PCs I didn't think that double precision was that slow.  Perhaps you or Joanne have some measurements.

For sine wave I build up a table first (perhaps with 32k samples) and simply use an increment to the angle vector each time.  Perhaps that's another reason I'm not fussed about speed!  A simple tone generator good enough for 1 Hz precision (depending on the audio card drivers, sigh!).

 https://www.satsignal.eu/software/audio.html#SweepGen

Cheers,
David

Look up the documentation for CuteSDR. Moe Wheatley did a good design document for it. It uses float or double. The results for float with regards to DSP performance rather than code performance suggest that unless double somehow magically saves you appreciable CPU resource float is just fine. I compute the VFO using double. Everything else is using float. I know float uses less CPU. And all other performance with float is more than good enough for everybody who is not AudioFeelie crazed. (No, gold plated wall sockets and plugs do not reduce noise and distortion in amplifiers.)

{^_^}

{^_^}


Re: External frequency reference for Airspy R2?

Martin Smith
 

On Sat, Sep 26, 2020 at 09:00 PM, Shirley Dulcey KE1L wrote:
Obligatory Airspy-related content: many current standards are based on OFDM,
including LTE data. You can see what it looks like with your Airspy R2 or
Mini. (An RTL-SDR dongle will also work. An Airspy HF+ will not because it
does not receive any cellular bands.) Tune to any LTE cellular band within its
tuning range; your spectrum display will show you what looks like broadband
noise, but with small evenly spaced peaks. The peaks are at the carrier
frequencies of the OFDM signal.
Not fully true, the Airspy HF+ can (currently/unofficially) receive part of the L-Band (1.2 GHz to 1.67 GHz). Both Japan and Italy use the 1500MHz band for LTE. So it is possible, just in a very limited number of locations to see LTE transmissions with a HF+.


Re: Exact tuning calculations

jdow
 

On 20200926 10:34:17, Phil Karn wrote:
On 9/26/20 07:31, David J Taylor via groups.io wrote:

I use double-precision floating point, both for orbit calculations and
frequencies.

David
GM8ARV
Same here. I do use single-precision FP for signal processing, for which
it's great. Most vector math instructions seem optimized for single
precision. They do double much slower if they do it all. But it's not
good enough when your operations tend to accumulate errors. The classic
example is a complex sinusoid generator where you're repeatedly
multiplying the phasor by a phase increment. Even with double precision,
repeatedly multiplying unit vectors will cause the amplitude to slowly
drift away from unity. I deal with this by renormalizing every N cycles,
where N can be in the tens of thousands for double precision. This
amortizes the expensive square root operation over many cycles. You can
still use single precision FP but you have to renormalize much more
often, and the quantization noise will be larger.

Phil

Have you seen "A New Recursive Quadrature Oscillator" by Martin Vicanek? This seems to be more stable than most. It is also simple and quick.

{^_^}


Re: Help me debug my spyverter

David Eckhardt
 

Do any of the indicator LED's on the SpyVerter illuminate when connected to the AirSpy with the Bias Tee turned ON?  These LED's should turn on and off based on the bias tee setting.

Dave - WØLEV

I have the older Ham-it-Up up-converter.




On Sat, Sep 26, 2020 at 9:28 PM Lyndxer <zekesgm@...> wrote:
My Spyverter installation has suddenly become deaf. Here's what I did so far:
 1.Checked the connection between the Airpsy R2 and the Spyverter. (The Airspy runs fine on its own.)
 2. Opened the Spyverter to confirm that the connectors were not detached from the board.
 3. Checked the settings in SDR# 1732.. Checking or unchecking the Bias T box did not make a difference.
 4. Changed from the linear gain setting to the free gain and tried various combinations of settings.
 5. Connected the Bias T directly from the Spyverter to a USB port on my computer (Dell Inspiron 5000) via the micro USB port - no change 
 6. Connected Bias T directly to a wall wart. No change.
 7. Checked reception on my Funcube Pro+ with the same antenna I had connected to the Spyverter and there were plenty of signals on the AM and SW bands.
 
What did I miss?   What else can I check?



--
Dave - WØLEV
Just Let Darwin Work


Help me debug my spyverter

Lyndxer
 

My Spyverter installation has suddenly become deaf. Here's what I did so far:
 1.Checked the connection between the Airpsy R2 and the Spyverter. (The Airspy runs fine on its own.)
 2. Opened the Spyverter to confirm that the connectors were not detached from the board.
 3. Checked the settings in SDR# 1732.. Checking or unchecking the Bias T box did not make a difference.
 4. Changed from the linear gain setting to the free gain and tried various combinations of settings.
 5. Connected the Bias T directly from the Spyverter to a USB port on my computer (Dell Inspiron 5000) via the micro USB port - no change 
 6. Connected Bias T directly to a wall wart. No change.
 7. Checked reception on my Funcube Pro+ with the same antenna I had connected to the Spyverter and there were plenty of signals on the AM and SW bands.
 
What did I miss?   What else can I check?


Re: SDR# I/Q Output

Max Mucci, N5NHJ (I8NHJ)
 

Hello Martin,
I have fixed the 96K audio sample rate modifying the config file.
Unfortunately it looks like the same fix doesn't work for the bandwidth which, no matter what I do, can't be set up higher than 32K.
----------------------
73 de Max, N5NHJ (I8NHJ)

Thursday, September 24, 2020, 5:30:59 PM, you wrote:

Oops, sorry you said 32kHz, that would not be what I suggested
(well it might be needed as well), this is a different problem:
For Modulation Raw, under Radio->Bandwidth the maximum allowed setting within SDR# is 32,000
I do not know any way to get that bandwidth higher within SDR#, I
only know that I used to be able to get it higher by manually modifying SDRSharp.exe.config
I also have no idea how the new slices might change things, but
traditionally I would have quit SDR# and modified the line in my
SDRSharp.exe.config from something like:
<add key="rawState" value="32000,1000,3,50,0,1000,1,4,0,1,0,0" />
To be something like this:
<add key="rawState" value="192000,1000,3,50,0,1000,1,4,0,1,0,0" />


Re: Exact tuning calculations

Marcus D. Leech
 

On 09/26/2020 04:27 PM, Phil Karn wrote:

Do you need to cover the whole frequency range between these two? I
thought radio astronomy mainly looks at a few narrow bands. So use a
downconverter and an HF direct sampling receiver. You reintroduce the
usual problems of superhets, mainly susceptibility to images. But if
you're only trying to cover a few specific frequency bands, that should
be easier than trying to build a broadband receiver.

Phil

It very much depends on what one is doing.

Some observing modes are "spectral". Some could usefully use as much bandwidth as you can throw at them, since sensitivity
is proportional (all else being equal) to sqrt(Tau * Bw), where Tau == integration time, and Bw == bandwidth.

Granted for my *own* observing, a few MHz at a time is usually sufficient.

The professional observatories think nothing of sampling 500MHz or 1GHz at a time and then using RFI-excision on the sub-bands that
are garbage.

Consider CHIME--they observe the entirety of the 400MHz to 800MHz band at once. They are using direct sampling--sampling in the second
Nyquist zone using an 800Msps sampler--two per antenna and they have 1024 antennae. I got to put my hands on one of their prototype
boards when they were doing testing for pulsar/FRB work at Algonquin Radio Observatory about 5 years ago. Sexy stuff. Not within reach
of this struggling science geek, though...


Re: Exact tuning calculations

Phil Karn
 

On 9/26/20 13:14, Marcus D. Leech wrote:
On 09/26/2020 04:08 PM, Phil Karn wrote:

Sounds like these algorithms simply aren't smart enough. Since they have
to be done somewhere, would there be a problem if these were
maximum-likelihood algorithms matched to the actual a priori behavior of
the device?

Maybe you need direct sampling.

Phil
Direct sampling at between 400MHz and 1.4GHz isn't exactly cheap...
Do you need to cover the whole frequency range between these two? I
thought radio astronomy mainly looks at a few narrow bands. So use a
downconverter and an HF direct sampling receiver. You reintroduce the
usual problems of superhets, mainly susceptibility to images. But if
you're only trying to cover a few specific frequency bands, that should
be easier than trying to build a broadband receiver.

Phil


Re: Exact tuning calculations

Marcus D. Leech
 

On 09/26/2020 04:08 PM, Phil Karn wrote:

Sounds like these algorithms simply aren't smart enough. Since they have
to be done somewhere, would there be a problem if these were
maximum-likelihood algorithms matched to the actual a priori behavior of
the device?

Maybe you need direct sampling.

Phil
Direct sampling at between 400MHz and 1.4GHz isn't exactly cheap...


Re: Exact tuning calculations

Phil Karn
 

On 9/24/20 17:54, Marcus D. Leech wrote:
Then there are architectures like LimeSDR and some of the USRPs that use
  an integrated RFFE (RF Front End) chip that takes care of things like
  DC-offset removal and I/Q balance correction before you ever see
  the samples. Chips like the AD9361 have *most* of an SDR packed
  inside them--synthesizers, quadrature mixers, ADC, DSP logic, etc.
As long as they do it correctly...

One of the issues with automatic (and free-running) I/Q correction is
that it can play havoc
  when you're doing interferometry, because the underlying DSP "goop"
is constantly
  trying to make corrections independently to each "side" of the
interferometer--depending
  on the time-scale of the corrections, that either leads to
artificially-increased mutual
  phase noise, or even "fringes that aren't there".
Sounds like these algorithms simply aren't smart enough. Since they have
to be done somewhere, would there be a problem if these were
maximum-likelihood algorithms matched to the actual a priori behavior of
the device?

Maybe you need direct sampling.

Phil


Re: External frequency reference for Airspy R2?

Shirley Dulcey KE1L
 

More on that ATSC 3 thing:

LA is one of the markets that is supposed to have at least one ATSC 3.0 test station on the air by the end of the year. (So is Boston, and I'm also waiting for my new HD HomeRun.) If your city has no available TV channels, the broadcasters may be repacking to make one available for that test station.

If ATSC 3.0 succeeds, the plan is to gradually transition. ATSC 1.0 broadcasts are not supposed to disappear completely until most of the viewers have ATSC 3.0 receivers, but the quality of available ATSC 1.0 signals will gradually degrade. They will get crammed onto fewer transmitters as stations transition to the new standard, requiring them to be encoded at lower bit rates and/or reduced resolution. The end point may be one transmitter in each city that carries a horrible-looking version of every station in the market to fulfill the requirement that ATSC 1.0 remain available.

The appeal of upgrading is that ATSC 3.0 will have about ten times the capacity of current ATSC 1.0 broadcasts. It uses H.265 encoding, which requires only about 25% as many bits for the same level of visual quality as the MPEG-2 encoding used in ATSC 1.0. The total bit rate is variable (there are tradeoffs between capacity and robustness of reception); the maximum is 54 Mbps, but my guess is that the sweet spot for most broadcasters will be in the 40-45 Mbps range. ATSC 1.0 carries 18 Mbps.

So far only a handful of TV sets have ATSC 3.0 tuners built in, all from Korea because that country is adopting ATSC 3.0. I know that 2019 and 2020 OLED TVs from LG do, and I believe some high end Samsung models do as well. A lot of viewers are going to need set-top boxes; my guess is that will mostly come in the form of combined tuner/streaming boxes, like a future generation of Roku, Fire TV, etc. There may also be additional companies that introduce network tuners similar to the HD HomeRun.

I agree that the FCC should have backed down on 8VSB back in 2000 or thereabouts. Some broadcasters would have lost money on equipment, but the number of receivers in the hands of consumers was tiny so it would not have been an issue. (The government could have simply bought out the hundreds of owners if necessary.) The adoption of 8VSB was driven by it being a good solution to the wrong problem. 8VSB was somewhat more power-efficient (you needed less signal to receive it; I don't know whether that is still true with 2020 technology), so it meant that reception was possible in some fringe areas that would have not been able to receive an OFDM signal. But the number of affected users would have been tiny, and was far outweighed by the number of people who lost reception because of the terrible performance of 8VSB in the face of multipath.

Whatever happened to ATSC 2, you ask? It never made it to market and was dropped in favor of the ATSC 3.0 standard that was under development.

Obligatory Airspy-related content: many current standards are based on OFDM, including LTE data. You can see what it looks like with your Airspy R2 or Mini. (An RTL-SDR dongle will also work. An Airspy HF+ will not because it does not receive any cellular bands.) Tune to any LTE cellular band within its tuning range; your spectrum display will show you what looks like broadband noise, but with small evenly spaced peaks. The peaks are at the carrier frequencies of the OFDM signal.

Obligatory legal note: reception of cellular signals is illegal in the US. That rule is meant to cover LISTENING to them, as it was written back in the days of analog voice. Although looking at the shape of the spectrum with an Airspy may or may not be technically illegal, it does not violate the intent of the law in any meaningful way.

On Sat, Sep 26, 2020 at 3:12 PM Chris Spacone <cspacone@...> wrote:
The FCC's choice of ATSC and 8-VSB over COFDM has been controversial and remains so, though of course it's far too late to change.
Phil,

ATSC 3.0 is rolling out. It is COFDM, better late than never I suppose.

There is no 'mandate' to shift to ATSC 3.0 so the 'marketplace' will determine if it is successful or not. While at Fox, then Disney, I participated the Digital Program Insertion (DPI) group of the SCTE,  the coming 3.0 standard has much to offer in that respect and many others.

Getting to 3.0 will be no small task. The current thinking and approach is to use a "lighthouse" station to accommodate several 1.0 stations programs as part of a single mux. PSIP information keeps the 'virtual channel' and enables branding while the tuner is simply told to find the mux on frequency f. Once the 3.0 station is built out they would go live and maintain the 1.0 presence on the 'lighthouse' for some period of time.

Asd I recall from my early days in the DTV transition the technical people at Sinclair were lobbying very hard for COFDM but got drowned out by the folks from the 'Grand Alliance'.

IMHO the Commission really screwed the pooch mandating 8VSB vs. COFDM.

https://en.wikipedia.org/wiki/ATSC_3.0

I'm waiting for my HD Homerun sporting ATSC 3.0 to arrive from Silicondust any week now. I can't find any direct references to 3.0 being deployed *right now* here in LA but I have noted, using my copy of TSReader Pro to examine the transport streams of several stations that some are engaging in a program shuffle.

Interesting times ahead for the broadcast TV industry.

-Chris