Raspberry Pi Support?

[Steve Haynal]

Hi Alan,

A few months ago you mentioned that it should be able to compile SparkSDR for Raspberry Pi, and you'd give it a try once the Linux version was more stable. Do you think the Linux version is stable enough now? I'd like to setup some remote stations but don't want to put in a full PC.

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

that's got me thinking, a few people have run Avalonia apps on Raspberry Pi but I rather got the feeling the gui performance is not quite there yet, but this is less important for a remote station.  I also want to setup a remote station so there is motivation there. I also have on the back burner an idea for a remoting protocol to connect multiple copies of Spark together. I shall go away and ponder.

73 Alan M0NNB

[Alan Hopper]

Steve,

the other option that had occurred to me was a Jetson nano version.

73 Alan M0NNB

[Steve Haynal]

Hi Alan,

Is it the waterfall guI performance which might be the issue? For remote usage, I'd be fine if there were a mode to disable any intensive graphics, and just live with a black boxes in waterfall places.

73,

Steve

kf7o

[Graeme Jury]

If a graphics stream was sent to the remote rather than a spectrum stream the lan traffic would be light. The remote could build a spectrogram and waterfall from that if required.

73, Graeme zl2apv

[Alan Hopper]

Steve, Graeme,

I'll try running a basic Avalonia app on a pi and see what happens, I've never tried this so my caution is based on comments on the Avalonia gitter so could be entirely unfounded.  My guess is the waterfall won't be too much of an issue, switching between receivers and updating spots etc might be slow (they are a bit slow on a pc but lots is happening in Avalonia which should improve this). Decoding lots of signals for skimming might be a challenge, I believe the red pitya code that decodes ft8 on the on board arm processor has to run at low decode depth to cope with 8 receivers, I don't know how that processor compares with the pi. 

There are lots of options for remote operation and I admit I've gone round in circles a couple of times thinking about it.

Btw there is an option in the later releases to turn off the small waterfalls that does save a little cpu.

73 Alan M0NNB

[Amogh Desai]

Hi Alan,

Will this be an armhf version or arm64 ?  Most the apps for arm64 architecture build and work on latest rpi and other SBCs like Pine64 that I own.  So would request to build it as arm64 version.

Last I tried to install armhf version (.deb package) of wsjtx, it wouldnt install on pine64. 

Regards,

Amogh

VU3DES

[Alan Hopper]

Hi Amogh,

I've not really got that far yet. For arm something like this https://github.com/pavel-demin/ft8d might be simpler than trying to get all of wsjtx to run and is all Spark needs.

73 Alan M0NNB

[Alan Hopper]

Hi All,

I finally had a go at running spark on a raspberry pi 2 this weekend, simplifying the build process for mac made it much simpler.It works but the gui is rather slow and I need to investigate a bit more before I release anything. A more powerful sbc is tempting especially if decoding on multiple bands/modes, at the moment I only have rpi1s and 2s, I don't want to end up with a big collection so I'm wondering what to put on my shopping list and what is favorite, pi4, pine 64, odroid, nano,??? ?   

73 Alan M0NNB

[John Williams]

NOT Pine64. I found the distro quality abysmal. My vote is for Pi4, but that is my bias as I just bought a 4GB one. Love it.

John

--
You received this message because you are subscribed to the Google Groups "SparkSDR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sparksdr+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sparksdr/0f808ff2-eeed-4eb2-b39e-d1bfda890330%40googlegroups.com.

[Graeme Jury]

Yes I will let my bias show and go for the Pi4 based on how well the Pi3 has gone for me.

73, Graeme ZL2APV

You received this message because you are subscribed to a topic in the Google Groups "SparkSDR" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sparksdr/198TALvyask/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sparksdr+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sparksdr/883f913d-2fc0-8293-2f17-84944f6316f2%40gmail.com.

[Rob Frohne]

I third the recommendation.  I have a Pine64, and it never worked.  Every raspberry pi I have used just worked, and the documentation and software support is much better than any other arm Linux hobbyist computer.

73,

Rob

KL7NA

On 2/25/20 12:07 PM, Graeme Jury wrote:

CAUTION: This email originated from outside the Walla Walla University email system.

To view this discussion on the web visit https://groups.google.com/d/msgid/sparksdr/a3ae3561-85a0-e873-cee8-7e49e3b7d229%40gmail.com.

-- 
Rob Frohne, Ph.D. P.E.
E. F. Cross School of Engineering
Walla Walla University
100 SW 4th Street
College Place, WA 99362
(509) 527-2075

[Jason Hitesman]

Yet another chiming in to express disappointment in the Pine64.  I want to like it but find the Pi ecosystem to be much more reliable.  I've only used the original Pi Model A (which didn't impress me at all) and the 3B (which did impress me) and have been considering picking up a 4 to play with specifically for SDR projects.  

Something about Pi kind of rubs me the wrong way, I see so many Pi projects that would be better with either a microcontroller or a full computer.  The Pi to me usually feels more like a solution in search of a problem and like most of the projects based around it are only based around it because someone had a Pi and wanted to find something to do with it - but the newer more powerful ones are starting to win me over.  

And the Pi definitely seems to be the most popular and well supported SBC out there which is a big benefit.  

[Joe LB1HI]

Hi group, we should not be guided by universality but should be guided by performance, computing power. Computing power that will ensure the smooth operation of Spark SDR. (with an upper price limit, for example around 100USD) The topic of this thread is not what universal SBC to choose for Ham Radio? But which SBC for SparkSDR. We are considering choosing SBC for special tasks with specific requirements, such as simultaneous reception for multi-band decoding at the same time.

(I am worried that the performance level of Raspberry Pi4B types etc.  It is not enough, It would be the bottleneck. It will work but there may be problems with the smooth use of the capabilities of SparkSDR with  Hermes hardware, and similar others.

73, Jozef, lb1hi

[Amogh Desai]

Hi Alan, 

Though I only own a pine64 for now, I will vote for RPI 4.  Pine has a very bad OS support hence the app support is also bad.  RPI is universal. widely accepted and has support from far more devs than any other sbc.  RPI4 is 2 to 3 times better performer than the PI3.

It's always going to be your choice if you want to choose some very very powerful SBC or something you just like. However I will request you too primarily support RPI as its just available everywhere and everyone supports it.

Regards,

Amogh

[f6ehp]

I just bought a Pi4 to drive a LimeSDR with PiHPSDR and must say how easy is the installation. A big improvement compared with the Pi3B.

[Alan Hopper]

Well my pi4 has not turned up yet but I have made some progress and am currently reporting ft8 on 20m from my pi2. There is loads of opportunity for optimization in the code but the basics are working surprisingly well on the pi 2. I hope to release something in the next few days if it proves reliable.

73 M0NNB 

[Alan Hopper]

Hi Group,

this is a very early release just for the really keen http://www.ihopper.org/radio/sparksdr2_0_1_0beta14_linux-armhf.tar.gz you will need to install portaudio and maybe boost, I recommend installing wsjtx before this. It takes ages to start up so be patient. You may need to turn on the opengl desktop in raspbian. Don't expect too much but I'm interested to know what it works on.

73 Alan M0NNB 

[Johan Maas]

Alan

I did install your sparksdr, using a rpi4.

Started very quickly; no problem at all.

See processor use...:

I was able to start 4 rx slices. Using 48K.

Also did a WSPR decoding run.

Using the mousewheel via vnc was not working to change freq. But clicking a digit in the display and using the arrow keys was working.

The audio settings where not persistent between two sessions.

I did add the cwx option to the radioberry... wanted to use that from the rpi; but your arm version is not based on a stable spark version i guess. 

Your first major step is set! GREAT WORK! I like it!

Looking forward to the improvements...

Johan

PA3GSB

Op vrijdag 28 februari 2020 20:07:33 UTC+1 schreef Alan Hopper:

[Alan Hopper]

Hi Johan,

great to hear it is working for you, It is actually the latest spark code but I think I'm doing something wrong with cwx. There is loads to do but the basics seem stable here, it has run for 48hrs without a blip.  Not much persists between runs unless you use the profiles or 'last session'. One obvious task is to make the gui behave better on small screens. I'm interested in talking to the radioberry directly and bypassing the udp stuff ( but probably not at the top of the ever growing list).  There are a few others using Avalonia on rpi but it is a minority use of a young product so I would expect a few issues like the mouse wheel but the Avalonia team never cease to amaze.  The mac and arm versions have been a bit of a distraction and I shall get back to finishing cw then rtty and then a performance idea I have which should help on rpi.  Did you have to install anything extra to get it running?  

73 Alan M0NNB

[Johan Maas]

Alan,

I have not installed additional software only the packages required to run the radioberry firmware and pihpsdr, only extracted your tar and runned sparksdr.

The first radioberry version running with pihpsdr (rpi-2) was without the udp stuff...but getting better performance using rpi-3 i decided to connect to the udp p-1 protocol (no special code for pihpsdr to maintain), creating a single component which could be used by different SDR products which implemented the p-1.

A nice idea to make a radioberry api for connection to sparksdr and pihpsdr, and also usable for the current radioberry firmware.

It was fun using the cwx option in sparksdr... it is working fine using the radioberry.

Have fun and goodluck making sparksdr running at different platforms, quite a challenge!

73 Johan

PA3GSB

Op zondag 1 maart 2020 20:52:50 UTC+1 schreef Alan Hopper:

[Alan Hopper]

Hi Johan,

please do let me know if I can add anything to better support radioberry.

73 Alan M0NNB

[Joe LB1HI]

This usefull for rpi4 speed https://jamesachambers.com/raspberry-pi-4-usb-boot-config-guide-for-ssd-flash-drives/
73, Jozef

[f6ehp]

No luck, Spark doesn't start on my Pi4

[Alan Hopper]

Hi f6ehp,

if you run for a terminal prompt ./SparkSDR what does it report? does ldd sparkcore.so report any missing dependencies?

73 Alan M0NNB

[f6ehp]

Hi Alan,

I have just installed portaudio19-dev, then extracted your files.

pi@raspberrypi:~/sparksdr2 $ ldd sparkcore.so
    linux-vdso.so.1 (0xbed77000)
    /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0xb6e0d000)
    libportaudio.so.2 => not found
    libasound.so.2 => /usr/lib/arm-linux-gnueabihf/libasound.so.2 (0xb6d18000)
    libpsk.so => /home/pi/sparksdr2/./libpsk.so (0xb6d00000)
    libboost_system.so.1.62.0 => not found
    libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6bb9000)
    libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6b37000)
    libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6b0a000)
    libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb69bc000)
    /lib/ld-linux-armhf.so.3 (0xb6f43000)
    libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb69a9000)
    libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb697f000)
    librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6968000)

