Feature Request - AirSpy Support about pictalk HOT 30 CLOSED

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.

from pictalk.

from pictalk.

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

from pictalk.

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

from pictalk.

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

from pictalk.

from pictalk.

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

from pictalk.

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.

from pictalk.

from pictalk.

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.

from pictalk.

from pictalk.

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!

from pictalk.

from pictalk.

from pictalk.

from pictalk.

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

from pictalk.

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

from pictalk.

from pictalk.

from pictalk.

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!

from pictalk.

from pictalk.

very nice

from pictalk.

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.

from pictalk.

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

from pictalk.

from pictalk.

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

from pictalk.

from pictalk.

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!

from pictalk.

from pictalk.

Excellent - Many thanks Sylvain!

from pictalk.