FT-857D RX frequency increments for satellites with identical RX and TX frequencies

[kconkas]

This may be related to #294 . I am trying to use gpredict for greencube. To define both the uplink and downlink frequencies, I added the following section to ~/.config/Gpredict/trsp/53106.trsp:

[Mode U GMSK FULL DUPLEX]
DOWN_LOW=435310000
UP_LOW=435310000
MODE=FSK AX.100 Mode 5
BAUD=1200

I defined a rig for this as "FT817/857/897 (auto)" with PTT Status set to "Read PTT". Its .rig file is as follows:

[Radio]
Host=localhost
Port=4533
LO=0
LO_UP=0
Type=4
PTT=1
SIGNAL_AOS=false
SIGNAL_LOS=false

My problem is when I start tracking the satellite and click "Engage", at first everything is normal; both the Downlink and Uplink radio frequencies get updated regularly:

After about 7-8 seconds, both the Downlink and Uplink radio frequencies get set to the same (Uplink) frequency and my Downlink frequency automatically shifts up. From this point onwards, my Downlink radio frequency tracks the Uplink radio frequency.

Fedora 37, gpredict 2.2.1, hamlib-4.5.4.

[mdblack98]

Can you compile Hamlib -- try the latest here... https://n0nb.users.sourceforge.net/

Mike W9MDB

On Monday, March 13, 2023 at 01:05:10 PM CDT, Kristijan Conkas ***@***.***> wrote:  

This may be related to #294 . I am trying to use gpredict for greencube. To define both the uplink and downlink frequencies, I added the following section to ~/.config/Gpredict/trsp/53106.trsp: [Mode U GMSK FULL DUPLEX] DOWN_LOW=435310000 UP_LOW=435310000 MODE=FSK AX.100 Mode 5 BAUD=1200

I defined a rig for this as "FT817/857/897 (auto)" with PTT Status set to "Read PTT". Its .rig file is as follows: [Radio] Host=localhost Port=4533 LO=0 LO_UP=0 Type=4 PTT=1 SIGNAL_AOS=false SIGNAL_LOS=false

My problem is when I start tracking the satellite and click "Engage", at first everything is normal; both the Downlink and Uplink radio frequencies get updated regularly. After about 7-8 seconds, both the Downlink and Uplink radio frequencies get set to the same (Uplink) frequency and my Downlink frequency automatically shifts up. From this point onwards, my Downlink radio frequency tracks the Uplink radio frequency.

Fedora 37, gpredict 2.2.1, hamlib-4.5.4.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[kconkas]

Thanks for the suggestion @mdblack98 . I built hamlib from its current github snapshot (commit 24a4a094843c5c149be76277a9ab3704b8b097b7) and I saw a few of your FT-857 fixes in the commit log. Unfortunately, the behaviour reported in this bug is still present. I'd appreciate any suggestions from anyone who may have got this working.

[mdblack98]

Ok -- now run rigctld with "-vvvvv -Z >log.txt 2>&1" added to the line and send me the debug file with a description of what you are seeing.

Mike W9MDB

On Wednesday, March 15, 2023 at 03:45:59 AM CDT, Kristijan Conkas @.***> wrote:

Thanks for the suggestion @mdblack98 . I built hamlib from its current github snapshot (commit 24a4a094843c5c149be76277a9ab3704b8b097b7) and I saw a few of your FT-857 fixes in the commit log. Unfortunately, the behaviour reported in this bug is still present. I'd appreciate any suggestions from anyone who may have got this working.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[mdblack98]

Also....try my fork and add "--vfo" to your rigctld command line. VFO mode is much better for gpredict usage. https://github.com/mdblack98/gpredict

[kconkas]

@mdblack98 please find the log below. This is with your fork of gpredict, latest snapshot of hamlib and rigctld used with the --vfo option. log.txt

[mdblack98]

Doesn't look like you were using my fork of gpredict as it is not using the --vfo option correctly. My fork does work with --vfo.

[kconkas]

@mdblack98 I built both from source code. Is there anything that needs setting up in gpredict to make it work?

[mdblack98]

Run rigctld with the --vfo option

Mike W9MDB

On Friday, March 17, 2023 at 12:36:11 PM CDT, Kristijan Conkas @.***> wrote:

@mdblack98 I build both from source code. Is there anything that needs setting up in gpredict to make it work?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[kconkas]

@mdblack98 this is the 1st line in the output I'd attached previously:

2023-03-15T22:50:02.471865-0000: rigctld.c(660) Startup: /usr/local/bin/rigctld -r /dev/ttyUSB11 -t 4533 -s 9600 -m 1022 --vfo -vvvvv -Z

Is this what you meant or is it somewhere else I should've added --vfo to?

[mdblack98]

That looks correct.

You can redirect the output by adding ">log.txt 2>&1"

Then when things don't work note the time and frequencies involved and send me at least the last few thousand lines of log.txt or zip the whole thing.

On Sunday, March 19, 2023 at 11:37:52 AM CDT, Kristijan Conkas @.***> wrote:

@mdblack98 this is the 1st line in the output I'd attached previously: 2023-03-15T22:50:02.471865-0000: rigctld.c(660) Startup: /usr/local/bin/rigctld -r /dev/ttyUSB11 -t 4533 -s 9600 -m 1022 --vfo -vvvvv -Z

Is this what you meant or is it somewhere else I should've added --vfo to?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[zyg0121]

I found the same problem today. Wanna know how to solve it...

[KG7WOC]

I have the same issue / same exact symptoms using my FT-818ND that Kristijan reported initially.

Hamlib (and therefore Gpredict) just do not appear to support this radio...

It's great you can use them for "RX only" - or if you have two radios to do the work of one, but that is just a work-around...

I'm wondering if there's been any changes / fixes to the software - or any success for those similarly affected -

Thanks.

[mdblack98]

I need a debug log from rigctl Ensure rigctld has "-vvvvv >log.txt 2>&1" on the command line and send me the log.txt file along with a description of the behavior you see. The FT-818 and FT-857 are similar and have limited capability and may need some timing adjustments to support Doppler shifting.

[KG7WOC]

Hi Mike - Thanks for the reply...

Behavior is identical to that described in the original post. I'm selecting the FT-818 radio type on the rigctld command line and selecting the "Special" config option in Gpredict (I assume the radio is similar to the other Yaesus), I get expected behavior initially when I hit "Engage": Then, anywhere from 2-7 seconds after that, the target downlink frequency changes by roughly the amount of the current doppler adjustment (or so it appears): Gpredict then appears to (correctly) apply the Doppler correction for the (bad) frequency to be sent to the rig - which it then does correctly - as shown in the second screen cap above, it then set the rig's VFOa to 435.309.960 MHz.

I found that if I hit the Tune ("T") button under the Target controls, it will set the target frequency for the sat back to the correct value of 435.310 - but then, a few seconds later, it will be shifted off again in similar fashion as before.

I had trouble with the rigctld log file option (-vvvvv -Z, etc.) trying to capture any text - but I did copy / paste direct from the window - attached here: Saved log.txt

It shows the logs generated immediately after I hit the "Tune" button, and the period of the subsequent "shifts" that followed after that - I think about 3 or 4 more shifts occurred before I killed the window and copied the text..

If you need the log header (startup / init, etc.) let me know and I'll attach another.

I am running Gpredict 2.3.37 and Hamlib 4.5.5

Please let me know if there's anything else I can do to support.

73,

Dave KG7WOC

[mdblack98]

Can you contact me directly at mdblack98@yahoo.com and we can hook up using AnyDesk and debug this? I'll be out for a while but should be back around 1000 or so Central time.

Can you upgrade to the latest Hamlib and test this again? The log you sent me is the Mar 14th version and not current. https://n0nb.users.sourceforge.net/ You'll need to remove any Hamlib package and build this one. I have a couple of ideas on how to fix this for these two rigs but need to be sure you are building the current version so I can send you some new files to compile and test.

One idea is to confirm that the vfo change worked. Problem is don't know really know how long to wait so need to experiment some.

Another idea that might work if we only set VFOB frequency when we transmit and then not set VFOA during transmit. These two model rigs have to change VFO in order to set frequency But PTT can get in the way and such when doing all the vfoA/freqA vfoB/freqB/vfoA calls. Also I suspect the VFO swap will affect reception.

[KG7WOC]

Hi Mike -  Thanks for everything - I'd like to be part of the solution, but I can't really support online debugging due to "other obligations" (wink wink) - I do have a fix that is currently working for my very experimental purposes - heck, I can't hit Greencube with 6W anyway, but I enjoy the work and progress needed to try anyway. I'm currently working on a DIY yagi that might work for this purpose - but it's still a work in progress.  (And my progress with that - like everything else - is kinda slow.) I'll update my Hamlib installation and try again - and keep you posted; but for now, I would share just a couple of my observations involving my radio: 1)  I came up with an app that does the Doppler shifting and updates the frequency on the radio - periodically for the RX freq, and just prior to TX when transmitting.  After watching multiple passes, it occurred to me that I don't really need to update the RX frequency every 200 ms - in fact, it takes about 10 seconds for the 10's digit on the display to change when the sat is passing - so I currently have that interval set at about 2-3 seconds.  Works fine - and if my hand-held positioning is working, I can see quality rates at 95% or so.   Good enough for government work, as we used to say... 2) As part of the development of my app, I asked the same question you are asking - "How long does it take to set the freq and return ?" - it's important as you know, since you have to wait for the unit to respond before send the next command - and unless  you are actively waiting for the responses (which I don't do out of sheer ignorance with my programming ability) - then you have to allow "more than enough" time ... To that end, I made a small diagnostic applet which measures the "ticks" between the time a command is sent and the time the response is received at the comm port.  I then used a freeware comm port analyzer to look at the packets at the comm port to backup the measurements made by the applet.  Here's a screen shot:

