Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doppler control bug on Icom IC-9700 #181

Open
Aleziss opened this issue Oct 28, 2019 · 32 comments

Comments

@Aleziss
Copy link

@Aleziss Aleziss commented Oct 28, 2019

Hello all,

I am trying to get the new Icom IC-9700 doppler control work but I get erratic control.

I did try to use the IC-910 driver from hamlib-w32-3.3 by changing the CIV adress to my IC-9700 and it does the same exact issue.

What is happening is that both Main/Sub VFOs are being swapped each time gpredict send frequecy correction to the radio which make VFOs frequencies swap to Sub/Main and then back to Main/Sub. Both frequencies are being updated though.

On top of that issue, the SPLIT function does turn on on the radio which complicate things even more.

Another issue I noticed is that when I transmit, the frequency stop being updated on the transmitting VFO but the receiving VFOs continues to work for a couple seconds until gpredict disconnect from hamlib, probably due to one of the VFO not responding while transmitting.

See text file of debug trace capture from rigctld hamlib-w64-4.0 (I let the doppler control work for a couple second without touching anything nor transmitting) using these switches: -m 381 -r COM5 -t 4532 -s 19200, remember, the radio behave the same exact way with the IC-910 driver from hamlib-w32-3.3 using these switches -m 344 -r COM5 -c a2 -t 4532 -s 19200. Some user reported that this seem to be a known issue with gpredict and hamlib with Icom radios but I can't verify and confirm for sure that this happend on other models at the moment.

You can SEE HERE how the radio behaves when running gpredict with rigctld hamlib v4.0.

The IC-9700 CI-V reference guide can be found HERE.

Thank you all for your help !

Rigctld Trace diag IC9700.txt

@Aleziss Aleziss mentioned this issue Oct 28, 2019
@Aleziss

This comment has been minimized.

Copy link
Author

@Aleziss Aleziss commented Oct 28, 2019

I may also add the following notes about the VFOs on the IC-9700.

In NORMAL operation with both VFO on, the TOP VFO (Main) is ALWAYS the TX and BOTTOM VFO (Sub) is ALWAYS RX.

In SATELLITE mode, it is the opposite, the TOP VFO (Main) is ALWAYS the RX and the BOTTOM VFO (Sub) is ALWAYS TX.

In both modes (normal/satellite), VHF/UHF frequencies CAN be swapped between both VFOs but the TX always remain at the same place (depending on being on normal/satellite mode).

It is also NOT possible to run both VFOs on the same band.

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Oct 30, 2019

The topic is, too, discussed here:
Hamlib Developer Mailinglist

Objet : IC9700 hamlib-w64-4.0
https://sourceforge.net/p/hamlib/mailman/message/36783570/

Maybe this information will help, to drill down to the real problem. I will get my IC9700 next week, then i can help to debug.

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Oct 30, 2019

some analysis work:
in the rigctrl-tracing file of Aleziss you see a regular cycle of gpredict calling rigctrl with the following:

--- start of a cycle

rigctl(d): t 'currVFO' '' '' ''  // get_ptt
rigctl(d): f 'currVFO' '' '' ''  // get_freq
rigctl(d): F 'currVFO' '145870639' '' ''  //set_freq
rigctl(d): f 'currVFO' '' '' ''  //get_freq
rigctl(d): i 'currVFO' '' '' ''  //get_split_freq
rigctl(d): I 'currVFO' '435218093' '' ''  //set_split_freq
rigctl(d): i 'currVFO' '' '' '' //get_freq

-- and a new cycle starts
rigctl(d): t 'currVFO' '' '' '' // get_ptt

now switching the focus on what hamlib v4.0 makes (did a fresh compile of the newest master branch of hamlib) for hard commands for -m 381(IC9700) from this, all is fine, but get_split_freq and set_split_freq use following hard Icom CI-V commands:

get_split_freq is separated in 3 steps:
a) fe fe a2 e0 07 b0 fd // exchange MAIN and SUB Bands
b) fe fe a2 e0 03 fd // read operating frequence
c) fe fe a2 e0 07 b0 fd // exchange MAIN and SUB Bands

the same behaviour when using set_split_freq. so hamlib switches short MAIN and SUB, to read or write the frequence of the SUB and then switching all back.

actual i think and guess a) and c) leads to massive switching in the display of IC9700.
i will test this with a small python script, when my IC9700 has arrived, and will give feeback here.

by the way: why is the PTT-Status checked every cycle? did gpredict use this information? Duplex-Transceiver should can switch the frequency during TX. so, IMHO frequence change have not to wait for PTT = off

there must be a solution :-) because on this video it is working fine https://www.youtube.com/watch?v=R1-vnHrARwk. Also frequency change, while TX.

@csete

This comment has been minimized.

Copy link
Owner

@csete csete commented Oct 30, 2019

Thanks for the info. Not sure why PTT is checked, it shouldn't be necessary if one selects full-duplex mode in gpredict.

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Oct 30, 2019

sorry, PTT is my fault. in the gpredict settings of transceiver setup you can define if you want to check PTT or not. i just switch it off. now the PTT status is not request.

i did some more analysis and hamlib has a subcommand for VFO.
rigctl V VFOA will switch to vfo a
rigctl V VFOB will switch to vfo b
rigctl V MAIN will switch to main
rigctl V SUB will switch to sub

at the moment, i guess, it is a better way not to exchange the MAIN and SUB to set and get the frequency.
But to switch with this vfo subcommand directly to the MAIN or SUB and then change the frequency there.

In the sourcecode of hamlib i see that IC9700 is implemented in sourcecode-file ic7300.c. so they just expand the ic7300.c for some IC9700 commands and the functionality of using the vfo subcomands V MAIN and V SUB are not implemented (the IC7300 just have no MAIN and SUB). They are also not implemented for IC910. so this might be the root of the problems, why many ICOM Transceiver are not working with gpredict.

they are only implemented for IC-9100, but at the moment i do not know if gpredict adress the command V MAIN and V SUB? when my IC9700 has arrived i will do testing with rigctl and IC9100 profil. i have checkout out github of gpredict and hamlib and have compiled the newest version of gpredict and hamlib. so i can test on the newest setup.

@csete

This comment has been minimized.

Copy link
Owner

@csete csete commented Oct 30, 2019

Thanks for the info, it is very helpful to understand the problems. Lately, I have been thinking that the best way forward might be to write our own rig server for the full-duplex radios since our use case is very specific and only requires implemeting a few CAT commands.

@Aleziss

This comment has been minimized.

Copy link
Author

@Aleziss Aleziss commented Oct 31, 2019

@dl7oap

The topic is, too, discussed here:
Hamlib Developer Mailinglist

Objet : IC9700 hamlib-w64-4.0
https://sourceforge.net/p/hamlib/mailman/message/36783570/

That is my post on sourceforge too.

@Aleziss

This comment has been minimized.

Copy link
Author

@Aleziss Aleziss commented Oct 31, 2019

@dl7oap

sorry, PTT is my fault. ....

but at the moment i do not know if gpredict adress the command V MAIN and V SUB? ...

So the menu in gpredict where we can chose if we like to use VFO as Main/Sub or A/B doesn't work then ?? I've tried all combinaisons and it always does the same thing. I thought those setting were there to accomodate radios that have different ways to use Main/Sub or A/B VFOs...

image

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Oct 31, 2019

Hi Aleziss, no, the menu himself is working correct. it is to early, i have to collect more facts.

but IMHO and for the moment my suspicion is, that it is not a bug in hamlib and not in gpredict.
the problem is that
a) IC910H and IC9700 is not completely integrated/implemented in hamlib, because VFO Subcommand MAIN and SUB are lack. [IC9100 it is implemented, so here we can do first test without gpredict]
b) and gpredict MAIN/SUB works ok for most radios, but for ICOM it have to call hamlib in a small other way

at the moment i wait for my ic9700, than i can give detail facts and a plan, how to solve this dilemma. i can develop in freepascal, python, java. C is not my favourit, but i can read it. i will try to extend hamlib v4.0 locally on my plattform, and when it works i will make a pullrequest to hamlib. and maybe there have to be a small adaption in gpredict. for a workaround i just developing a small python tcp server script which can be plugged between gpredict and the ic9700 which corrects this. but at the moment i develop this in a suspicion, because my ic9700 has not arrived.

i will give a signal here in 2-3 weeks, when i got the hardware and can check the facts. :-)
i am using linux, so i am very interested, that ICOM TX works with gpredict. for the last JOTA i have to use IC821H with Windows and SATPC32. But with the IC9700 i definitely will not switch back to windows.

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Nov 6, 2019

Hi, short very first feedback. ic9700 arrived today. i was using my prepared python adapter script between gpredict and ic9700 and dopplershift correction works fine for FM and SSB satellites.
the python script just open a tcp server where gpredict can connect, translate in a very easy first way the downlink and uplinkfrequence and is using fe fe a2 00 07 d 0fd (CI-V command to select MAIN) and fe fe a2 00 07 d1 fd (CI-V command to select SUB) to switch between MAIN and SUB Band and setting the frequence with standard fe fe a2 00 05 * fd via usb/serial.

so there will definitely (in the near future) a way that gpredict will work with ic9700. maybe for now with my pythonscript as workaround.

in the next days/weeks i will try to find a way to send MAIN (fe fe xa2 00 07 d0 fd) and SUB (fe fe xa2 00 07 d1 fd) via hamlib. maybe by implementing this missing feature in hamlib. it should be no big step.

as a last step (when hamlib will have this feature) we have kindly to ask, if gpredict could use a small other way to speak with hamlib while using icom transceiver.

@Aleziss

This comment has been minimized.

Copy link
Author

@Aleziss Aleziss commented Nov 7, 2019

@dl7oap thank you so much for the update ! is your python script currently replacing the hamlib driver ? I don't know much about that programming language but can it be ran under windows ?

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Nov 8, 2019

the pythonscript is replacing hamlib. it uses the correct commands. it is very rudimentary but i use it to test out the real civ-v commands and how the ic9700 reacts. i can send you the script. please contact me, via email on qrz.com.

In the last 2 days i monitored the serial communication between ic9700 and satpc32/satpc32iss with a hex-sniffer and have created a complete list of the used civ-v commands. now i compare these commands against hamlib sourcecode (freshest commit from hamlib repository) to find the correct request for rigctl.
Until now i have found 3 relvant civ-v commands which can not be called by hamlib for ic9700.

Next steps:

  • complete the necessary command list
  • fix hamlib
  • write a short concept/userstory how commands have to be used for SSB, FM and simplex (like ISS) satellites in gpredict
@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Nov 9, 2019

There is no need of fixing hamlib. All commands are already present in hamlib 4.0 (nightly build).

This is a list of all commands, which will be needed, to control IC9100, IC910H, IC9700 for satellite operation (SSB, FM and Simplex (like ISS)):

concept_command_mapping.pdf

Hint: IC9100 and IC9700 have the identical CIV-V commands here. IC910H has only one difference: rigctl G XCHG has the meaning of exchange VFO A and VFO B (and not MAIN/SUB).

Last step:

  • writing a short concept/workflow how to use these commands for SSB, FM, simplex-Satellites for IC9100, IC910H, IC9700
@Aleziss

This comment has been minimized.

Copy link
Author

@Aleziss Aleziss commented Nov 10, 2019

@dl7oap wonderful work you've done there, it is getting along pretty good I think ! I am trying to reach you to test your script (on windows ??) but it seem you don't have an email contact on qrz.

I see in your concept command list that there are commands to set tones and modes, that was another suggestion I set to implement in gpredict that it would be nice it could send those information to the radio and set it automatically with the parameters fetch from the internet.

good work, it's nice to see how you work on this and mainly, thank you for sharing the progress on fixing that issue with icom radios and gpredict !

@csete

This comment has been minimized.

Copy link
Owner

@csete csete commented Nov 10, 2019

@dl7oap many thanks for the info. I'm glad to know that there is a way forward :)

I hope we will be able to make this work with a command sequence that also works for the other full-duplex radios, i.e. FT-847 and TS-2000, and avoid radio specific sequences in gpredict. That has been the major concern for a long time. But at least now I have access to to IC-910H, IC-9700, FT-847 and TS-2000 and will also be able to test along the way.

I'm also glad to see many people being engaged in fixing these issues, thanks everyone!

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Nov 10, 2019

@Aleziss sorry, my fault, now you should find the email on qrz.com (you have to login). python 3.* works, too, with windows.

@csete i was in contact with Michael from hamlib, on this way i get the missing statements and he also did a cosmetic bugfix for me Hamlib/Hamlib@5df82b7

Today i was testing a typical inital start sequence for a satellite with ic9700 (setting frequency, mode, tone in main and sub) with 8 commands:

  • direct via serial interface this 8 commands are finished in 1ms
  • using rigctld and sending the commands via tcp i had to set a 20ms sleeping time between each command, because hamlib miss some or all commands if i was sending them faster than 20ms. so 8 commands need 160ms or a little bit more.

