CubicSDR
CubicSDR copied to clipboard
cjcliffe
Serial port, USB device list, Pulse Audio Missing
Hello,
I'm using Linux Mint 18.3 and I've the same problem with AppImage as described before : There is no way to enter serial port and I need it for Doppler Correction with GPredict.
So I've tried to compile the software by following this link : https://github.com/cjcliffe/CubicSDR/wiki/Build-Linux
After a long time, I finally succeed but I was disappointed because there was no "RigControl" in the menu. After many hours searching on the web I found a post with the magic line -DUSE_HAMLIB=1. You should add it to the wiki despite I was still unable to enter the port. I noticed that the entry Pulseaudio that appears in the AppImage version is not present on the compiled software and I still don't know how to add it.
My goal is to use CubicSDR to make a IF Panadaptor for my Yaesu FT-847. The problem will be to control the transceiver and get Doppler correction from GPredict too.
Another problem I have is that I have persistent name for my usb device like /dev/YAESU-CAT and this one is not listed because the software is filtering the devices list.
Thanks for help.
David.
@magellan-13016 for your CAT control issues you mentioned in PR #728 that you can enter the port but can't connect; can you confirm that your user has serial port device access? I found in Ubuntu here without setting up user device rules I had to run CubicSDR as root (via sudo) to access the serial ports.
You should also confirm that the radio is actually communicating over serial and the appropriate cable is being used (my Uniden scanner needed a 'NULL MODEM' type serial cable and specific baud rate). If you have another program that's working with your radio's CAT to confirm functionality it would be helpful.
Otherwise you should be able to see messages in the console (if you launch CubicSDR from the command line) which would likely display an error message from hamlib about permissions, inability to connect or other errors when initializing the rig.
As far as hooking in GPredict I'm not sure what to do; you should be able to get CubicSDR to track a remote program via the rig control; I've done it using FLDigi and the 'Hamlib NET rigctl' before where I was able to have CubicSDR follow the frequency control from FLDigi -- see https://github.com/Hamlib/Hamlib/wiki/FAQ#i-have-2-programs-which-use-hamlib-can-i-use-them-with-the-same-radio and https://github.com/Hamlib/Hamlib/wiki/Network-Device-Control for some basics on using rigctl.
Also I checked the Wiki and the line "Note: add -DUSE_HAMLIB=1 to cmake command line to include hamlib support." is already written directly below the "Building CubicSDR" header -- if there's something I can do to make it more visible then suggestions are welcome :+1:
@magellan-13016 here's a fresh AppImage build for testing:
CubicSDR-0.2.5-x86_64_AppImage.zip
Cheers.
Hi ! Many thanks for your help. I apologize for the Hamlib note below the "Building CubicSDR" header ! I don't know how I could miss it... I think I was to hurried to achieve compiling... Perhaps you could change the cmake line with hamlib option and write in the note to remove -DUSE_HAMLIB=1 for thus who don't need the rigcontrol. I think that most people would prefer the full version of a software instead of having to compile again when they need it. There is another but I noticed : At first start, when we click on a recent entry on the left, there is a redrawing error (see picture).
For my Yaesu, I will test again with your appimage later when I'll come back at home.
For the USB device list, we can now enter the port but I suggest to add a checkbox with the label "Show all" to avoid listing only ttySx and ttyUSBx. For those like me who have persistent name it would be nice since I have "YAESU-CAT" name for my CAT interface in /dev folder pointing to ttyUSB0 or ttyUSB1 according to the order the cable has been plugged to the computer because I have two differents cable for my transceiver. This avoid me to select the wrong device.
For GPredict, I would like to be able to correct Doppler effect like GQRX do because I really prefer CubicSDR which is more simple to use for me and students and it has some nice options that GQRX doesn't have ! The deal is that CubicSDR change the frequency in real time according to Doppler correction made by GPredict. Actually, in GQRX, we activate remote control via TCP and in in the remote control settings we enter the port to listen. In GPredict, we configure it to send the frequency in the same port and it's done. I think this would be one of the most interesting option in CubicSDR since both GPredict and CubicSDR are cross-platforms.
I invite you to have a look at http://f4bpp.com to see all my educational projects, press revues and videos.
Once again, many thanks for your help.
David.
Hello Charles,
I come back with some news. First, many thanks for the Appimage which is working better than the version I've compiled. In mine, there is no PulseAudio in device/Local list, I don't have squares on menu, and RigControl does not work. With the Appimage, it works sometime.
I've noticed many bugs and like the redrawing problem. For example, when we select a rig model, this one does not always act as a radio button and sometimes there is more than one device selected like Hamlib and another (yes I made many test ! ;-) .
I noticed that when some options are selected in the RigControl menu, they are marked with point instead of checked square. The software does not memorize the rig I've selected.
For the manual port, there is a big problem for me since CubicSDR does not store the one I entered. As I told you before, I've setup persistent names for my devices which are identified with their serial number. This allow me to set "YAESU-CAT" for my control cable. Whatever it is the first or the second connected, I use "YAESU-CAT" for the port and it is automatically redirected to the good port : USB0, USB1... Without that, I would have to change between USB0 and USB1 everytime.
But CubicSDR does not store this and sometimes it uses the wrong cable and switch my transceiver to transmit mode since I have to use 2 cables : one for rig-control and another for data transmission.
A big improvement would be to put the las rig selected on top of the list to avoid having to scroll all the list every time.
Thanks for considering all my feedback. I hope it will help to make the best SDR software and use it with all my students.
David.
@magellan-13016 here's an updated build; it fixes the rig selection issues, configuration reload problems and hopefully bookmark redraw issues:
When entering a manual port it will now remember and add the manual entry as the default selection in the port selector dialog.
To make your own ports appear automatically in the port selection list simply prefix your symbolic links with a typical serial prefix of "ttyACM", "ttyUSB", "rfcomm" or "ttyS" and it will appear automatically -- example: "rfcomm.YAESU-CAT".
For rig selection I think the manufacturer sub-menu collapse is a huge improvement for now; it may be moved to some sort of settings dialog in the future.
Waouh ! Amazing Work ! I'm going to test this version this evening. Many thanks for your help ! Things seems getting better very quickly. It's a chance for me having such developers. I'm now sure all my students will use CubicSDR for my educational project and I'll give you feedback about it.
I've just noticed that in the settings menu we can set rig control, serial port and rate. Until now I thought that it was just read-only informations. What's the difference with the Rig Control menu ? Can I use both (settings and Rig Control menus) to control my transceiver and update CubicSDR frequencies with GPredict ? How does it works ? Once again, many thanks for your work. I like it.
@magellan-13016 if you're seeing rig controls in the settings menu it's because you're using the 'SoapyAudio' audio input module; which also supports hamlib so that you can control the radio center frequency as if it was an SDR input device but hooked up to audio input instead.
Well, after some investigations, there is still a redrawing bug (see screenshot) . To get it, I found a way since I don't remember how I've got it. So I searched how to reproduce it. So, here is the way I found : Double-click on a recent entry then double-click on a view range (like 160m) then double-click again on a recent entry. I hope this will help you to find the problem.
About the rig control, all is now OK. I had the rig control on the settings menu because without my SDR dongle, I've tried with "Devices\Local\PulseAudio". With my Dongle plugged and selected, this entry disappears. So all is OK.
Now, I just need your help a last time. Could you install GPredict, the free cross-platform satellite tracker and find a way to get frequencies updated in real-time for Doppler correction like GQRX does ? With this software we have to choose the same port on both but if we only could have one fixed port in CubicSDR, it would be enough since in GPredict we can choose the one we want.
Perhaps it is already possible for CubicSDR to be controlled but I don't know how and the links to follow you gave me before didn't help me. So if you have an easy way to do that, please just tell me what I have to do. After that, I promise I will send you some photos of my students using CubicSDR for my educational project and perhaps that press review will talk about CubicSDR as a main part of my project ;-)
Many thanks, David.
@magellan-13016 seems like it might be possible to add basic GPredict remote support; I'll see what I can do :+1:
@magellan-13016 ahoy, I've managed to do this purely through hamlib as I initially thought might work.
First open a terminal and start a hamlib net rig control using hamlib dummy radio (model 1) and port 7356:
rigctld -v -m 1 -r localhost -t 7356
Which should result with:
rigctl and netrigctl will automatically detect vfo mode
Opened rig model 1, 'Dummy'
Closed rig model 1, 'Dummy - will reopen for clients'
This dummy rig can now be used as a hub between the two applications as they'll both talk with the 'dummy' radio and end up controlling each other:
You can also use any other hamlib supported radio instead of the dummy radio by providing a different model number with the '-m' flag; running rigctld --list will show available models.
Next set up a radio in GPredict (same as your previous settings):
You should now be able to Track and Engage with the 'CubicSDR' dummy radio:
In the rigctld terminal you should see the gpredict client connect:
Opened rig model 1, 'Dummy'
Next in CubicSDR from the Rig Control menu choose the model Hamlib -> Hamlib NET rigctl and manually set the Control Port to localhost:7356.
From the Rig Control menu make sure the following options are selected:
Tune the center frequency of CubicSDR into the range you want; place a modem on the waterfall that you'd like to frequency track and then click 'Enable Rig' from the menu.
If everything went well the modem should start following the frequency controlled by GPredict.
You should also see the additional connection from CubicSDR in the rigctld log:
Opened rig model 1, 'Dummy'
Only quirk I've noticed so far is that sometimes I have to Disengage and Re-engage GPredict before CubicSDR will stay connected, but then it works fine after that.
Ok ! Your solution is working very well. just hope you will add a dedicated GPredict menu so that things becomes more simple and avoid using terminal command line. The best deal would be to have a menu option to connect Gpredict and another one to enter the port to listen.
My computer runs under Linux but the school computers are all running Windows 10 and that's why I choose CubicSDR and Gpredict because they are both cross-platform. My goal is to do the same thing on windows so the students can work beside the main Linux computer with CubicSDR.
Anyway, I want to send you special thanks for all the good job you made for me. It's very awesome having such quick answers and solutions. Many people helped me for my project like radioamateurs, developers (SoundModem and MyDDE-847, QSSTV, UISS, and now CubicSDR) and i'm very touched by that because in the end, all this efforts is to help children having better self-confidence because whatever their difficulties, if they succeed in sending APRS messages through ISS or connect to its Personnal Message System, in their mind, they will be able to do everything in the life. That's why I'm working with this project and all people acting with are giving a special sense to their work. So many thanks to join the venture !
@magellan-13016 glad I could help, and best of luck with your projects!
I'll consider adding native GPredict support; it's very useful and would be nice to support without additional setup.
Wonderful ! I'm waiting for CubicSDR-0.2.6 eagerly. I hope that it will be operational with windows OS. If not I will try to find a solution like using another computer under Linux for the project but it would be a bit complicated.
What about the redrawing bug I talked to you ? Could you reproduce it ? An idea about what causes it ?
@magellan-13016 I was able to reproduce the redraw issue in the AppImage but wasn't able to find a proper workaround yet.
I'll post a windows build here for you soon for testing that includes the recent fixes.
Many thanks ! I've read many others bugs in the forum so I wish you good luck and success. I will wait for the 0.2.6.... it seems it will be a nice update !
@magellan-13016 there are now windows alpha test builds available in issue #742 that includes the most recent fixes and cleanups built with the latest version of visual studio.
Thanks for helping with this. It looks like Gpredict can send AOS and LOS signals over rig control. It might be possible to read these messages and start and stop recording for example for the busy and time challenged.
