search

csete / gpredict

Gpredict satellite tracking application
http://gpredict.oz9aec.net/
GNU General Public License v2.0
881 stars 250 forks source link

Transponder frequency calibration #127

Open prstoetzer opened 6 years ago

prstoetzer commented 6 years ago

For full Doppler tuning on amateur radio transponder satellites, a calibration feature is needed to apply an offset to the calculated Doppler shift on the uplink, downlink, or both. This is required due to the frequency inaccuracy on both the satellite transponders and users transceivers. The calibration needs to be able to be performed during the pass and separate offsets should be able to be stored for each satellite.

EA4ZK commented 4 years ago

That is what I was looking for!!! Great issue for the future!!! Thanks

mripv6 commented 4 years ago

I agree - this is much needed feature. I just attempted to use the radio control feature with my IC9700. It worked great (hamlib 4), but there isn't a way to account for the frequency inaccuracies identified by the OP.

For the beacon, the calculated frequency is different than the actual frequency. However, I can tune the main dail to find the beacon and then the doppler correction keeps the beacon in tune. However, when I look for my downlink signal, it usually is out of the audio passband. Then, there isn't any way (that I know of) to correct for the offset and let the computer continue to correct for doppler.

I know the solution needs to be generic. With the IC9700, it's possible to press Main or Sub and adjust the uplink or downlink independently to adjust for the offsets. Once the offset is discovered during a pass, then I need another button in Gpredict to apply doppler correction to the new frequencies. (and store the offset) I thought that's what the L button was supposed to do, but it doesn't.

dl7oap commented 4 years ago

Hi, I would also prefer a function like this.

I currently have 2 workarounds to fix the problem a) i start the tracking on a SSB satellite and press T to be on the mid of the transponder. i do not use L. i open a new linux shell and make a manual second access (the first is rigctl-demon for gpredict) to the ic9700 with "rigctl -m 3081 -r /dev/ic9700a -s 19200" and set the RIT with command "J -100" or whatever the needed difference for cw or ssb. b) i start the tracking on a SSB satellite and press T to be on the mid of the transponder. i do not use L. and i only change the frequency on the uplink in the radio control GUI with the small triangles at 100hz or 10hz. but every time you use T or start a new satellite you have to calibrate again.

with this two methods i can dial over the transponder and most of the time i hear me excatly back.

by the way: on heavy load, when updating all 100ms or 300ms (cw mode), its sometimes even impossible to change the rit manually on the ic9700 because the ic9700 is busy with the incoming command via hamlib or because of heavy display flickering you are not fast enough to cought the correct band (want to change rit in main, but its just switching to sub, when you dial the rit knob). maybe there is also a function need, that minimize unnecessary command via CAT. so there is no need to send a new frequency when it was only changing 10 hz. but maybe 50 hz or on FM it could be even more. for testing i set up a python script between gpredict and the ic9700 which throw away unnecessary commands, then the ic9700 is reacting a lot smoother.

i am using gpredict 2.3.58 and hamlib 4.0

csete commented 4 years ago

Hi guys, Thanks for your input and feedback. As you may have noticed, I have added the label "feature" to this issue, which means that it is on the list to be implemented. I am currently trying to figure out what to do about the radio controller functionality because there are many challenges using the generic hamlib interface. I am afraid we have to rethink the whole concept and fix it once and for all.

dl7oap commented 4 years ago

Hi, just brainstorming to this story:

the offset is different for the mode you are using on a satellite. so working on XW-2F in SSB i need a offset near 300-500 hz. on cw i need 800-1000Hz. maybe you can keep it simple and there is only one offset per satellite and the user have to manage this by himself. so IMHO in a first step i only would implement one offset correction per satellite and then wait some time to see if the users are happy with this.

A) one solution is the variant a) i mention above and which i am using here at home as a workaround. so you could implemented a changeable offset in the radio gui which will use hamlib command J/j to set the RIT of the radio and will tune the uplink. this will work, but IMHO this will lead to more hamlib commands and therefore to more heavy traffic on the cat interface. normaly every radio which can handle RIT, should work with J/j command via hamlib.

B) this is the variant b) i mentioned above. here you can, too, implement a changeable offset in the gui. but it is added/subtracted from the calculted uplink frequency of gpredict. so here you will save unnecessary cat command, because the correction will just reach the radio, via the normal updates of the uplink frequency.

i personally would prefer variant B)

just a mockup of how the gui could be changed, so you can change the offset (which is stored per satellite) via plus and minus. Or you even could implement a radio button (a dial knob). maybe even a keyboard shortcould like PageUp, PageDw will help the user, to easly correct the offset, when its needed during a satellite pass.

suggestion

IMHO the variant b should work for all radios via hamlib, without deep changes in gpredict?

with a look at issue #202 i think the offset still can be added to uplink... or not?

73, de DL7OAP, Andy

mripv6 commented 4 years ago

Thanks for the brainstorming. I think variant B would work. (Should the offset add/subtract from the downlink or uplink?) I don't think it would be difficult with hamlib because the offset is calculate by gpredict. I find that I can use the gpredict control panel radio to make the corrections. Once I figure out the offset, gpredict seems to correct for doppler as I move around the passband using the knob on my IC9700. Either way, for planning/development purposes, the offset needs to be stored with the satellite info and depend on mode.

I also wonder if this information could be shared between users. Similar to the doppler.sql file in satpc32. That might give some people a starting point. I know every rig is different, but I find similar offsets as DL7OAP.

EA4ZK commented 4 years ago

Remember that the calibration depends of the rig too, so the same rig could have different calibration.

El dom., 17 may. 2020 16:28, mripv6 notifications@github.com escribió:

Thanks for the brainstorming. I think variant B would work. (Should the offset add/subtract from the downlink or uplink?) I don't think it would be difficult with hamlib because the offset is calculate by gpredict. I find that I can use the gpredict control panel radio to make the corrections. Once I figure out the offset, gpredict seems to correct for doppler as I move around the passband using the knob on my IC9700. Either way, for planning/development purposes, the offset needs to be stored with the satellite info and depend on mode.

I also wonder if this information could be shared between users. Similar to the doppler.sql file in satpc32. That might give some people a starting point. I know every rig is different, but I find similar offsets as DL7OAP.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/csete/gpredict/issues/127#issuecomment-629807196, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOBZX5I3H4WBLX44PVZJUXTRR7YCDANCNFSM4FDS6ORA .

whattwood commented 3 years ago

I would like to 2nd this feature request! Seems like it would simply take 1 more field in the radio control window to make the "fine tune" adjustment. And obviously it would be great if the setting saved for future use on the same satellite.

mdblack98 commented 3 years ago

You'll find --twiddle-timeout=[secs] will allow you to move the VFO knob and -- with the latest hamlib as of yesterday gpredict will resume wherever you stop. Previously it was a bit of a crap shoot whether it would resume at your current point or snap back to it's own Doppler. That's what was fixed yesterday.

Rather than using RIT which is not capable on all rigs just adjust the frequency on the RX VFO which, with twiddle-timeout can be done from the VFO knob or the frequency controls in gpredict. Mike W9MDB

whattwood commented 3 years ago

Thanks, that sounds like a great feature on hamlib.

However, I'm not sure it will address the issue in question here because, although gpredict will "obey" manual VFO adjustments, it will also change the downlink frequency by a correlating amount. What we need is a way to temporarily unlock the downlink/uplink pair, then re-lock at a slightly different spot. That way once we've found our downlink on the satellite we can tune around to different frequencies in the passband and our uplink will be at exactly the right place.

The workaround for now is to:

  1. Unlock the uplink/downlink with the "L" button and, while transmitting audio, figure out how much to move the TX frequency up or down - usually between 100 to 500 Hz.
  2. Re-lock the uplink/downlink with the "L" button (which pulls the TX frequency back to the place defined in the trsp file) and move to another spot on the transponder where there is a station you want to contact.
  3. Press the "L" button to unlock uplink/downlink and move TX frequency by the same amount you found in step 1.

However, the workaround is fairly clumsy when the DX station is drifting or if you are quickly chasing a number of stations. As you probably know, a satellite pass can be quite frantic :-)

Cheers, Bill

On Fri, Apr 16, 2021 at 9:56 PM Michael Black @.***> wrote:

You'll find --twiddle-timeout=[secs] will allow you to move the VFO knob and -- with the latest hamlib as of yesterday gpredict will resume wherever you stop. Previously it was a bit of a crap shoot whether it would resume at your current point or snap back to it's own Doppler. That's what was fixed yesterday.

Rather than using RIT which is not capable on all rigs just adjust the frequency on the RX VFO which, with twiddle-timeout can be done from the VFO knob or the frequency controls in gpredict. Mike W9MDB

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/csete/gpredict/issues/127#issuecomment-821760966, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATW4OFJ5YKHILFWNP35CAHTTJEBGVANCNFSM4FDS6ORA .