Doppler control bug on Icom IC-9700

[Aleziss]

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]

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]

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]

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]

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

[dl7oap]

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]

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]

@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]

@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...

[dl7oap]

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]

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]

@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]

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]

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]

@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]

@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]

@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 https://github.com/Hamlib/Hamlib/commit/5df82b7f3ca17cf79be49c9a90049c3a66ed754b

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]

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

[dl7oap]

The issue https://github.com/csete/gpredict/issues/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]

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]

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]

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]

@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]

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

[dl7oap]

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]

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.

https://github.com/Hamlib/Hamlib/pull/143

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]

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]

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.

https://github.com/Hamlib/Hamlib/pull/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]

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]

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]

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]

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]

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

[EA5SW]

I come here from a problem with my 9700,hamlib and gpredict.. Understand that those bug are already open...

[dl7oap]

the hamlib 4.0 alpha is still in progress. with the last version https://github.com/mdblack98/Hamlib/commits/master (commit 7ae2f28) you can work ssb leo satellites like EO-88 directly with gpredict and the ic9700 (satellite mode) and also ISS on APRS 145.825 with a dopplershiftcorrection via VFOA and VFOB within the main band.

so, please all oldman, who are able to checkout a git repository and can compile hamlib, should be help testing... to get a very bug free hamlib 4.0 for the ic9700..

.. it was just merged, too, to the masterbranch https://github.com/Hamlib/Hamlib/commits/master

[Aleziss]

the hamlib 4.0 alpha is still in progress. with the last version https://github.com/mdblack98/Hamlib/commits/master (commit 7ae2f28) you can work ssb leo satellites like EO-88 directly with gpredict and the ic9700 (satellite mode) and also ISS on APRS 145.825 with a dopplershiftcorrection via VFOA and VFOB within the main band.

so, please all oldman, who are able to checkout a git repository and can compile hamlib, should be help testing... to get a very bug free hamlib 4.0 for the ic9700..

.. it was just merged, too, to the masterbranch https://github.com/Hamlib/Hamlib/commits/master

I have setup an environment since three weeks with Mike where he can program, test and control my very own 9700, he has been working hard since the past weeks on all the 9700 issues and hamlib, I have tried to make him understand what were all the issues and I think it is getting along.

I have been testing a lot with him and document evey logs so he can sort things out.

I am glad to be part of this hamlib developpement. I sure do hope that it will run smoothly with gpredict, hopefully this last one will also receive a push on windows release !

[josipvuk1]

Hi, a few months ago we purchased an ICOM 9700, which was described as an "ultimate tool" for radio amateur purposes. I am working on a student cubesat project that will have both downlink and uplink on UHF (as VHF is becoming too crowded and it is hard to get a frequencyslot). The plan was to work in half duplex mode, with AX.25 data. ICOM is connected to a Linux computer, we tested the reception of APRS AX.25 data and it works. To start some tests with existing satellites the computer will have to control the ICOM to compensate for Doppler shift (that is how i stumbled on this thread).

I don't yet have much experience with radio amateur equipment or procedures. In this thread I saw that "It is also NOT possible to run both VFOs on the same band" with ICOM 9700. However, it seems that with the updates of gpredict and hamlib you worked on it would be possible to change frequencies fast, so that I get uplink on UHF, shortly after the downlink on UHF and vice versa. Did I understand it right?

[dl7oap]

The plan was to work in half duplex mode, with AX.25 data. ICOM is connected to a Linux computer, we tested the reception of APRS AX.25 data and it works. ... However, it seems that with the updates of gpredict and hamlib you worked on it would be possible to change frequencies fast, so that I get uplink on UHF, shortly after the downlink on UHF and vice versa. Did I understand it right?

Yes. We are using this, for example, for AX.25 connections (APRS) on VHF to the ISS. So you will use the main band with UHF and receiving is on VFO A and transmit is on VFO B (via SPLIT function). Gpredict and the new hamlib will do the doppler correction on down and uplink for you, in such a way that it permanently adjusts the downlink (on VFO A) and the correct transmission frequency is set with start of transmission (on VFO B).

But, as you mentioned, only halfduplex. Fullduplex is only possible with up- and downlink on U/V or V/U.

i personally using gpredict version 2.3.58 (master branch of the github repo). and the latest hamlib 4.0 (https://github.com/Hamlib/Hamlib).

By the way: If you use FM signals, you may not even need to make a doppler correction on the receiving side, since the AFC function of the ic9700 can center the signal itself within a certain range. (Read the manual for the AFC function page 7-3). • The AFC (auto frequency control) function automatically compensates for the frequency drift caused by the Doppler effect

[josipvuk1]

Thanks for a prompt response, I will test it as soon as I get access to the equipment again (currently in COVID-19 quarantine).

[Eric731-art]

Gpredict Help. Can anyone offer a Script file command for Linux to connect Com port to Antenna Rotator? I thought using a PuTTY Terminal might help to but not sure. I see most Com port connection files are (Batch files) for Windows and I'm not to great at re-writing code for Linux Ubuntu 18.04 LTE. Thanks. Many Regards, Station KB3DTQ/Eric

On Thu, Mar 26, 2020 at 10:25 AM josipvuk1 notifications@github.com wrote:

Thanks for a prompt response, I will test it as soon as I get access to the equipment again (currently in COVID-19 quarantine).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/csete/gpredict/issues/181#issuecomment-604460693, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOVAC6FA6FVZ653XKN4WUKLRJNQVTANCNFSM4JFVRHXA .

-- Sent from Gmail Mobile

[rufnut]

By the way: If you use FM signals, you may not even need to make a Doppler correction on the receiving side, since the AFC function of the ic9700 can centre the signal itself within a certain range. (Read the manual for the AFC function page 7-3). • The AFC (auto frequency control) function automatically compensates for the frequency drift caused by the Doppler effect

I have a suggestion for Icom Engineers regarding AFC even working on TX:

The AFC (Auto Frequency Correction) could be used as a Doppler correction for the opposite VFO in mode U/V FM by negating the error from the initial memory/main VFO and multiplying by approx 3 to get the U/V mode UHF offset for the Sub VFO TX frequency. This would be derived from the initial setting i.e. memory/VFO before the AFC is activated. You would need an initial carrier signal from the satellite to lock onto before transmitting(good sat users do this).

Guess what: The signal is available in the case of some satellites e.g. AO-91 and AO-92, they have voice identification that could start the process and give the AFC something to work with (otherwise use the beacon). With this method you would not need a cumbersome Doppler correction setup (computers and stuff).

I have noticed the AFC working on RX brings the radio within 300Hz of incoming signal. some sensitivity adjustment or control of AFC centering could be brought into the above satellite correction method.

Brett VK2KYB

[rufnut]

so, please all oldman, who are able to checkout a git repository and can compile hamlib, should be help testing... to get a very bug free hamlib 4.0 for the ic9700..

Gpredict 2.2.1 and Hamlib 4+ git as of 2 days ago.

Thank you all involved, it works well.

So far so good the only issue I really see is the waterfall stutter. This looks to be the way the radio is initially setup in the firmware. I am hoping Icom are looking at this?

Brett VK2KYB

[dl7oap]

IMHO this issue can be closed. with hamlib 4.0 it is solved. the only open issue here should be #217 which belongs to ic910, ic9100 an ic9700.

[rufnut]

Looks OK but I have had a small issue, in regard to when "radio control" is opened, if I don't hit "T" before "Engage" the ssb mode is reversed as the default VFO were in this state especially if the satellite being used is at the top of the list. i.e.default. This appears to be only after the commits around the 15/05/2020. Otherwise working well. Thank you again DL7OAP, mdblack98 and everyone else involved. Brett VK2KYB

[csete]

Could somebody summarize how gpredict and rigctld should be configured to have a working setup with the IC-9700? Something like https://github.com/csete/gpredict/blob/master/doc/notes/ft-847.txt

[rufnut]

I hope this is right: https://github.com/csete/gpredict/pull/220/commits/d9d7215896f976f1904ce87e57f51987f4f54f84

[csete]

Thanks @rufnut, the pull request has been merged.