You can see the applet in the upper-left corner - and it has 3 buttons that generate the 3 commands I wanted to test:  Get TX Data, Get RX Data, and Get Freq and Mode Data.  Hitting those buttons makes the app send the corresponding commands to the radio, and then display the elapsed time in ms when the response is received. On the right side of this graphic is the serial port analyzer's display, which shows the packets in and out on the port - with timestamps.  Some simple math shows that the  differences observed at that end - and I added those times in red next to the applet's times. Those red numbers show a slight increase in the time lag at the port as measured by the port analyzer - which I believe is simply the additional "overhead" added by the analyzer to grab, process, and display the data.  I think that both numbers are a good "ballpark" - so I think I settled on a 60 ms delay in my app for all commands. I think you are correct that you can't keep changing VFOs while you are trying to receive a signal - so that leaves us watching for the radio to TX, and then changing the TX freq (which - as we know - doesn't work).   So, for now my DIY radio app does the Doppler math and sends the shifted RX frequency to the radio like once every 2 seconds, then prior to transmitting, I hit a button on my app, and the shifted TX frequency is sent, and then further updates are suspended until the TX is complete.  It's kind of a manual setup, I know - but it's working for now.   Btw, I tried using Gpredict's "Manual" special option for the Yaesu radios - and it does kick the radio into transmit - but then I can get it out !!! lol.  Have to turn the radio off! I could use that option - if it worked... Thanks again for your help and expertise - and I'll keep you posted with my observations ! 73, Dave KG7WOC 

On Saturday, June 29, 2024 at 05:32:37 AM PDT, Michael Black ***@***.***> wrote:  

Can you contact me directly at @.*** and we can hook up using AnyDesk and debug this? I'll be out for a while but should be back around 1000 or so Central time.

Can you upgrade to the latest Hamlib and test this again? The log you sent me is the Mar 14th version and not current. https://n0nb.users.sourceforge.net/ You'll need to remove any Hamlib package and build this one. I have a couple of ideas on how to fix this for these two rigs but need to be sure you are building the current version so I can send you some new files to compile and test.

One idea is to confirm that the vfo change worked. Problem is don't know really know how long to wait so need to experiment some.

Another idea that might work if we only set VFOB frequency when we transmit and then not set VFOA during transmit. These two model rigs have to change VFO in order to set frequency But PTT can get in the way and such when doing all the vfoA/freqA vfoB/freqB/vfoA calls. Also I suspect the VFO swap will affect reception.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[mdblack98]

Your screenshot didn't come through -- can you send that direct to me?  @.***

And are you saying you can't change VFOB frequency while transmitting?  That may explain the problem.

Mike W9MDB

On Saturday, June 29, 2024 at 10:38:16 AM CDT, KG7WOC @.***> wrote:

Hi Mike -  Thanks for everything - I'd like to be part of the solution, but I can't really support online debugging due to "other obligations" (wink wink) - I do have a fix that is currently working for my very experimental purposes - heck, I can't hit Greencube with 6W anyway, but I enjoy the work and progress needed to try anyway. I'm currently working on a DIY yagi that might work for this purpose - but it's still a work in progress.  (And my progress with that - like everything else - is kinda slow.) I'll update my Hamlib installation and try again - and keep you posted; but for now, I would share just a couple of my observations involving my radio: 1)  I came up with an app that does the Doppler shifting and updates the frequency on the radio - periodically for the RX freq, and just prior to TX when transmitting.  After watching multiple passes, it occurred to me that I don't really need to update the RX frequency every 200 ms - in fact, it takes about 10 seconds for the 10's digit on the display to change when the sat is passing - so I currently have that interval set at about 2-3 seconds.  Works fine - and if my hand-held positioning is working, I can see quality rates at 95% or so.   Good enough for government work, as we used to say... 2) As part of the development of my app, I asked the same question you are asking - "How long does it take to set the freq and return ?" - it's important as you know, since you have to wait for the unit to respond before send the next command - and unless  you are actively waiting for the responses (which I don't do out of sheer ignorance with my programming ability) - then you have to allow "more than enough" time ... To that end, I made a small diagnostic applet which measures the "ticks" between the time a command is sent and the time the response is received at the comm port.  I then used a freeware comm port analyzer to look at the packets at the comm port to backup the measurements made by the applet.  Here's a screen shot:

You can see the applet in the upper-left corner - and it has 3 buttons that generate the 3 commands I wanted to test:  Get TX Data, Get RX Data, and Get Freq and Mode Data.  Hitting those buttons makes the app send the corresponding commands to the radio, and then display the elapsed time in ms when the response is received. On the right side of this graphic is the serial port analyzer's display, which shows the packets in and out on the port - with timestamps.  Some simple math shows that the  differences observed at that end - and I added those times in red next to the applet's times. Those red numbers show a slight increase in the time lag at the port as measured by the port analyzer - which I believe is simply the additional "overhead" added by the analyzer to grab, process, and display the data.  I think that both numbers are a good "ballpark" - so I think I settled on a 60 ms delay in my app for all commands. I think you are correct that you can't keep changing VFOs while you are trying to receive a signal - so that leaves us watching for the radio to TX, and then changing the TX freq (which - as we know - doesn't work).   So, for now my DIY radio app does the Doppler math and sends the shifted RX frequency to the radio like once every 2 seconds, then prior to transmitting, I hit a button on my app, and the shifted TX frequency is sent, and then further updates are suspended until the TX is complete.  It's kind of a manual setup, I know - but it's working for now.   Btw, I tried using Gpredict's "Manual" special option for the Yaesu radios - and it does kick the radio into transmit - but then I can get it out !!! lol.  Have to turn the radio off! I could use that option - if it worked... Thanks again for your help and expertise - and I'll keep you posted with my observations ! 73, Dave KG7WOC 

On Saturday, June 29, 2024 at 05:32:37 AM PDT, Michael Black @.***> wrote:

Can you contact me directly at @.*** and we can hook up using AnyDesk and debug this? I'll be out for a while but should be back around 1000 or so Central time.

Can you upgrade to the latest Hamlib and test this again? The log you sent me is the Mar 14th version and not current. https://n0nb.users.sourceforge.net/ You'll need to remove any Hamlib package and build this one. I have a couple of ideas on how to fix this for these two rigs but need to be sure you are building the current version so I can send you some new files to compile and test.

One idea is to confirm that the vfo change worked. Problem is don't know really know how long to wait so need to experiment some.

Another idea that might work if we only set VFOB frequency when we transmit and then not set VFOA during transmit. These two model rigs have to change VFO in order to set frequency But PTT can get in the way and such when doing all the vfoA/freqA vfoB/freqB/vfoA calls. Also I suspect the VFO swap will affect reception.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[mdblack98]

Patches were done Here's some observations:

Re: my app behavior - I can't verify how that previous version of the app functions now having revised the code several times (and not saving the intermediate products) - sorry about that - let me know if you need something specific...

Re: the new DLL - I updated my installation and then substituted in the DLL you had in you dropbox. This appears to be a step in the right direction!

Log file is attached.

1) The radio was set up in DIG mode with Duplex operation activated; I used another HT radio to verify TX functionality. The Gpredict radio interface was set for the "Special Yaesu (Auto) Mode"; After opening the Radio Control window, I selected the desired sat/transponder combo and activated the "Track" function, then engaged the radio control. When the "Engage" button was pressed, the Doppler RX and TX offsets were displayed correctly.

After about 5-10 seconds, the target RX frequency jumped by about 4 MHz - but then it went back almost exactly to 435.310 - but it was off by like 1 Hz - so it now read (I believe) 435310001. Curious! Rounding error ?

About 5-10 seconds later, this process repeated, and an additional drift of 1 or 2 Hz was now added tp the freq in the target window = 435310003.

In order to keep the log short, I let this process repeat only about 5 or 6 more times, and then I tested the TX function. Each time 1 or 2 Hz was added to the target frequency in the TX window

2) I had the Greencube Terminal running, and initiated a TX frame of data. The radio went into TX mode, and transmitted on the correct TX frequency - verified by my 2nd/HT radio. I verified that the display on the FT-818 showed the correct TX frequency on VFOb during transmit, and then the radio switched back to VFOa and RX mode.

As during previous experiments, I noted that I could hit the "Tune" button on the Gpredict Target controls, and it would reset the RX frequency back to 435310000 - so I think it's possible to use this app "as is" since the drift is very minor (just a few Hz).. As long as the user remembers to periodically re-tune to compensate.

I would consider using it "useable" now - but not quite "optimal" :-)

[mdblack98]

Try this ft817.c file (for the4 FT818 too). I changed the rounding to round down instead of nearest. https://www.dropbox.com/scl/fi/gvxrlk3670jetgms5usvx/ft817.c?rlkey=g2t0uuc0ret2nkd1wi5xrzdvl&dl=1