View Issue Details

IDProjectCategoryView StatusLast Update
0003094Ham Radio DeluxeBugpublic2019-02-28 13:23
ReporterWA9PIEAssigned ToK7ZCZ 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version6.5.0.196 
Target VersionFixed in Version6.5.0.199 
Summary0003094: Doppler frequency adjustment for uplink VFO goes in the wrong directcion
DescriptionThe 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 ReproduceLaunch 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 InformationI recorded a video that depicts this behavior (and other things observed during my test):

https://youtu.be/WSl948P4k5Q
TagsNo tags attached.
ModuleSatellite Tracking
Sub-ModuleFunctional
Testing Beta Successful

Relationships

related to 0001328 acknowledged 3 - Current Dev List TS-2000 - inverting transponder TX Freq off [5.23.0.12] 

Activities

K7ZCZ

2019-02-04 18:20

manager   ~0007258

I think this is fixed with this checkin:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4807

WA9PIE

2019-02-05 22:42

administrator   ~0007288

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.

K7ZCZ

2019-02-06 08:47

manager   ~0007291

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:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4807

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:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/40

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.

WA9PIE

2019-02-10 21:55

administrator   ~0007350

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.

WA9PIE

2019-02-26 22:37

administrator   ~0007519

MB - I screwed this up. I'm not sure why... but we need to put this back the way it was. Can you revert this change please?

K7ZCZ

2019-02-27 21:10

manager   ~0007527

Switched the offset back with this checkin:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4854

The chnag wasn't directly reverted, since it had a bit of cleanup that we do want to keep.

WA9PIE

2019-02-28 10:43

administrator   ~0007534

Validated

Issue History

Date Modified Username Field Change
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 => 6.5.0.191
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
2019-02-24 14:36 WA9PIE Fixed in Version 6.5.0.191 => 6.5.0.196
2019-02-24 15:13 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe
2019-02-26 22:37 WA9PIE Status closed => assigned
2019-02-26 22:37 WA9PIE Resolution fixed => reopened
2019-02-26 22:37 WA9PIE Product Version 6.5.0.187 => 6.5.0.196
2019-02-26 22:37 WA9PIE Fixed in Version 6.5.0.196 =>
2019-02-26 22:37 WA9PIE Testing Beta Successful => Not Started
2019-02-26 22:37 WA9PIE Note Added: 0007519
2019-02-27 21:10 K7ZCZ Status assigned => resolved
2019-02-27 21:10 K7ZCZ Resolution reopened => fixed
2019-02-27 21:10 K7ZCZ Note Added: 0007527
2019-02-28 10:43 WA9PIE Project Ham Radio Deluxe => 3 - Current Dev List
2019-02-28 10:43 WA9PIE Status resolved => closed
2019-02-28 10:43 WA9PIE Fixed in Version => 6.5.0.198
2019-02-28 10:43 WA9PIE Testing Not Started => Beta Successful
2019-02-28 10:43 WA9PIE Note Added: 0007534
2019-02-28 13:21 WA9PIE Fixed in Version 6.5.0.198 => 6.5.0.199
2019-02-28 13:23 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe