View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003094||3 - Current Dev List||Bug||public||2019-01-24 23:50||2019-02-13 13:52|
|Target Version||Fixed in Version||18.104.22.168|
|Summary||0003094: Doppler frequency adjustment for uplink VFO goes in the wrong directcion|
|Description||The Uplink VFO is running in the opposite direction of tuning with regards to the Doppler shift. To explain this, I need to discuss a bit of physics for a moment.|
The satellite has a fixed TX and RX frequency. If you were riding on the satellite with a radio in your hand, these frequencies wouldn't change. As the satellite approaches you, the radio needs to be tuned higher than that fixed frequency. That frequency would decrease to the point of this "fixed frequency". At the moment where the satellite is at its nearest position to you, the frequency will be the same as that fixed frequency. The radio would need to tune lower and lower as the satellite moves away until it can no longer be heard.
This is working properly for the RX VFO. But it is behaving in the exact opposite way for the TX VFO. I don't know at the moment whether this is unique to the FT-991A or not.
The program is completely unusable in this condition.
|Steps To Reproduce||Launch Rig Control connected to an FT-991(A).|
Launch Logbook (for good measure)
Launch Rotor Control (for good measure)
Launch Satellite Tracker
Select a satellite with a pass that is relevant for your location
Connect to the radio and select the boxes to track TX and RX.
As the satellite is coming towards you, you'll notice that the RX (downlink) frequency is higher than the TX frequency of the satellite and it will be decreasing until it is at its apex... then it will be (momentarily) equal to the satellite's TX frequency... then it will continue to decrease as the satellite moves away from you. This is the correct behavior.
As the satellite is coming towards you, you'll notice that the TX (uplink) frequency is lower than the RX frequency of the satellite and it will be increasing until it is at its apex... then it will be (momentarily) equal to the satellite's TX frequency... then it will continue to inrease as the satellite moves away from you. This is the INCORRECT behavior.
|Additional Information||I recorded a video that depicts this behavior (and other things observed during my test):|
|Tags||No tags attached.|
I think this is fixed with this checkin:
Can you tell what had happened that caused this problem? I can't believe it was always backwards. Somehow along the way, it got flipped.
I'm anxious to test this. It's a big deal. We don't know how many radios this will affect. But without this, it would be hard to move other things forward.
The RX and TX frequencies start at the natural frequency of the satellite. The app reads the natural frequencies from the satellite definition file. The natural frequency is adjusted by manual tuning and by the calculated Doppler effect value.
I'm not familiar with the third-party library we use to calculate satellite positions, their travel rate, or the resulting Doppler shift. My read of that code is that it does produce a signed value for the shift. But the sign isn't intuitive: the calculated shift is negative as the satellite approaches, and goes positive as the satellite passes.
When I arrived at the code in Satellite Tracker, I found that the RX and TX frequencies were each calculated differently. The TX code took the natural frequency, added the calculated Doppler shift frequency, and tuned to that. The RX code took the natural frequency, subtracted the calculated Doppler shift frequency, and tuned to the resulting frequency.
The fix, reflected in this change set:
is to subtract the calculated Doppler shift from both the natural TX and RX frequencies. This gets the sign correct, and correctly polarizes the Doppler shift offset with on both sides of the link.
As far as I'm able to tell, the code was like this ever since it was checked-in to our source control system. That check in was made in March of 2012 with this change set:
I can't see back in history of the HRD code further than that.
It's conceivable that the polarity of the Doppler shift calculation made by the third-party library flipped. But that wouldn't explain the change of the RX frequency independently of the TX frequency. The same shift value is used for both TX and RX calculations, and the third-party library doesn't discern between transmit and receive paths... because it doesn't need to.
Or, it's possible that some compensating sign change was made elsewhere in the code, and it was since removed but not corrected at the source -- at the point changed int he above change list. I'm not familiar enough with this application's operation to guess where that change might be.
I've tested this under several different conditions with various satellites and radios available. The Doppler adjustment is in the correct direction.
We're looking at pass accuracy from a different Mantis issue.
|2019-01-24 23:50||WA9PIE||New Issue|
|2019-02-04 18:20||K7ZCZ||Assigned To||=> K7ZCZ|
|2019-02-04 18:20||K7ZCZ||Status||new => resolved|
|2019-02-04 18:20||K7ZCZ||Resolution||open => fixed|
|2019-02-04 18:20||K7ZCZ||Note Added: 0007258|
|2019-02-05 22:42||WA9PIE||Note Added: 0007288|
|2019-02-06 08:47||K7ZCZ||Note Added: 0007291|
|2019-02-06 11:19||K7ZCZ||Fixed in Version||=> 22.214.171.124|
|2019-02-10 21:55||WA9PIE||Status||resolved => closed|
|2019-02-10 21:55||WA9PIE||Testing||Not Started => Beta Successful|
|2019-02-10 21:55||WA9PIE||Note Added: 0007350|
|2019-02-13 13:52||K7ZCZ||Relationship added||related to 0001328|