Feature Request - AirSpy Support #7
Comments
|
It is also worth noting that the Airspy is a superior receiver compared to a standard RTL-SDR. So, the potential increase in telemetry volume is an incentive for the addition of Airspy products when programming time permits it. Linux libraries are available for the Airspy as it's commonly used in GNU Radio and other custom-built linux applications. |
|
Bonjour
No problem to add Airspy too. Mostly done in fact.... stay tuned
Sylvain f4gkr
Le 22 févr. 2018 06:36, "K4KDR" <notifications@github.com> a écrit :
… It is also worth noting that the Airspy is a superior receiver compared to
a standard RTL-SDR. So, the potential increase in telemetry volume is an
incentive for the addition of Airspy products when programming time permits
it. Linux libraries are available for the Airspy as it's commonly used in
GNU Radio and other custom-built linux applications.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADwLsYaHOLj-kDAtLfSqr_iPrsNhc51xks5tXPzCgaJpZM4SOAx4>
.
|
|
Implemented at home with a last issue underwork : the frame rate required by the python decoder is 38400 samples / secs, which is not an integer ratio from 10 MSPS given by the AirSpy. Closest integer ratio is 260 and gives 10 000 000 / 260 = 38461,53... Hz . Should be within the correction range of the "autodoppler compensation", but needs to check |
|
According to Sylverstre from Picsat this should be okay, processed as a "Doppler bias" |
|
Hi Sylvain, Not sure if helpful but several points to consider -
In this case (2,500,000 x 48)/3125 would give 38400. Or (10,000,000x12)/3125 Maybe such an approach can be applied here if useful? Best, Bob |
|
Bob,
No problem to switch to 2.5 M, but in reality the 10M->2.5M is done by the
Airspy lib, not the hardware :-) hence, it will use CPU too ...
Yes of course can use the fractional, just that for the other SDR it was
not needed, so I did not want to add that in the code :-D (lazy man... )
According to the Picsat team, they are confident that the slight error will
be accepted by the decoder because it corrects the bit rate dynamically for
Doppler... and 60 Hz is well inside its correction loop
2018-02-23 15:45 GMT+01:00 N6RFM <notifications@github.com>:
… Hi Sylvain,
Not sure if helpful but several points to consider -
- the airspy libraries accept sample rates of both 2.5M and 10M.
- using a 10K sampling rate tends to me processor intensive, so unless
a wide very wide reception band (10M) is desired, then the less wide 2.5M
may be preferred and consume less CPU.
- in the GNURadio world, to avoid fractional ratios, there is a
function called rational resaampling which combines interpolation and
decimation.
In this case (2,500,000 x 48)/3125 would give 38400. Or
(10,000,000x12)/3125
Maybe such an approach can be applied here if useful?
Best,
Bob
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADwLsWOE9kvgSL1VL9fw_BrDq3uJiMkwks5tXs6tgaJpZM4SOAx4>
.
|
|
Thanks Sylvain for the explanation. I look forward to trying it. |
|
Just tried with Airspy - runs fine but at elevated processor load. On my system, CPU use goes from 3% (RTL-SDR) to 44% (AirSpy). As a possible user choice in future releses, maybe the option to use 2.5 instead of 10MHz sampling rate, if 10MHz is selected by current default? Merci. |
|
Yes, ok, no pb. Will let you know when done (tomorow saturday) so you can
test and compare to see CPU load change
2018-02-23 21:18 GMT+01:00 N6RFM <notifications@github.com>:
… Just tried with Airspy - runs fine but at elevated processor load. On my
system, CPU use goes from 3% (RTL-SDR) to 44% (AirSpy). As a possible user
choice in future releses, maybe the option to use 2.5 instead of 10MHz
sampling rate, if 10MHz is selected by current default? Merci.
[image: screenshot at 2018-02-23 15-16-55]
<https://user-images.githubusercontent.com/36707700/36614987-a046cde2-18ac-11e8-93ba-98c9aa06642f.png>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADwLsUXHHUahuo7rH4aP01eZE-Hyid7oks5tXx0UgaJpZM4SOAx4>
.
|
|
Trying Airspy SDR. First test of newly complied version with experimental AirSpy support. 41% processor use. No decodes. It appeared that the most of the pass was in "continuous" mode. Noticed that "Received Frame" counter at bottom of window hung up but waterfall keeps working. Restarted program at end of pass when packets reverted to about 10 seconds apart. Still same behavior. Again hung received frames window. |
|
Thanks for the test. Clearly it does not work...
Le 24 févr. 2018 02:55, "N6RFM" <notifications@github.com> a écrit :
… First test of newly complied version with experimental AirSpy support. No
decodes. It appeared that the most of the pass was in "continuous" mode.
Noticed that "Received Frame" counter at bottom of window hung up but
waterfall keeps working. Restarted program at end of pass when packets
reverted to about 10 seconds apart. Still same behavior. Again hung
received frames window.
[image: screenshot at 2018-02-23 20-41-18]
<https://user-images.githubusercontent.com/36707700/36624322-a7dd4d2c-18db-11e8-9857-d1f1c1cdafa7.png>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADwLsdUQWt2OdtoUM5P11fVxTNRfdQ1Jks5tX2v8gaJpZM4SOAx4>
.
|
|
We very much appreciate and look forward to the integration with Airspy. I was not able to test it because of system load... at the 10m sample rate, my computer was monopolized and there were no remaining resources to run normally. That is the main reason that the 2.5m sample rate option is so desirable. Thank you! |
|
Currently testing on my machine with 2.5 Msps, will try to commit today
2018-02-24 7:12 GMT+01:00 K4KDR <notifications@github.com>:
… We very much appreciate and look forward to the integration with Airspy. I
was not able to test it because of system load... at the 10m sample rate,
my computer was monopolized and there were no remaining resources to run
normally. That is the main reason that the 2.5m sample rate option is so
desirable.
Thank you!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADwLsdVneN8shwDyOslRorLEXL6TZq6lks5tX6g6gaJpZM4SOAx4>
.
|
|
I think I fixed it
2018-02-25 15:52 GMT+01:00 Sylvain AZARIAN <sylvain.azarian@gmail.com>:
… Currently testing on my machine with 2.5 Msps, will try to commit today
2018-02-24 7:12 GMT+01:00 K4KDR ***@***.***>:
> We very much appreciate and look forward to the integration with Airspy.
> I was not able to test it because of system load... at the 10m sample rate,
> my computer was monopolized and there were no remaining resources to run
> normally. That is the main reason that the 2.5m sample rate option is so
> desirable.
>
> Thank you!
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#7 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/ADwLsdVneN8shwDyOslRorLEXL6TZq6lks5tX6g6gaJpZM4SOAx4>
> .
>
|
|
Running gprofiler on the code shows "intereting" results...
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total time seconds seconds calls ms/call ms/call name
*67.14 2.37 2.37 1385 1.71 1.71 iqconverter_float_process*
* 12.75 2.82 0.45 consumer_threadproc*
9.63 3.16 0.34 6818 0.05 0.05 OverlapSave::step2()
3.97 3.30 0.14 1385 0.10 0.10 Controller::generateSpectrum(_sCplx*)
1.13 3.34 0.04 6485 0.01 0.01 FrameProcessor::ac(_sCplx*, int)
0.57 3.36 0.02 9960606 0.00 0.00 FrameProcessor::modulus(int)
It takes more time inside the driver to do the int->float conversion than
extracting the 38900 Hz band out of the 2.5 MHz..........
|
|
I tried with new AirSpy library, even with SSE2 on, does not change much... Still 67.90% of processing time spent in the converter. |
|
Hi Sylvain, Thanks for the follow-up on this. I will try it! FYI, when I used the RTL-SDR for an earlier pass today, the % CPU usage was 31%. So, will be interesting to compare. 73, Bob |
|
Would be interesting you track CPU when just noise and when you are
processing frames...
The most consuming (apart from the AirSpy stuff) is the waterfall and the
chart with level detection... Several people have asked for a "console
only" version and this would I guess remove of lot of the processing load...
sylvain
2018-02-25 17:00 GMT+01:00 N6RFM <notifications@github.com>:
… Hi Sylvain,
Thanks for the follow-up on this. I will try it!
FYI, when I used the RTL-SDR for an earlier pass today, the % CPU usage
was 31%. So, will be interesting to compare.
73,
Bob
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADwLsWSyURIJmACwaKkfWgz-XGF57rlrks5tYYOXgaJpZM4SOAx4>
.
|
|
the Airpsy as also a feature to "compress" a bit the USB throughput. The
trick is to use one IQ pair over 3 bytes instead of 4 bytes where some bits
are unused. It does have a slight impact also on the load but not that
significant
2018-02-25 17:02 GMT+01:00 Sylvain AZARIAN <sylvain.azarian@gmail.com>:
… Would be interesting you track CPU when just noise and when you are
processing frames...
The most consuming (apart from the AirSpy stuff) is the waterfall and the
chart with level detection... Several people have asked for a "console
only" version and this would I guess remove of lot of the processing load...
sylvain
2018-02-25 17:00 GMT+01:00 N6RFM ***@***.***>:
> Hi Sylvain,
>
> Thanks for the follow-up on this. I will try it!
>
> FYI, when I used the RTL-SDR for an earlier pass today, the % CPU usage
> was 31%. So, will be interesting to compare.
>
> 73,
>
> Bob
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#7 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/ADwLsWSyURIJmACwaKkfWgz-XGF57rlrks5tYYOXgaJpZM4SOAx4>
> .
>
|
|
Good ideas, but agree using only 3 bytes unlikely to offer much improvement. Thanks! |
|
There is in fact already a webserver embedded in the program for remote
control... is used at PicSat ground station. This could be extended too
Unless http port is set to 0 in config file, starts a http server listening
by default on port 8001
supported requests are so far :
- http://<< ip >>:<< port >>/start
- http://<< ip >>:<< port >>/stop
- http://<< ip >>:<< port >>/status : returns a description of the
current status (ongoing, not finished)
- http://<< ip >>:<< port >>/tune/ tunes to desired freq for example : *
http://<< ip >>:<< port >>/tune/438.256 to receive 438.256000 MHz
2018-02-25 17:15 GMT+01:00 N6RFM <notifications@github.com>:
… Good ideas, but agree using only 3 bytes unlikely to offer much
improvement.
As for console only, yes that might be useful. One thing to note is the
signal fading which can be resolved by changing RX antenna polarization
from vertical to horizontal (or visca versa). What's important, is knowing
when to do this. At the moment, the waterfall shows when the signal is
fading and prompts the user to try different polarization. But, the beauty
of PicTalk is that the user does not even have to see the waterfall for
tuning purposes! It's enough to see the "received frame versus correlation"
plot at the bottom of the screen. So, maybe a way to turn off the
waterfall? Or for a console based version allow for some information (such
correlation level) to be printed in real time. That way the user has an
idea when switching polarity is worth a try.
Thanks!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADwLsfwFJa6jEnoL-dDwAAYzJCAeYt0mks5tYYcrgaJpZM4SOAx4>
.
|
|
very nice |
|
OK - I see that some revisions have been made. Merci Some quick tests only since the satellite will not pass overhead again until later today. Previous version (10 Mhz Airspy)
Current version (2.5Mhz Airspy) So, changing from 10 to 2.5 MHz really changes the CPU load and distribution. For the new version, only one core seems to be pushed to the limit and the is switched out for another. |
|
So thanks Sylvain!!! I look forward to trying the updated version later today with real data input. BTW, you might want to update the version number on the "splash" screen from v1.0 24/01/18 to something different. :-) |
|
That's right for the splash !
I forgot to remove the GPROF directives in the .pro file ...............
comment lines 73 to 75, it should even take less CPU now !
Just changed this file
2018-02-25 18:21 GMT+01:00 N6RFM <notifications@github.com>:
… So thanks Sylvain!!!
I look forward to trying the updated version later today with real data
input.
BTW, you might want to update the version number on the "splash" screen
from v1.0 24/01/18 to something different. :-)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADwLsRFFhjUGy3sbWoLmigJHpZDzLtqJks5tYZaBgaJpZM4SOAx4>
.
|
|
Should the updated .pro file cause a change in the compile, or at runtime? I got the following when trying to re-compile: |
|
The profiling option add extra code in the binary to write a specific file
(gmon.out) that is used to estimate the function use and time spent. This
adds a small overhead at runtime.
It says "nothing to be done" because the sources have not changed. You
should "make clean" first, and recompile the program to git rid of that
'feature' and you will use a bit less CPU
2018-02-25 21:08 GMT+01:00 K4KDR <notifications@github.com>:
… Should the updated .pro file cause a change in the compile, or at runtime?
I got the following when trying to re-compile:
k4kdr@:~/PicTalk$ git pull -v
POST git-upload-pack (452 bytes)
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/f4gkr/PicTalk
2a4727c..9b5cb7a master -> origin/master
Updating 2a4727c..9b5cb7a
Fast-forward
pictalk.pro | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
k4kdr@:~/PicTalk$ qmake
k4kdr@:~/PicTalk$ make
make: Nothing to be done for 'first'.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADwLsdKiPR4YaAJdiqYZ8nGVbOyAKPH_ks5tYb3IgaJpZM4SOAx4>
.
|
|
Ah, thank you so much! I am not a programmer so was not familiar with "make clean"... many of us just follow build / install instructions to the letter. Appreciate all your help! |
|
you're welcome
2018-02-25 21:19 GMT+01:00 K4KDR <notifications@github.com>:
… Ah, thank you so much! I am not a programmer so was not familiar with
"make clean"... many of us just follow build / install instructions to the
letter. Appreciate all your help!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADwLsXlnMPOg7cwaNIv_WtDMDVevRsm7ks5tYcBRgaJpZM4SOAx4>
.
|
|
Excellent - Many thanks Sylvain! |
Great job and thanks for developing PicTalk.
Please consider adding support for the AirSpy SDR.
Merci,
Bob
N6RFM
The text was updated successfully, but these errors were encountered: