USALS Notebook

[pendragon]

But, I am left with a question here. If the USALS calculations and equations are freely available to all manufacturer's of receivers, then why would a difference exist? Do you suggest that the manufacturer's are using their own modifications to the USALS algorithm?

I was a little frustrated that if the algos are freely available to any manufacturer, whether they pass compliance or not, why shouldn't STAB simply publish these in the open literature? It's possible the Moteck site that BJ found has effectively done this, because it agrees completely with the Pansat 9200HD until an obvious bug appears. I did not try to unwind their code.

I think the simplest explanation is the USALS calculations may use a zero declination offset, or consider the direct rotation to the satellite position. Unfortunately neither of these is a good fit for a properly adjusted dish mount. It's also possible they didn't want the added complication of having the user enter the declination angle into the receiver, or having the receiver tell the user how to adjust the declination angle. That would be a major departure from having to only enter one's lat and long.

In order for any receiver to sport the USALS official logo, they have to pass the USALS lab tests to verify the integrity of the receiver and adherence to the USALS math program.

This argues that all implementations should use the approved algorithms. In fact it would be silly not to use them and still try to get STAB's approval. One factor is that USALS was developed in a Euro-centric environment. I have no direct experience with dishes there, but my sense is they tend to be smaller and generally cover a smaller arc compared to FTA here. I don't want to over-generalize, so my apologies if this last statement is unfounded. However if there is an element of truth to it, the USALS algorithms may have been developed with this mindset and the verification would then be a natural fallout.

I have both motors, a PowerTech DG-280 and a DG-380, and I am using a Coolsat 5000 receiver to control them. All my dishes are Winegard DS-2076 models. The LNBF's are Invacom QPH-031. I do not have a Pansat 9500HD receiver to compare my results with, but I do not seem to detect any discrepancies in the tracking with this receiver and setup. Just FYI.

Did you compare the results with your Pansat 9500HD with another receiver? With more than one receiver?

The Winegards have a beamwidth of about 2.4 degrees, which will be more tolerant of pointing errors than the 1.2 m I used with a beamwidth of 1.4 degrees. You do have a valid question whether different receivers have different implementations. That was concern of mine and one of the reasons I brought my work to the forums. I have seen off-hand comments over time that indicate I am not the only one seeing these issues.

I only have a Pansat 9200HD as a standalone receiver. As there is no receiver that does everything I want, it was a reasonable compromise as it could do HD, H.264, DVB-S2 and blindscanning, albeit on DVB only. I only use this for hunting and playing. I also have five USB/PCI receivers for our 'operational' uses. One of the primary reasons for this research was to weed out the software applications that cannot properly send DiSEqC commands and motor positionings. Unfortunately that has proved to be every one I have tried. I am now writing code snippets on Linux to do this right. If I can find the time, I will write a full-up application.

I find your discussion very informative and interesting as I recently tested a Sonic View 360 Premier receiver and it was not very accurate when USALS mode was implemented. I will not go into the entire details of what I found, but I will state that it was basically unusable until I had recorded several satellites using DiSEqC positioning first. Then, I was able to set other satellites to utilize USALS positioning and they appeared to be fairly accurate in locating the satellites. It seemed that the positioning algorithm in this specific receiver required more input from the user (me) in order to calculate the position of all satellites. That indicated to me that this receiver was not using a true form of USALS. It also did not display the official USALS logo.

With my Coolsat 5000, this does not appear to be the case. Once I have aligned the dish to one satellite, my true south satellite, it was able to determine (position) the motor accurately to all other satellites.

Pendragon, does the receiver in question, the Pansat 9500HD, have an official USALS logo? If it does not, I submit that they may not be utilizing an accurate positioning program. Maybe they are using a GOTO X program, as one possibility. Something that closely emulates USALS, but is not as accurate.

The Pansat 9200HD has all the proper DiSEqC 1.3 and USALS logos.

 

[B.J.]

I think we're basically using the same approach and geometry. I start with the dish's rotation axis tilted down with respect to the true polar axis. Some people call this the polar axis tilt and in my case it is 0.695 degrees. On this rotation axis the dish is further depressed by what some people call the declination offset which was 5.526 degrees for my calculations. With these values my dish will point exactly at a true south satellite. As the antenna scans east or west, the dish will initially point very slightly under the actual orbital positions, before starting to rise again.

There's nothing sacred about the choice of these two angles, because one can optimize the fit where one wants.

Yeah, it sounds like we're TRYING to do the same thing. I've spent much of the afternoon trying to figure out exactly what I actually did, and I can't figure it out.
The wierd thing is that one of my intermediate results agrees pretty closely with your results, but I THOUGHT it was a result for NOT cosidering the forward tilt.... but I'm not sure now. I'll probably spend most of tomorrow trying to figure out whatI did.

I DID check my Fotec Ultra, an it agrees perfectly with your Pansat numbers, which I guess isn't surprising. But apparently they aren't using the Motec equations, and have some problem with the sats real close to the horizon.

I agree with the " There's nothing sacred about the choice of these two angles" thing, at least for alignment. I look at it as finding two declinations to interpolate between. Relative to the USALS angle, I'm not sure if it makes a difference or not.

As far as my derivation, I don't like drawing complicated diagrams that require a lot of trig. Instead I calculated the cartesian coordinates of each satellite and my location on the earth's surface. From that I could quickly obtain the true vector to the satellite and the various pointing angles.

To figure out where my dish points for a given motor angle, I did a series of coordinate transformations. The first in the plane of the dish, the second in the plane of the rotated polar axis, the third in the plane of a non-rotated polar axis and finally in the tangent plane of my location on the earth's surface. Using linear algebra I only have to multiply three simple rotation matrices and I'm done. To find the motor angle I made the approximation of matching the sine of the rotated pointing vector to that of the true vector. This yields a miniscule error compared to the closest match of the two vectors, but provides a closed solution. Because of the simplicity of the derivation, I'm pretty confident that it is correct, if a bit ugly.

Again, this sounds REAL similar to what I was TRYING to do, but it's been 45 years since I've done any of those rotated polar axis things, so I had to mix in some simplifications of my own.

Anyway, it's nice to get into this again, because I'm sure I had some approximations which affected my results, but since they were within a couple tenths for all the angles I compared, I didn't bother trying to get it perfect.

 

[dhubsith]

I only have a Pansat 9200HD as a standalone receiver. As there is no receiver that does everything I want, it was a reasonable compromise as it could do HD, H.264, DVB-S2 and blindscanning, albeit on DVB only. I only use this for hunting and playing. I also have five USB/PCI receivers for our 'operational' uses. One of the primary reasons for this research was to weed out the software applications that cannot properly send DiSEqC commands and motor positionings. Unfortunately that has proved to be every one I have tried. I am now writing code snippets on Linux to do this right. If I can find the time, I will write a full-up application.

Pendragon, thanks for the information you have provided.

I am using xdipo to move my dish, but have had a couple of problems with it. First, the "Goto Angle" command does not work with any satellite west of my location (108.3W). To go to a satellite west of me, such as AMC21, I have to tweak the dish east and west using the "Installer Commands" until I lock on a signal, then store the Satellite Number. After that I can return to the same position using the "Goto Sat Nr" command. I cannot tell if the problem is with xdipo or with my STAB HH90 rotor, but it has never worked right.

The other problem is that the further away from due south I go, the greater the error. Here is my "baseline" streams.dat, computed simply by adding or subtracting the offset from due south:

29 11612.00 h 3670 -50.30 IN9 58.00 8192
30 12055.00 v 6890 -36.30 AMC6 72.00 8192
31 11735.00 h 6616 -34.30 HZN2 74.00 8192
32 12178.00 h 20500 -29.30 AMC5 79.00 8192
33 11718.00 h 4859 -21.30 AMC3 87.00 8192
34 11955.00 v 19532 -19.30 G28 89.00 8192
35 11780.00 h 20760 -13.30 G3C 95.00 8192
36 12177.00 v 23000 -11.30 G19 97.00 8192
37 11774.00 v 14321 -9.30 G16 99.00 8192
38 12120.00 v 30000 -7.30 AMC4 101.00 8192
39 12100.00 v 20000 -5.30 AMC1 103.00 8192
40 11800.00 v 26657 14.70 G18 123.00 8192
41 12180.00 v 30000 16.70 AMC21 125.00 8192
42 11966.00 h 2920 20.70 G27 129.00 8192

