Changes found useful when compiling for Pi

[jontio]

I was compiling for the Pi and noticed some things. The CLI commands weren't passed through the bash helper script. Some build artifacts weren't in the gitignore. Pi doesn't have Qt 5.12 so reduced to 5.11. Added an autostart option. Added checking for ini file existence. sh files hadn't been set to exe.

I just have a pi 3 and at first glance it doesn't seem to be fast enough. For other projects on Pi's I've managed to make them multi-threaded to be able to run but it can be really tricky.

[jeroenbeijer]

Hi Jonti!

Many thanks for that, very useful.

For the autostart there is an option via the ini with these keys:

auto_start=1 auto_start_tuner_idx=0

Can you give that a try? I had not yet documented it on the readme but added it now. If possible I would like to keep as much of the options in the ini file.

Cheers,

Jeroen

[jontio]

Ohh I didn't notice that

auto_start=1
auto_start_tuner_idx=0

can be used in the ini file to autostart. Yup I agree best to remove the CLI autostart option. I see you have already done that. I've tested on the Pi and it autostarts using the ini autostart settings, so all good.

[jeroenbeijer]

Hi Jonti,

Cool thanks.

Will the linux build script run on raspi as is? I don't own one myself.

Maybe it runs better with fewer VFO's?

BR

Jeroen

Sent from my Galaxy

-------- Original message -------- From: Jonti Olds @.> Date: 31/07/2021 10:53 (GMT+01:00) To: jeroenbeijer/SDRReceiver @.> Cc: jeroenbeijer @.>, State change @.> Subject: Re: [jeroenbeijer/SDRReceiver] Changes found useful when compiling for Pi (#1)

Ohh I didn't notice that

auto_start=1 auto_start_tuner_idx=0

can be used in the ini file to autostart. Yup I agree best to remove the CLI autostart option. I see you have already done that. I've tested on the Pi and it autostarts using the ini autostart settings, so all good.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/jeroenbeijer/SDRReceiver/pull/1#issuecomment-890314504, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHNGZH5BWNXE6AY5ATQS2FDT2O2Y3ANCNFSM5BJUSSQA.

[jontio]

Hi Jeroen,

Yup as long as git is already installed then it's just...

git clone https://github.com/jeroenbeijer/SDRReceiver
cd SDRReceiver
./ci-linux-build.sh

I have it as a headless device and can either ssh or vnc into it. You can still run the gui application headless from either a service or via a command like...

DISPLAY=:0 SDRReceiver -s sample_ini/CBAND_143E.ini

The gui will appear in the virtual monitor when vnc'ing into it so you can still see what's going on if you want.

I've noticed that on ubuntu 21.04 qt5-default package is missing so that may be a problem that will need fixing in the future but in the meantime building works fine on ubuntu-esque os 20.04 and raspberrian buster.

I gave it a quick go with 5 VFOs but didn't seem to reduce the CPU enough. The problem with the Pi 3 is although altogether it's 4 cores are reasonable, single core applications with SDR devices on the other hand can struggle. For one project I did I had to bend over backwards to get a 1Mb/s decoder working, the viterbi decoder was the most CPU intensive class and I ended up splitting it into 4 threads so as to not max out any of the threads.

I see about 50% CPU usage so at first glance it looks like there are 2 threads that are maxed out.

I'll have another go tomorrow and see both if I can get the CPU usage down as is and also have a look to see if I can find the most CPU intensive part. However, I'm not that optimistic that it will be easy but it's worth a little look just in case it is.

Cheers, Jonti

[jontio]

Hi Jeroen,

The single core CPU usage is too high for even one the VFO...

After that I tried reducing the sample rate of the SDR dongle. The RTL dongles support 225,001 - 300,000 f/s and 900,001 - 3,200,000 f/s sample rates. All the 900kf/s + ones the CPU seemed too high but maybe 912kf/s would be workable with some tweaking. Anyway the next thing I noticed is that if the RTL sample rate is not 1,536kf/s then the sample rate as advertised to JAERO was not the one as set in the VFO. So if the VFO was set to 48kHz and the RTL rate to 920kf/s then JAERO said the rate was 57.5kHz not 48. For RTL rate of 1.24Mf/s, VFO 48kHz, then JAERO said 77.5kHz. Apart from the change in the RTL sample rate here is the ini file I used...

auto_start=1
auto_start_tuner_idx=0

sample_rate=920000
center_frequency=1547300000
zmq_address=tcp://*:6003

tuner_gain=496
correct_dc_bias=1
mix_offset=0

[main_vfos]
size=1
1\frequency=1547310000
1\out_rate=144000

[vfos]
size=1
1\frequency=1547300600
1\gain=5
1\filter_bandwidth=24000
1\out_rate=48000
1\topic=VFC01

So something's not right there. Maybe it's just the rate being advertised to JAERO I don't.

I had a look at this part of the code ...

// find main VFO
        for(int a = 0; a<VFOmain.length(); a++)
        {

            int drate = VFOmain.at(a)->getOutRate();
            if(drate == 768000)
            {
                drate = 384000;
            }
            int diff = std::abs((center_frequency-VFOmain.at(a)->getMixerFreq())-vfo_freq);
            if(diff < drate && !VFOmain.at(a)->getDemodUSB() )
            {
                main_idx=a;
                main_vfo_freq=VFOmain.at(a)->getMixerFreq();
                main_vfo_out_rate=VFOmain.at(a)->getOutRate();
                break;
            }

        }

It seems to find a main VFO that can be used as a source for another VFO. I don't know what the hard coded 768000 is about. I had a look what drate was, it was 1/4 of the sample rate and 1/4 of what was advertised to JAERO. If a main VFO isn't available that covers the desired VFO will the receiver still work? It looks like later on in the code it tries to add the desired VFO as a main VFO, is that right?

I then tried some things that were impossible such as the desired VFO being beyond what the RTL was covering eg RTL rate 1.536Mf/s and 1.5473GHz but desired VFO was 1.0473GHz. I didn't get any errors doing this and there was still data being displayed in the spectrograph.

Some VFO sample rates caused the program to crash. E.g. this crashed ...

auto_start=1
auto_start_tuner_idx=0

sample_rate=1240000
center_frequency=1547300000
zmq_address=tcp://*:6003

tuner_gain=496
correct_dc_bias=1
mix_offset=0

[main_vfos]
size=1
1\frequency=1547310000
1\out_rate=96000

[vfos]
size=1
1\frequency=1547300600
1\gain=5
1\filter_bandwidth=24000
1\out_rate=48000
1\topic=VFC01

with this response...

terminate called after throwing an instance of 'std::bad_array_new_length'
  what():  std::bad_array_new_length
Aborted

While this didn't

auto_start=1
auto_start_tuner_idx=0

sample_rate=1240000
center_frequency=1547300000
zmq_address=tcp://*:6003

tuner_gain=496
correct_dc_bias=1
mix_offset=0

[main_vfos]
size=1
1\frequency=1547310000
1\out_rate=192000

[vfos]
size=1
1\frequency=1547300600
1\gain=5
1\filter_bandwidth=24000
1\out_rate=48000
1\topic=VFC01

So if the RTL sample rate could be changed to say 300kf/s it should work on a Pi3. 912kf/s might work on a Pi3 but the FIR filters and any other CPU stuff would probably need reducing and tweaking. I had a look at the FIR sizes and they varied from about 50 to 120 taps. Other things such as the USB detector might also be interesting to look at. I noticed you used a hilbert filter but there are other ways. Running a complex FIR as two real ones in two different threads might also be interesting. However at the moment reducing the RTL sampling is probably the most effective and easiest thing to look at.

Cheers, Jonti

[jeroenbeijer]

Hi Jonti,

You are correct, as I wrote on the readme the page the only currently supported rates are 1536 and 1920. The idea is to keep it as simple as possible and only use multiples of 48K to use the halfband filters as much as possible. Catering for varying rates is much easier when using audio cables, in this case more logic would be needed to do all that and I simply did not have the need for it, the goal was to cover all voice and data channels. As you wrote there is a gap in the sample rates meaning that covering only say the slower channels is a little trickier with a rate that can be done with halfband only. It should work with a 240K rate though and then decimate 4/5 , it may require a few small changes, let me have a quick look. There are a few hardcoded things in there as you found :-)

BR

Jeroen

Sent from my Galaxy

-------- Original message -------- From: Jonti Olds @.> Date: 01/08/2021 05:46 (GMT+01:00) To: jeroenbeijer/SDRReceiver @.> Cc: jeroenbeijer @.>, State change @.> Subject: Re: [jeroenbeijer/SDRReceiver] Changes found useful when compiling for Pi (#1)

Hi Jeroen,

The single core CPU usage is too high for even one the VFO...

[Screenshot_20210801_100545]https://user-images.githubusercontent.com/13667843/127757332-a511211c-29d2-412c-a0e4-c1fc4912176d.png

After that I tried reducing the sample rate of the SDR dongle. The RTL dongles support 225,001 - 300,000 f/s and 900,001 - 3,200,000 f/s sample rates. All the 900kf/s + ones the CPU seemed too high but maybe 912kf/s would be workable with some tweaking. Anyway the next thing I noticed is that if the RTL sample rate is not 1,536kf/s then the sample rate as advertised to JAERO was not the one as set in the VFO. So if the VFO was set to 48kHz and the RTL rate to 920kf/s then JAERO said the rate was 57.5kHz not 48. For RTL rate of 1.24Mf/s, VFO 48kHz, then JAERO said 77.5kHz. Apart from the change in the RTL sample rate here is the ini file I used...

auto_start=1 auto_start_tuner_idx=0

sample_rate=920000 center_frequency=1547300000 zmq_address=tcp://*:6003

tuner_gain=496 correct_dc_bias=1 mix_offset=0

[main_vfos] size=1 1\frequency=1547310000 1\out_rate=144000

[vfos] size=1 1\frequency=1547300600 1\gain=5 1\filter_bandwidth=24000 1\out_rate=48000 1\topic=VFC01

So something's not right there. Maybe it's just the rate being advertised to JAERO I don't.

I had a look at this part of the code ...

// find main VFO for(int a = 0; a<VFOmain.length(); a++) {

        int drate = VFOmain.at(a)->getOutRate();
        if(drate == 768000)
        {
            drate = 384000;
        }
        int diff = std::abs((center_frequency-VFOmain.at(a)->getMixerFreq())-vfo_freq);
        if(diff < drate && !VFOmain.at(a)->getDemodUSB() )
        {
            main_idx=a;
            main_vfo_freq=VFOmain.at(a)->getMixerFreq();
            main_vfo_out_rate=VFOmain.at(a)->getOutRate();
            break;
        }

    }

It seems to find a main VFO that can be used as a source for another VFO. I don't know what the hard coded 768000 is about. I had a look what drate was, it was 1/4 of the sample rate and 1/4 of what was advertised to JAERO. If a main VFO isn't available that covers the desired VFO will the receiver still work? It looks like later on in the code it tries to add the desired VFO as a main VFO, is that right?

I then tried some things that were impossible such as the desired VFO being beyond what the RTL was covering eg RTL rate 1.536Mf/s and 1.5473GHz but desired VFO was 1.0473GHz. I didn't get any errors doing this and there was still data being displayed in the spectrograph.

Some VFO sample rates caused the program to crash. E.g. this crashed ...

auto_start=1 auto_start_tuner_idx=0

sample_rate=1240000 center_frequency=1547300000 zmq_address=tcp://*:6003

tuner_gain=496 correct_dc_bias=1 mix_offset=0

[main_vfos] size=1 1\frequency=1547310000 1\out_rate=96000

[vfos] size=1 1\frequency=1547300600 1\gain=5 1\filter_bandwidth=24000 1\out_rate=48000 1\topic=VFC01

with this response...

terminate called after throwing an instance of 'std::bad_array_new_length' what(): std::bad_array_new_length Aborted

While this didn't

auto_start=1 auto_start_tuner_idx=0

sample_rate=1240000 center_frequency=1547300000 zmq_address=tcp://*:6003

tuner_gain=496 correct_dc_bias=1 mix_offset=0

[main_vfos] size=1 1\frequency=1547310000 1\out_rate=192000

[vfos] size=1 1\frequency=1547300600 1\gain=5 1\filter_bandwidth=24000 1\out_rate=48000 1\topic=VFC01

So if the RTL sample rate could be changed to say 300kf/s it should work on a Pi3. 912kf/s might work on a Pi3 but the FIR filters and any other CPU stuff would probably need reducing and tweaking. I had a look at the FIR sizes and they varied from about 50 to 120 taps. Other things such as the USB detector might also be interesting to look at. I noticed you used a hilbert filter but there are other ways. Running a complex FIR as two real ones in two different threads might also be interesting. However at the moment reducing the RTL sampling is probably the most effective and easiest thing to look at.

Cheers, Jonti

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/jeroenbeijer/SDRReceiver/pull/1#issuecomment-890443052, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHNGZH6LG3TZMZSFM32P5ODT2S7RBANCNFSM5BJUSSQA.

[jeroenbeijer]

Hi Jonti,

Some time ago I did this, but now I realized 240K won't work directly either. Like I said, simple being the operative word here. The rtlsdr_read_async buffer length needs to be a multiple of 512. For 15360000 and 1920000 this is true when we want to send 4 buckets of data to jaero per second. So everything is nice and even and simple so to speak 🙂

BR

Jeroen

---

From: Jonti Olds @.> Sent: Sunday, August 1, 2021 5:46 AM To: jeroenbeijer/SDRReceiver @.> Cc: jeroenbeijer @.>; State change @.> Subject: Re: [jeroenbeijer/SDRReceiver] Changes found useful when compiling for Pi (#1)

Hi Jeroen,

The single core CPU usage is too high for even one the VFO...

[Screenshot_20210801_100545]https://user-images.githubusercontent.com/13667843/127757332-a511211c-29d2-412c-a0e4-c1fc4912176d.png

After that I tried reducing the sample rate of the SDR dongle. The RTL dongles support 225,001 - 300,000 f/s and 900,001 - 3,200,000 f/s sample rates. All the 900kf/s + ones the CPU seemed too high but maybe 912kf/s would be workable with some tweaking. Anyway the next thing I noticed is that if the RTL sample rate is not 1,536kf/s then the sample rate as advertised to JAERO was not the one as set in the VFO. So if the VFO was set to 48kHz and the RTL rate to 920kf/s then JAERO said the rate was 57.5kHz not 48. For RTL rate of 1.24Mf/s, VFO 48kHz, then JAERO said 77.5kHz. Apart from the change in the RTL sample rate here is the ini file I used...

auto_start=1 auto_start_tuner_idx=0

sample_rate=920000 center_frequency=1547300000 zmq_address=tcp://*:6003

tuner_gain=496 correct_dc_bias=1 mix_offset=0

[main_vfos] size=1 1\frequency=1547310000 1\out_rate=144000

[vfos] size=1 1\frequency=1547300600 1\gain=5 1\filter_bandwidth=24000 1\out_rate=48000 1\topic=VFC01

So something's not right there. Maybe it's just the rate being advertised to JAERO I don't.

I had a look at this part of the code ...

// find main VFO for(int a = 0; a<VFOmain.length(); a++) {

        int drate = VFOmain.at(a)->getOutRate();
        if(drate == 768000)
        {
            drate = 384000;
        }
        int diff = std::abs((center_frequency-VFOmain.at(a)->getMixerFreq())-vfo_freq);
        if(diff < drate && !VFOmain.at(a)->getDemodUSB() )
        {
            main_idx=a;
            main_vfo_freq=VFOmain.at(a)->getMixerFreq();
            main_vfo_out_rate=VFOmain.at(a)->getOutRate();
            break;
        }

    }

It seems to find a main VFO that can be used as a source for another VFO. I don't know what the hard coded 768000 is about. I had a look what drate was, it was 1/4 of the sample rate and 1/4 of what was advertised to JAERO. If a main VFO isn't available that covers the desired VFO will the receiver still work? It looks like later on in the code it tries to add the desired VFO as a main VFO, is that right?

I then tried some things that were impossible such as the desired VFO being beyond what the RTL was covering eg RTL rate 1.536Mf/s and 1.5473GHz but desired VFO was 1.0473GHz. I didn't get any errors doing this and there was still data being displayed in the spectrograph.

Some VFO sample rates caused the program to crash. E.g. this crashed ...

auto_start=1 auto_start_tuner_idx=0

sample_rate=1240000 center_frequency=1547300000 zmq_address=tcp://*:6003

tuner_gain=496 correct_dc_bias=1 mix_offset=0

[main_vfos] size=1 1\frequency=1547310000 1\out_rate=96000

[vfos] size=1 1\frequency=1547300600 1\gain=5 1\filter_bandwidth=24000 1\out_rate=48000 1\topic=VFC01

with this response...

terminate called after throwing an instance of 'std::bad_array_new_length' what(): std::bad_array_new_length Aborted

While this didn't

auto_start=1 auto_start_tuner_idx=0

sample_rate=1240000 center_frequency=1547300000 zmq_address=tcp://*:6003

tuner_gain=496 correct_dc_bias=1 mix_offset=0

[main_vfos] size=1 1\frequency=1547310000 1\out_rate=192000

[vfos] size=1 1\frequency=1547300600 1\gain=5 1\filter_bandwidth=24000 1\out_rate=48000 1\topic=VFC01

So if the RTL sample rate could be changed to say 300kf/s it should work on a Pi3. 912kf/s might work on a Pi3 but the FIR filters and any other CPU stuff would probably need reducing and tweaking. I had a look at the FIR sizes and they varied from about 50 to 120 taps. Other things such as the USB detector might also be interesting to look at. I noticed you used a hilbert filter but there are other ways. Running a complex FIR as two real ones in two different threads might also be interesting. However at the moment reducing the RTL sampling is probably the most effective and easiest thing to look at.

Cheers, Jonti

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/jeroenbeijer/SDRReceiver/pull/1#issuecomment-890443052, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHNGZH6LG3TZMZSFM32P5ODT2S7RBANCNFSM5BJUSSQA.

[jeroenbeijer]

Hi Jonti,

Tinkered a little today but short on time. Pretty sure it can be run at 960K without too many changes and the multiple of 512 can be solved quite easily. It should also be able to run at 240K but it looked like the dongle chose a default higher rater anyways, not sure why.

Once I have some more time I will sort this out. It does run on the raspi 4 without any issues at least.

BR

Jeroen

---

From: Jonti Olds @.> Sent: Sunday, August 1, 2021 5:46 AM To: jeroenbeijer/SDRReceiver @.> Cc: jeroenbeijer @.>; State change @.> Subject: Re: [jeroenbeijer/SDRReceiver] Changes found useful when compiling for Pi (#1)

Hi Jeroen,

The single core CPU usage is too high for even one the VFO...

[Screenshot_20210801_100545]https://user-images.githubusercontent.com/13667843/127757332-a511211c-29d2-412c-a0e4-c1fc4912176d.png

After that I tried reducing the sample rate of the SDR dongle. The RTL dongles support 225,001 - 300,000 f/s and 900,001 - 3,200,000 f/s sample rates. All the 900kf/s + ones the CPU seemed too high but maybe 912kf/s would be workable with some tweaking. Anyway the next thing I noticed is that if the RTL sample rate is not 1,536kf/s then the sample rate as advertised to JAERO was not the one as set in the VFO. So if the VFO was set to 48kHz and the RTL rate to 920kf/s then JAERO said the rate was 57.5kHz not 48. For RTL rate of 1.24Mf/s, VFO 48kHz, then JAERO said 77.5kHz. Apart from the change in the RTL sample rate here is the ini file I used...

auto_start=1 auto_start_tuner_idx=0

sample_rate=920000 center_frequency=1547300000 zmq_address=tcp://*:6003

tuner_gain=496 correct_dc_bias=1 mix_offset=0

[main_vfos] size=1 1\frequency=1547310000 1\out_rate=144000

[vfos] size=1 1\frequency=1547300600 1\gain=5 1\filter_bandwidth=24000 1\out_rate=48000 1\topic=VFC01

So something's not right there. Maybe it's just the rate being advertised to JAERO I don't.

I had a look at this part of the code ...

// find main VFO for(int a = 0; a<VFOmain.length(); a++) {

        int drate = VFOmain.at(a)->getOutRate();
        if(drate == 768000)
        {
            drate = 384000;
        }
        int diff = std::abs((center_frequency-VFOmain.at(a)->getMixerFreq())-vfo_freq);
        if(diff < drate && !VFOmain.at(a)->getDemodUSB() )
        {
            main_idx=a;
            main_vfo_freq=VFOmain.at(a)->getMixerFreq();
            main_vfo_out_rate=VFOmain.at(a)->getOutRate();
            break;
        }

    }

It seems to find a main VFO that can be used as a source for another VFO. I don't know what the hard coded 768000 is about. I had a look what drate was, it was 1/4 of the sample rate and 1/4 of what was advertised to JAERO. If a main VFO isn't available that covers the desired VFO will the receiver still work? It looks like later on in the code it tries to add the desired VFO as a main VFO, is that right?

I then tried some things that were impossible such as the desired VFO being beyond what the RTL was covering eg RTL rate 1.536Mf/s and 1.5473GHz but desired VFO was 1.0473GHz. I didn't get any errors doing this and there was still data being displayed in the spectrograph.

Some VFO sample rates caused the program to crash. E.g. this crashed ...

auto_start=1 auto_start_tuner_idx=0

sample_rate=1240000 center_frequency=1547300000 zmq_address=tcp://*:6003

tuner_gain=496 correct_dc_bias=1 mix_offset=0

[main_vfos] size=1 1\frequency=1547310000 1\out_rate=96000

[vfos] size=1 1\frequency=1547300600 1\gain=5 1\filter_bandwidth=24000 1\out_rate=48000 1\topic=VFC01

with this response...

terminate called after throwing an instance of 'std::bad_array_new_length' what(): std::bad_array_new_length Aborted

While this didn't

auto_start=1 auto_start_tuner_idx=0

sample_rate=1240000 center_frequency=1547300000 zmq_address=tcp://*:6003

tuner_gain=496 correct_dc_bias=1 mix_offset=0

[main_vfos] size=1 1\frequency=1547310000 1\out_rate=192000

[vfos] size=1 1\frequency=1547300600 1\gain=5 1\filter_bandwidth=24000 1\out_rate=48000 1\topic=VFC01

So if the RTL sample rate could be changed to say 300kf/s it should work on a Pi3. 912kf/s might work on a Pi3 but the FIR filters and any other CPU stuff would probably need reducing and tweaking. I had a look at the FIR sizes and they varied from about 50 to 120 taps. Other things such as the USB detector might also be interesting to look at. I noticed you used a hilbert filter but there are other ways. Running a complex FIR as two real ones in two different threads might also be interesting. However at the moment reducing the RTL sampling is probably the most effective and easiest thing to look at.

Cheers, Jonti

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/jeroenbeijer/SDRReceiver/pull/1#issuecomment-890443052, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHNGZH6LG3TZMZSFM32P5ODT2S7RBANCNFSM5BJUSSQA.

[jontio]

Hi Jeroen,

Ah OK, I see only 1536 and 1920 are allowed at the moment. 960k and 240k would be nice to try.

So some people have tried it on a Pi 4? That's good it works on that.

Cheers, Jonti

[thebaldgeek]

Just saw this thread now.
I have spent hours and hours figuring out how to compile qt5.12.10 to build the new versions of Jaero, Figured it out, but the ci-linux script still uses the Pis 5.11.
The only Jaero I got to build cleanly on the Pi4 was 1.0.4.11.
Where do I find the Jaero v13 with the ZMQ input that will build with the Pi4 qt5.11?
I have SDRReceiver working on the Pi4, took all of about 30 seconds to build and get running. Very nice work - thanks guys.

[jeroenbeijer]

Hopefully Jonti can reply on that one, I am not experienced with Pi much.

[jontio]

Hi @thebaldgeek,

So you run JAERO on a pi4, are the powerful enough to do that?

I'm having a look running the ci script on pi. Yup it doesn't seem to work as is.

Usually when I've had to build something that needs a higher version of qt than a pi has I've removed anything specific to the newer version. Maybe qtchooser is an issue, try typing qmake -v if that comes up with v5.11 then the os isn't using the one you built. I think qtchooser can change what qt version the system uses.

As far as I'm aware of no one has build JAERO 1.0.4.13 on a pi4 yet.

I'll continue looking at the ci script on the pi3 that I have. I'm not quite up to the qt5.12 thing yet, and still having issues with checkinstall and other bits and pieces.

Cheers, Jonti

[jontio]

I don't see any reason for qt5.12. I've branched a dev for the pi build script, fixed the things that didn't work for me and changed the dependencies to qt5.11. Try the following on your pi...

git clone https://github.com/jontio/JAERO
cd JAERO
git checkout dev-pi-build
./pi-build.sh

It builds and installs for me.

Here it is on my pi3 with a zmq signal as its input coming from another computer.

If it works for you let me know and I'll merge it into master. If there is anything I've missed also let me know so we can fix the script.

[thebaldgeek]

Jonti and Jeroen.
I am just blown away. I am exited, happy, amazed, impressed, thankful and ... just wow... Thanks to you two, we now have a solid non-Windows PC way forward to receive and decode Satcom data on Linux, and a Pi4 no less.
A picture for a 1000 words....

A screenshot of my current L-Band setup running on a Pi4 without breaking a sweat. I never imagined such a thing in all the hours I have spent trying to do just this, SDRReceiver built in minutes and Jaero in about 15-20.
The key is a little odd, when you launch a Jaero, pulseaudio starts and uses about 70%, when you configure ZMQ in Jaero, pulse keeps running, the next Jaero kicks pulse up a gear and after about 2-3 Jareos running, the CPU is 100% and we are dropping decodes.
It then occurred to me that we don't need pulseaudio running any more so sudo kill -15 pulseaudio and I just about fell off the chair, the CPU went to about 15%. Everything kept running just fine. I'm currently running 8 Jaeros using the 54W .ini from Jeroen's GitHub.
Please let me know if the build instructions change when its pushed into the master and I will write it up and shout it from the rooftops. (And learn how to write a start script for all this).
Thank-you so much guys. Just amazing work.

[jontio]

Oh that is odd. I can't tell what's happening yet. With pulseaudio running and clients connected to pulseaudio from JAERO, on the low CPU option 10500bps the CPU jumps all over the show but using htop sometimes a core goes up to 100% for a second, on high CPU option 10500bps is constant but is maxes out a core.

From what I can tell is pulseaudio -k will do the same as sudo kill -15 pulseaudio. However sudo kill -15 pulseaudio says kill: failed to parse argument: 'pulseaudio' for me, to kill pulseaudio I used sudo killall pulseaudio. Either way pulseaudio should auto respawn when killed. To stop pulseaudio you need to stop the service. There seems to be 2 services related to it, a socket and a service so to stop it I used...

systemctl --user stop pulseaudio.socket
systemctl --user stop pulseaudio.service

When running 1 JAERO I get two connections from it to pulseaudio. I guess one for the beep sound and another for audio decoding?

When I kickoff the connections using pulseaudio -k I get the following from JAERO...

"Stream error: Connection terminated"
QSoundEffect(pulseaudio): Error in pulse audio stream

and the 2 streams get closed. Again the CPU jumps all over the show but a single core only goes up to 33% at peak. I'm not sure why having those streams open and not doing anything causes so much CPU usage.

When stopping pulseaudio altogether with

systemctl --user stop pulseaudio.socket
systemctl --user stop pulseaudio.service

and start JAERO I get the same lower 33% of a core usage.

Ahh I think I have it. It's audiooutdevice.cpp. It runs all the time for decoding audio; that's not good and should be fixed. A simple fix if you don't want to disable pulseaudio or kick of clients is to mute the audio in JAERO (green speaker icon)...

that seems to do almost as well. But for best performance I think stopping all services that you aren't using such as pulseaudio is the best way to go.

Another issue you may have is the plane log. Currently it sucks and loads everything into ram. That could eat up the RAM of the pi over time. As you're not using the plane log you might want to disconnect the signals going to the plane log. Really it should only be loaded when needed but that could be tricky to retrofit.

[jontio]

I have merged the pi build script into the master branch of JAERO and deleted the dev-pi-build branch. So building from a fresh install of Raspberrian is probably...

sudo apt install git
git clone https://github.com/jontio/JAERO
cd JAERO
./pi-build.sh

[thebaldgeek]

Thanks for the helpful comment about the audio.
One last question, you said ' disconnect the signals going to the plane log'. How do I do this?

[jontio]

I haven't tried it but I think commenting out connect(aerol,SIGNAL(ACARSsignal(ACARSItem&)),planelog,SLOT(ACARSslot(ACARSItem&))); and connect(aerol2,SIGNAL(ACARSsignal(ACARSItem&)),planelog,SLOT(ACARSslot(ACARSItem&))); in mainwindow.cpp should do the trick.

[jontio]

I added a setting to disable the planelog window that does the disconnections

[thebaldgeek]

Oh that's great! Thanks so much for that addition.
That's very helpful to a lot of us.

[thebaldgeek]

Jonti.
Thanks so much for the changes to the audio and logging.
I have had 3 people in total (me and two others) confirm that the Pi now builds quickly and cleanly.
The one overwhelming request from Pi and Window users alike is this....
Before the current alpha version gets turned, could one last change me made?
The title bar no longer shows the configured input device. Here are three images to show the issue:
Old Jaero:
New Jaero:

The label issue is the same for Window task bar and Linux:

Thanks for taking a look at this.

Ben.

[jontio]

Hi Ben,

Ah that was a mistake. I have also already released the version. I have pushed changes to show the settings in the title if given else it shows the version. It seems the new qt version doesn't show the application name when I used square brackets so it's now it shows a hyphen. I gave it a quick test on the pi, windows and kubuntu 20.04 and I think it is ok now. The CI has released it as a pre-release to https://github.com/jontio/JAERO/releases/tag/latest for windows and ubuntu-ish 20.04, confusingly it will have the same version info though. Let me know if it seems ok.

Cheers, Jonti