Feature Request - AirSpy Support

[N6RFM]

Great job and thanks for developing PicTalk.

Please consider adding support for the AirSpy SDR.

Merci,

Bob N6RFM

[K4KDR]

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.

[f4gkr]

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 https://github.com/f4gkr/PicTalk/issues/7#issuecomment-367572851, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwLsYaHOLj-kDAtLfSqr_iPrsNhc51xks5tXPzCgaJpZM4SOAx4 .

[f4gkr]

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

[f4gkr]

According to Sylverstre from Picsat this should be okay, processed as a "Doppler bias" Will commit for test

[N6RFM]

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 be more processor intensive, so unless a wide very wide reception band (10M) is desired, then the less wide 2.5M may be preferred to reduce CPU load.
• 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

[f4gkr]

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 https://github.com/f4gkr/PicTalk/issues/7#issuecomment-368028071, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwLsWOE9kvgSL1VL9fw_BrDq3uJiMkwks5tXs6tgaJpZM4SOAx4 .

[N6RFM]

Thanks Sylvain for the explanation. I look forward to trying it. B.

[N6RFM]

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.

[f4gkr]

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 https://github.com/f4gkr/PicTalk/issues/7#issuecomment-368127370, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwLsUXHHUahuo7rH4aP01eZE-Hyid7oks5tXx0UgaJpZM4SOAx4 .

[N6RFM]

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.

[f4gkr]

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 https://github.com/f4gkr/PicTalk/issues/7#issuecomment-368187784, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwLsdUQWt2OdtoUM5P11fVxTNRfdQ1Jks5tX2v8gaJpZM4SOAx4 .

[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!

[f4gkr]

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 https://github.com/f4gkr/PicTalk/issues/7#issuecomment-368203762, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwLsdVneN8shwDyOslRorLEXL6TZq6lks5tX6g6gaJpZM4SOAx4 .

[f4gkr]

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 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 https://github.com/f4gkr/PicTalk/issues/7#issuecomment-368203762, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwLsdVneN8shwDyOslRorLEXL6TZq6lks5tX6g6gaJpZM4SOAx4 .

[f4gkr]

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..........

[f4gkr]

I tried with new AirSpy library, even with SSE2 on, does not change much... Still 67.90% of processing time spent in the converter. I will commit for your appreciation

[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

[f4gkr]

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 https://github.com/f4gkr/PicTalk/issues/7#issuecomment-368320751, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwLsWSyURIJmACwaKkfWgz-XGF57rlrks5tYYOXgaJpZM4SOAx4 .

[f4gkr]

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 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 https://github.com/f4gkr/PicTalk/issues/7#issuecomment-368320751, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwLsWSyURIJmACwaKkfWgz-XGF57rlrks5tYYOXgaJpZM4SOAx4 .

[N6RFM]

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!

[f4gkr]

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 https://github.com/f4gkr/PicTalk/issues/7#issuecomment-368321926, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwLsfwFJa6jEnoL-dDwAAYzJCAeYt0mks5tYYcrgaJpZM4SOAx4 .

[N6RFM]

very nice

[N6RFM]

OK - I see that some revisions have been made. Merci ++ AirSpy sample rate changed to 'lowest' instead of 'highest'. For example 2.5 MHz for the "AirSpy one" ++ AirSpy start/stop bug fixed

Some quick tests only since the satellite will not pass overhead again until later today.

Previous version (10 Mhz Airspy) PicTalk started - no decodes (Theshold = 40) CPU (quad core) ~ 41% load changing Threshold to zero, average CPU load to 68% and higher, GUI hangs as previously noted but console keeps running trying to process the pile up of data. Screen shot below shows effects on CPU when Threshold is changes from 40 (left side of picture) to zero (right side).

Current version (2.5Mhz Airspy) PicTalk started - no decodes (Theshold = 40) CPU (quad core) ~ 20% load changing Threshold to zero, average CPU load to 41% on average, GUI OK. Screen shot below shows effects on CPU when Threshold is changes from 40 (left side of picture) to zero (right side).

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.
Also, with the Threshold at zero, I let the decoder run for several hundred frame searches, and the system no longer hangs.

[N6RFM]

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. :-)

[f4gkr]

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 https://github.com/f4gkr/PicTalk/issues/7#issuecomment-368326860, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwLsRFFhjUGy3sbWoLmigJHpZDzLtqJks5tYZaBgaJpZM4SOAx4 .

[K4KDR]

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'.

[f4gkr]

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 https://github.com/f4gkr/PicTalk/issues/7#issuecomment-368340186, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwLsdKiPR4YaAJdiqYZ8nGVbOyAKPH_ks5tYb3IgaJpZM4SOAx4 .

[K4KDR]

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!

[f4gkr]

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 https://github.com/f4gkr/PicTalk/issues/7#issuecomment-368340992, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwLsXlnMPOg7cwaNIv_WtDMDVevRsm7ks5tYcBRgaJpZM4SOAx4 .

[N6RFM]

Excellent - Many thanks Sylvain!