And here is the actual streams.dat that I use:

29 11612.00 h 3670 -54.30 IN9 58.00 8192
30 12055.00 v 6890 -39.80 AMC6 72.00 8192
31 11735.00 h 6616 -36.80 HZN2 74.00 8192
32 12178.00 h 20500 -31.30 AMC5 79.00 8192
33 11718.00 h 4859 -22.80 AMC3 87.00 8192
34 11955.00 v 19532 -20.30 G28 89.00 8192
35 11780.00 h 20760 -13.00 G3C 95.00 8192
36 12177.00 v 23000 -11.30 G19 97.00 8192
37 11774.00 v 14321 -8.80 G16 99.00 8192
38 12120.00 v 30000 -6.30 AMC4 101.00 8192
39 12100.00 v 20000 -4.30 AMC1 103.00 8192
40 11800.00 v 26657 16.20 G18 123.00 8192
41 12180.00 v 30000 18.20 AMC21 125.00 8192
42 11966.00 h 2920 22.20 G27 129.00 8192


I would be very interested in seeing your updates to xdipo, and of course if you write a complete app that would be even better.

Thanks.

 

[pendragon]

Again, this sounds REAL similar to what I was TRYING to do, but it's been 45 years since I've done any of those rotated polar axis things, so I had to mix in some simplifications of my own.

This is the essence of the derivation, if it helps:

Center the earth at (0,0,0). The z-axis is aligned with the poles and the x-axis is pointing through the equator towards the "true south" orbital position. The position of our dish is then:

dishVector = (re*cos(lat), 0, re*sin(lat))

where:

re = radius of a spherical earth (6371 km)
lat = latitude of our location

The location of any geosynchronous satellite is

satVector = (rg*cos(off), rg*sin(off), 0)

where:

rg = radius of geosynchronous orbit (42164.17 km)
off = orbital offset from true south

We can form two vectors from these:

trueSouthSatPointing = satVector(off = 0) - dishVector
satPointing = satVector(off = orbital offset) - dishVector

If we take the inner product of these two vectors, we can calculate the angle between them. This angle seems to be what USALS claims is the motor angle. I've referred to it as the Direct Angle.

Now we move on to to how we typically build and align a FTA dish. There are three angles involved:

Alpha - Polar axis tilt ~0.7 degrees
Beta - Declination offset ~ 5.6 degrees
Theta - Motor angle

Let's unwind these starting with the plane of the dish itself:

Beta rotation - x-axis is the direction dish is pointing y-z plane is the dish plane; rotation about y-axis (down)
Theta rotation - z axis is the dish rotation axis; x is toward dish; rotation about z-axis (east-west)
Alpha rotation - z-axis is parallel to the true polar axis; x-axis is south; rotation about y-axis (down)

Each one of these is a simple rotation matrix. I've notated the matrices and the final product in my attachment. The resulting vector is where the dish will point with these three rotations. We can compare this to the direct vector, which is pointing exactly, to measure any error.

My only approximation is, after normalizing both vectors, to set the y-coordinate of each to be the same and solve for theta to get the motor angle. The correct way to do this would be to calculate the offset angle between the two vectors as a function of theta, take the derivative and set in to zero. The error involved with the approximation is negligible because we are talking about angle differences of a few thousandths of a degree, so I took the shortcut.

 

[pendragon]

I am using xdipo to move my dish, but have had a couple of problems with it. First, the "Goto Angle" command does not work with any satellite west of my location (108.3W). To go to a satellite west of me, such as AMC21, I have to tweak the dish east and west using the "Installer Commands" until I lock on a signal, then store the Satellite Number. After that I can return to the same position using the "Goto Sat Nr" command. I cannot tell if the problem is with xdipo or with my STAB HH90 rotor, but it has never worked right.

The other problem is that the further away from due south I go, the greater the error. Here is my "baseline" streams.dat, computed simply by adding or subtracting the offset from due south:

<snip>

While xdipo is a very useful tool, the calculations of the motor angle it makes are simply incorrect. If you enter the motor angle yourself, it looks like it will send the correct command. However I didn't test the original code because I rewrote that part for my tests. I believe the errors you are seeing are primarily caused by the incorrect angle being calculated by xdipo. However there may be errors in your motor, too. When my motor is set to a zero offset, the down-tube is actually slightly rotated. I modified xdipo to incorporate a zero-offset correction to compensate for this.

I would be very interested in seeing your updates to xdipo, and of course if you write a complete app that would be even better.

At this stage my xdipo is hacked to do what I want. My internal debate is whether to fix the code and incorporate my motor angle calculations, or to simply write my own application. I am leaning a bit to the latter, because:

1. I would prefer to have a Java app running on my laptop, commanding a headless app in Linux, as compared to running X-Windows through a ssh tunnel.

2. xdipo is blissfully unaware of DiSEqC switches between the receiver and the motor. In my case I have three motorized dishes, one with two LNBs, one with four and one with six. That is currently run through a combination of DiSEqC 1.0 4x1 switches, one for each of six receivers, and 4x8 switches, one for every four LNBs. I'm working to add a DiSEqC 1.1 8x1 switch for each receiver, plus bunches of 4x8 switches to handle up to 32 LNBs on fixed dishes. This could be theoretically scaled to 128 LNBs, but I doubt that will happen, soon To teach xdipo how to untangle this with its current architecture makes a rewrite look easier.

3. It would be nice to have a master running the motors and switching for a pool of the five USB/PCI receivers we use to distribute FTA programming to multiple locations in the house. This would simplify dish pointing for those family members who don't want to decode DiSEqC commands on a scope.

 

[guapoharry]

...It would be nice to have a master running the motors and switching for a pool of the five USB/PCI receivers we use to distribute FTA programming to multiple locations in the house. This would simplify dish pointing for those family members who don't want to decode DiSEqC commands on a scope.

:haha

I don't follow why pendragon used the theodolite as discussed in post #1.

 

[pendragon]

I don't follow why pendragon used the theodolite as discussed in post #1.

Way overkill, but it did allow me to make sure all of the angles were correct.

 

[B.J.]

This is the essence of the derivation, if it helps:

Center the earth at (0,0,0). .....

Thanks.... I'll take a look at that, and eventually try to remember how to do the matrix math, which I haven't done for years.

But I went back, trying to figure out my equations in my calculators.
I quickly concluded that I was getting the wrong answers at the extremes, like you said, however I couldn't figure out what the heck I did wrong, so I re-wrote the thing from scratch, using the same approach, but doing things in a different order. Turns out I made it WAY harder than it needed to be.

Anyway, I *THINK* that I've corrected my calculator, and it now pretty much agrees with what you have.

It is strange that both your Pansat and my Fortec diverge when close to the horizon, but I would never notice that difference here, as I can't get anywhere near that close to the horizon due to trees.

Anyway, thanks for starting the discussion. I'd still have errors in my calculator otherwise.

 

[Anole]

I think the simplest explanation is the USALS calculations may use a zero declination offset, or consider the direct rotation to the satellite position. Unfortunately neither of these is a good fit for a properly adjusted dish mount.

I don't see any way they could justify such a poor design...
But as mentioned, larger dishes with wide beam angles might have led them to an oversimplified solution.

It's also possible they didn't want the added complication of having the user enter the declination angle into the receiver, or having the receiver tell the user how to adjust the declination angle. That would be a major departure from having to only enter one's lat and long.

The declination can be computed, or fetched from a table, so user interaction is no excuse for a half-assed job.

The fact that actual declination is hidden (ignored by the user) when setting up the typical STAB H-H motors, doesn't mean it's not there.
It's just conveniently glossed over.

 

[Babadem]

This a wealth of information on USUALS!!:up

 

[pendragon]

After all of this time I would like to correct some nomenclature errors I have made. It does not affect any of the results, however.

If one sets the polar axis of a motor to match one's latitude, one will need to lower the antenna's elevation relative to the shaft perpendicular to exactly point at the true south position in the Clarke Belt. This is properly called the 'declination angle' and is always non-zero except at the equator. USALS does take this into account. Unfortunately as the dish is rotated closer and closer to the horizon, it will point farther and farther off the arc. USALS has exactly this problem and hence this thread.

One can achieve much better tracking if a small offset angle is introduced when setting the polar axis angle. This is sometimes referred to as 'polar axis tilt'. A corresponding adjustment must then be made to the declination angle to point exactly at true south. With reasonable choices of polar axis tilt, the tracking error can be brought to within 0.01 degrees over the entire visible arc for most latitudes. The choice of the polar axis tilt does depend on one's latitude, so there is no "one-size-fits-all" value. However it is arbitrary in that for a given latitude, varying it will affect where the fit is exact and where the largest deviations occur. Fortunately one has a fairly broad range where the errors are not that sensitive to its choice.

The problem with USALS is it assumes a zero polar axis tilt. I have carelessly referred to this several times as declination in this thread, which it is not. However my calculations were all correct and the results can be interpreted properly with this terminology repair. Sorry for any confusion.

 

[Anole]

One can achieve much better tracking if a small offset angle is introduced when setting the polar axis angle. This is sometimes referred to as 'polar axis tilt'. A corresponding adjustment must then be made to the declination angle to point exactly at true south. With reasonable choices of polar axis tilt, the tracking error can be brought to within 0.01 degrees over the entire visible arc for most latitudes. The choice of the polar axis tilt does depend on one's latitude, so there is no "one-size-fits-all" value.

I believe the table called Modified Polar Mount Tracking Angles on the Geo Orbit site implements this fix.
And it still seem to me that a motor product or a computer program could easily carry the correction in a look-up table.

The problem with USALS is it assumes a zero polar axis tilt.

How could one best fool a STAB motor and USALS-certified receiver to come closer as the motor swings the dish east or west toward the horizon?

 

[pendragon]

I believe the table called Modified Polar Mount Tracking Angles on the Geo Orbit site implements this fix.
And it still seem to me that a motor product or a computer program could easily carry the correction in a look-up table.

Yes, this table seems to be in the ballpark. Alternately instead of a look-up table, one could simply calculate the polar axis tilt and declination angles. The minor problem for a USALS receiver is they would either (1) have to tell you how to set these angles after you entered your lat/longs or (2) have a way for you to enter the angles you set. This would make the existing, very simple USALS interfaces a bit more complicated.

How could one best fool a STAB motor and USALS-certified receiver to come closer as the motor swings the dish east or west toward the horizon?

You could enter offset orbital positions instead of the actual values. That's a bit of a pain, but you would only have to do it once for each position. I found it easier to write my own software for my never-to-be-completed Linux rework

 

[B.J.]

I had originally assumed that there was an official USALS motor angle algorithm, and I had assumed that the GAAPS calculator web page must use that algorithm.

I have changed my mind on that. I now think that USALS doesn't have any official algorithm for calculating the motor angle, but instead just leaves that up to the receiver manufacturers, and leaves it up to the motor manufacturers to go to the proper angle. The GAAPS web page apparently uses an algorithm that is faulty, and it looks like different receivers use subroutines that give even other results. I also notice that the GAAPS web page also calculates dish elevation angle, and uses the conventional zero forward tilt method for that. So I have lost all confidence in the GAAPS page.

Relative to the forward tilt angle, although it is a bit arbitrary with respect to what number is used, I have always calculated the declination of the sat to the south, and the furthest west slot, and subtracted these, and used the difference. In MY case, for my 44.1 latitude and 70.8 longitude, the south declination is 6.725, and the west declination calculated by my calculator is 6.04, and subtracted to get 0.685 degrees for the forward tilt, although I've always rounded this off to 0.7 deg. However, I can't remember how I chose the sat position for the western satellite. I MAY have chosen a sat with an azimuth of 270, ie due west, however a sat to my due west is below the horizon, and thus may not be a good choice.
Anyway, I was curious just how much difference it made relative to what forward tilt angle is used, so using MY location, used the spreadsheet I use to calculate the USALS angles, then calculated the declination of each orbital slot assuming polar tilted axis coordinates. Ie if the tilted axis (modified declination) method was perfect, all the declinations would be the same, and the results could be compared to the conventional zero tilt method which will be off by the 0.685 degrees on my extreme sat.
Well, the results weren't perfect, but they were pretty good. ALL the declinations, across the arc that I can see, were all within +/- 0.0066 degrees of the same 6.045 degree declination (which was the western sat declination I used). Ie accurate to less than 1/100th of a degree.
Out of curiosity, I started varying the forward tilt angle to see how much it changed the results. Interestingly, I found that the 0.70 deg forward tilt actually gave me better results, with all values were within +/- 0.0025. A value of 0.707 was actually the best fit, giving a standard deviation of .0012, and all values except the extreme (below an 11 deg elevation near the horion) are within .0017 of the average value.
So it's not perfect (unless I still have bugs in my program, which is VERY possible, however it is MUCH MUCH better than using the conventional zero tilt method which will be off by nearly 0.7 degrees. And if you add that 0.7 deg error due to not using modified declination to the error introduced by the USALS algorithms in the receivers, it shows that you can be off by quite a bit if you use USALS on a system aligned via the conventional method which virtually all motor manufacturers recommend in their manuals.
So the most accurate tracking would seem to be by using the forward tilt, modified declination method AND to either use diseqC instead of USALS, or modify the sat longitudes as suggested above in order to eliminate the USALS error.
However, if my spreadsheet is accurate, I am a bit confused relative to how to accomplish the best fit. I've always assumed that it was best to set the polar axis elevation then peak on your south sat first, then peak on the extreme sat via mount azimuth. However looking at my spreadsheet suggests that it might be best to peak on a sat approximately 54 deg west or east of your south sat for both elevation AND azimuth.... but this just sounds wrong. I think I'll continue to do it my old way, as that should be capable of being within 1/100th of a degree if I do it right, and I can't get close to that accurate on the first elevation setting anyway.

 

[pendragon]

It sounds as though you and I came to basically the same conclusions. Last year I wrote a short piece of code that plotted the tracking error for different values of the polar axis tilt and declination angles over the entire arc. I ran it over a range of values and realized that the overall errors are generally insensitive to particular choices. As many are of the order of 0.01 degrees or less, it is all irrelevant to FTA given the aperture sizes we use and the more dominant errors sources present in our mechanical alignments.

From an academic point of view, the choice of these parameters allows a lot of freedom of where the fit is perfect, the maximum deviations and where those deviations are. There is no one perfect or best fit. One could define one such that the overall errors are minimized over the arc, but even this will be arbitrary (does one consider error**2 or abs(error) for example). More practically one is not likely to track satellites with the same positional density over the entire arc. Many of us have trees blocking look angles, and when one lives in the western US, there is nothing much on the western part of the arc at all. I'm just pointing out that if this optimization actually made any difference, we FTAers would have a lot of choices to make.

I have only one USALS certified receiver and the GAAPS page to compare. For my latitude they agree almost exactly on the calculated motor angles. Curiously they also agree with the 'direct angle' method I defined earlier in this thread. While this is flimsy evidence, it certainly made me speculate whether there was an official USALS algorithm, and whether both of these implementations were using it. If true, such an algorithm not only assumes a zero polar axis tilt, but makes other simplification errors.

It's hard to tell whether a particular receiver's implementation is actually USALS certified, and what that really means in terms of accuracies. Last year I also tested a number of PC-based USALS calculations, some of which are available as open-source. I did not find any that were truly accurate over the arc, and none that incorporated a non-zero polar axis tilt. I don't remember any of them agreeing. This wasn't an exhaustive study, but I did conclude this is somewhat a Pandora's box. USALS was a great idea, but its implementation was not carefully reviewed.

 

[a33]

How could one best fool a STAB motor and USALS-certified receiver to come closer as the motor swings the dish east or west toward the horizon?

This may be an old thread, but I read it some time ago and found it very interesting, and very puzzling at the same time, because back then I didn't understand a lot of it I must confess.
However now I understand quite a bit more, and maybe can add some usefull info.

The calculated rotation angles for a motor axis parallel to the earth polar axis is also called Hour Angle in some calculators.
(Hour angles are also the base for calculating LNB-distances for multifeed-rails on satellite dishes, by the way.)

For calculating angles for the adjusted motor angles, using a polar axis tilt, I had the following thought:
With a tilted rotation axis, the "equator" of the rotation gets lower than the earth equator, to exactly the amount of degrees of the axis tilt.
So with calculating the adjusted Hour Angles, the axis tilt value has to be added to the value of the latitude angle, used in the formula for the Hour Angle.
All the other variables in the formula can then remain the same.

I put this way of calculating in a spreadsheet, an got results only some hundredth degrees different from the values of pendragon and B.J.
So my way of calculating must be accurate enough, I would say.


