View Issue Details

IDProjectCategoryView StatusLast Update
0001833Ham Radio DeluxeBugpublic2019-02-24 15:12
Reporteruser47Assigned ToJOSE 
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.5.0.196 
Summary0001833: HRD Rotor - When South Stop is selected, East becomes 270 dgrees
DescriptionHRD Rotor - When South Stop is selected, East becomes 270 degrees on the map screen and on the HRD Rotor display.

Steps To ReproduceSelect 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
TagsNo tags attached.
Testing Beta Successful


related to 0001384 closedJOSE Rotators with south stop stop positions (Yaesu G-540) do not work correctly 
related to 0001637 closedJOSE Rotator DCU-2 North/South Stop not working correctly 
related to 0002751 closedWA9PIE Documentation: "South Stop" option not described in documentation 
child of 0002917 closedWA9PIE "South Stop" implementation has problems and needs to be fixed or removed 



2015-12-18 09:14


Reminder sent to: W4PC

still outstanding - and we still get calls


2015-12-18 09:15


Reminder sent to: ERIK

please help fix?


2017-07-11 09:38

administrator   ~0003623

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)


2018-05-28 11:52

administrator   ~0005120

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)


2018-05-28 14:41

developer   ~0005121

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.


2018-05-28 14:54

developer   ~0005122

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.


2018-05-28 16:17

administrator   ~0005126

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)".


2018-05-28 16:27

administrator   ~0005127

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)


2018-05-28 18:18

developer   ~0005129

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)


2018-05-30 09:14

administrator   ~0005155

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.


2019-01-10 11:08

viewer   ~0006944

Still receiving complaints about this and customer is far from happy.
Please escalate this one

Ticket 525796


2019-01-29 20:18

developer   ~0007135

South/North stop have been removed.


2019-01-29 23:31

administrator   ~0007145


Issue History

Date Modified Username Field Change
2015-12-02 05:18 user47 New Issue
2015-12-02 05:18 user47 Status new => assigned
2015-12-02 05:18 user47 Assigned To => W4PC
2015-12-02 05:19 user47 Status assigned => confirmed
2015-12-18 09:13 user47 Severity minor => major
2015-12-18 09:14 user47 Note Added: 0000715
2015-12-18 09:15 user47 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 =>
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
2019-02-24 14:40 WA9PIE Fixed in Version =>
2019-02-24 15:12 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe