PiScan - an SDR Radio Scanner

[fire42man]

"Persistent lockout" is synonymous to a lockout feature on most scanners - it will avoid that channel and will stay that way until you unlock it. My intentions are to compliment it with a temporary lockout feature at some point in the future, so you could lock a channel plagued by open mics and not have to remember to unlock it later.

DC31, if you don't absolutely need to use PulseAudio you should compile with ALSA or JACK. I'm not sure what it is with Pulse that causes these issues, but my hunch is that it relates to how it processes floating point numbers.

 

[davidVT]

PiScan seems to be working well for my needs.
I am using it now in place of a very old old scanner and audio usb combination that I used for like 7 years on a Pi.
This really simplifies my process and removes several problematic cables, components and controls.
Using the same antenna and preamp the cheap SDR is actually pulling weaker signals than I had before.
Looking forward to your future upgrades and really appreciating your work thus far!!

 

[davidVT]

trying to build in a new clean RaspberryPiOS 32 bit.
All went well into the build then...


Did I miss a step somewhere?
Thoughts?
Thank you

 

[fire42man]

trying to build in a new clean RaspberryPiOS 32 bit.
All went well into the build then...
View attachment 87078

Did I miss a step somewhere?
Thoughts?
Thank you

Try this: cmake ../src -DLIQUID_API_OLD=ON
There seems to have been a change in Liquid's API at some point but I haven't found any documentation on it

 

[DC31]

What audio library did you compile with? In my experience PulseAudio uses a ton of CPU to the point where it can't run on a Pi, but with ALSA everything works fine

I never got back to trying again on the Buster-Lite Pi. However, I did take your advice on compiling with ALSA on a GUI installation. Since I am using the sdr as an audio source for TTD I am locked into using pulseaudio. PA runs very well on top of ALSA allowing me to route the ALSA Audio to where I need it. My PiScan has been running 24/7 for about a week now in that fashion without issues.

Looking forward to future features.

Now, about that Apple CarPlay integration...

 

[davidVT]

Try this: cmake ../src -DLIQUID_API_OLD=ON
There seems to have been a change in Liquid's API at some point but I haven't found any documentation on it

Yep I can confirm that worked to complete the compile. Thank you
Now back to keeping it running. That means creating the systems.json in data directory and removing the comments.
also a good place to manually introduce the ppm adjustments into the required frequency. It is running on an older pi2b with the newest piOS32 as I edit this comment!!
Thanks for your help!

 

[davidVT]

Well you probably know what I ran into on the old pi....
Lesson learned..
I was able to tune it from the client on another pi. But this load won’t work out well.

 

[davidVT]

Well the 3b did better. I just swapped the sdcard and sdr and nothing else.

 

[davidVT]

Hello,
Seeking a little guidance again please...
(I bring these to the forum in hopes my lessons learned will help others... )

As a shortcut I first tried to copy compiled backend from one Pi to another without success. I tried a few variations and gave up for now. (An easy way to migrate between my herd of Pi's would be helpful... But this post is about a normal build process on Stretch...)

I then tried to simply follow the directions and fixes to run your build on this stretch Pi.
(I deleted the earlier shortcut attempts first, those having failed looking for libraries)
Your process went fairly well but for this one I am stuck on during the last 'make'....
Again, did I miss something?

---output from Pi Stretch on Pi3B+--
[ 2%] Built target sigproc
[ 7%] Built target core
[ 41%] Built target cubic
[ 47%] Built target external
make[3]: *** No rule to make target 'external/CMakeFiles/proto.dir/build'. Stop.
CMakeFiles/Makefile2:474: recipe for target 'external/CMakeFiles/proto.dir/all' failed
make[2]: *** [external/CMakeFiles/proto.dir/all] Error 2
CMakeFiles/Makefile2:123: recipe for target 'CMakeFiles/piScan_backend.dir/rule' failed
make[1]: *** [CMakeFiles/piScan_backend.dir/rule] Error 2
Makefile:131: recipe for target 'piScan_backend' failed
make: *** [piScan_backend] Error 2

 

[fire42man]

Hello,
Seeking a little guidance again please...
(I bring these to the forum in hopes my lessons learned will help others... )

As a shortcut I first tried to copy compiled backend from one Pi to another without success. I tried a few variations and gave up for now. (An easy way to migrate between my herd of Pi's would be helpful... But this post is about a normal build process on Stretch...)

I then tried to simply follow the directions and fixes to run your build on this stretch Pi.
(I deleted the earlier shortcut attempts first, those having failed looking for libraries)
Your process went fairly well but for this one I am stuck on during the last 'make'....
Again, did I miss something?

---output from Pi Stretch on Pi3B+--
[ 2%] Built target sigproc
[ 7%] Built target core
[ 41%] Built target cubic
[ 47%] Built target external
make[3]: *** No rule to make target 'external/CMakeFiles/proto.dir/build'. Stop.
CMakeFiles/Makefile2:474: recipe for target 'external/CMakeFiles/proto.dir/all' failed
make[2]: *** [external/CMakeFiles/proto.dir/all] Error 2
CMakeFiles/Makefile2:123: recipe for target 'CMakeFiles/piScan_backend.dir/rule' failed
make[1]: *** [CMakeFiles/piScan_backend.dir/rule] Error 2
Makefile:131: recipe for target 'piScan_backend' failed
make: *** [piScan_backend] Error 2

Currently the protobuf files are generated by bootstrap.sh because I haven't yet figured out how to make CMake play nice with proto compilation. This step can fail for any number of reasons, causing the proto step to fail. If that happens you need to cd into src/external/PiScan-protobuf and run protoc --cpp_out=. *.proto, then return to build and try compiling again.

 

[markrob7000]

I was able to get it up and running thanks to some of the earlier posts in the thread. I like it so far and hope to see development continued.

Thanks!
Mark

 

[davidVT]

Currently the protobuf files are generated by bootstrap.sh because I haven't yet figured out how to make CMake play nice with proto compilation. This step can fail for any number of reasons, causing the proto step to fail. If that happens you need to cd into src/external/PiScan-protobuf and run protoc --cpp_out=. *.proto, then return to build and try compiling again.

That hint helped. I was able to compile! Thank you

 

[fire42man]

Just an update for everyone, interning full time has kept me busy so progress has slowed to a crawl. With that being said, new features are on hold for now as I’m shifting my focus towards refactoring and cleaning up the codebase. My goal is to pave a path for contributors so that the project doesn’t have to be at the mercy of my free time