IC-821H does not switch between MAIN/SUB when calling icom_set_freq with gpredict client #693
Comments
|
I need more debug to see what's going before this.
I get the feeling the IC821 does not allow setting frequency on the uplink by default so would be another special case.
The manual says to use the SCAN-S to adjust the uplink frequency. Looks like we can maybe do that in the code if needed.
You are in SAT mode, right?
What happens to the audio when you push the SCAN-S button? Does it continue and you can adjust the frequency without any problem?
Mike W9MDB
On Thursday, May 6, 2021, 02:16:28 PM CDT, Oliver Schönrock ***@***.***> wrote:
A Gpredict client connected to rigctld (compiled from latest github) appears to not correctly switch between Main/sub.
The Main VFO is updated correctly according to doppler from gpredict. The sub VFO is static. verbose output from rigcltd shows
icom_set_freq called currVFO=432156217.000000
icom_set_freq: special check for vfo swap
icom_set_freq: set freq failed: Command rejected by the rig
icom_set_freq: set freq failed: Command rejected by the rig
I have checked recent commits such as this for the ic910h:
#657
Before this commit the ic910h had special cases for cross band freq changes temporarily swapping to VFO_SUB and performing the change there. That commit removed those special cases and falls back on icom_set_freq(). This is the sort of thing needed forthe 821 I believe.
However, 821h.c looks like it makes no attempt to handle these cases. But it seems the 821 config does not trigger the "special" behaviour in icom_set_freq() .
I have the C knowledge, but lack familiarity with the code. I have the radio sitting on my desk, newly acquired.
Rather than hack something, if I could be given some guidance on best way to trigger to the MAIN/SUB swap for set_freq on other band, then I should be able to create a pull request.
Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
I also need more verbosity...
Use 6 v's please....
Mike W9MDB
On Thursday, May 6, 2021, 02:16:28 PM CDT, Oliver Schönrock ***@***.***> wrote:
A Gpredict client connected to rigctld (compiled from latest github) appears to not correctly switch between Main/sub.
The Main VFO is updated correctly according to doppler from gpredict. The sub VFO is static. verbose output from rigcltd shows
icom_set_freq called currVFO=432156217.000000
icom_set_freq: special check for vfo swap
icom_set_freq: set freq failed: Command rejected by the rig
icom_set_freq: set freq failed: Command rejected by the rig
I have checked recent commits such as this for the ic910h:
#657
Before this commit the ic910h had special cases for cross band freq changes temporarily swapping to VFO_SUB and performing the change there. That commit removed those special cases and falls back on icom_set_freq(). This is the sort of thing needed forthe 821 I believe.
However, 821h.c looks like it makes no attempt to handle these cases. But it seems the 821 config does not trigger the "special" behaviour in icom_set_freq() .
I have the C knowledge, but lack familiarity with the code. I have the radio sitting on my desk, newly acquired.
Rather than hack something, if I could be given some guidance on best way to trigger to the MAIN/SUB swap for set_freq on other band, then I should be able to create a pull request.
Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Actually I have tried in both Satmode and non satmode, mainly the latter. What happens to the audio when you push the SCAN-S button? Does it continue and you can adjust the frequency without any problem? Yes, audio continues, and yes you can change the uplink frequency without issue, Also while Txing. This is ICOMs way of "breaking lockstep" to adjust for differing doppler other non-mirrored frequency offsets/inaccuracies, right? When driving this from Gpredict, it can also work without satmode, right? All that the in-radio satmode gives us is locking the 2 bands into (reverse) lockstep, right? And Gpredict already does that if you select "L" in the Radio Control Window. I figured, if computer control, then 100% computer control and the 821 is just a full duplex capable slave - except for rolling the dial which gpredict reads and back calcs everything. ... or is that "too slow / laggy" and I should be in satmode? I have been hacking away at It is 75% working right now. set_freq works, just need get_freq now and make it less hacky. Here is the full 6vs debug output of the latest git rigctld (not my hacked version) in satmode and non-satmode (I hit "engage" and let it run for 2 seconds or so). The failure mode in satmode is different to my original description. the display shows "SUB" as if "Sub" button had been pushed. But this doesn't do anything in satmode, as you say, you need to use RIT and SCAN to adjust one of the frequencies without changing the other. I have not tried if the radio responds to CAT based VFO freq-set commands while in satmode with SCAN/ or RIT pressed (ie one display shows underscores) |
|
Further info on how current git code works with satmode. NOTE that in sat-mode the subband is the UPLINK. In all other operation of the 821 you only ever TX on the MAIN band. I don't know why they introduced this logic inversion. It is even more bizzare, in that the main band LED is labelled TX/RX and the SUB band led is ONLY labelled RX. (both next to the analog S-meter). Yet in satmod, when you key the radio, the "RX labelled"(!!) sub band light goes from green to red. This is what Gpredict does via latest git hamlib when radio is in satmode:
|
|
Do a "git pull" and try again.
I added a set_split_vfo for the IC821H which may solve the problem but at least is the 1st step towards a solution.
Mike W9MDB
On Thursday, May 6, 2021, 06:32:16 PM CDT, Oliver Schönrock ***@***.***> wrote:
Further info on how current git code works with satmode.
NOTE that in sat-mode the subband is the UPLINK. In all other operation of the 821 you only ever TX on the MAIN band. I don't know why they introduced this logic inversion. It is even more bizzare, in that the main band LED is labelled TX/RX and the SUB band led is ONLY labelled RX. (both next to the analog S-meter). Yet in satmod, when you key the radio, the "RX labelled"(!!) sub band light goes from green to red.
This is what Gpredict does via latest git hamlib when radio is in satmode:
- It turns the SUB symbol in the main display on and it seems to stay lit permanently. I said above that this doesn't do anything when you are in satmode, and that is true when operating the radio by hand...BUT
- It is tracking the sub band, ie it is following doppler shift freq adjustments from gpredict. And that is without apparently using the "SCAN/RIT" buttons, because those show "_ _ _ _ _ _ _ _ _ _" in one of the displays.
- It is not tracking the Main band, which matches the fact that the SUB symbols stays lit and the log shows "set_freq rejected by rig".
- it seems to make satmode work we need to be sending "ANTI-SUB / access main" before set_freq for Main band. I haven't found the place in the code where it sends the initial "SUB / access isb" and whether that is the same command I used in my hack ie 0x07 0xd1 => "Access Sub" from manual p42
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Thank you. Done BTW, I have also noticed that in satmode, the SUB indicator comes on before the client connects, and after the client connects, the logs show that 0x07 0xd0 (ie "select main band") is sent many times, yet the radio remains on "SUB". I cannot find any indication in the log that 0x07 0xd1 (ie "select sub") is ever sent, yet the radio changes to it. I have not yet worked out which of of the other commands being sent by Hamlib during startup is putting the radio into "SUB". Presumably if I can identify that, then we might be able to identify the "opposite" command, and thus have something to work towards. Also, if I manually hit the SUB button while gpredict/hamlib are trying to track both uplink and downlink, both bands track for a moment, ie the freq on the hitherto static band moves to what it should be. ie it is possible to change it via CAT control, if we could only change "access to other band". - note this works in both satmode and non-satmode. Note also that after a single update gpredict then gets its knickers in a twist because it "reads back the wrong band" and the "setpoints both go to one band". It seems to me that in satmode 0x07 0xd0/1 do not work the way they do in non-satmode. I can't find proper icom docs on this. Yet apparently it is possible to "change to sub" with a remote command, so hopefully the reverse is also possible. In your opinion, should this work in satmode or non-satmode? Updated logs attached: |
|
OK, further investigation this morning (UK time). Given it would take me ages to understand the complex vfo substitution logic that hamlib is doing, let alone how to code a clean fix, that doesn't break anything, I think I will concentrate on providing as much information as possible about what the radio actually does when you send it certain commands in certain modes/states etc, since I have one sitting here. To this end, I have found the place where hamlib switches the SUB indicator on when radio is in satellite mode. I just did a binary debug search in the code with an exit(1), and found it happens here: Line 2455 in 29013fd and And as logic would have it, 2 negatives make a positive, ie I can do this: retval = icom_transaction(rig, C_SET_VFO, 0xd1, NULL, 0,
ackbuf, &ack_len);immediately after the above line, and if I run that (to be clear, this is all before any client connects) with radio in sat mode, I get precisely one flicker of the SUB indicator. So when in satellite mode, send 0x07 0xd0 => to access "SUB" which is the TX/Uplink Band (so kind of main) and send 0x07 0xd1 => to access "Main" which is the RX/downlink band. Hope that's not too confusing. It is for me. This interpretation tallies with grep'ing of the satmod log file I posted earlier. ie hamlib is never sending 0x07 0xd1, which (in satmode!) is switch to MAIN, which is the RX/downlink band, and that is why that band doesn't track the satellite doppler shift which gpredict is calculating. This should be good news really, because we now know what we have to send the radio in satmode. Lets prove we can control both frequencies. // this is the original from git HEAD - it switches the SUB indicator on, ie TX/uplink band in satmode
retval = icom_transaction(rig, C_SET_VFO, icvfo, NULL, 0, ackbuf, &ack_len);
// lets see if we can control frequency of Uplink.
// hacking this as a raw icom_transaction to avoid yet more VFO swap logic in icom_set_freq
unsigned char freqbuf[MAXFRAMELEN];
int freq_len, cmd, subcmd;
freq_t freq_uplink = 430e6;
freq_len = 5;
to_bcd(freqbuf, freq_uplink, freq_len * 2);
cmd = C_SET_FREQ;
subcmd = -1;
if ((retval = icom_transaction(rig, cmd, subcmd, freqbuf, freq_len, ackbuf, &ack_len)) != RIG_OK) {
rig_debug(RIG_DEBUG_VERBOSE, "%s could not set uplink freq .\n", __func__);
exit(10);
}
// and lets switch to controlling the Downlink (switching the SUB indicator off on the radio)
retval = icom_transaction(rig, C_SET_VFO, 0xd1, NULL, 0, ackbuf, &ack_len);
// and control its frequency
freq_t freq_downlink = 145e6;
freq_len = 5;
to_bcd(freqbuf, freq_downlink, freq_len * 2);
cmd = C_SET_FREQ;
subcmd = -1;
if ((retval = icom_transaction(rig, cmd, subcmd, freqbuf, freq_len, ackbuf, &ack_len)) != RIG_OK) {
rig_debug(RIG_DEBUG_VERBOSE, "%s could not set uplink freq .\n", __func__);
exit(20);
}
// and quit before any client even connects
exit(30);Yes, it works. We can control both frequencies. ie we can break the lockstep (to adjust for doppler), and we can do all this while transmitting and with continous RX audio => tested OK. |
Seems the IC821H reverses Main/Sub logic when in satmode Remove IC821 from riglist.h and icom.c -- not used #693
|
That's not the current version....
You need to do a "git pull" in the hamlib src directory.
I did a change to reverse the Main/Sub when in satmode so let's see how that behaves
You should see this version
rigctl Hamlib 4.2~git Fri May 07 13:25:54 2021 +0000 SHA=e84b8a
On Friday, May 7, 2021, 12:31:55 AM CDT, Oliver Schönrock ***@***.***> wrote:
Thank you. Done git pull recompile and retest. I am afraid I cannot detect a difference.
In non-satmode the main band (uplink) still tracks, but downlink on sub does not.
In satmode the sub band (now the uplink) still tracks, but downlink on main does not.
BTW, I have also noticed that in satmode, the SUB indicator comes on before the client connects, and after the client connects, the logs show that 0x07 0xd0 (ie "select main band") is sent many times, yet the radio remains on "SUB". I cannot find any indication in the log that 0x07 0xd1 (ie "select sub") is ever sent, yet the radio changes to it. I have not yet worked out which of of the other commands being sent by Hamlib during startup is putting the radio into "SUB". Presumably if I can identify that, then we might be able to identify the "opposite" command, and thus have something to work towards.
In you opinion, should this work in satmode or non-satmode?
Updated logs attached:
rigctld_sat_mode_2.log
rigctld_non_sat_mode_2.log
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Sorry, not sure what you mean with "incorrect version". I did a git pull and compile after your commit last night (early this morning for me) as reported above. The _2 logs are with that commit. My experiments in terms of what to send to the radio were done on old code, prior to that commit, because they were just hacks for purpose of investigating how the radio reacts to commands in certain states. Anyway your new commit has made a world of difference. SatMode now works! Both Frequencies update and the "SUB" indicator flashes in a relatively regular pattern. New _3 logs below, showing that timestamp you mentioned (although my SHA is different, not sure how that's computed). rigctld_none_sat_mode_3.log Non satmode still only updates the TX band, but it doesn't have to work if satmode does. the "spinning the dial feedback loop" via gpredict is a little wobbly. It seems to take 2 steps forwards and one step back, but that might be "normal" and related to time lags . I have played with the "Cycle ... msec" setting in Gpredict and that makes quite a difference. Actually slowing gpredict down to about 2s seems better: I am using max baud rate of 19200. For the record I am using these "device settings" in gpredict - they are the ones recommened for the 910. But actually even if I choose Sub (up) / Main (down) - which is arguably more accurate...it still works the same:
Also the RIT Control for satmode seems very useful. Just writing here for people who find this. It needs activiting with the "CALL" button on right side of rig. RIT is printed to the right of the button in a square (which seems to be the satellite mode symbol). It seems to cover a fairly wide range of several kHz so can be used to compensate for things like:
I will keep testing. |
|
I don't expect satellite mode to work in non-satellite mode. |
|
Yeah there is no logical reason non-satmode can't work from the radios POV, but it is certainly not necessary, and may not be very good for the "spinning the dial through the transponder bandwidth", due to serial comms lag. Thanks very much for your awesomely quick response and great work on hamlib! There are a few places in forums (QRZ.com being one I think) where people struggled to make the 821h work with gpredict and hamlib and ended up running sat32pc under WINE (yuck). If I can refind them I will post there to draw attention to the fact that the latest git version now works. Thanks again. |
A Gpredict client connected to rigctld (compiled from latest github) appears to not correctly switch between Main/sub.
The Main VFO is updated correctly according to doppler from gpredict. The sub VFO is static. verbose output from rigcltd shows
(Note this in non-satellite mode - for the differences with satellite mode, see below)
I have checked recent commits such as this for the ic910h:
#657
Before this commit the ic910h had special cases for cross band freq changes temporarily swapping to VFO_SUB and performing the change there. That commit removed those special cases and falls back on
icom_set_freq(). This is the sort of thing needed forthe 821 I believe.However,
821h.clooks like it makes no attempt to handle these cases. But it seems the 821 config does not trigger the "special" behaviour inicom_set_freq().I have the C knowledge, but lack familiarity with the code. I have the radio sitting on my desk, newly acquired.
Rather than hack something, if I could be given some guidance on best way to trigger to the MAIN/SUB swap for set_freq on other band, then I should be able to create a pull request.
Thanks
The text was updated successfully, but these errors were encountered: