FT-857D RX frequency increments for satellites with identical RX and TX frequencies #326
Comments
kconkas
changed the title
kconkas
changed the title
|
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: ***@***.***>
|
|
Thanks for the suggestion @mdblack98 . I built hamlib from its current github snapshot (commit |
|
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: ***@***.***>
|
|
Also....try my fork and add "--vfo" to your rigctld command line. VFO mode is much better for gpredict usage. |
|
@mdblack98 please find the log below. This is with your fork of gpredict, latest snapshot of hamlib and rigctld used with the |
|
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. |
|
@mdblack98 I built both from source code. Is there anything that needs setting up in gpredict to make it work? |
|
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: ***@***.***>
|
|
@mdblack98 this is the 1st line in the output I'd attached previously: Is this what you meant or is it somewhere else I should've added |
|
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: ***@***.***>
|
|
I found the same problem today. Wanna know how to solve it... |
|
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. |
|
I need a debug log from rigctl |
|
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": 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: 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 |
|
Can you contact me directly at [email protected] and we can hook up using AnyDesk and debug this? Can you upgrade to the latest Hamlib and test this again? The log you sent me is the Mar 14th version and not current. 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. |
|
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: ***@***.***>
|
|
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: ***@***.***>
|
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:I defined a rig for this as "FT817/857/897 (auto)" with PTT Status set to "Read PTT". Its .rig file is as follows:
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.
The text was updated successfully, but these errors were encountered: