I find that gpredict is a beautiful convenient interface but I feel it is complicated to make gpredict work properly because it is dealing with hamlib for rotor and radio control which make trouble shooting difficult in my opinion…
I’ve tried to send issues I am having here without getting clear answer (not complaining, just report the facts) and submitting those issues to the hamlib support is not giving much more help as I am told to check with gpredict support…
When I find an issue in gpredict, what is the best way to report and more importantly, to help resolve the issue without being a programmer but rather a user ?
For example, I reported a IC9700 radio control issue where both Main/Sub VFOs are always being swapped while doppler is updated on top of the SPLIT function always turn on.
I’ve received an answer (thanks for that anyway) saying that it seem to be a known issue and also Alex does not have the radio on hand to test what is going on.
So how can I help then since I do have the radio and can run both hamlib with debug switch and gpredict ? How can I send information (and what to send) so other can fix things I can’t ?
Thank you all for the superb work that has been done throughout the years on gpredict !
If you are not a coder and don’t want to become one I think this is not possible.
If you like to start becoming one: just go ahead and pick some simple C projects and examples, make your first steps with git, etc.
I wish I knew how to program for sure but I don’t unfortunately… Not that I do not want but I don’t know how… and jumping in such a huge program (and just understand how the library works and how to get the code is a hassle already). I am here because I was told this was the place to post question about gpredict support…
It is disapointing knowing this now… like I said, gpredict is the most beautiful and efficient tracking software that I have found but like all the other softwares, support is abandoned and we are left with one choice that still has support but the interface looks horrible and I think I never swear that much at a software… when I saw gpredict, I was soooo happy… now not so much… back to square one again…
Please ask your hardware vendors for proper software support integrating with the open source ecosystem. Report interface bugs to your hardware vendor. If they don’t care, consider to choose other vendors.
@kerel Icom has release clear CIV protocol for their newest radios so information is there. gpredict/hamlib needs to be adapted to that available protocol, not the other way around like you are saying. Whatever brand don’t care about their devices not being supported when they release the full protocol, it’s the developpers who needs to adapt to the protocol, not the other way around.
Right now there is an issue where both Main/Sub VFOs are constantly being swaped to Sub/Main then back to Main/Sub on top of turning on the SPLIT function so, in my opinion, it is how gpredict/hamlib handle the protocol that make icom radios behave like that, not their protocol that they do provide.
I understand that it is difficult to test software when you do not have the actual gear but I do. Problem is I am not a programmer so my initial question was, how can I help then to improve things ?
@csete again, thank you for taking your time and reply to me.
I will send as much information as I can in a post to the link you provided and I’ll even try to video how the radio respond to the current control set. I’ll also grab some debug information on the hamlib IC9700 driver in a hope this will get sort out.
I even tried to use the IC910 driver (I simply changed the CIV adress of the 9700) and it does the exact same thing.
I sure do hope to see some movement on gpredict. I can’t understand how user use other interface on windows that date from 1990’ or 2000’ instead of gpredict… developpement shoud be here, not on these old clunky DOS like interface…
Thank you for showing some sign that everything is not lost about gpredict !!!