this is just a observation, which could be a reason to implement direct interfaces in gpredict. because this direct way is very fast. but hamlib is just fast enough, too. That's your decision :-)

@csete you are right, radio specific sequences, will be harder to maintain. it is always good to use standard. i just will write this workflow concept. it is already finished :-) but i will sleep 2-3 nights and consolidate it.

in rough the concept will describe a startsequence (one easy and one fullfeature, with tone and mode). And the loop for FM, SSB and SimplexSats(ISS) which have slight differences.

at the moment i build a new pythonscript which gets the type of satellite (FM,SSB,ISS) and listen on port 4352 to gpredict, and it sending rigctl commands on port 4372. i have setup rigctld to listen on port 4372. so this pythonscript is a "plugin" between gpredict and hamlib. (my first pythonscript was using not hamlib, but directly the serial interface). that's why i found this differences in speed (milliseconds). but i want to use the workflow of my concept few days so i can see, if there are some brainbugs in it. so i hope @Aleziss can test my script, too. 4 eyes see more than 2...

give me a week. I can only work on it in the late evening hours

@Aleziss

This comment has been minimized.

Copy link
Author

@Aleziss Aleziss commented Nov 11, 2019

again, wonderful work you've done there. Thank you for all the follow ups !

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Nov 12, 2019

The issue #42 should also be considered in this context. Some of the suggestions also fit here, for example the usage of V Main and V Sub with F.

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Nov 15, 2019

https://github.com/dl7oap/gp2hmlb

a small python 3.7 script which can be plugged between gpredict and hamlib 4.0 by using two TCP ports.
it can handle 2m and 70cm band and SSB/CW/FM/Simplex.
for CW and SSB the main dail of ic9700 can be used to change the downlink frequency.
on simplex frequency change is only done when PTT is not active.

this pythonscript is a workaround and alphaversion just for me to use gpredict with ic9700. it works here with Windows 10 and Linux.

I using this script to get a better understanding of the worflow of startsequence and the loop. But when there is some old man with the possibility to test it with ic9100 and ic910 this would be good.
it will help to write a good workflow process for gpredict for the ic9700 and the other icom transceivers.

and i hope we will find a way to implement this in a smooth way into gepredict.

@Aleziss

This comment has been minimized.

Copy link
Author

@Aleziss Aleziss commented Nov 15, 2019

I will take a look at your latest script. Thank you !

By what I see, this is far from being fixed by hamlib. It seem to be a lot more complicated than I expected. I ran the latest hamlib 4.0 and it is still doing the same issues even though I saw changes recently in hamlib for the IC9700...

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Nov 15, 2019

hi, hamlib works correct IMHO. but the hamlib commands, which gpredict is using, did not match exactly.
when you zoom wide out just

  • "S 1 Main" have to be "V Main"
  • "S 1 Sub" have to be "V Sub".
  • you can not use "i" and "I" with ic9700, because this exchanges the bands completely (between main and sub) and leads to the flickering you see. hamlib uses a uncomily way to read the split frequency (which is not a real split frequency, because its the frequency of the sub, not the split between vfo a and b). maybe this point is the only bug in hamlib.

I am not an expert, it would be good to have some more people to discuss with, to get a sharper understanding of the situation.

with this small pythonscript it works fine and it is, too, preparing all the tone, modes etc. and this script works with "V Main" and "V Sub" and "f" and "F" only to do the main work.

bye Andreas

@Aleziss

This comment has been minimized.

Copy link
Author

@Aleziss Aleziss commented Nov 15, 2019

@dl7oap Andreas, you are being modest when you are saying "you are not an expert", to my eyes, all of you programmers are !

Will test your script soon and keep a look on your github page.

@jh4xsy

This comment has been minimized.

Copy link

@jh4xsy jh4xsy commented Nov 16, 2019

@dl7oap, gp2hmlb works fine with my linux box/hamlib-3.3 & ic-910.

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Nov 16, 2019

what is the intention of hamlib command S 1 Main and S 1 VFOA?
when setting S 1 Main, means this i will get with "i" the split frequency of the Sub?
when setting S 1 VFOA, means this i will get with "i" the split frequency of the VFOB?

when this is the real intention, gpredict didn't need any fixing, but hamlib need a big fix.

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Nov 23, 2019

