OP25 and a desktop icon

jmayson

Member
Database Admin
Joined
Dec 18, 2002
Messages
40
Location
Austin, TX
I had been pulling my hair out on this one. I solved the problem. I thought I would share here in case anyone else was running into this issue. Maybe it's just me.

I'm using a Raspberry Pi (i.e. Linux) for my setup using OP25 Boatbod. When I invoke my BASH script from the command line, all is well.

I created a desktop launcher icon (a .desktop file) and that runs said BASH script and I got a Python error saying "No module named OP25". Again, it works flawlessly when called from the command line. Why?

It turns out when I use the icon, my $PYTHONPATH variable from my .bashrc wasn't defined. I had to copy that line from my .bashrc into my BASH script that calls my rx.py script.
 

a417

!#
Joined
Mar 14, 2004
Messages
2,017
I had been pulling my hair out on this one. I solved the problem. I thought I would share here in case anyone else was running into this issue. <snip> .bashrc wasn't defined. I had to copy that line from my .bashrc into my BASH script that calls my rx.py script.
Which desktop are you using?

I seldom run OP25via my Raspi, but I have several physical installations of debian (usually xfce/kde) and I have never had a problem with making a standard launcher and running a script to launch OP25.

It might be something specific to Raspbian.
 

jmayson

Member
Database Admin
Joined
Dec 18, 2002
Messages
40
Location
Austin, TX
I just use the default desktop, LXDE. This post actually started out as a question, but as I was typing it a light bulb went off. I added a line to echo my $PYTHONPATH variable and saw it was empty when I launched from the desktop icon. So now it's part of my BASH script it's always set.

You're right, I use other Linuxes and have never seen anything like this.
 

sjacket99

FuzzThePiGuy
Joined
Dec 21, 2016
Messages
18
Location
Pa
I have my OP25 to auto open a terminal on boot and launch the OP25 software and open a web browser that shows the dash board. Works pretty good.
 

jmayson

Member
Database Admin
Joined
Dec 18, 2002
Messages
40
Location
Austin, TX
Here's my setup. Super high-tech as you can see. The Raspberry Pi keyboard is great, it feels solid without being bulky and I can plug my dongles into it instead of my Pi. So much easier.

20210130_212340.jpg
 

boatbod

Member
Joined
Mar 3, 2007
Messages
2,653
Location
Talbot Co, MD
Here's my setup. Super high-tech as you can see. The Raspberry Pi keyboard is great, it feels solid without being bulky and I can plug my dongles into it instead of my Pi. So much easier.

View attachment 98022
Nice setup.
If you run a RPi headless, short USB3 "extension" pigtails work well for plugging in multiple dongles at the same time.
 

KA1RBI

Member
Joined
Aug 15, 2008
Messages
589
Location
Portage Escarpment
The install process for OP25 should (ideally) install the OP25 python libraries and shared objects to a place already in the default python path. In this case there would be no need to set the PYTHONPATH env variable at runtime. The cmake step of the install process contains code to decide where to install the python libraries. As I recall this code (which comes from GNU Radio sources upstream to OP25) has a "colorful" modification history and accordingly I find it to be somewhat suspect.

In the osmocom repo there is a patch for building in python3 and GNU Radio 3.8. One of the provisions of this patch attempts to get the libs to install in a directory that is present in the default python path (exactly to try to preclude the problem reported by the OP, although this wouldn't necessarily help running python 2).

This all does however go to show that (1) the problem may be more widespread than the PI, and that (2) it's at least in theory possible to fix the issue at OP25 build time...

Max
 

a417

!#
Joined
Mar 14, 2004
Messages
2,017
As I recall this code (which comes from GNU Radio sources upstream to OP25) has a "colorful" modification
Worked with boatbod last week to find some GNU Radio 3.8 code that prevented compilation on a debian bullseye new install. I'm sure it's not the last problem that we will see.
 

boatbod

Member
Joined
Mar 3, 2007
Messages
2,653
Location
Talbot Co, MD
Worked with boatbod last week to find some GNU Radio 3.8 code that prevented compilation on a debian bullseye new install. I'm sure it's not the last problem that we will see.
Yup, and as best I can tell that was caused by something changing in the cmake files between gnuradio-3.8.1 (Ubuntu 20.04) and gnuradio-3.8.2 (Debian bullseye). I still don't have a good fix, just a dirty rotten hack of a workaround.
 
Top