pi@raspberrypi:~/sparksdr2 $ ./SparkSDR
bash: ./SparkSDR: Aucun fichier ou dossier de ce type
pi@raspberrypi:~/sparksdr2 $

I

[Alan Hopper]

Hi,

the ldd output indicates boost.system (from boost) and portaudio need to be installed.  I'm not sure about the other error, is SparkSDR marked as executable?

73 Alan M0NNB

[Peter Johnson]

Hi Alan.

Also failed to start on my PI3 B+ hope below helps.

pi@raspberrypi:~ $ cd sparksdr2
pi@raspberrypi:~/sparksdr2 $ ./SparkSDR
starting
avusegpu
libEGL warning: DRI2: failed to authenticate
loading sparkcore
loading ./sparkcore.so
Error loading ./sparkcore.so
loaded ./sparkcore.so
failed to load SparkCore
System.TypeInitializationException: The type initializer for 'radio.vtrx' threw an exception.
---> System.TypeInitializationException: The type initializer for 'radio.sparkCore' threw an exception.
---> System.ArgumentNullException: Value cannot be null. (Parameter 'ptr')
at System.Runtime.InteropServices.Marshal.GetDelegateForFunctionPointer(IntPtr ptr, Type t)
at radio.sparkCore.load_function[T](String name)
at radio.sparkCore..cctor()
--- End of inner exception stack trace ---
at radio.sparkCore.load_function[T](String name)
at radio.vtrx.LoadFunctions()
at radio.vtrx..cctor()
--- End of inner exception stack trace ---
at radio.wirelessModel.tryAddFavorite(Favourite fav)
at radio.wirelessModel.loadSettings()
at radio.wirelessModel..ctor()
at SparkSDR.App.OnFrameworkInitializationCompleted()
at Avalonia.Controls.AppBuilderBase`1.Setup()
at Avalonia.Controls.AppBuilderBase`1.SetupWithLifetime(IApplicationLifetime lifetime)
at Avalonia.ClassicDesktopStyleApplicationLifetimeExtensions.StartWithClassicDesktopLifetime[T](T builder, String[] args, ShutdownMode shutdownMode)
at SparkSDR.Program.Main(String[] args)
pi@raspberrypi:~/sparksdr2 $


73 Peter M1BCV

[Alan Hopper]

Hi Peter,

thanks for that, they key error here is 'Error loading ./sparkcore.so' this almost certainly means a dependency needs to be installed, probably boost or portaudio. ldd sparkcore.so will tell you what is missing. Hopefully I'll remove the boost dependency in the next release.

73 Alan M0NNB

[f6ehp]

Hi Alan,

After installation of portaudio, I get the same as did Peter.

So I wait for the next release.

Best 73  Pascal

[Alan Hopper]

Hi Pascal and All,

http://www.ihopper.org/radio/sparksdr2_0_1_0beta15_linux-armhf.tar.gz is much the same but has no boost dependency so should be slightly simpler to install.

73 Alan M0NNB

[f6ehp]

Thanks Alan for this new release, that looks working well in ssb, RX and Tune are ok, Because of a too small screen, I cannot test tx but I supose it works also.

(Test with a Redpitaya )

Pascal

[Alan Hopper]

Hi Pascal,

good to know it works. I have a plan to tidy up the layout to make better use of the screen at all sizes, I'll use the standard rpi 7" screen as the minimum size.

73 Alan M0NNB

[Peter Johnson]

Hi Alan,

The latest also works well here will do some more testing this weekend.

73 Peter M1BCV

> --
> You received this message because you are subscribed to the Google
> Groups "SparkSDR" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to sparksdr+u...@googlegroups.com

> <mailto:sparksdr+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sparksdr/ea900fcc-d4d8-4bb8-862f-bd9b37232b41%40googlegroups.com
> <https://groups.google.com/d/msgid/sparksdr/ea900fcc-d4d8-4bb8-862f-bd9b37232b41%40googlegroups.com?utm_medium=email&utm_source=footer>.

[f6ehp]

Hi Alan,

Yes I use a VU7 Odroid screen with the Pi4.  ( 7").  Perfect with PiHPSDR software, but too small for Spark. I will do more tests next week, but the mic was not recognized.

73.

[Ron Spicuzza]

Hi Group
I just wanted to let everyone know that Alans SparkSDR Rasberry Pi version is up and running.
I have received and transmitted on WSPER 40 meters for the past 24 hours. I selected FT-8 and watched
a few minutes of received messages just to see if that mode worked. It did.

My system is a Pi-4 with a small sd card which boots into an attached hard drive using
Jim Chambers methodology https://jamesachambers.com/raspberry-pi-4-usb-boot-config-guide-for-ssd-flash-drives/
I dont have a monitor or mouse and KB attached but am using XRDP to access the desktop.  it works flawlessly.
Thanks Alan.

73 KB3EDF

[Alan Hopper]

Hi Ron,

that's great to hear. Please do let me know of any issues as I don't have enough time to test everything thoroughly on every platform.

73 Alan M0NNB

[Johan Maas]

Alan,

Just to inform you:

I have created a device driver for radioberry. Makes it possible to bypass the UDP stuff which is normally required.

filename:       /lib/modules/4.19.97-v7l+/kernel/drivers/sdr/radioberry.ko

version:        0.1

license:        GPL

description:    Radioberry SDR device driver. (rpi-4)

author:         Johan Maas - pa3...@gmail.com

srcversion:     27CBFF6875C70CB62F21220

depends:        

name:           radioberry

vermagic:       4.19.97-v7l+ SMP mod_unload modversions ARMv7 p2v8 

73 Johan

PA3GSB

[Alan Hopper]

Hi Johan,

that sounds interesting, Avalonia has a mode where it works directly with the linux framebuffer and so bypasses the desktop so you can just have the kernel and your app installed, this might make a very lightweight standalone radio.

73 Alan M0NNB

[Joe LB1HI]

Hi group,

To use the acceleration of use Raspberry Pi by using an SSD drive, I can recommend a simple method. Works great

Instructions on this You tube video https://www.youtube.com/watch?v=5Qgno42VGPY  

73, Jozef, lb1hi

On Saturday, March 14, 2020 at 3:35:47 PM UTC, Ron Spicuzza wrote:

[Alan Hopper]

Hi Group,

this https://ihopper.org/radio/sparksdr2_0_1_4_linux-armhf.tar.gz tries to make it a bit more useable on the 7" rpi screen. There is a full screen mode '[ ]' and a button '^' to hide the toolbar, with both these done the simpler modes now fit the screen with no scrolling. All settings screens should now scroll if needed. I need to get a bit more clever to make the digi modes work well on a small screen. It also has the option to connect serial controllers as long as they emit midi data.

73 Alan M0NNB

[Johan Maas]

Alan,

Nice improvements. It is working better and better; some time ago i did give it a try but there is much improvement.

You understand i like to run it on the rpi together with the radioberry... so cpu usage is important.

Maybe nice for comparison:

spark 

pihpsd

Both running @48K using 1 rx slice.

Have fun.

73 Johan

PA3GSB

[Alan Hopper]

Hi Johan,

I'm a little surprised the cpu is so high, I have a number of things planned to improve it but it would be useful to know if the cpu drops when you make the window smaller and what pi you are running on. On one pi I did have to play with the desktop gpu settings to make the most of it.  Nice to know it still works with the Radioberry, I do very much like the neatness of it and intend to support it more in future (one step at a time though). 

73 Alan M0NNB

[Alan Hopper]

Hi Johan & all,

the performance on rpi on raspbian is generally greatly improved if you select one of the GL desktop options in raspi-config advanced.

73 Alan M0NNB

[Johan Maas]

Alan,

Tried the version https://ihopper.org/radio/sparksdr2_0_1_4_linux-armhf.tar.gz  

I see a decrease of about 10% of usage using the GL option.

When i do the minimize... the average usage is 25% for SparkSDR using 1 rx channel 48K.

The spectrum and waterfall are taking appearantly much of the cpu power...

73 Johan

PA3GSB

Op woensdag 20 mei 2020 12:06:26 UTC+2 schreef Alan Hopper:

[Alan Hopper]

hi Johan,

what rpi is this on? I see 16% with 1 48k rx dropping to 10% if minimised. This on a rpi4 with 7" screen. what screen resolution are you using? The display stuff in my code is particularly bad on arm as I have not used simd to optimize it as I have on intel. Avalonia has recently added a gl control which should allow me to use gpu shaders to do the work, this will benifit all platforms rather than writing arm specific simd but is more work.

73 Alan M0NNB

[Johan Maas]

Hi Alan,

Your 16% and 10% are sounding very good!

iam running a rpi-4 with 4G Ram.

Linux raspberrypi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

Using different resolutions from 1920x1080 downto 720x480 does not make any difference.

Running via HDMI or using vnc viewer no diffenrences.

I have a 7 inch touchscreen; i will try to run tomorrow with that screen. I will also try to run with HL2 iso of radioberry.

Real strange.... need to investigate further.

73 Johan

PA3GSB

Op donderdag 21 mei 2020 12:48:52 UTC+2 schreef Alan Hopper:

[Johan Maas]

Alan

I did not succeed in getting the CPU lower.

Did use the HL-2.

Tried:

• 7 inch touch screen
• hdmi different resolutions.
• fresh image; downloaded the latest raspbian buster; only configuration i did was setting  the GL driver.

All without luck. 

What is your rpi-4 setup? 

73 Johan

PA3GSB

Op donderdag 21 mei 2020 20:15:46 UTC+2 schreef Johan Maas:

[Joe LB1HI]

Hi Johan,
14 - 17 %  one RX 48k  window visible

4 - 7 % window minimalized 
Gateware 7p1
Spark SDR sparksdr2_0_1_4_linux-armhf.tar.gz
Rasbian Buster without recommended software
OpenGL desktop driver with fake KMS
arm_freq=1700

gpu_freq=700

If you are still interested in any other settings, I will gladly provide you  

73, Jozef
lb1hi

[Alan Hopper]

Hi Jonan & Jozef,

I wonder if we are using different measures, I'm using the Raspbian TaskManager that gives a total out of 100% over all cores, some other measures are based on one core so read 4x higher.

73 Alan M0NNB

[Johan Maas]

Alan

You are right.... we are looking to different meters!  

Iam always using top for measuring.... but now running the taskmanager i see the same figures.

Happy we have that clear! 

@Jozef thanks for sharing your settings:

arm_freq=1700  => must be 700 

 gpu_freq=700

When adding these to the config file the rpi is not booting anymore!

73 Johan

PA3GSB

Op vrijdag 22 mei 2020 15:39:18 UTC+2 schreef Alan Hopper:

[Johan Maas]

Jozef, Alan,

Based on the parameters Jozef was using i searched for more info about feasible settings.

I think this will give some nice info:

https://magpi.raspberrypi.org/articles/how-to-overclock-raspberry-pi-4

73 Johan

PA3GSB

[Joe LB1HI]

Johan, 
it works fine here with arm_freq=1700
it works even with arm_freq= 2000 but if I start too many receivers then RPI crashes. So arm_freq=1700 is optimal and runs 9RX over a long time period without a crash. Therefore I reduced  CPU to 1700 Mhz 

Active cooling is important for overclocking.

Use "Argon One" cooling case
It is a combination of passive and active cooling. It never goes to maximum speed so it's quiet.

over_voltage = 7

(with such overvoltage settings above 6  must bear in mind that the simultaneous activation of force_turbo force_turbo = 1 will void the warranty)

73, Jozef
lb1hi

[F5NPV Amateur Radio]

Hello,

I am using a RPI 3B+ and RASPBIAN . Currently SparkSdr is working well and using about 50% of the CPU with one receiver when using the following setup:

-I disable the tiny waterfall for the receiver display on the top

-Decoding deep : 1

-Disable auto for the waterfall

-I am not using Opengl Drivers

I can use Spark for up to 3 virtual receivers and the CPU reach about 80 to 90% . With 4  receiver I reach the limit of my 3B+

If I can make some recommendation , it should be great if we can disable the waterfall and keep only active Spectral view , I guess it will reduce significantly the amount of CPU .

73s Didier

 

[Alan Hopper]

Hi Didier,

switching off either or both of the displays is on my todo list. The waterfall actually uses less cpu than the spectrum display, you can reduce the load a bit by turning the persistence to zero. Does shrinking the window make much of a differnce? This should give an indication of the possible savings.  Have you tried the opengl desktop, it gave me a big boost on pi2 and pi4 ?  I still have lots of performance tweaks to do for pi/arm so it is good to know it is being used as is.

73 Alan M0NNB

[F5NPV Amateur Radio]

Hello ,

Shrinking the windows makes a little difference only as far i can remember . I will perform additional test this evening.
For the PI 4 i have noticed that for some application or software it is providing a significant enhancement regarding the CPU but for some things are worst and this is why i roll-back my shack with the RPI3B+. i have installed sparkSdr and few other like PIhpsdr and Quisk and the load is higher for all of them . SparkSDR on my RPI 4 is reaching mostly the maximum load with only one receiver,  for PIHPSDR , with the RPI4 the load is almost 50% on the RPI3B+ it is only 20 to 25%.

73s Didier

[F5NPV Amateur Radio]

Hello,

i am performing some test and according full screen or windowed , the CPU amount remain identical (Nothing i can measure visually)

73s Didier

Le mercredi 1 juillet 2020 13:05:37 UTC+2, Alan Hopper a écrit :

[Alan Hopper]

Hi Didier,

your rpi4 results sounds as if something odd is happening there. Is the waterfall and display scrolling smoothly? On my rpi2 the display had very slow frame rate until I enabled opengl (it made it 20x better in one case. In the next release I'll add an option to try differnt Avalonia gpu options in case the rpi3 is different. I've not got a rpi3 but the cpu sounds higher than I would expect, what samplerate are you using?

73 Alan M0NNB

[F5NPV Amateur Radio]

Hi Alan,

Yes something wrong with the RPI4 and thats why i roll back to the RPI3 which is really more mature in terms of libraries , drivers and maybe more . i guess we need to wait a bit to have something stable and mature .

According the waterfall , not really since i put all the waterfall setup at the minimum  level with the sliders . Mostly i focus only on the spectral display. 

Hereafter a screen shot and you will notice the CPU Load is acceptable during JT9 decoding i reach 66% ,  without decoding time the CPU level is about 42 to 47%  only . with 3 virtual receivers during 3 JT9 decoding the CPU is reaching about 80% , and with 4 virtual receivers i reach the maximum load during decoding .