there was a bigger hamlib commit now for ic9700, ic9100 and ic910.
so the main commands you need for satellite control (for example activating TONE, disable reaptershift DUP, ..) are now available when you use the newest master branch of hamlib for ic9700, ic9100 and ic910.

Hamlib/Hamlib#143

icoms_in_sync_now

The horizontal split via VFO A and VFO B (within Main) and the vertical split between Main (currentVFO) and Sub (currentVFO) is under progress. But it is hard and tricky.

It seems that this topic is a problem for a lot of transceivers (for example TS-790), for a couple of years (found threads from year 2011 and older).
So for some transceivers hamlib seems to use MAIN as synonym for VFOA and SUB as synonym for VFO B. But for ICOM this is not true.

And in the moment i do not understand the methodic concept in general how hamlib command differ between this two (vertical and horizontal) split methodes.

so for SPLIT by Main and Sub (S 1 Main ?) we do not want that the original SPLIT-Icom-original-functionn is activating.. when we ask for split by Main and Sub we want that SUB is active and SPLIT-Icom-original-function is off.

maybe someone can explain me, how hamlib is design to solve this, but at the moment i think this is a problem of the design and it-architecture.

The easiest way seems to be to simply work with standard commands (V Sub, f, V Main), like in my python script, instead of using (S 1 Main, i), because hamlib command "i" is not really clear, what you will get (or how you will get > look at the flicker problem of icom transceivers).

@n2fvb

This comment has been minimized.

Copy link

@n2fvb n2fvb commented Nov 27, 2019

Hello all,
I'm a little nervous. First post on GitHub.
In a place with so much talent!

I love Gpredict!
I recently got an IC-9700, and have been playing with rigctl(d) and Gpredict.
Maybe I can contribute a little.
It seems that there may be some confusion.
The 9700 in satellite mode has an upper (main) display
and a lower (sub) display.
The term VFO normally refers to non satellite mode and each display has a VFO-A and VFO-B.
I think the "Set_split_freq" is only useful in non-satellite mode, and causes the strange behavior in Satellite mode.
I've been playing around with rigctl.exe -m 381 -r COM4 -s 115200 -vvvv.
When in satellite mode if I type "V Main" the display on the radio changes to upper display highlighted. Then if I type "F 446000000" the upper display (labeled main) changes to the desired frequency.
Then if I type "V Sub", the lower display (sub) gets highlighted, and if I then type
"F 146580000" the lower display changes to the desired frequency .
Put this into a loop and I think it would do what we want.
(Wish I knew how to do that!)

A couple of more notes. The "Main" and "Sub" displays cannot be on the same band.
In other words, U/U, V/V, L/L, is not possible.

The lower display (sub) is always the transmit display.

If changing satellite modes from U/V to V/U, the command:
"G XCHG" does what is expected, exchanging the frequencies from the upper and lower display. (lower display remains the TX frequency)

If I only use the "V Main", "V Sub", "F", and "G" commands, it all works as hoped.
Except I can't type fast enough to track a satellite ;-)

Also, I am able to change my transmit frequency while PTT is active.

From watching the -vvvv output of rigctld when running Gpredict, it would seem that there is a whole lot more going on here, especially if changing tones and modes etc.

I would love to see Gpredict running smoothly for this.
I do not have any of the other radios with this problem, but if I can help test something on the 9700 please let me know.
I have both Win10 and RaspberryPi running Gpredict and Hamlib, but only been testing commands on Win10 so far.

Thanks!
Ralf
n2fvb

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Nov 28, 2019

Hi Ralf,

All what you have found out, is correct.

Just take my python script https://github.com/dl7oap/gp2hmlb
it is doing the very fast typing for you :-) it's just use the way, your described. just worked on CW and SSB on satellites yesterday with my ic9700. its working fine with the python script.

But i am in contact with the hamlib developer and we are fixing hamlib.
At the moment, with the newest commit on hamlib master, gpredit will maybe already work correct. The last fix they did is to give a correct handling when you want to split by Main and Sub or by Vfo A and B.

Hamlib/Hamlib#148

This new fix have to be tested and verified now by us. So everybody is welcome to test the newest hamlib 4.0 nightly build and give feedback.

by the way:
When you speak of the command hamlib i/I "Set_split_freq" and "get_split_freq" please do not think in a narrow split sense. It is not the SPLIT function/command from the icom manual meant. But the general possibility to send and receive via a "main and sub" or " vfo a and b within the main".

welcome on github :-)
bye Andreas, DL7OAP

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Nov 28, 2019

ok, i did compile the newest hamlib master branch. it works now direct with gpredict (without my pythonmodul). using sat mode on icom. you have to set mode and the right frequency band on sub and main. And you have to activate the main on the display. No flicker anymore.
just use it on EO-88 in cw. works with a update rate of 100ms and faster :-)

i think hamlib is on the correct way now, but it is still not "smooth" and "plug-and-play". and i already seen some minor problems (so i was not able to activate a split via VFO A and B where hamlib command i/I gets/sets the VFO B frequency).

Mike is just committing a lot of stuff on hamlib master branch. so we should wait 1-2 weeks and then do a intensiv test of the newest hamlib version. he wants to introduce new vfos in hamlib.
so there will be a split by MainA and MainB or MainA and SubA.. so with the option --vfo a lot of options should be possible in near future.

@Aleziss

This comment has been minimized.

Copy link
Author

@Aleziss Aleziss commented Nov 29, 2019

That is some great news ! Also, I think there is movement on satnog to implant dedicated modes for each uplink and downlink. The programming seem to be done, the only thing missing is some aprobations and roll out the changes. This will simplify the use of the satellite data I think and gpredict will be able to use that data to maybe in a near future, push not only the frequency doppler correction but also set the proper up/downlink frequency, mode of operation for both up/downlink and tone control ! I am happy to see things evolve ! Thanks everybody !

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Nov 29, 2019

Hi,

i have setup some satellite memories on ic9700. one for SO-50 with 67,0 Hz Tone and 2m in Main and 70cm in Sub. And a memory with 70cm/USB on Main and 2m/LSB Sub and one with cw on 70cm on Main.
So now i can switch verify fast between CW and Voice on a SSB Satellite. i just select the suitable memory with the multicontrol. gpredict is just feeding the frequencies and you can change the memories without problem.

Working satellites is now easy. start ic9700. select satmode. choose one of the suitable memories, start gepredict and... making QSOs :-)

But Mike is still working on the hamlib split function.. but for the moment, the main problem is already solved... so choosing ic9700 modell on hamlib it should be possible even to work now with ic9100 and ic910 without problems.

@n2fvb

This comment has been minimized.

Copy link

@n2fvb n2fvb commented Nov 30, 2019

Hello all,
Just downloaded hamlib-w64-4.0~git-686acaec-20191129.exe
The core functionality seems to work well now with Gpredict 2.3.37.

But when I change from a U/V satellite to a V/U satellite, it does not exchange the Main/Sub displays.
Hamlib does not seem to know that it cannot write a 145.xxx if the current frequency in the other (main/sub) band is 145.xxx
I have to disEngage Gpredict , manually exchange, and reengage and it works fine again.

Next, if we could get Icom to change satellite mode display so it doesn't change the highlighting and focus of the dial when hamlib sends frequency updates, it would be a joy to operate.

Thanks again to all who are working on these things!
Ralf
n2fvb

@dl7oap

This comment has been minimized.

Copy link

@dl7oap dl7oap commented Nov 30, 2019

Hi,
that's why i did set up satellite memories. so i can switch very fast manually to the different types of satellites (FM, SSB, U/V,V/U, with cw or lsb in the uplink). And yes, you have to active the main band (highlighting) by yourself, at the moment.

the actual plan is the following:

  • Mike from hamlib is fixing hamlib, so it will work with the different split operations, which are possible with satellite transceivers like IC910, IC9100, IC9700. He will get a icom 9700 in the next days, so he is able to test by himself. he wrotes, that he plan to finish this near christmas. you can follow the commit here: https://github.com/mdblack98/Hamlib
  • thereafter (and during development) we will intensive testing hamlib and give feedback
  • thereafter, when hamlib is finished and released, we have have to look, what have to be changed and enhance in gpredict.
  • and last: operating satellites in a smooth way :-)

For the moment i can operate with gpredict on all satellites direct with hamlib and for ISS just using my pythonscript, which supports this simplex mode. But with the mentioned manual efforts.

A view in the future:
The new world will be using --vfo and then the following new vfo and Splitmodes will be available:

  1. S 1 MainA MainB
  2. S 1 MainB MainA
  3. S 1 SubA SubB
  4. S 1 SubB SubA
  5. S 1 MainA SubA
  6. S 1 MainA SubB
  7. and on are the same as 1. through 6. but for crossband ops

Bye Andreas, DL7OAP

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.