The latitude alteration would also be the way to trick the 'normal' USALS Hour Angle calculation of a receiver, I think.
Add the difference of the "normal" motor elevation and the used "adjusted" motor elevation to the latitude value in the receiver, and you get the "adjusted" hour angle (which is then sent to the motor).
(You can also use the difference between the "normal" declination angle and the used "adjusted" declination angle; that is of course the same value.)


I compared the values of the normal hour angle and the adjusted hour angle for some earth coordinates and a range of satellites, and the difference between them was never more than 0.07 degrees, I'm afraid. I had expected bigger differences.
However maybe for hard to get satellites it might be of help, to use this adjusted latitude value.


greetz,
A33

Edit: BTW, I 've never seen tested that a USALS calculation of a receiver actually sends the diseqc command corresponding to the hour angle (that is the rotation angle when using a motor axis parallel to the earth polar axis). Has anyone tested this, with a diseqc command reader or oscilloscope or other measuring instrument?

 

[a33]

BTW I used the Huevos method of this post: Traditional vs Modified Elevation/Declination Angles
i.e. taking the mean of the 'southern' and 'northern' satellite declination; and then of course also altering the motor elevation angle by the difference of 'normal' and 'modified' declination angle.
That is rather easy to calculate in a spreadsheet, as I don't understand vector calculations.....

I noticed that you both, pendragon and B.J. , use even a slightly higher forward axis tilt for your locations, than calculated with this method.
But I comfort myself that that could result in tracking errors of only some hundredth of degrees, if I understand you well, and it isn't a bad choice as it is very near your tilt angle.

BTW2. I noticed that the satsig.net data in your (pendragon's) table in post #9 are exactly the same as with a motor axis parallel to polar axis calculation, using 6378 as earth radius.
BTW3. Why would the 'direct angle' in that table be different from the 'polar angle' (which would be the correct USALS angle, if I understand correctly)? What then is the nature of this 'direct angle'? I don't understand.

Greetz,
A33

 

[Cham]

Using an SG2100 and HH120 motors here with around 2 degree aperture antennae (90cm and 100cm dishes respectively) I have found the assemblies to be quite accurate even at low angle targets satellites to the east. I have found changing the latitude entry in the USALS menu in the receiver or PC software 1-2 degrees lower seems to help a bit though, suggesting an error somewhere. I have always thought this error might be a combination of latitude and declination adjustments. Any error seems to be less than 1 degree so manufacturers likely don´t bother fine-tuning the manufacturing process due to cost of production and maintaining a low price point.

Since USALS on these motors only allows 30 deg or so sweep from ¨0¨ (true south) I am able to aim at 30W at 6deg elevation using diseqc, running the motor to the eastern stop which seems to be where the best signal is acquired. Playing with azimuth, elevation, and skew does not improve the signals from 30w suggesting good hardware tracking. This also might suggest manufacturers are aware of the USALS error and restrict the range of it´s use to the approximate 60deg sweep?

Maybe this range angle varies with manufacturer, but I get a USALS error on both positioners that I use when a target is entered beyond this range.

Nice work on the calculations, maybe we´ll see some better firmware for USALS in the future!

 

[Fizbi]

I just picked up on this thread...

My question is, do any of the USALS calculations account for altitude, and does it make a difference?

I live over a mile high above sea level. I know my head sunburns faster here than at sea level, and that all my clocks with a penduleum, had to be readjusted (to accurately keep time) when I moved from sea level to my current location. Yes, gravity changes with altitude.

I attribute my arc misses (at the extreme ends) to a warped dish, sloppy motor, and the dish leaning to the side acting as a lever to pull the dish off true south.

All good arguments to plant a dish farm and stop using motors, or install a counter balance (if needed).

 

[Cham]

Altitude should not make a difference to USALS calculations, at least not enough of a difference to change settings. If you needed accuracy to less than 1/10th of a degree then maybe... Consider how far away the satellite is and if it moved a mile up, down, left, or right, it wouldn't make a change in reception.

However... as you mentioned sunburning your head.. there is less atmosphere up there than at sea level so signals to the horizon should be better than lower down in elevation. If you are on a mountaintop then you might even squeek in a half or a degree or more off your horizon... but at 5000ft not much of a difference.