Topics

Can't tune very far #sdrsharp #spyserver

jim.white@...
 

We have a remote Pi 4 set up running spyserver with an airspy. Running SDR# on a Win10 PC.

But I'm missing something on how to tune it.

It generally works nicely. Spyserver is set up with an initial frequency of 158.88 MHz.  But we can't tune it beyond about 153Mhz on the low side and 160Mhz on the high side.  We seem to be missing something fundamental on how bandwidth and tuning work.  How do we move it down to say 127 MHz?

Thanks in advance.

jim.white@...

jdow
 

Play with the numbers above the spectrum and the button to the right of the numbers. With enough playing you can see what is going on.

{^_^}

On 20200212 08:46:44, jim.white@... wrote:
We have a remote Pi 4 set up running spyserver with an airspy. Running SDR# on a Win10 PC.
But I'm missing something on how to tune it.
It generally works nicely. Spyserver is set up with an initial frequency of 158.88 MHz.  But we can't tune it beyond about 153Mhz on the low side and 160Mhz on the high side.  We seem to be missing something fundamental on how bandwidth and tuning work.  How do we move it down to say 127 MHz?
Thanks in advance.
jim.white@...

Martin Smith
 

If only one client is connected they can by default re-tune the device anywhere that the device can be tuned, unless restricted by the configuration on the spyserver.
If two or more clients are connected at the same time, the frequency is locked to whatever was the last frequency selected by the first client to connect. And then no client, including the first to connect, is able to re-tune the frequency. Until the number of connected clients to the spyserver drops to only one, then that client is able to re-tune the frequency.

So my guess is that either someone else on the Internet is connected at the same time as you are, or you have two clients connected at the same time.

I'm assuming that the following were unchanged in your spyserver.config:
# Allow clients to retune and change of gain of the device
#
allow_control = 1

And that you only changed one line, and left the other lines below at their default (commented out).
# Initial Center Frequency
#
#initial_frequency = 7100000
initial_frequency = 158880000

# Minimum Tunable Frequency
# Comment if using the device default
#
#minimum_frequency = 0

# Maximum Tunable Frequency
# Comment if using the device default
#
#maximum_frequency = 35000000

Or you could just leave the number of clients that can connect remotely at its default:
# User sessions
#
maximum_clients = 1

Jim White
 

Martin,

Thanks very much for the detailed reply.

I had set the maximum_clients to 3 when I put this in.  I changed it back to 1 to eliminate that as a possible issue but the problem persists.  Below is a list of the parms in the .config file. I entered the max and min frequencies for the AirSpy and that made the behavior a bit different but now a bit more broken as well.  The behavior is hard to describe because it seems inconsistent.  With the parms below this is what I see:

- On connect the gain is 5 but cannot be changed, the frequency cannot be changed by scrolling the spectrum display, the <> control does not change when clicked.  Clicking on a signal in the spectrum display demodulates that signal OK.  Clicking the digits of the frequency display allows tuning only over the range on the spectrum display.

- If I change the bandwidth to 500 Khz I can then change the frequency display down below 154 and above 164 (up to 776 for example) but the frequency is not actually changing.  The spectrum display remained in the 154 to 162 range and clicking on a signal there demodulated it.

Jim

Spyserver.config

maximum_clients = 1

allow_control = 1

device_type = AirspyOne

device_serial = 0

device_sample_rate = 10000000

maximum_bandwidth = 200000

fft_fps = 14

fft_bin_bits = 16

initial_frquency = 158880000

minimum_frequency = 24000000

maximum_frequency = 17500000

initial_gain = 5

buffer_size_ms = 50

buffer_count - 10

On 2/14/2020 2:21 AM, Martin Smith via Groups.Io wrote:
If only one client is connected they can by default re-tune the device anywhere that the device can be tuned, unless restricted by the configuration on the spyserver.
If two or more clients are connected at the same time, the frequency is locked to whatever was the last frequency selected by the first client to connect. And then no client, including the first to connect, is able to re-tune the frequency. Until the number of connected clients to the spyserver drops to only one, then that client is able to re-tune the frequency.

So my guess is that either someone else on the Internet is connected at the same time as you are, or you have two clients connected at the same time.

I'm assuming that the following were unchanged in your spyserver.config:
  # Allow clients to retune and change of gain of the device
  #
  allow_control = 1

And that you only changed one line, and left the other lines below at their default (commented out).
  # Initial Center Frequency
  #
  #initial_frequency = 7100000
initial_frequency = 158880000

  # Minimum Tunable Frequency
  # Comment if using the device default
  #
  #minimum_frequency = 0

  # Maximum Tunable Frequency
  # Comment if using the device default
  #
  #maximum_frequency = 35000000

Or you could just leave the number of clients that can connect remotely at its default:
# User sessions
#
maximum_clients = 1



Joe M.
 

"maximum_frequency = 17500000"?????

That's less than your maximum. Are you missing a zero?

Joe M.

On 2/14/2020 6:52 PM, Jim White wrote:
Martin,

Thanks very much for the detailed reply.

I had set the maximum_clients to 3 when I put this in. I changed it
back to 1 to eliminate that as a possible issue but the problem
persists. Below is a list of the parms in the .config file. I entered
the max and min frequencies for the AirSpy and that made the behavior a
bit different but now a bit more broken as well. The behavior is hard to
describe because it seems inconsistent. With the parms below this is
what I see:

- On connect the gain is 5 but cannot be changed, the frequency cannot
be changed by scrolling the spectrum display, the <> control does not
change when clicked. Clicking on a signal in the spectrum display
demodulates that signal OK. Clicking the digits of the frequency
display allows tuning only over the range on the spectrum display.

- If I change the bandwidth to 500 Khz I can then change the frequency
display down below 154 and above 164 (up to 776 for example) but the
frequency is not actually changing. The spectrum display remained in
the 154 to 162 range and clicking on a signal there demodulated it.

Jim

Spyserver.config

maximum_clients = 1

allow_control = 1

device_type = AirspyOne

device_serial = 0

device_sample_rate = 10000000

maximum_bandwidth = 200000

fft_fps = 14

fft_bin_bits = 16

initial_frquency = 158880000

minimum_frequency = 24000000

maximum_frequency = 17500000

initial_gain = 5

buffer_size_ms = 50

buffer_count - 10

On 2/14/2020 2:21 AM, Martin Smith via Groups.Io wrote:
If only one client is connected they can by default re-tune the device anywhere that the device can be tuned, unless restricted by the configuration on the spyserver.
If two or more clients are connected at the same time, the frequency is locked to whatever was the last frequency selected by the first client to connect. And then no client, including the first to connect, is able to re-tune the frequency. Until the number of connected clients to the spyserver drops to only one, then that client is able to re-tune the frequency.

So my guess is that either someone else on the Internet is connected at the same time as you are, or you have two clients connected at the same time.

I'm assuming that the following were unchanged in your spyserver.config:
# Allow clients to retune and change of gain of the device
#
allow_control = 1

And that you only changed one line, and left the other lines below at their default (commented out).
# Initial Center Frequency
#
#initial_frequency = 7100000
initial_frequency = 158880000

# Minimum Tunable Frequency
# Comment if using the device default
#
#minimum_frequency = 0

# Maximum Tunable Frequency
# Comment if using the device default
#
#maximum_frequency = 35000000

Or you could just leave the number of clients that can connect remotely at its default:
# User sessions
#
maximum_clients = 1


<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virus-free. www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>


<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Joe M.
 

Correction: Are you missing two zeroes?

maximum_frequency = 1750000000

Joe M.

On 2/14/2020 7:10 PM, Joe M. wrote:
"maximum_frequency = 17500000"?????

That's less than your maximum. Are you missing a zero?

Joe M.

On 2/14/2020 6:52 PM, Jim White wrote:
Martin,

Thanks very much for the detailed reply.

I had set the maximum_clients to 3 when I put this in. I changed it
back to 1 to eliminate that as a possible issue but the problem
persists. Below is a list of the parms in the .config file. I entered
the max and min frequencies for the AirSpy and that made the behavior a
bit different but now a bit more broken as well. The behavior is hard to
describe because it seems inconsistent. With the parms below this is
what I see:

- On connect the gain is 5 but cannot be changed, the frequency cannot
be changed by scrolling the spectrum display, the <> control does not
change when clicked. Clicking on a signal in the spectrum display
demodulates that signal OK. Clicking the digits of the frequency
display allows tuning only over the range on the spectrum display.

- If I change the bandwidth to 500 Khz I can then change the frequency
display down below 154 and above 164 (up to 776 for example) but the
frequency is not actually changing. The spectrum display remained in
the 154 to 162 range and clicking on a signal there demodulated it.

Jim

Spyserver.config

maximum_clients = 1

allow_control = 1

device_type = AirspyOne

device_serial = 0

device_sample_rate = 10000000

maximum_bandwidth = 200000

fft_fps = 14

fft_bin_bits = 16

initial_frquency = 158880000

minimum_frequency = 24000000

maximum_frequency = 17500000

initial_gain = 5

buffer_size_ms = 50

buffer_count - 10

On 2/14/2020 2:21 AM, Martin Smith via Groups.Io wrote:
If only one client is connected they can by default re-tune the
device anywhere that the device can be tuned, unless restricted by
the configuration on the spyserver.
If two or more clients are connected at the same time, the frequency
is locked to whatever was the last frequency selected by the first
client to connect. And then no client, including the first to
connect, is able to re-tune the frequency. Until the number of
connected clients to the spyserver drops to only one, then that
client is able to re-tune the frequency.

So my guess is that either someone else on the Internet is connected
at the same time as you are, or you have two clients connected at the
same time.

I'm assuming that the following were unchanged in your spyserver.config:
# Allow clients to retune and change of gain of the device
#
allow_control = 1

And that you only changed one line, and left the other lines below at
their default (commented out).
# Initial Center Frequency
#
#initial_frequency = 7100000
initial_frequency = 158880000

# Minimum Tunable Frequency
# Comment if using the device default
#
#minimum_frequency = 0

# Maximum Tunable Frequency
# Comment if using the device default
#
#maximum_frequency = 35000000

Or you could just leave the number of clients that can connect
remotely at its default:
# User sessions
#
maximum_clients = 1


<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

Virus-free. www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Jim White
 

Yes. That's a typo from when I copied the info from spyserver.config. The correct number in that file is

1750000000

Jim

On 2/14/2020 5:32 PM, Joe M. wrote:
Correction: Are you missing two zeroes?

maximum_frequency = 1750000000

Joe M.

On 2/14/2020 7:10 PM, Joe M. wrote:
"maximum_frequency = 17500000"?????

That's less than your maximum. Are you missing a zero?

Joe M.

On 2/14/2020 6:52 PM, Jim White wrote:
Martin,

Thanks very much for the detailed reply.

I had set the maximum_clients to 3 when I put this in.  I changed it
back to 1 to eliminate that as a possible issue but the problem
persists.  Below is a list of the parms in the .config file. I entered
the max and min frequencies for the AirSpy and that made the behavior a
bit different but now a bit more broken as well. The behavior is hard to
describe because it seems inconsistent. With the parms below this is
what I see:

- On connect the gain is 5 but cannot be changed, the frequency cannot
be changed by scrolling the spectrum display, the <> control does not
change when clicked.  Clicking on a signal in the spectrum display
demodulates that signal OK.  Clicking the digits of the frequency
display allows tuning only over the range on the spectrum display.

- If I change the bandwidth to 500 Khz I can then change the frequency
display down below 154 and above 164 (up to 776 for example) but the
frequency is not actually changing.  The spectrum display remained in
the 154 to 162 range and clicking on a signal there demodulated it.

Jim

Spyserver.config

maximum_clients = 1

allow_control = 1

device_type = AirspyOne

device_serial = 0

device_sample_rate = 10000000

maximum_bandwidth = 200000

fft_fps = 14

fft_bin_bits = 16

initial_frquency = 158880000

minimum_frequency = 24000000

maximum_frequency = 17500000

initial_gain = 5

buffer_size_ms = 50

buffer_count - 10

On 2/14/2020 2:21 AM, Martin Smith via Groups.Io wrote:
If only one client is connected they can by default re-tune the
device anywhere that the device can be tuned, unless restricted by
the configuration on the spyserver.
If two or more clients are connected at the same time, the frequency
is locked to whatever was the last frequency selected by the first
client to connect. And then no client, including the first to
connect, is able to re-tune the frequency. Until the number of
connected clients to the spyserver drops to only one, then that
client is able to re-tune the frequency.

So my guess is that either someone else on the Internet is connected
at the same time as you are, or you have two clients connected at the
same time.

I'm assuming that the following were unchanged in your spyserver.config:
   # Allow clients to retune and change of gain of the device
   #
   allow_control = 1

And that you only changed one line, and left the other lines below at
their default (commented out).
   # Initial Center Frequency
   #
   #initial_frequency = 7100000
initial_frequency = 158880000

   # Minimum Tunable Frequency
   # Comment if using the device default
   #
   #minimum_frequency = 0

   # Maximum Tunable Frequency
   # Comment if using the device default
   #
   #maximum_frequency = 35000000

Or you could just leave the number of clients that can connect
remotely at its default:
# User sessions
#
maximum_clients = 1


<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

    Virus-free. www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


Martin Smith
 

And "buffer_count - 10" is a typo as well ?

I'd be inclined to backup your existing configuration file and try with the default configuration file that comes with the download and see if that works (which it should, otherwise lots of people would be reporting problems).

Then I would add, and test, one line at a time from the "backup configuration file" by adding it to the working configuration file (commenting out the working line) to find which line is the "backup configuration" is causing your problem.
It could be a typo. I'm in the habit of copying lines before I modify them , and then commenting them out so that I can easily spot simple mistakes.

Jim White
 

This problem turned out to be with the port forwarding in the remote router.  I brought the Pi/SDR back to the shop and it works fine on the local LAN.  No issues with the .config file.

When at the remote location the router port forward for :5555 to the address of the Pi/SDR there had to be working, somewhat, because we saw and heard signals.  But commands from SDR# were apparently not getting through the router to the Pi because we could not tune beyond the initial frequency plus/minus the bandwidth.

What I'm reading is that I only need to forward 5555 to the IP address of the Pi port 5555, nothing else.  Is that correct?

On 2/15/2020 1:58 AM, Martin Smith via Groups.Io wrote:
And "buffer_count - 10" is a typo as well ?

I'd be inclined to backup your existing configuration file and try with the default configuration file that comes with the download and see if that works (which it should, otherwise lots of people would be reporting problems).

Then I would add, and test, one line at a time from the "backup configuration file" by adding it to the working configuration file (commenting out the working line) to find which line is the "backup configuration" is causing your problem.
It could be a typo. I'm in the habit of copying lines before I modify them , and then commenting them out so that I can easily spot simple mistakes.

Martin Smith
 

Maybe find out for yourself what is being blocked by your configuration:

If you are using Windows install npcap and Wireshark.

And if you are using UNIX just use tcpdump, and/or Wireshark. But with the right filter arguments (host/port/src/dst) in a tcpdump command line you do not need to use Wireshark most of the time. At least for basic network troubleshooting.


Do a packet capture of everything white it is working, a second packet capture when it is not working and then compare the two.

The issue in trying to diagnose a networking problem, is that every single hop that handles your traffic between the two machines has the potential to be the problem. Do a traceroute or a tcptraceroute (with a port number) between the two machines, it may help to highlight the issue.

I'm going to use some fake details as an example of what you should expect to see for the first four IP packets:
PC IP address: 1.2.3.4 (a made up IP address)
PC TCP port: 23456 (a random port number <65k, different each time a new socket is created)
spyserver IP address : 6.5.4.3 (a made up IP address)
spyserver TCP port: 5555 (fixed port number, may not be 5555)


The client initiates a normal TCP/IP three-way handshake to create a socket:

A SYN packet is sent from the PC to the machine that has the spyserver running bound to an explicit port number:
IP: Source IP: 1.2.3.4 Destination IP: 6.5.4.3
TCP: Source port: 23456 Destination port: 5555
Flags: SYN

A SYN+ACK packet is sent back from the spyserver to the PC:
IP: Source IP: 6.5.4.3 Destination IP: 1.2.3.4
TCP: Source port: 5555 Destination port: 23456
Flags: SYN, ACK

An ACK packet is sent from the PC to the spyserver:
IP: Source IP: 1.2.3.4 Destination IP: 6.5.4.3
TCP: Source port: 23456 Destination port: 5555
Flags: ACK

The handshake is over, the connection has been established, a socket (IP address+ TCP port number) on the server and matching socket on the client have been created.

The very first thing the client does is tell the spyserver what version of SDR# is running, the OS version running and service pack installed.
IP: Source IP: 1.2.3.4 Destination IP: 6.5.4.3
TCP: Source port: 23456 Destination port: 5555
Flags: PSH+ACK
Data: some binary data followed by a string "SDR# v1.0.0.1732 on Microsoft Windows ..."

All communications takes place across the PC's socket to/from the spyservers socket for the duration of that connection. No other ports are used, and only TCP is currently used, but that could change in the future.

Jim White
 

Martin,

Thank you for the very complete reply and explanation.

In this case the problem was in the port forward settings in the remote router (Adtran/Netvanta 1234).  It has numerous settings and options.  I had guessed that more than TCP was used so set the protocol to forward to "all".  That didn't work.  When I set it to just tcp it worked fine.

Your confirmation that only tcp is used cements that. And that only inbound 5555 is used also confirms I'm now set up right.

Thanks again for your time in explaining this and your work in these tools.

Jim

On 2/19/2020 2:08 PM, Martin Smith via Groups.Io wrote:
Maybe find out for yourself what is being blocked by your configuration:

If you are using Windows install npcap and Wireshark.

And if you are using UNIX just use tcpdump, and/or Wireshark. But with the right filter arguments (host/port/src/dst) in a tcpdump command line you do not need to use Wireshark most of the time. At least for basic network troubleshooting.


Do a packet capture of everything white it is working, a second packet capture when it is not working and then compare the two.

The issue in trying to diagnose a networking problem, is that every single hop that handles your traffic between the two machines has the potential to be the problem. Do a traceroute or a tcptraceroute (with a port number) between the two machines, it may help to highlight the issue.

I'm going to use some fake details as an example of what you should expect to see for the first four IP packets:
PC IP address: 1.2.3.4 (a made up IP address)
PC TCP port: 23456 (a random port number <65k, different each time a new socket is created)
spyserver IP address : 6.5.4.3 (a made up IP address)
spyserver TCP port: 5555 (fixed port number, may not be 5555)


The client initiates a normal TCP/IP three-way handshake to create a socket:

A SYN packet is sent from the PC to the machine that has the spyserver running bound to an explicit port number:
IP: Source IP: 1.2.3.4 Destination IP: 6.5.4.3
TCP: Source port: 23456 Destination port: 5555
Flags: SYN

A SYN+ACK packet is sent back from the spyserver to the PC:
IP: Source IP: 6.5.4.3 Destination IP: 1.2.3.4
TCP: Source port: 5555 Destination port: 23456
Flags: SYN, ACK

An ACK packet is sent from the PC to the spyserver:
IP: Source IP: 1.2.3.4 Destination IP: 6.5.4.3
TCP: Source port: 23456 Destination port: 5555
Flags: ACK

The handshake is over, the connection has been established, a socket (IP address+ TCP port number) on the server and matching socket on the client have been created.

The very first thing the client does is tell the spyserver what version of SDR# is running, the OS version running and service pack installed.
IP: Source IP: 1.2.3.4 Destination IP: 6.5.4.3
TCP: Source port: 23456 Destination port: 5555
Flags: PSH+ACK
Data: some binary data followed by a string "SDR# v1.0.0.1732 on Microsoft Windows ..."

All communications takes place across the PC's socket to/from the spyservers socket for the duration of that connection. No other ports are used, and only TCP is currently used, but that could change in the future.