Date   

Re: New package required to build freedv modules in 4.5.0

Edouard Griffiths
 

Hi,

"-DCODEC2_DIR=/opt/install/codec2" is missing in the final step to compile SDRangel. This has been fixed in the Wiki

Brgds, Edouard.


Re: Dockerized sdrangel

Edouard Griffiths
 

Hi Alain,

normally you should be able to fork and make PRs that's what all people do. Anyway this part is still very much under construction and is far from being in a workable stage and is going to be refactored heavily. Thanks for the tips indeed the last RUN commands have no effect when you start again the container.

I see you aim at a headless variant but sdrangel is the GUI variant and requires an X display with OpenGL. However the server variant must be also built as /opt/install/sdrangel/bin/sdrangelsrv.

Brgds, Edouard. 


Re: Dockerized sdrangel

alain@...
 

Edouard,

Thank you for the clarification.

I see you are trying to run those daemons via "RUN", which is incorrect.
I tried pushing a branch for a pull request but I have no permission to do that. In any event, at the end of the Dockerfile you should use something like this:

 

# Start some services on which SDRangel depends
COPY start.sh /start.sh
ENTRYPOINT ["/start.sh"]

and then add the start.sh executable in the same directory (make sure it is executable):

 

#!/bin/bash
sudo service ssh start
sudo service dbus start
sudo service avahi-daemon start
/opt/install/sdrangel/bin/sdrangel

Unfortunately, those modifications solve the first problem but reveal another one:


2019-03-03 22:14:28.932 (W) Unrecognized OpenGL version
2019-03-03 22:14:28.932 (W) Unrecognized OpenGL version
2019-03-03 22:14:28.933 (D) FFTEngine::create: using FFTW engine
2019-03-03 22:14:33.442 (D) FFT: creating FFTW plan (n=1024,forward) took 4509ms
2019-03-03 22:14:33.442 (D) GLSpectrum::connectTimer
2019-03-03 22:14:33.450 (D) DSPDeviceSourceEngine::addSink:  SpectrumVis
2019-03-03 22:14:33.450 (D) DSPDeviceSourceEngine::handleSynchronousMessages:  DSPAddBasebandSampleSink
2019-03-03 22:14:33.453 (D) DSPDeviceSourceEngine::setSourceSequence: seq: 0
2019-03-03 22:14:33.453 (D) FileSourceInput::FileSourceInput: device source engine: 0x55dd2f71dce0
2019-03-03 22:14:33.453 (D) FileSourceInput::FileSourceInput: device source engine message queue: 0x55dd2f71dcf8
2019-03-03 22:14:33.453 (D) FileSourceInput::FileSourceInput: device source: 0x0
2019-03-03 22:14:33.463 (D) DSPDeviceSourceEngine::setSource
2019-03-03 22:14:33.463 (D) DSPDeviceSourceEngine::handleSynchronousMessages:  DSPSetSource
2019-03-03 22:14:33.463 (D) DSPDeviceSourceEngine::gotoIdle
2019-03-03 22:14:33.463 (D) DSPDeviceSourceEngine::handleSetSource: set
2019-03-03 22:14:33.467 (D) MainWindow::setDeviceGUI: insert Rx tab at 0
2019-03-03 22:14:33.467 (D) MainWindow::setDeviceGUI: adding tab for FileSource
2019-03-03 22:14:33.467 (D) DSPDeviceSourceEngine::handleInputMessages: message: DSPSignalNotification
2019-03-03 22:14:33.467 (D) DSPDeviceSourceEngine::handleInputMessages: DSPSignalNotification:  m_sampleRate:  48000  m_centerFrequency:  435000000
2019-03-03 22:14:33.468 (D) DSPDeviceSourceEngine::handleInputMessages: forward message to  SpectrumVis
2019-03-03 22:14:33.468 (D) DSPDeviceSourceEngine::handleInputMessages: DSPSignalNotification: guiMessageQueue: 0x55dd2f7deed8
2019-03-03 22:14:33.470 (D) MainWindow::MainWindow: load current preset settings...
2019-03-03 22:14:33.470 (D) MainWindow::loadPresetSettings: preset [default | no name]
2019-03-03 22:14:33.470 (D) DeviceSourceAPI::loadSourceSettings: Loading preset [default | no name]
2019-03-03 22:14:33.470 (D) Preset::findBestSourceConfig: no match
2019-03-03 22:14:33.470 (D) DeviceSourceAPI::loadSourceSettings: center frequency: 0 Hz
2019-03-03 22:14:33.470 (D) DeviceSourceAPI::loadSourceSettings: source sdrangel.samplesource.filesource[0]:  not found
2019-03-03 22:14:33.471 (D) DeviceUISet::loadRxChannelSettings: Loading preset [default | no name]
2019-03-03 22:14:33.471 (D) DeviceUISet::loadRxChannelSettings: 0 channel(s) in preset
2019-03-03 22:14:33.471 (D) MainWindow::MainWindow: apply settings...
2019-03-03 22:14:33.471 (D) MainWindow::MainWindow: update preset controls...
2019-03-03 22:14:33.472 (D) MainWindow::MainWindow: registered resource file /opt/install/sdrangel/bin/sdrbase.rcc
2019-03-03 22:14:33.472 (D) StaticFileController: docroot=:/webapi, encoding=UTF-8, maxAge=60000
2019-03-03 22:14:33.473 (D) StaticFileController: cache timeout=60000, size=1000000
2019-03-03 22:14:33.473 (D) HttpListener: Listening on port 8091
2019-03-03 22:14:33.473 (I) WebAPIServer::start: starting web API server at http://127.0.0.1:8091
2019-03-03 22:14:33.474 (D) MainWindow::MainWindow: end
2019-03-03 22:14:33.495 (C) GLSpectrum::initializeGL: no current context
/start.sh: line 6:    65 Segmentation fault      /opt/install/sdrangel/bin/sdrangel

Is the segmentation fault related to OpenGL? I can't tell.
It would really be nice being able to have this running in Docker, at least for the headless client.


Re: Dockerized sdrangel

Edouard Griffiths
 

Hi,

Running in docker is not officially supported yet, I don't think you will ever see it mentioned anywhere yet. However I am exploring this and currently having a hard time with NVidia OpenGL on a Linux host. Actually this seems easier in Windows with Xming. Compilation should run smoothly though. At the end you should add:

RUN sudo service dbus start \
&& sudo service avahi-daemon start

The idea is to have a pretty much fail safe build from source in any environment getting rid of all the hassle and issues with package builds.

Contributions welcome...

Brgds,
Edouard.


Dockerized sdrangel

alain@...
 

Hello,
I'm trying to run the dockerized version of sdrangel but I am getting this error:

Alains-MacBook:~ alain$ docker run -it --rm -e DISPLAY=docker.for.mac.host.internal:0  alain/sdrangel /opt/install/sdrangel/bin/sdrangelsrv

[...]

ERROR: Unable to find host: Name or service not known
2019-03-03 15:54:43.536 (D) DeviceSoapySDRScan::scan: Lib Version: v0.7.0-g6d21756e
2019-03-03 15:54:43.538 (D) DeviceSoapySDRScan::scan: API Version: v0.7.0
2019-03-03 15:54:43.538 (D) DeviceSoapySDRScan::scan: ABI Version: v0.7
2019-03-03 15:54:43.539 (D) DeviceSoapySDRScan::scan: Install root: /opt/install/SoapySDR
2019-03-03 15:54:43.544 (D) DeviceSoapySDRScan::scan: loaded module: /opt/install/SoapySDR/lib/SoapySDR/modules0.7/libremoteSupport.so
2019-03-03 15:54:43.544 (D) DeviceSoapySDRScan::scan: driver: remote
[ERROR] avahi_client_new() failed: Daemon not running
sdrangelsrv: client.c:785: avahi_client_get_state: Assertion `client' failed.

Yes, It is a mac :)

I have no devices attached to this laptop as my plan are to use run sdrangel headless. Am I doing anything wrong?
Thanks for your help.

Alain


Re: New package required to build freedv modules in 4.5.0

James Dallas
 

Ahh! My wandering eye somehow skipped over that.


On Sun, Mar 3, 2019, 2:35 AM Edouard Griffiths <f4exb06@...> wrote:
Hi James,

what about just following the instructions in the Wiki page mentioned just above?

Brgds, Edouard.


Re: New package required to build freedv modules in 4.5.0

Edouard Griffiths
 

Hi James,

what about just following the instructions in the Wiki page mentioned just above?

Brgds, Edouard.


Re: New package required to build freedv modules in 4.5.0

James Dallas
 

Eduoard,

I interpreted it as, "you will need to build yourself."

What is unclear is what version of codec2 is needed.

I have tried with both 0.7 and 0.8 and doesn't seem to work.

Will try the development branch, but it looks like I'll need to figure out how to build that with speex.


On Sat, Mar 2, 2019 at 7:49 PM Edouard Griffiths <f4exb06@...> wrote:
Hello,

I am wondering how "Not distributed as a binary. Too complex to embed FreeDV library and packages are not up to date" in the first bullet of "Limitations" in the release notes should be interpreted.

Brgds, Edouard.


Re: New package required to build freedv modules in 4.5.0

James Dallas
 

Yes, I see that make tried to build the FreeDV modules after I downloaded libcodec2-dev, but failed because of some changes.

I am going to try to see if I can build latest codec2 and see if that works.

On Sat, Mar 2, 2019 at 7:54 PM Filipe Laíns (FFY00) <filipe.lains@...> wrote:

Hey,

To be fair, packages are up to date. You are depending on a development version.

Thanks, Filipe Laíns


Re: New package required to build freedv modules in 4.5.0

Filipe Laíns (FFY00) <filipe.lains@...>
 

Hey,

To be fair, packages are up to date. You are depending on a development version.

Thanks, Filipe Laíns


Re: New package required to build freedv modules in 4.5.0

Edouard Griffiths
 
Edited

Hello,

I am wondering how "Not distributed as a binary. Too complex to embed FreeDV library and packages are not up to date" in the first bullet of "Limitations" in the release notes should be interpreted. Also the wiki: https://github.com/f4exb/sdrangel/wiki/Compile-from-source-in-Linux has been updated accordingly.

Brgds, Edouard.


New package required to build freedv modules in 4.5.0

James Dallas
 

Hi everyone,

I didn't find it obvious in the release announcement, but since this version is only available to those building from source, you will need to install the codec2 package before building 4.5.0 on Linux to take advantage of freedv.

I tried building without it and it build, but freedv didn't show up, either in the GUI or as a compiled .so file. After going and looking at the cmakelist file, I realized that codec2 was needed.

So I did "sudo apt-get install codec2" then rebuilt. And that didn't work either.

I'm trying again after installing libcodec2-dev. I suppose I could also try building latest codec2 from source (the Ubuntu 18 repos use .07-1).

Anybody else have success, and if so, with what steps?


Re: How to set TX = RX frequency

Ondra OK1CDJ
 

Hi, it will be great if you give me some example how to do it..

Regrads, Ondra

út 26. 2. 2019 v 9:23 odesílatel Edouard Griffiths <f4exb06@...> napsal:

Hi,

I think this sort of thing was put in place for HackRF. However in the meantime the REST API was developed and is now the preferred way of managing the application with an external agent. This is typically the case where you would have a Python (typically) script running in the background that listens for changes in frequency on one sife and copies it over to the other side. This would aldo support heterogeneous Rx/Tx combinations. I'll try to post a gist or example in the examples directory to demonstrate this.

Brgds, Edouard




Re: Install from binary v source, missing swagger

Mick
 
Edited

Edouard,

Thanks for the very fast response. I will create a /opt/build folder and move them into the correct place as if I had built from source.

It might be worth adding that info to the binary releases wiki, it had me stumped for a bit but it wasn't a major drama. it just made me question if there were any other differences in the builds.

Thanks again for the quick response. The software is fantastic and with the availability of LimeSDR Mini and the recent arrival of the Amateur transponders on Es'hail-2 at 26E, I am sure the downloads server will be seeing plenty of traffic at the moment.

73

Mick
G1EUZ


Re: Install from binary v source, missing swagger

Edouard Griffiths
 

Hello,

at the moment the API client examples are not deployed anywhere. They are not essential to the working of the binary and completely standalone. I may think of deploying in a subfolder of the share directory for completeness.

Brgds, Edouard.


Install from binary v source, missing swagger

Mick
 

Hi,

Just checking I havent missed something, installed from binary on Mint 19 and everything is working.

I have just tried command ptt and had to download the source from git as the /build/swagger/examples are not included in the binary install. I assume I am not missing anything else and that I can move stuff around into the /opt directory or link to the downloaded sdrangel source folder .

If I am missing something else crucial I might compile from source, but everything else seems to be there.

Has anybody else, found anything else, missing from the binary version compared to compiling from source?

I already have LimeSuite and Soapy installed and the LimeSDR mini is recognised by the binary install.

Cheers

Mick
G1EUZ


Re: How to set TX = RX frequency

Edouard Griffiths
 

Hi,

I think this sort of thing was put in place for HackRF. However in the meantime the REST API was developed and is now the preferred way of managing the application with an external agent. This is typically the case where you would have a Python (typically) script running in the background that listens for changes in frequency on one sife and copies it over to the other side. This would aldo support heterogeneous Rx/Tx combinations. I'll try to post a gist or example in the examples directory to demonstrate this.

Brgds, Edouard


How to set TX = RX frequency

Ondra OK1CDJ
 

Hello all, is possible to set automatically tx to same rx frequency? I would like to use pluto as trx. 

73 Ondra OK1CDJ 


Re: usb relay board

James Dallas
 

Working example of point #1 using fldigi:

$ old_status=16736; while [[ 1 = 1 ]]; do status=$(sudo statserial -d /dev/ttyS0);if [[ $status != $old_status ]]; then if [[ $status = 16736 ]]; then echo OFF; else echo ON; fi; fi; old_status=$status; done

image.png


On Mon, Feb 25, 2019 at 12:14 PM James Dallas via Groups.Io <jim.dallas=gmail.com@groups.io> wrote:
Thank you Eduoard. I believe we had a similar discussion some months ago. So I can confirm you've been firm and consistent on this point. =D

FWIW here are some random thoughts for the group that I've had along these lines (TX/RX switching and such):

(1) There is a Linux program called statserial that you can use to monitor the status of a serial line (either real or virtual). A lot of software programs for digital ham modes (WSJTX, FLDIGI, etc) allow you to control rig PTT using a serial port line. Using statserial you could monitor the status of, say, the CTS line and use changes there to trigger a curl call to the sdrangel REST API, or trigger a relay using usbrelay (as linked to in my previous e-mail). Or both. At any rate, statserial can be used to build a bridge between "old school" (pre-SDR) ham radio software and sdrangel.

Example output on my Linux VM at work (I came up with this while taking a short stress break before serving patching last week):

image.png

(2) I wasn't aware of the reverse API, but this makes a lot of sense and I'll have to play around with that. Would definitely be better than having to loop / constantly poll the API to get the PTT status. 



On Mon, Feb 25, 2019 at 3:30 AM Edouard Griffiths <f4exb06@...> wrote:
Hello,

as already mentioned I am not going to support interfacing with ancillary hardware to make the code just more ugly than it is already. This subject has already been debated and the proposed and implemented solution is application collaboration using REST APIs. I forgot to mention it but since v4.3.2 a "reverse API" feature was put in place that if activated can route (nearly) all change events in SDRangel to an external application using the same REST API used the other way round and PUT or POST verbs. Check the wiki page here: https://github.com/f4exb/sdrangel/wiki/Reverse-API.
 
Think of it as a modern software oriented CAT interface. You wouldn't ask Yaesu or Icom to implement support for this or that GPIO board in their rigs firmware. This is a similar case here transposed to the software realm. So anything that you would like to support like PTT or filter switch-boxes has to be done through a custom DIY application that interfaces with SDRangel using its REST API. 
 
I have indeed enough work with maintenance and trying to develop new signal processing oriented features.

Brgds, Edouard.


Re: usb relay board

James Dallas
 

Thank you Eduoard. I believe we had a similar discussion some months ago. So I can confirm you've been firm and consistent on this point. =D

FWIW here are some random thoughts for the group that I've had along these lines (TX/RX switching and such):

(1) There is a Linux program called statserial that you can use to monitor the status of a serial line (either real or virtual). A lot of software programs for digital ham modes (WSJTX, FLDIGI, etc) allow you to control rig PTT using a serial port line. Using statserial you could monitor the status of, say, the CTS line and use changes there to trigger a curl call to the sdrangel REST API, or trigger a relay using usbrelay (as linked to in my previous e-mail). Or both. At any rate, statserial can be used to build a bridge between "old school" (pre-SDR) ham radio software and sdrangel.

Example output on my Linux VM at work (I came up with this while taking a short stress break before serving patching last week):

image.png

(2) I wasn't aware of the reverse API, but this makes a lot of sense and I'll have to play around with that. Would definitely be better than having to loop / constantly poll the API to get the PTT status. 



On Mon, Feb 25, 2019 at 3:30 AM Edouard Griffiths <f4exb06@...> wrote:
Hello,

as already mentioned I am not going to support interfacing with ancillary hardware to make the code just more ugly than it is already. This subject has already been debated and the proposed and implemented solution is application collaboration using REST APIs. I forgot to mention it but since v4.3.2 a "reverse API" feature was put in place that if activated can route (nearly) all change events in SDRangel to an external application using the same REST API used the other way round and PUT or POST verbs. Check the wiki page here: https://github.com/f4exb/sdrangel/wiki/Reverse-API.
 
Think of it as a modern software oriented CAT interface. You wouldn't ask Yaesu or Icom to implement support for this or that GPIO board in their rigs firmware. This is a similar case here transposed to the software realm. So anything that you would like to support like PTT or filter switch-boxes has to be done through a custom DIY application that interfaces with SDRangel using its REST API. 
 
I have indeed enough work with maintenance and trying to develop new signal processing oriented features.

Brgds, Edouard.

961 - 980 of 1565