View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001833||3 - Current Dev List||Bug||public||2015-12-02 05:18||2019-01-29 23:31|
|Target Version||Fixed in Version||188.8.131.52|
|Summary||0001833: HRD Rotor - When South Stop is selected, East becomes 270 dgrees|
|Description||HRD Rotor - When South Stop is selected, East becomes 270 degrees on the map screen and on the HRD Rotor display.|
|Steps To Reproduce||Select a rotor, even the demo AZ one .. select South stop.. |
Click on the map East of your location - bearing is shown as 270.. Click West - bearing is shown as 90 ..
North and South bearings are correct. 0 or 360 is North 180 is south
|Additional Information||#909158 ticket|
|Tags||No tags attached.|
|related to||0001384||closed||JOSE||Rotators with south stop stop positions (Yaesu G-540) do not work correctly|
|related to||0001637||resolved||JOSE||Rotator DCU-2 North/South Stop not working correctly|
|related to||0002751||closed||WA9PIE||Documentation: "South Stop" option not described in documentation|
|child of||0002917||resolved||WA9PIE||"South Stop" implementation has problems and needs to be fixed or removed|
Reminder sent to:
still outstanding - and we still get calls
Reminder sent to: ERIK
please help fix?
This issue still remains un-resolved and that is if the rotor is configured as a "South Stop" the guage is flopped and indicates that WEST is at the 90 degree position on the gauge. When you click in the Atlantic ocean, which should indicate 90 degrees on the gauge, although the indicator is pointing EAST, toward 90 degrees, the gauge is actually indicating EAST is at the 280 degree mark and WEST is at 90 degrees. This is just opposite of what it should be. The gauge should not be flopped when the "South" stop is configured.
South Stop Rotator.jpg (185,061 bytes)
South Stop Rotator.jpg (185,061 bytes)Proper display with North Stop.jpg (284,829 bytes)
It seems like this should be an easy fix. The rotor dial display should always show East to the right, West to the left, South at the bottom, and North at the top.
RotorDialOrientation.png (96,067 bytes)
RotorDialOrientation.png (96,067 bytes)
||I notice that the "south stop rotator" screenshot shows the azimuth line drawn to the east with a label of 276 degrees. While I am able to reproduce the issue with the oritentation of the labels on the gauge, I'm not able to reproduce the what's depicted in the screen shot with the azimuth label being 276 degrees when pointing east-ish while the south stop is selected.|
This is another issue that seems to suffer from a clear specification of the desired behavior. We're also struggling because we don't have any hardware to test with; and we don't have broad knowledge of the range of products we support to know if a proposed solution might be specific to a vendor (or even a model), is settable, or what user requirements surrounding the feature really are.
At the moment, the Rotator's stop setting can be set to "North" or "South". This setting controls a member variable in the rotator's frame (implemented as CRotatorFrame in RotatorFrame.cpp, with some more code in RotatorFrameSetPosition.cpp). The member is a boolean named m_bNorth. If the UI is set to "North", this member variable is true; if set to "South", this member variable is false.
The member variable controls a few things in the UI regarding the behavior of the application.
When the stop is set to "north", the limits and range of the gauge are set to be from 0 to 360.
When the stop is set to "south", the limits and range of the gauge are set to be from 360 to 0. This effect is noted in the screenshots above; in the North setting, 30 degrees is clockwise from 0 on the guage. With the south setting, 30 degrees is anti-clockwise from 0 on the gauge.
If the code in the gauge were modified to always range from 0 to 360, then the labels on the gauge would increase in a clockwise direction regardless of the stop setting. That is, even if "south" were selected, 30 degrees would be clockwise from 0 rather than anti-clockwise from 0. It seems like this fix is the core of what this issue requests.
But the issue is, of course, deeper.
Even with the gauge's labelling fixed, the "south" setting changes the computation of the azimuth.
The computation of the azimuth depends both on the north/south stop setting, but also on the model of rotator selected.
If the selected brand of rotator is an M2 Az or M2 Az/El, the north/south stop setting is ignored. For all other brands and models, when "South" is selected, the azimuth is adjusted. A heading of 200 is more than 180, so 180 is subtracted from 200 leaving 20. A heading of 40 is less than 180, so 180 is added leaving a heading of 220. The "south" and non-M2 computation effectively adds 180 degrees to the azimuth.
Further, the Rotator application includes logic that is intended to minimize the change in rotation angle when a new azimuth is selected. After the above computation, the resulting azimuth is compared with the known position of the rotator and a decision is made to travel "over" or "under" to reach the desired setting. This decision takes into account the rotation limits of the rotator.
The claim is made that "this should be an easy fix". "Easy" is a common estimate from someone who's not actually doing the work, and an examination of the reality reveals unanswered questions as well as some complexity.
One issue is that the application actually uses the setting of the gauge to maintain the position of the rotator. If the rotator reports a position, the position is set to the gague. If the application ever needs to know the position of the rotator, it actually retreives that value from the gague itself. If the gauge ever translates the position of the rotator, then that must be taken into account. Ideally, the application would maintain the position of the rotator in internal state; then draw heading lines and gauge position based on that state rather than using the visualization to use the state.
Since we're uncertain of which brands of rotators should be controlled in which way, we don't know if the use should be told the actual value sent to the rotator or the effective direction of the rotator. If the application needs to maintain two separate values for azimuth (for the actual azimuth and the perceived azimuth), then the gauge control itself can't be used to manage the actual position since it shows the perceived position.
If the perceived position and the actual position are the same, then the fix is less involved.
In either case, we must first understand if the application is responsible for managing the azimuth setting of the rotator or not. If not, then the setting doesn't need to exist. If so, then the north/south setting must be maintained and its implementation defined well enough to correctly implement.
Perhaps this will clear-up this topic a bit. The intended behavior for this item is that the rotor display is oriented as shown here when the Stop position is set to "South (180)".
RotorDialOrientationCorrect.png (84,648 bytes)
RotorDialOrientationCorrect.png (84,648 bytes)
To collect up some artifacts, I'm attaching the Green Heron RT-20 setup guide. It speaks a bit to configuring the "North stop" and "South stop" in the controller.
RT-20_Manual_3_3_041606.pdf (806,633 bytes)
This Prosistel Manual describes that controller's north and south stop settings. It specifically says that south stop directions are reversed compared to north stop drections.
Prosistel Manual rev 2001_12A.pdf (520,319 bytes)
I'm sure the Prosistel manual does say that the south stop direction is reversed compared to the north stop. But that doesn't imply that East is 270 degrees and west is 90 degrees. It implies that a south stop rotor can't travel past 180 degrees and a north stop rotor can't travel past 360. Those are opposite. This is as I understand it. Probably, all manual describe it in a similar way.
I've had one rotor. It was oriented to a south stop. I had no controller at that time.
To the point - if we're going to fix this properly, we're going to need some experts in this who can help us understand it better.
Still receiving complaints about this and customer is far from happy.
Please escalate this one
||South/North stop have been removed.|
||Status||new => assigned|
||Assigned To||=> W4PC|
||Status||assigned => confirmed|
||Severity||minor => major|
||Note Added: 0000715|
||Note Added: 0000716|
|2017-07-11 09:11||K7ZCZ||Assigned To||W4PC => K7ZCZ|
|2017-07-11 09:13||K7ZCZ||Assigned To||K7ZCZ =>|
|2017-07-11 09:13||K7ZCZ||Assigned To||=> K7ZCZ|
|2017-07-11 09:13||K7ZCZ||Status||confirmed => assigned|
|2017-07-11 09:13||K7ZCZ||Project||2 - Next Dev List (Holding Area) => 3 - Current Dev List|
|2017-07-11 09:18||K7ZCZ||Relationship added||related to 0001384|
|2017-07-11 09:38||KB3NPH||File Added: South Stop Rotator.jpg|
|2017-07-11 09:38||KB3NPH||File Added: Proper display with North Stop.jpg|
|2017-07-11 09:38||KB3NPH||Note Added: 0003623|
|2017-09-18 00:14||WA9PIE||Project||3 - Current Dev List => 2 - Next Dev List (Holding Area)|
|2018-03-04 00:53||WA9PIE||Assigned To||K7ZCZ => JOSE|
|2018-03-04 00:54||WA9PIE||Project||2 - Next Dev List (Holding Area) => 3 - Current Dev List|
|2018-03-04 00:56||WA9PIE||Testing||=> Not Started|
|2018-05-28 11:52||WA9PIE||File Added: RotorDialOrientation.png|
|2018-05-28 11:52||WA9PIE||Note Added: 0005120|
|2018-05-28 12:10||K7ZCZ||Relationship added||related to 0001637|
|2018-05-28 14:41||K7ZCZ||Note Added: 0005121|
|2018-05-28 14:54||K7ZCZ||Note Added: 0005122|
|2018-05-28 16:17||WA9PIE||File Added: RotorDialOrientationCorrect.png|
|2018-05-28 16:17||WA9PIE||Note Added: 0005126|
|2018-05-28 16:27||WA9PIE||File Added: RT-20_Manual_3_3_041606.pdf|
|2018-05-28 16:27||WA9PIE||Note Added: 0005127|
|2018-05-28 18:18||K7ZCZ||File Added: Prosistel Manual rev 2001_12A.pdf|
|2018-05-28 18:18||K7ZCZ||Note Added: 0005129|
|2018-05-29 10:04||K7ZCZ||Relationship added||related to 0002751|
|2018-05-30 09:14||WA9PIE||Note Added: 0005155|
|2018-10-16 23:05||WA9PIE||Relationship added||child of 0002917|
|2019-01-10 11:08||PD9FER||Note Added: 0006944|
|2019-01-29 20:18||JOSE||Status||assigned => resolved|
|2019-01-29 20:18||JOSE||Resolution||open => fixed|
|2019-01-29 20:18||JOSE||Fixed in Version||=> 184.108.40.206|
|2019-01-29 20:18||JOSE||Note Added: 0007135|
|2019-01-29 23:31||WA9PIE||Status||resolved => closed|
|2019-01-29 23:31||WA9PIE||Testing||Not Started => Beta Successful|
|2019-01-29 23:31||WA9PIE||Note Added: 0007145|