Install fails on Raspberry Pi 4 #82
Comments
|
Can you please check which Qt version you have installed? At least Qt 5.7 is necessary, preferably Qt >= 5.14 |
|
I have 2 versions of QT installed, the original Qt version 5.11.3 for
Desktop that is in the Raspberry Pi OS packager and Qt version 5.14.2 for
Desktop that I installed.
When installing qradiolink, for the qmake command, I used
"/opt/Qt5/bin/qmake .." to specify Qt version 5.14.2.
I used 5.14.2 because TLS was not supported until Qt 5.12. I had this
error: ../src/sslclient.cpp:32:32: error: 'TlsV1_3' is not a member of
'QSsl'
I specified the master fork. Below is the procedure I followed. The failure
was in make.
git clone https://github.com/qradiolink/qradiolink
cd qradiolink/
git checkout master
mkdir -p build
cd src/ext/
protoc --cpp_out=. Mumble.proto
protoc --cpp_out=. QRadioLink.proto
cd ../../build/
/opt/Qt5/bin/qmake ..
make -j3
As for gr-osmosdr, how does the installer choose to use it? I started with
the SDRplay RPI v.07 image, which has soapysdr and Cubic SDR installed. The
SDRplay API would have been preinstalled.
https://www.sdrplay.com/community/viewtopic.php?t=4211
*I did not use this: *This 'sdrplay3' branch is available here:
https://github.com/fventuri/gr-osmosdr/tree/sdrplay3
https://www.sdrplay.com/linux-gr-source/
...building osmosdr
https://osmocom.org/projects/gr-osmosdr/wiki
Makes reference to SDRplay RSP through SDRplay API library
Maybe I need to do a special osmosdr build? If you could look this over,
maybe you could make sense out of it.
…----Steve
On Fri, Nov 6, 2020 at 11:13 AM adrian ***@***.***> wrote:
Can you please check which Qt version you have installed? At least Qt 5.7
is necessary, preferably Qt >= 5.14
Also, I was not aware that SDRplay is supported by gr-osmosdr. Are you
using a fork or the official version? If it's indeed supported, I'd like to
add this information to the README.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMJK62XEDZAAHDSLG3TSOQOBTANCNFSM4TMKWE6Q>
.
|
|
Ok, let me check, I think the TLS v1.3 version define in the code is not correct, I'll adjust that so the build can pass with 5.11 as well. But the fact that it says it's missing QSslSocket is not normal. That's been a part of Qt since at least version 4, specifically the libqt5network5 library and corresponding headers. I can suspect that the Qt5 dev package (the headers required to build it) are missing some components. The dev package should be the same version as the version it is trying to link into. |
|
Regarding the SDRplay. If you are normally using it through SoapySDR, that's going to work, you just need the relevant Soapy plugin. If you don't, then you'll probably need a fork like the one you mentioned. As a general rule, if the device is usable in Gqrx, it will also be usable here since it uses the exact same gr-osmosdr API. |
|
Thanks. I just need to know how to install everything. Making it simpler
would have 12 hours of compiling QT and the potential errors.
Every step of the way was fraught with stumbling blocks. I am unable to
find instructions from anyone who has successfully installed it on RPI.
With the installation I have of Gqrx (on a separate installation), I have
to use Soapy Remote, which I don't like as it uses the network, which is
silly when used on the same machine.
Apparently, I don't know how to build it with SoapySDR included.
It appears that gr-osmosdr is listed in the QRadioLink requisites, so I
installed it. Also, there was a QRadioLink installation error related to it.
Error Resolved:
#include <osmosdr/sink.h>
compilation terminated.
…----Steve
On Fri, Nov 6, 2020 at 1:46 PM adrian ***@***.***> wrote:
Regarding the SDRplay. If you are normally using it through SoapySDR,
that's going to work, you just need the relevant Soapy plugin. If you
don't, then you'll probably need a fork like the one you mentioned. As a
general rule, if the device is usable in Gqrx, it will also be usable here
since it uses the exact same gr-osmosdr API.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMKS4XLP4EJLNHRUCLTSORABJANCNFSM4TMKWE6Q>
.
|
|
I'm afraid the only easy way is to have a distribution provided package, because the Raspberry Pi OS is not exactly similar to Debian although it's derived from it. I can't provide even Debian packages currently, because Travis CI which was used for this purposes does not support open source projects anymore. Re. SoapySDR support, in the official gr-osmosdr version this is built in so you don't have to do anything about it. But there are numerous unofficial forks floating around and I don't know about any of those. |
|
Any guidance is appreciated. Let me know if you have any answers. Enabling
me to use Qt 5.11 would be nice. I can restore my system to one from before
Qt 5.14.
I may also try qradiolink-0.8.3-5, but I prefer to use the latest.
…----Steve
On Fri, Nov 6, 2020 at 2:14 PM adrian ***@***.***> wrote:
I'm afraid the only easy way is to have a distribution provided package,
because the Raspberry Pi OS is not exactly similar to Debian although it's
derived from it. I can't provide even Debian packages currently, because
Travis CI which was used for this purposes does not support open source
projects anymore.
I know what sort of issues you are going through, I had the same problems
with raspbian in the past and eventually just ended up using Debian on it.
Re. SoapySDR support, in the official gr-osmosdr version this is built in
so you don't have to do anything about it. But there are numerous
unofficial forks floating around and I don't know about any of those.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMLRHE64HVLVL3GL25DSORDHJANCNFSM4TMKWE6Q>
.
|
|
I decided to try an older version of qradiolink on another installation
where I did not upgrade gnuradio and QT5. I hope I did it right.
Is there documentation for configuration and for the user interface?
git clone https://github.com/qradiolink/qradiolink
cd qradiolink/
git checkout 0.8.3-5
sh ./build_debian.sh
After installation, it started the program and it runs! How can I check the
version?
Here are my notes with text from the terminal:
***********************
[with soapy remote running]
pi@sospisdr:~/qradiolink/build $ ./qradiolink
qt5ct: using qt5ct plugin
[7/Nov/2020 00:41:49] [Info] Starting qradiolink
qt5ct: D-Bus global menu: no
[7/Nov/2020 00:41:50] [Debug] Looking up available audio devices
[7/Nov/2020 00:41:50] [Info] Using audio input device default
[7/Nov/2020 00:41:50] [Info] Using audio output device default
[7/Nov/2020 00:41:50] [Info] Setting VOIP bitrate to 24600
[7/Nov/2020 00:41:51] [Info] Using audio input device default
[7/Nov/2020 00:41:51] [Info] Using audio output device default
[clicked RX on GUI]
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.13.4
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf
rfspace airspy airspyhf soapy redpitaya freesrp
FATAL: Wrong rtlsdr device index given.
Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.
[Does not use soapy remote and Gqrx runs at this point]
***********************
Original RX device args: rtl=0
Tried the string from Gqrx: driver=remote,remote=tcp://192.168.1.76:55132
,remote:driver=sdrplay,soapy=1
Is there a string to try that will not require remote?
Will now receive. I had to play with the gains to get anything.
In setup > RX gains, There are the IF and RF gains, identified only by tool
tips. The level values are not labeled, but print in the terminal window as
the slider is moved.
Broadcast FM sounded OK. No Stereo. AM is really tinny. Is there something
shaping the audio?
The low audio freq cut helps with SSB, but I would like to be able to
adjust this.
Other demululators have different audio frequency responses. Is this
configurable?
The FreeDV demodulators have dropouts and glitches. The basic ones are
clean.
When adjusting RX gain on FM, it basically froze. It would come to life
occasionally.
Restarted the program.
AGC in Radio Settings seems to work when the gains are cranked to the
extreme (as a test).
Constellation doesn't display anything.
Now I need to figure out how to get something to transmit.
…----Steve
|
|
Ok, glad you could make it work. The only way to check version right now is to know either the version of the deb package installed or the git tag / commit hash from which it was built. When I have some time, I will try to add a command line parameter to retrieve the version at runtime. Most documentation, as far as I have been able to document it, is located in the docs/README.md file inside the repository. The constellation display is onyl needed for digital signals, BPSK, DQPSK, 2FSK and 4FSK (except FreeDV which has different internals). It will also be useful for the video signal or the IP modem signal. The video transmission in your older version has no sound. That is implemented on the next branch (development branch) but not part of any release yet. To transmit a text message, just press "Send text" or "Text file beacon" which will broadcast a text file on repeat. To stop text transmission, press "PTT" twice. |
|
Thanks for the operation tips. I need to figure out how to install the
newer version.
qradiolink is interesting because I should be able to get a transmitter
working with it.
I need to figure out how to use the non-network sdrplay driver. The
Internet says to use device string soapy=0,driver=sdrplay, but it doesn't
work for me.
The "freezes" that I was referring to was the application freezing. The
squelch is set fully counterclockwise. Large changes in the RX gain control
can cause the application to freeze.
The AGC does not seem to be working. If gains are set to hear weak
stations, audio clipping can be heard on strong ones.
Sometimes, decreasing attenuation seems to invoke AGC, but it does not
recover.
Sometimes turning up RX gain(atten) resets the AGC by appearing to have the
opposite effect.
After restarting the application, the gains are changed or reset.
As for AM sounding tinny, it is due to attenuation in the audio low
frequencies. With AM, the only bandpass adjustment is the width. That will
cut or extend the high frequencies of both sidebands, but has no effect on
the low frequencies, which are centered between the filter edges. The low
frequency rolloff would have to be done somewhere else.
On USB, changing the low cut which displays on the screen as you adjust it,
has no effect on the sound unless you adjust it past/higher than the high
cut. It cannot be adjusted lower than 200 Hz. The bandpass adjustment has
no effect on the FreeDV filters. LSB does the same thing in the opposite
direction.
…----Steve
On Sat, Nov 7, 2020 at 3:49 AM adrian ***@***.***> wrote:
Ok, glad you could make it work. The only way to check version right now
is to know either the version of the deb package installed or the git tag /
commit hash from which it was built. When I have some time, I will try to
add a command line parameter to retrieve the version at runtime.
Most documentation, as far as I have been able to document it, is located
in the docs/README.md file inside the repository.
Your audio "freezes" are most likely the squelch coming in and out, you
can adjust it manually and there is also an Autosquelch button which will
adjust it to squelch above the current level, so don't press it while you
want to listen to something.
SSB, AM, and FM filters are adjustable by dragging on the margins of the
filter box on the screen. You can also zoom in on the signal by hovering on
the bar where frequency numbers are displayed and using the mouse scroll
wheel or dragging left and right. Same for the vertical bar with signal
levels on the left.
Be aware that qradiolink is a voice communications transceiver, so it is
not really optimized as a receiver for best sound. If you need best sound
quality, Gqrx will be a lot better. The audio sample rate is only 8000 Hz
so it will cut out frequencies outside the human voice spectrum.
The constellation display is onyl needed for digital signals, BPSK, DQPSK,
2FSK and 4FSK (except FreeDV which has different internals). It will also
be useful for the video signal or the IP modem signal. The video
transmission in your older version has no sound. That is implemented on the
next branch (development branch) but not part of any release yet. To
transmit a text message, just press "Send text" or "Text file beacon" which
will broadcast a text file on repeat. To stop text transmission, press
"PTT" twice.
The tooltips will hopefully guide you from here. This being a hobby to me,
I don't always have time to properly document things.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMN4LGBGVXC3VU3AKCLSOUCZRANCNFSM4TMKWE6Q>
.
|
|
This is great feedback, much appreciate your taking the time to describe the issues. One issue at a time:
|
|
One other comment. Looking at your logs above I noticed this: If the system has Pulseaudio (default in most distros), don't use the |
|
1. SoapySDRUtil --find gives the 3 lines below:
Found device 0
driver = sdrplay
label = SDRplay Dev0 RSP1A 19110C0797
That makes the device string "soapy=0,driver=sdrplay", which is like what I
find on the Internet. It doesn't work in qradiolink or gqrx.
When I put it in RF device args, the terminal shows:
--
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.13.4
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf
rfspace airspy airspyhf soapy redpitaya freesrp
FATAL: SoapySDR::Device::make() no match
--
SoapySDRUtil --find="soapy=0,driver=sdrplay" does find the device.
4. I think this is the audio device that you suggested. Strangely, there
are no stereo devices. I know that with other SDRs, I can have FM Stereo.
The sound quality seemed to be the same on this or any device. While
messing around, the audio level decreased a lot. It's like the thing that I
referred to in the AGC issue. Restarting Soapy Remote and qradiolink
brought the audio level up to normal.
[image: qradiolink_audio.png]
It seems to me that the low frequency rolloff for music stations, AM and FM
should be really low.
5. The FreeDV filters don't work very well. They are full of pops, squeals
and random sound from who knows where.
Still, the plain USB/LSB filters default to a low cut of 200 Hz and
dragging that end doesn't do anything.
The frequency display can be adjusted by hovering over a digit and rolling
the mouse wheel. It works very well, much better than CubicSDR.
…----Steve
On Sun, Nov 8, 2020 at 2:13 AM adrian ***@***.***> wrote:
This is great feedback, much appreciate your taking the time to describe
the issues. One issue at a time:
1.
For soapy devices, what seems to help sometime when a device is not
found correctly, is to put in more parameters that SoapySDRUtil --find
gives in the string, without spaces. For example:
Found device 1
addr = 24607:1027
driver = lime
label = LimeNET-Micro [USB 2.0] 583A25BFD101
media = USB 2.0
module = FT601
name = LimeNET-Micro
serial = 00583A25BFD101
The device string could be
soapy=1,driver=lime,addr=24607:1027,serial=00583A25BFD101
To make matters a little worse, this also depends on which gr-osmosdr
is used. I have version 0.20 here and it behaves in a different way to
version 0.19.
2.
The freezes, I now remember a similar issue seen some time ago with an
early pre-production Lime board. The freeze is definitely caused by one of
my mutexes, but the root cause in that case was an issue in the Soapy Lime
plugin, which got fixed later so I didn't bother looking at that code
again. But now based on your description I think I may have to actually
change something in the code as a workaround.
3.
The AGC in GNU radio is a source of headaches, there are actually
three different blocks which behave in their own way, I will try to
reproduce the issues and change the parameters to the blocks.
4.
I don't really ever use AM, not having a shortwave antenna, but the
filter rolloff for low frequencies may indeed be too high. That can easily
be corrected. Probably the same for the SSB low frequency cutoff, although
SSB is different because it uses a complex taps filter for transmitting
which is tightly coupled to the receiver filter adjustment. There is
potential for improvement there, but needs changes to the UI code as well.
5.
FreeDV has a fixed width filter for the digital signal implemented on
FreeDV side, so changing the filter width on GNU radio's side will have no
effect, unless you mean for close adjacent SSB signals (they will only pass
through if FreeDV is not synced in digital mode RX, if FreeDV is
synchronized there will be no analog pass-through.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMPKWMPKJUDGC4V25FLSOZAIDANCNFSM4TMKWE6Q>
.
|
|
Just to clarify, the AM mode is meant for amateur radio not for receiving broadcast radio. So it is optimized for human voice spectrum. And the WideFM receiver is mono only, not stereo. |
|
I agree that Qradiolink would be best used for communications applications.
However, user’s choice would be nice for the audio quality. Those who use
AM like the audio quality it gives.
I have been thinking about trying to get the latest version working.
I have never used FreeDV. I ran it recently to see what it’s like, but I
don’t see anything I would use. It doesn’t seem to be able to access an
SDR.
The pops, click and squeaks in their filters are clearly not working right,
not in the other filters, and is very annoying. I could try to get an audio
recording is you would like.
…----Steve
On Nov 8, 2020, at 1:12 PM, adrian <notifications@github.com> wrote:
Just to clarify, the AM mode is meant for amateur radio not for receiving
broadcast radio. So it is optimized for human voice spectrum. And the
WideFM receiver is mono only, not stereo.
Have you used FreeDV before with an SSB transceiver? I think what you are
describing as noise is just random spurious decodes, they are quite normal.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMIEA2E6LV7YTCOMQJDSO3NPBANCNFSM4TMKWE6Q>
.
|
|
A recording would be good. I'm intrigued about what you're describing. FreeDV is a digital mode, and you need to be listening to a ham transmitting it to be able to decode. Is that what you are trying to do? Listening to any analog signals with it would be useless, it's not what it's meant for. It's fairly sensitive to accurate tuning due to the OFDM waveform, but otherwise very usable. |
|
I have to admit that I was unaware of the purpose of DV. They don't talk
about it on the air enough that I had ever heard of it.
The FreeDV filters do decode SSB and almost sound good, so I thought is was
supposed to work. One works fairly well.
I'll try DV later.
If you still want a recording, I can do that.
…----Steve
On Nov 8, 2020, at 3:11 PM, adrian <notifications@github.com> wrote:
A recording would be good. I'm intrigued about what you're describing.
FreeDV is a digital mode, and you need to be listening to a ham
transmitting it to be able to decode. Is that what you are trying to do?
Listening to any analog signals with it would be useless, it's not what
it's meant for. It's fairly sensitive to accurate tuning due to the OFDM
waveform, but otherwise very usable.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMPXCAXMT6GYAG2PVVDSO33N7ANCNFSM4TMKWE6Q>
.
|
|
After reading qradiolink/docs/README.md, I see that this program has a lot
of unique and interesting capabilities.
It seems to be written for those who already know what everything is and
how to do them.
Am I correct in assuming that with qradiolink, I will be able to run my
qradiolink radio station from a remote location over the Internet?
How can I use the FreeDV digital voice modulator and demodulator?
Apparently I don't need to virtually connect it to the FreeDV application
to get the demodulated audio.
I couldn't find any FreeDV signals on the documented frequencies late this
evening. I'll keep looking.
There are also a lot of digital filters and a video one. Are they to be
used on the air? I looked up the usual digital modes, but they don't match
the filter names. Are these the IP radio modems? I'll need more help to
figure that out.
I attached a recording of the FreeDV800XA LSB filter made using qradiolink.
I was tuned to an 80 meter signal.
…----Steve
On Sun, Nov 8, 2020 at 3:43 PM Steven Sostrom ***@***.***> wrote:
I have to admit that I was unaware of the purpose of DV. They don't talk
about it on the air enough that I had ever heard of it.
The FreeDV filters do decode SSB and almost sound good, so I thought is
was supposed to work. One works fairly well.
I'll try DV later.
If you still want a recording, I can do that.
----Steve
On Nov 8, 2020, at 3:11 PM, adrian ***@***.***> wrote:
A recording would be good. I'm intrigued about what you're describing.
FreeDV is a digital mode, and you need to be listening to a ham
transmitting it to be able to decode. Is that what you are trying to do?
Listening to any analog signals with it would be useless, it's not what
it's meant for. It's fairly sensitive to accurate tuning due to the OFDM
waveform, but otherwise very usable.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMPXCAXMT6GYAG2PVVDSO33N7ANCNFSM4TMKWE6Q>
.
|
|
|
1. Yes, I have been an amateur for 40 years. Combining the digital stuff
with it is new.
2. Thanks
3. I tried it today. I finally caught a FreeDV signal on the air. When
chatting on the FreeDV HF QSO Finder, I find that they are using FreeDV 700D
and qradiolink supports 700C. I'll have to wait for an upgrade to try it.
With this implementation, it would save a lot of configuration.
4. See 1.
5. I do need to read up on digital for amateur radio. There's more going on
than digital signal processing. I have been receiving FT8 for a few months
now. With GridTracker, I can easily see where the band is open. The digital
operating modes are new to me, especially the voice modes.
I tried installing the latest version on my system with Qt 5.11 after
seeing "The version check for TLS v1.3 was looking at the wrong version
#82" on github. I hoped that you had fixed it.
I still get:
./src/station.cpp
../src/sslclient.cpp: In constructor 'SSLClient::SSLClient(QObject*)':
../src/sslclient.cpp:32:32: error: 'TlsV1_3' is not a member of 'QSsl'
_socket->setProtocol(*QSsl::TlsV1_3*);
^~~~~~~
../src/sslclient.cpp:32:32: note: suggested alternative: 'TlsV1_2'
_socket->setProtocol(QSsl::TlsV1_3);
^~~~~~~
TlsV1_2
make: *** [Makefile:1396: sslclient.o] Error 1
make: *** Waiting for unfinished jobs....
…----Steve
On Mon, Nov 9, 2020 at 8:07 AM adrian ***@***.***> wrote:
1. Yes it helps if you have amateur radio knowledge.
2. Yes you can do remote operation via Internet
3. The same as the other modes, just select the appropriate modulation
and transmit or receive. FreeDV here is standalone, does not require
anything other than a SDR device.
4. They are not called digital filters. They are called digital
operating modes, the filters are just a DSP component in a larger chain.
And yes, obviously over the air. To use high power you need to have an
amateur radio license, these are generally issued by the state regulatory
agency following an exam. Contact some local hams in your country and they
will help walk you through the procedure to get licensed, it is not very
complicated, you just need to fulfill some legal requirements.
5. To learn more about digital signal processing, head over to the
https://www.gnuradio.org website or start looking at some amateur
radio resources online, there is a lot to learn but there are a lot more
interesting things to do as an amateur radio opeator than just shortwave:
microwave communications, sattelite operations, repeater operations etc.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMIVM6YBIQOZS6QEFVTSO7SSZANCNFSM4TMKWE6Q>
.
|
|
I found a binary package of Qt5.14.1-RaspberryPi3, which should run on my
Pi4.
I deleted the build directory, ran /usr/local/Qt-5.14.1/bin/qmake ..
re-ran make, which ran quite a bit longer, and ended in a new error. Can
you help me to determine what went wrong? Could it have used gnuradio 3.7?
I also installed gnuradio 3.8.
/usr/bin/ld:
gr_mod_ssb.o:(.data.rel.ro._ZTV10gr_mod_ssb[_ZTV10gr_mod_ssb]+0x40):
undefined reference to
`gr::hier_block2::set_log_level(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >)'
/usr/bin/ld:
gr_mod_ssb.o:(.data.rel.ro._ZTV10gr_mod_ssb[_ZTV10gr_mod_ssb]+0x44):
undefined reference to `gr::hier_block2::log_level[abi:cxx11]()'
collect2: error: ld returned 1 exit status
make: *** [Makefile:597: qradiolink] Error 1
Thanks, Steve
…On Mon, Nov 9, 2020 at 10:06 PM Steven Sostrom ***@***.***> wrote:
1. Yes, I have been an amateur for 40 years. Combining the digital stuff
with it is new.
2. Thanks
3. I tried it today. I finally caught a FreeDV signal on the air. When
chatting on the FreeDV HF QSO Finder, I find that they are using FreeDV 700D
and qradiolink supports 700C. I'll have to wait for an upgrade to try it.
With this implementation, it would save a lot of configuration.
4. See 1.
5. I do need to read up on digital for amateur radio. There's more going
on than digital signal processing. I have been receiving FT8 for a few
months now. With GridTracker, I can easily see where the band is open. The
digital operating modes are new to me, especially the voice modes.
I tried installing the latest version on my system with Qt 5.11 after
seeing "The version check for TLS v1.3 was looking at the wrong version
#82" on github. I hoped that you had fixed it.
I still get:
./src/station.cpp
../src/sslclient.cpp: In constructor 'SSLClient::SSLClient(QObject*)':
../src/sslclient.cpp:32:32: error: 'TlsV1_3' is not a member of 'QSsl'
_socket->setProtocol(*QSsl::TlsV1_3*);
^~~~~~~
../src/sslclient.cpp:32:32: note: suggested alternative: 'TlsV1_2'
_socket->setProtocol(QSsl::TlsV1_3);
^~~~~~~
TlsV1_2
make: *** [Makefile:1396: sslclient.o] Error 1
make: *** Waiting for unfinished jobs....
----Steve
On Mon, Nov 9, 2020 at 8:07 AM adrian ***@***.***> wrote:
>
> 1. Yes it helps if you have amateur radio knowledge.
> 2. Yes you can do remote operation via Internet
> 3. The same as the other modes, just select the appropriate
> modulation and transmit or receive. FreeDV here is standalone, does not
> require anything other than a SDR device.
> 4. They are not called digital filters. They are called digital
> operating modes, the filters are just a DSP component in a larger chain.
> And yes, obviously over the air. To use high power you need to have an
> amateur radio license, these are generally issued by the state regulatory
> agency following an exam. Contact some local hams in your country and they
> will help walk you through the procedure to get licensed, it is not very
> complicated, you just need to fulfill some legal requirements.
> 5. To learn more about digital signal processing, head over to the
> https://www.gnuradio.org website or start looking at some amateur
> radio resources online, there is a lot to learn but there are a lot more
> interesting things to do as an amateur radio opeator than just shortwave:
> microwave communications, sattelite operations, repeater operations etc.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#82 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AQQ3FMIVM6YBIQOZS6QEFVTSO7SSZANCNFSM4TMKWE6Q>
> .
>
|
|
If you're an amateur radio operator, great, it means you can use it to the full extent. Now, about your first error, the define in the code should check the version and not enable TLS v1.3 unless using Qt 5.14. I can only assume that the version check fails for some reasons on your system (multiple mixed Qt versions and the wrong one is found? I don't really know). And here is another curious thing: if you built 0.8.5-rc3 successfully, there is no dependency or version difference to the latest code from |
|
It looked like there was no easy way to separate gnuradio 3.7 from 3.8, so
I uninstalled 3.7. This caused qradiolink make to fail, so I
reinstalled gnuradio 3.8 and gr-osmosdr.
I ended up with gnuradio 3.8.2.0
I installed Release 0.8.5-rc3. I used git checkout master, which I
assume means the latest.
This time, the compiler completed. qradiolink runs, but I can't get it to
receive anything.
The terminal window displays:
[11/Nov/2020 01:35:13] [Info] Starting qradiolink
[11/Nov/2020 01:35:14] [Debug] Looking up available audio devices
[11/Nov/2020 01:35:14] [Info] Using audio input device default
[11/Nov/2020 01:35:14] [Info] Using audio output device
alsa_output.platform-bcm2835_audio.analog-mono
[11/Nov/2020 01:35:15] [Info] Setting VOIP bitrate to 24600
[11/Nov/2020 01:35:15] [Info] Using audio output device
alsa_output.platform-bcm2835_audio.analog-mono
When I click the RX button, 2 controls appear to the right of RX gain: IFGR
and RFGR which is what the 2 gain controls are called in my SDR.
Then the terminal displays:
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.2.0
built-in source types: file rtl rtl_tcp uhd rfspace soapy redpitaya
[INFO] devIdx: 0
[INFO] hwVer: 255
[INFO] SoapyRemote::setupRxStream(remoteFormat=CS16, localFormat=CF32,
scaleFactor=32767, mtu=1500, window=44040192)
[INFO] Client side stream bound to 192.168.1.76:36786
[INFO] Client side status bound to 192.168.1.76:57770
[INFO] Using format CS16.
[INFO] Server side stream bound to [::ffff:192.168.1.76]:38315
[INFO] Server side stream connected to [::ffff:192.168.1.76]:36786
[INFO] Server side status connected to [::ffff:192.168.1.76]:57770
[WARNING] StreamEndpoint resize socket buffer: set 43008 KiB, got 1024 KiB
[INFO] Configured sender endpoint: dgram=1452 bytes, 357 elements @ 4
bytes, window=1024 KiB
[WARNING] Set thread priority 0.5 failed: Operation not permitted
[INFO] Client side stream connected to 192.168.1.76:38315
[INFO] Configured receiver endpoint: dgram=1452 bytes, 357 elements @ 4
bytes, window=43008 KiB
Soapy Server says:
SoapyServerListener::accept([::ffff:192.168.1.76]:49224)
SoapyServerListener::accept([::ffff:192.168.1.76]:49226)
SoapyServerListener::close()
SoapyServerListener::accept([::ffff:192.168.1.76]:49228)
With squelch set to minimum and playing with the gain controls, I never get
anything on the display. Sometimes the S meter moves, then it freezes.
I can select the frequency by clicking on the display. It was initially in
the range of the frequency it had when I clicked RX.
If I set the frequency 1-2 MHz lower, for example, the display does not
move, but clicking on it changes the frequency to something in the range I
changed it to. The display does not zoom or scroll.
The display does work normally when RX is stopped.
Later I changed the frequency, clicked RX to stop it, and when I clicked RX
again to start, it displayed a signal panorama, but only one screenfull,
then it froze. Once, it worked long enough to get a tiny bit of the
waterfall to display.
------------------
The older version that I was initially successful with was 0.8.3-5.
When I got TLS error, I tried it with only Qt5 5.11 installed. There was no
other version at that time.
To identify the right Qt5 version, I used
/usr/local/Qt-5.14.1/bin/qmake ..
After installing gnuradio 3.8, I added
export PYTHONPATH=/usr/local/lib/python3/dist-packages:$PYTHONPATH
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
Later, I added /usr/local/Qt-5.14.1/bin to the path.
I did a ldconfig after gnuradio installation as instructed and also after
qradiolink although the instructions do not call for it.
Uninstalling gnuradio 3.7 and reinstalling 3.8 made the difference.
…----Steve
On Tue, Nov 10, 2020 at 2:35 AM adrian ***@***.***> wrote:
If you're an amateur radio operator, great, it means you can use it to the
full extent.
Note about FreeDV 700D: the current implementation of this mode has an
issue with having more than one instance of mod/demod loaded - when trying
to stop the receiver or transceiver by using the relevant button, the
program will segfault in libcodec2. Other FreeDV modes are not affected.
I've been meaning to contact David Rowe, the author of FreeDV, about this
issue, but I've been a little busy with other things lately. I actually
added 700D at some point, but removed it later due to the instability it
caused. I want to add it back too, but I'm not sure how hard will this
issue be to resolve on their side.
The other digital modes are for voice and text mainly for experimentation
with different DSP techniques. The prefix denotes the modulation type, and
the number suffix (1K, 2K, 10K etc.) denotes the effective bit rate. There
are 3 codecs used for digital voice (outside of FreeDV of course): Codec2
700C, Codec2 1400, and Opus 9400 bits per second.
Now, about your first error, the define in the code should check the
version and not enable TLS v1.3 unless using Qt 5.14. I can only assume
that the version check fails for some reasons on your system (multiple
mixed Qt versions and the wrong one is found? I don't really know).
The second error seems easier. Yes, I think it is trying to link into GNU
radio version 3.7 instead of 3.8. These things tend to happen when you mix
library versions, the good news is that it is usually fixed quite easy, by
having the appropriate PATH and LD_LIBRARY_PATH variables set.
You also need to ensure that the Qt / GNU radio headers (they are usually
in a package suffixed with -dev) are consistent. It can happen that qmake
uses one version of Qt for headers and another for ld to link into.
Of course, it also depends on you install locations, but usually (this is
what I do) the source build is configured to be installed in
/usr/local/lib and LD_LIBRARY_PATH has /usr/local before /usr/lib. I also
assume that you tried to run manually ldconfig already. My advice would
generally be aimed at Debian, since this is what I use everywhere, but I
hope the Raspberry Pi OS does not stray to far from normal defaults.
And here is another curious thing: if you built 0.8.5-rc3 successfully,
there is no dependency or version difference to the latest code from next
apart from some gstreamer plugins used for video mode transmission. So you
just need to ensure some consistency when switching builds and it should
work just as well. 0.8.5-rc3 requires GR 3.8 as well. I have to prepare for
work now, but if you do some research into having multiple library versions
installed in different locations, I'm sure you can pull this off. I do this
all the time, despite the general advice not to do it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMIBNGQUXJHDASB2UBDSPDUMVANCNFSM4TMKWE6Q>
.
|
|
I've been pretty busy at work these days, but it looks like you made good progress with the install, except for the Soapy Remote thing. I've made some changes to the code based on your feedback: enabled AGC for AM mode in addition to SSB, widened AM audio filter and changed it from bandpass to low_pass for better low frequency respose. These changes will be present in the next release along with other new features. If you manage to get a fully working installation on Raspberry Pi OS, it would be great if you wrote a short installation guide, this has been a pain point for many users who choose to use this OS. |
|
I have been able to get it to install, but I have no idea why it is not
working. I was hoping that you may know what is wrong with my qradiolink
installation.
Yes, I would be willing to share my procedure with the world, but I still
can't get the latest version to work.
I decided to start over. I removed the existing gnuradio, Qt4 and Qt5
installations. I reinstalled gnuradio 3.8.2.0 and gr-osmosdr
I installed the binary package of Qt-5.14.1
I also installed the latest gqrx from source. It uses gnuradio 3.8.
Initially it didn't run because it couldn't find libQt5Network.so.5.
After an hour of searching, I found that the LD_LIBRARY_PATH that I set in
.profile is being deleted by the operating system, so I had to add the path
to a file in /etc/ld.so.conf.d/ What a PAIN!
Now it runs and works well if I select the filter and mode options before
starting the DSP. When the DSP is running and I change things like LSB or
change the filter width from the pulldown menu, the panoramic display
freezes.
With that somewhat working, and on the new installation, I get more errors
when I run qradiolink.
Here is the terminal window contents
[14/Nov/2020 03:31:45] [Info] Starting qradiolink
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_num_locks
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_id_callback
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_locking_callback
qt.network.ssl: QSslSocket: cannot resolve ERR_free_strings
qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_cleanup
qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_init
qt.network.ssl: QSslSocket: cannot resolve sk_new_null
qt.network.ssl: QSslSocket: cannot resolve sk_push
qt.network.ssl: QSslSocket: cannot resolve sk_free
qt.network.ssl: QSslSocket: cannot resolve sk_num
qt.network.ssl: QSslSocket: cannot resolve sk_pop_free
qt.network.ssl: QSslSocket: cannot resolve sk_value
qt.network.ssl: QSslSocket: cannot resolve SSL_library_init
qt.network.ssl: QSslSocket: cannot resolve SSL_load_error_strings
qt.network.ssl: QSslSocket: cannot resolve SSL_get_ex_new_index
qt.network.ssl: QSslSocket: cannot resolve SSLv23_client_method
qt.network.ssl: QSslSocket: cannot resolve SSLv23_server_method
qt.network.ssl: QSslSocket: cannot resolve X509_STORE_CTX_get_chain
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf
qt.network.ssl: QSslSocket: cannot resolve SSLeay
qt.network.ssl: Incompatible version of OpenSSL
[14/Nov/2020 03:31:45] [Debug] Looking up available audio devices
[14/Nov/2020 03:31:45] [Info] Using audio input device default
[14/Nov/2020 03:31:46] [Info] Using audio output device default
[14/Nov/2020 03:31:46] [Info] Setting VOIP bitrate to 24600
I click the RX button. The two RX gain controls appear and ...
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.2.0
built-in source types: file rtl rtl_tcp uhd rfspace soapy redpitaya
[INFO] devIdx: 0
[INFO] hwVer: 255
[INFO] SoapyRemote::setupRxStream(remoteFormat=CS16, localFormat=CF32,
scaleFactor=32767, mtu=1500, window=44040192)
[INFO] Client side stream bound to 192.168.1.76:45122
[INFO] Client side status bound to 192.168.1.76:59098
[INFO] Using format CS16.
[INFO] Server side stream bound to [::ffff:192.168.1.76]:40946
[INFO] Server side stream connected to [::ffff:192.168.1.76]:45122
[INFO] Server side status connected to [::ffff:192.168.1.76]:59098
[WARNING] StreamEndpoint resize socket buffer: set 43008 KiB, got 1024 KiB
[INFO] Configured sender endpoint: dgram=1452 bytes, 357 elements @ 4
bytes, window=1024 KiB
[INFO] Client side stream connected to 192.168.1.76:40946
[INFO] Configured receiver endpoint: dgram=1452 bytes, 357 elements @ 4
bytes, window=43008 KiB
[WARNING] Set thread priority 0.5 failed: Operation not permitted
…----Steve
On Fri, Nov 13, 2020 at 4:28 AM adrian ***@***.***> wrote:
I've been pretty busy at work these days, but it looks like you made good
progress with the install, except for the Soapy Remote thing.
I've made some changes to the code based on your feedback: enabled AGC for
AM mode in addition to SSB, widened AM audio filter and changed it from
bandpass to low_pass for better low frequency respose. These changes will
be present in the next release along with other new features.
If you manage to get a fully working installation on Raspberry Pi OS, it
would be great if you wrote a short installation guide, this has been a
pain point for many users who choose to use this OS.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMIIQWT6IRRN6HO4MODSPT32ZANCNFSM4TMKWE6Q>
.
|
|
For the Qt Network errors, the hint is in this message: This warning: |
|
I just remembered another thing. When building gqrx, qmake failed on
osmosdr. I used cmake instead and it worked. I found other people who had
the same problem.
I am fairly certain that [WARNING] Set thread priority 0.5 failed:
Operation not permitted appears when starting gqrx also.
I tried running qradiolink with sudo and that message did not appear, but
there were other issues.
…----Steve
On Nov 14, 2020, at 4:39 AM, adrian <notifications@github.com> wrote:
For the Qt Network errors, the hint is in this message:
qt.network.ssl: Incompatible version of OpenSSL
This warning:
[WARNING] Set thread priority 0.5 failed: Operation not permitted
Might come from SoapyRemote. Since I've never used the Soapy remote
feature, I don't know if it means anything.
So, the question is: does reception work now or do you still have issues
with it?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMI4EXS3PWKNT77UUZTSPZF3XANCNFSM4TMKWE6Q>
.
|
|
I forgot to answer your question.
No, qradiolink is not working. I do not receive signals. When I press the
RX button, the 2 gain controls from my SDR appear, so I think it is
talking.
gqrx does work as described previously.
…----Steve
On Nov 14, 2020, at 4:39 AM, adrian <notifications@github.com> wrote:
For the Qt Network errors, the hint is in this message:
qt.network.ssl: Incompatible version of OpenSSL
This warning:
[WARNING] Set thread priority 0.5 failed: Operation not permitted
Might come from SoapyRemote. Since I've never used the Soapy remote
feature, I don't know if it means anything.
So, the question is: does reception work now or do you still have issues
with it?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMI4EXS3PWKNT77UUZTSPZF3XANCNFSM4TMKWE6Q>
.
|
|
I would suggest to solve first the reported OpenSSL compatibility issue. However, your main issue seems to come from SoapyRemote not receiving samples from the device. I have never used SoapyRemote, so I can't give any useful advice here. Perhaps you could ask on the SoapySDR discussion forum or bug tracker? I am not sure if the version of gr-osmosdr is the same as the one you were using before, but you might want to check that as well. |
|
Sorry about that. Apparently Qt is too quick to mark deprecations even if the new alternative is not yet available. I've reverted that commit now, so your build should pass. And I think I have an explanation for the weird AGC behaviour. Right now, the AGC attack and decay times are not linear as you would expect, they are exponential with powers of 10. So if the AGC updates every X seconds, for a value of 2, it would take it 100 seconds to decay, and for a value of 3 it would take 1000 seconds to decay. I think I need to add a more useful range for the values that is not exponential. Might take me a few tries though, because I don't have a shortwave setup and other signals on the 2 meter band and above are too weak to even need an AGC. |
|
Here are a couple of changes I made now: I've added AGC control dials to the main menu to be easier to tweak, and I've linearized the AGC range to the interval (-500, 500). This range may be too large, only values around the center are probably useful. Explanation of range values: -500 means it will take the AGC update loop 500 seconds to adjust attack and decay, while a value of 500 means the attack and decay will be adjusted 500 times per second. |
|
Found interval (-500, 500) to be too larged, reduced to (-25, 25) and lowered AGC reference voltage to avoid some clipping noise. You may find that the best attack and decay values are around the center of the dial. |
|
Until I ran a quarter wave 80 meter long wire outdoors, I used a wire
thrown across the floor. It could be the coax shield to your 2 meter
antenna or an extension cord. You should be able to find a good signal
somewhere.
The current AGC action is the best I've seen on QrRadioLink yet.
I found a decay setting that I like Decay just CCW of center. It is a long
decay, but sometimes the noise pumping in and out rapidly was apparent even
with the long decay. It was more noticeable with weaker signals, maybe
because the noise was more significant. Maybe change the response curve so
that the decay drops slower at first and decreases more rapidly as time
goes on, or adding a little "hang"?
For attack, it will take more experimentation. Theoretically, instant
attack would be optimal, but I don't notice too much change by turning the
control. I need a conversation where there are both strong and weak signals
and they allow time for AGC to recover between transmissions.
I haven't yet found anyone on the US standard FreeDV frequency of 14.236
MHz USB yet today. I'll eventually find someone...
The pull-down menus have a white background with yellow text. It has a
black highlight as the mouse passes over it, and that is the only time the
text is readable. I don't have any system settings that affect that.
I hope I don't have to upgrade Qt. My experience is that compiling takes
10-12 hours and always fails.
…----Steve
On Sun, Dec 13, 2020 at 6:12 AM adrian ***@***.***> wrote:
Found interval (-500, 500) to be too larged, reduced to (-25, 25) and
lowered AGC reference voltage to avoid some clipping noise. You may find
that the best attack and decay values are around the center of the dial.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMPPFG2RLZZBEEYLXALSUSOSHANCNFSM4TMKWE6Q>
.
|
|
The colors being off (yellow on white or similar) is caused by Gnome overriding my Qt CSS theme and replacing it with some other values from a local theme. In other words it's a Gnome/GTK theme bug, nothing I can do here. If you try to run it on a machine with KDE you will see it looks fine. There might exist a way to fix that by looking into what other desktop themes for Qt applications are available in Gnome. |
|
I'm pretty dissatisfied that Gnome users continue to have an inferior experience even after all the recent CSS styling effort I put through, so in the next days I'll try to spin up a Gnome VM to search for a workaround regarding visual theme. |
|
It looks to me like Gnome doesn't have tools to configure the UI that are
apparent in the Applications menu. There is an appearance settings app, but
it doesn't offer much. After searching, I found lxappearance that can be
launched from a Terminal prompt that is much better. You still can't change
the menu colors, but I was able to select a theme that had a black menu
background. None of this affected the QRadioLink menu.
There was a new RPI image released on Dec. 2. I want to see if they
included some recent packages...
…----Steve
On Mon, Dec 14, 2020 at 11:23 AM adrian ***@***.***> wrote:
I'm pretty dissatisfied that Gnome users continue to have an inferior
experience even after all the recent CSS styling effort I put through, so
in the next days I'll try to spin up a Gnome VM to search for a workaround
regarding visual theme.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMOCGTT726K5TYEOZSTSUY3XPANCNFSM4TMKWE6Q>
.
|
|
I tried to reproduce the graphical issue on a Gnome system but aside from a few minor glitches which are now fixed I can't reproduce the yellow on white menus problem. So the question is, what desktop environment are you using, and can you attach a screenshot here on Github. |
|
I've reduced the minimum AGC attack time to 2 msec (from 40 previously). I'm not seeing any marked improvement, hower my testing involves only locally generated signals. |
|
I tried it and I don't hear much difference. Attack seems to be good at any setting. |
|
There is no way in GNU radio's AGC to detect speech and treat it differently, so the "hang" feature is probably just slightly different voice timing you are seeing. I think the best setting is with a decay between 10 seconds and 1 second, so between 9 o'clock and 11 o'clock on the dial since decay is constant at a certain setting. I tried to test the settings by using a magloop and a HF receiver but no signals were strong enough here. |
|
I don't see any need to detect speech, just tailor the response curve not
to have quick decay shortly after the attack. Unlike most other receivers,
the noise swishing in and out during speech detracts from the clarity.
Is the magloop large enough to tune HF?
If your antenna feed line uses a PL259, just disconnect the shield and
leave the center connection in place. Maybe use a clip lead to connect the
feed line shield to the radio connector's center pin.
HF radio depending on the time propagates world wide, so there should be a
signal.
…----Steve
On Dec 22, 2020, at 2:12 AM, adrian <notifications@github.com> wrote:
There is no way in GNU radio's AGC to detect speech and treat it
differently, so the "hang" feature is probably just slightly different
voice timing you are seeing. I think the best setting is with a decay
between 10 seconds and 1 second, so between 9 o'clock and 11 o'clock on the
dial since decay is constant at a certain setting. I tried to test the
settings by using a magloop and a HF receiver but no signals were strong
enough here.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMIJQM5MBCG4YZBFPATSWBBERANCNFSM4TMKWE6Q>
.
|
|
You're right, ideally it should work like that. However, the AGC in gnuradio is not that advanced, it only has two configuration values: attack speed and decay speed (and a maximum gain). I think its main purpose always was digital signals (especially PSK). Some other applications like Gqrx for instance have their own much more advanced AGC code written from scratch and don't use the GNU radio one for analog modes. I decided to use the GNU radio AGC because implementing it from scratch would have been quite a difficult task which would take much more time than just use the existing AGC in GNU radio. But maybe going forward a custom AGC could be an option. |
|
Don't put too much effort into the AGC then.
Maybe GNU Radio will make improvements in the future.
…----Steve
On Wed, Dec 23, 2020 at 3:40 AM adrian ***@***.***> wrote:
You're right, ideally it should work like that. However, the AGC in
gnuradio is not that advanced, it only has two configuration values: attack
speed and decay speed (and a maximum gain). I think its main purpose always
was digital signals (especially PSK). Some other applications like Gqrx for
instance have their own much more advanced AGC code written from scratch
and don't use the GNU radio one for analog modes. I decided to use the GNU
radio AGC because implementing it from scratch would have been quite a
difficult task which would take much more time than just use the existing
AGC in GNU radio. But maybe going forward a custom AGC could be an option.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMIWA6GR53EVHN6CFP3SWGUIZANCNFSM4TMKWE6Q>
.
|
|
I have been trying out new Raspberry Pi installations and am finding that
qradiolink hangs on the first several initial runs, right after
installation. The SDR gains do not appear. I usually stop it after a while.
It really seems that it has to go through a timeout before it will start
the SDR. This installation was downloaded and installed on 1/22/2021
It will finally start, but the last time after the SDR gains appeared, it
crashed. The first message after the apparent timeout is:
Ncodec2frames: 4 n_speech_samples: 1280 n_codec_bits: 112 nbit: 28 nbyte:
16
This is the text from the terminal:
[22/Jan/2021 13:25:51] [Info] Starting qradiolink
[22/Jan/2021 13:25:51] [Info] No memory channels found.
[22/Jan/2021 13:25:52] [Debug] Looking up available audio devices
[22/Jan/2021 13:25:52] [Info] Using audio input device default
[22/Jan/2021 13:25:53] [Info] Using audio output device hw:CARD=b1,DEV=0
[22/Jan/2021 13:25:53] [Info] Setting VOIP bitrate to 24600
[22/Jan/2021 13:25:54] [Info] Using audio output device hw:CARD=b1,DEV=0
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.2.0
built-in source types: file rtl_tcp uhd sdrplay rfspace soapy redpitaya
[INFO] devIdx: 0
[INFO] hwVer: 255
[INFO] Using format CF32.
Ncodec2frames: 4 n_speech_samples: 1280 n_codec_bits: 112 nbit: 28 nbyte:
16
Ncodec2frames: 4 n_speech_samples: 1280 n_codec_bits: 112 nbit: 28 nbyte:
16
/home/pi/.gnuradio/prefs/vmcircbuf_default_factory: No such file or
directory
vmcircbuf_createfilemapping: createfilemapping is not available
gr::vmcircbuf_sysv_shm: shmat (2): Invalid argument
gr::vmcircbuf_sysv_shm: shmat (2): Invalid argument
gr::vmcircbuf_sysv_shm: shmat (2): Invalid argument
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.2.0
built-in source types: file rtl_tcp uhd sdrplay rfspace soapy redpitaya
[INFO] devIdx: 0
[INFO] hwVer: 255
[INFO] Using format CF32.
Ncodec2frames: 4 n_speech_samples: 1280 n_codec_bits: 112 nbit: 28 nbyte:
16
Ncodec2frames: 4 n_speech_samples: 1280 n_codec_bits: 112 nbit: 28 nbyte:
16
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.2.0
built-in source types: file rtl_tcp uhd sdrplay rfspace soapy redpitaya
[INFO] devIdx: 0
[INFO] hwVer: 255
[INFO] Using format CF32.
Ncodec2frames: 4 n_speech_samples: 1280 n_codec_bits: 112 nbit: 28 nbyte:
16
Ncodec2frames: 4 n_speech_samples: 1280 n_codec_bits: 112 nbit: 28 nbyte:
16
[22/Jan/2021 13:27:27] [Info] Stopping radio controller thread
[22/Jan/2021 13:27:27] [Info] Stopping audio input thread
[22/Jan/2021 13:27:27] [Info] Stopping audio output thread
[22/Jan/2021 13:27:27] [Info] Shutting down remote control interface
[22/Jan/2021 13:27:27] [Info] Shutting down Mumble client
[22/Jan/2021 13:27:27] [Info] Stopping qradiolink
After all of this, as usual, it worked.
…----Steve
|
|
See this old email thread about GR on ARM platforms, it references your error: https://lists.gnu.org/archive/html/discuss-gnuradio/2013-08/msg00479.html |
|
I need to find out why QRadiolink always fails at first, then always works.
The post that you refer to does not have enough information for me to run
one of the tests that they refer to.
Any links to more information lead to a 404 error.
$ sudo ctest -V -R
UpdateCTestConfiguration from :/usr/local/bin/DartConfiguration.tcl
UpdateCTestConfiguration from :/usr/local/bin/DartConfiguration.tcl
Test project /usr/local/bin
Constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
No tests were found!!!
I'll google this later, but everyone seems to assume i know what these test
scripts are. I don't seem to have them.
…----Steve
On Sat, Jan 23, 2021 at 8:51 AM adrian ***@***.***> wrote:
See this old email thread about GR on ARM platforms, it references your
error:
https://lists.gnu.org/archive/html/discuss-gnuradio/2013-08/msg00479.html
This is not related to qradiolink code.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMJKQFQXWS7ZHHF47MLS3LH47ANCNFSM4TMKWE6Q>
.
|
|
Right, that email thread was just informational, regarding some issues gnuradio seems to have on some ARM platforms. It might also be related to the support for your particular device. |
|
After looking into this further, it seems that one method doesn't work on
ARM.
gnuradio will go through 3 methods and find one that works. This has been
taking a long time.
home/pi/.gnuradio/prefs/vmcircbuf_default_factory now contains
gr::vmcircbuf_mmap_shm_open_factory
Apparently, we'll just have to live with it. I suspected QRadioLink because
it is the first application I run after a new install.
…----Steve
On Sat, Jan 23, 2021 at 3:59 PM adrian ***@***.***> wrote:
Right, that email thread was just informational, regarding some issues
gnuradio seems to have on some ARM platforms.
The clue being these errors:
/home/pi/.gnuradio/prefs/vmcircbuf_default_factory: No such file or
directory
vmcircbuf_createfilemapping: createfilemapping is not available
gr::vmcircbuf_sysv_shm: shmat (2): Invalid argument
gr::vmcircbuf_sysv_shm: shmat (2): Invalid argument
gr::vmcircbuf_sysv_shm: shmat (2): Invalid argument
It might also be related to the support for your particular device.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMPSRRJA6DCJA2D4ZRDS3M2EFANCNFSM4TMKWE6Q>
.
|
|
Ok, thanks for letting me know. I have only run qradiolink on armhf, but there are other ARM architectures and this problem in gnuradio could be occuring in a more recent version. Which arch are your running on your pi? Is it arm64? |
|
Raspberry Pi OS is 32 bit so ARM32.
Once qnuradio goes through its checks, it "fixes" this and QRadiolink works.
This is from some posts that I found.
GNU Radio allocates a large buffer to use for block input/output buffers.
It has about three ways to do this, one of which uses shmem calls. These
calls fail on arm due to some internal difference between x86 and arm. (I
forget what the detail is)Since this fails, it tries another allocator that
succeeds and saves this info in a dot file. I think you see the message
from gnuradio once, then you do not see it again.
The circular buffer allocator chooses from about three different ways of
setting up the buffer. The shm version does not work on ARM.
Look at /home/pi/.gnuradio/prefs/vmcircbuf_default_factory
You can override it in the ~/.gnuradio/prefs/vmcircbuf_default_factory
file. Just put in there the line (with no newline):
gr::vmcircbuf_createfilemapping_factory
And that will tell the system to use that method of managing the circular
buffers. Though it’s supposed to test to see if your system can handle the
shared memory method first before setting this prefs file. So I guess
there’s something different on the ARM that’s not being tested for
compliance here.
----Steve
…On Sun, Jan 24, 2021 at 11:52 AM adrian ***@***.***> wrote:
Ok, thanks for letting me know. I have only run qradiolink on armhf, but
there are other ARM architectures and this problem in gnuradio could be
occuring in a more recent version. Which arch are your running on your pi?
Is it arm64?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FML3RCDDX6GQYVDLMS3S3RF5JANCNFSM4TMKWE6Q>
.
|
|
Thanks for the update, I'll update the docs as well as soon as I get a chance. |
|
I’ll be trying to include QRadioLink to the aarch64 build of DragonOS, if I run into issues I’ll refer to this. What I wanted to point out though is that rsp_tcp can remotely or even locally run the sdrplay equipment. This in turn can then be accessed via gr-osmosdr just like rtl_tcp can. I’ve found it works rather well in other situations where I want to use sdrplay equipment w/ the newer API. |
|
I have come a long way since this posting. I have also been building aarch64 systems. I have tried 32-bit Ubuntu, 64-bit Debian and the pre-release Raspberry Pi OS 64-bit system. ----Steve |
|
I was able to build it and run it on aarch64 (Ubuntu 20.04). For the most part it seems okay when starting and using it with the hackrf. I used a debugger to see why sometimes and it would start showing the waterfall and sometimes it’d take awhile or not start. Actually not sure what was up, but I’ll go back and try my rsp1a. Do you have a good example of how to test the Tx side? I’d try Fm, am, etc and each time it would say I was selecting a frequency outside the allowed band. Getting slightly off topic here, sorry. |
|
By the way, this is the 64 bit image I’m working on. I just had to install a few of the decencies and then it built fine. https://sourceforge.net/projects/dragonos-pi64/files/ |
|
I think there are docs for QRadioLink on the github site and on your
installation directory.
Run QRadiolink with a terminal prompt so you can see the error messages.
There are transmit limits and it will either warn you or prevent
transmitting if you are outside of the IARU region bands.
I found that transmitting with the hackRF was somewhat flaky, but I was
able to do it. While it was on the 32-bit OS, I think it will work either
way. I haven't transmitted recently, though.
- For HackRF
- In RX device args, enter hackrf=0
- In RX antenna, enter 0
- In TX device args, enter hackrf=0
- In TX antenna, enter 0
- You may want to uncheck TX Limits if you are not in IARU region 1
Select a valid audio input device.
Enable TX and click the PTT button to start transmission.
…----Steve
On Sat, Jun 5, 2021 at 2:27 PM alphafox02 ***@***.***> wrote:
I was able to build it and run it on aarch64 (Ubuntu 20.04). For the most
part it seems okay when starting and using it with the hackrf. I used a
debugger to see why sometimes and it would start showing the waterfall and
sometimes it’d take awhile or not start. Actually not sure what was up, but
I’ll go back and try my rsp1a.
Do you have a good example of how to test the Tx side? I’d try Fm, am, etc
and each time it would say I was selecting a frequency outside the allowed
band. Getting slightly off topic here, sorry.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQ3FMOVSCTCLJE3MX4U3JLTRJUCVANCNFSM4TMKWE6Q>
.
|
|
Indeed only IARU region 1 band limits are implemented, so if you're in the US depending on frequencies you might need to disable TX limits in the settings otherwise the application will prevent you from even tuning the TX outside the hardcoded bands. |
|
Sorry I didn’t jump right back on here. I quickly figured out I had to uncheck the tx limit, but what I really need to be doing is learning all the bands! I was able to use it and will keep testing with the hackrf, b205, lime, and bladerf! Love the program - I just need to learn how to better use it. Some notes though, after reading above. I to have had some issues with starting qradiolink on the Pi4 with asrch64. Actually the program itself starts, but say I click RX with proper hackrf settings I can see in terminal the mention of gr-osmosdr as if it’s going to start up, but the waterfall stays empty and it just stays there. I’ll kill it a couple times and then suddenly is works after starting it all back up. I’ll get more detailed info after I build it all over again and include it in my img file. |
I have an SDRplay RSP1A.
After trying to satisfy all of the prerequisites and following the installation in README.md, the installation fails with errors.
Here is the last bit of installation messages:
In file included from ../src/mumbleclient.h:34,
from ../src/mumbleclient.cpp:17:
../src/sslclient.h:48:5: error: 'QSslCipher' does not name a type; did you mean 'QSslKey'?
QSslCipher getCipher();
^~~~~~~~~~
QSslKey
../src/sslclient.h:65:5: error: 'QSslSocket' does not name a type; did you mean 'QUdpSocket'?
QSslSocket *_socket;
^~~~~~~~~~
QUdpSocket
make: *** [Makefile:7622: mumbleclient.o] Error 1
make: *** Waiting for unfinished jobs....
In file included from ../src/mumbleclient.h:34,
from ../mainwindow.h:38,
from ../mainwindow.cpp:17:
../src/sslclient.h:48:5: error: 'QSslCipher' does not name a type; did you mean 'QSlider'?
QSslCipher getCipher();
^~~~~~~~~~
QSlider
../src/sslclient.h:65:5: error: 'QSslSocket' does not name a type; did you mean 'QUdpSocket'?
QSslSocket *_socket;
^~~~~~~~~~
QUdpSocket
In file included from ../src/mumbleclient.h:34,
from ../mainwindow.h:38,
from ../main.cpp:27:
../src/sslclient.h:48:5: error: 'QSslCipher' does not name a type; did you mean 'QSlider'?
QSslCipher getCipher();
^~~~~~~~~~
QSlider
../src/sslclient.h:65:5: error: 'QSslSocket' does not name a type; did you mean 'QUdpSocket'?
QSslSocket *_socket;
^~~~~~~~~~
QUdpSocket
make: *** [Makefile:7079: mainwindow.o] Error 1
make: *** [Makefile:6590: main.o] Error 1
Do I need to include any other information?
----Steve
The text was updated successfully, but these errors were encountered: