USALS Notebook

[pendragon]

I took some time off from redeploying my dishes to look over a nagging problem I had called USALS. Last year I tossed a 1.2 m GEOSATpro on the roof with a PowerTech DG-380 motor. It was easy to tweak and I soon had it tracking the Clarke belt over the motor's range.

My true south is about 105 degrees, allowing me to get most of the Ku action not too far off-center. From the beginning I noticed when using my Pansat 9200HD, the farther I drove the dish from center in either direction, the greater the in-track error in positioning. In fact both east and west errors were about the same for similar offsets, with the Pansat always driving the dish not quite far enough. I realized this might simply be accumulating mechanical errors in the motor, but the consistency was concerning. In reality this wasn't causing any real trouble, because orbital locations 45 degrees from my true south were experiencing only about a 0.2 degree error. This could be easily compensated by lying to the Pansat about the orbital location. However the error quickly got larger for the lower elevation birds.

We had high winds a few weeks ago that blew the 1.2 m mount slightly off. When resetting the adjustments I again verified the satellites far off-center only had in-track errors (ie. bumping the dish up or down only reduced the signal level). I got curious what was going on. As far as I can tell, the USALS algorithms have not been openly published. There were a handful of website calculators that made some or all of the calculations, but none agreed for significant offset angles, and none agreed with my Pansat's calculated motor angles. I also looked through a number of open-source codes for controlling USALS motors, and that only increased the cacophony.

I surmised the discrepancies might have to do with different declination offset angles, and further reading found many approaches to calculating the 'optimal' declination offset angle. Of course none were the same. As the declination offset is only an approximate correction to track the arc, it appeared the differences probably resulted from different optimization criteria. For example, one approximation might minimize the tracking error for angles close to true south, at the expense of angles close to the horizon. Another might do the opposite.

Rather than re-derive each approach and figure out where they made different assumptions, I thought this was prime territory for a little linear algebra. For fun I decided to employ a non-spherical earth model and consider my altitude (this turned out to be useless for Denver because its altitude essentially offsets the earth's polar flattening). Fairly quickly I found the Pansat calculated motor angles were precisely in agreement with a zero declination offset angle, other than when it tried to calculate orbital positions more than about 65 degrees from true south and got completely nonsensical answers.

I then set up my calculations to optimize cross-track performance by varying the declination offset angle. This was all fun and good, but not terribly practical because there were many excellent fits using different optimization criteria with maximum cross-track errors of a few-thousandths of a degree. Satellites typically are only kept positioned in a box much bigger than that, even considering the folly of thinking one could adjust a dish to that accuracy.

Nevertheless to put theory into practice I hauled up the theodolite and tweaked everything until I got bored. One of the open-source programs I had come across is called xdipo and with one of my USB receivers was an excellent starting point for a better USALS controller than the Pansat. xdipo's calculations for motor offset angles are way off, but that can be fixed. I modified a number of xdipo's controls and tweaked its display of the signal levels and quality to make it into a more precise tuning instrument. It's rather convenient because the USB receiver is inside the house run by a Linux machine running xdipo remotely over wireless to display on my laptop on the roof. In some ways this turned out to be more precise than using a spectrum analyzer, and a lot faster. It didn't take long to confirm my direct calculations of the motor angle were dead-on for the given declination angle, while the Pansat was not. I was also able to calibrate out an error in the DG-380's view of what was a zero offset angle by subtracting this out in xdipo. I haven't taken the DG-380 apart, but I would like to remove this mechanical error.

I'm confident the Pansat is making the simplifying assumption that there is no declination offset angle, causing the positioning error to increase with angle. One could partially compensate for this mechanically through an intentional misalignment, at the expense of cross-track error. That wouldn't make a lot of sense.

I can't change the Pansat USALS calculations, but I could write code for Linux to build an accurate satellite positioning system. I've put that in my project to-do hopper because the Pansat has other limitations with positioning that I am no longer willing to tolerate. Whether these same approximations/errors exist in other receivers I cannot say, but hopefully some of what I've come across may explain oddities others have observed.

 

[ikki]

Thanks pendragon for that information. Its def something worth noting.
Keep up the good research.

 

[Anole]

Pretty interesting stuff.
So, the receiver is not calculating correctly?
I though that code was freely available, so all receivers should be doing it right.

What info does the receiver communicate to the motor?
Something like: "move 2.14° clockwise"?
Or does it say: "move 1234 steps clockwise" ?

Does the receiver even know what level of fine adjustment the motor can do?
I wondered if there was a power-up handshake where the receiver could ask the motor for it's granularity?

Also, it's pretty obvious that all motors should always approach their final landing from the same direction every time.
I think some don't do that.
So, a receiver option might be to incorporate such action.
And if engaged, it should be used even for fine stepping.

 

[pendragon]

Pretty interesting stuff.
So, the receiver is not calculating correctly?
I though that code was freely available, so all receivers should be doing it right.

It is correct as long as you set up your dish without a declination offset. That's certainly not optimal. It's possible USALS was developed with this assumption to make it simpler. Otherwise you would either have to enter the declination into the receiver or have the receiver tell you what the declination needs to be. I haven't ever seen either, so in a perverted way this makes sense.

What info does the receiver communicate to the motor?
Something like: "move 2.14° clockwise"?
Or does it say: "move 1234 steps clockwise" ?

The receiver specifies an absolute angle.

Does the receiver even know what level of fine adjustment the motor can do?
I wondered if there was a power-up handshake where the receiver could ask the motor for it's granularity?

The DiSEqC 1.2 spec has a resolution of 1/16 of a degree. That's probably a reasonable choice, although it seems possible the DG-380 can be nudged in smaller increments. I don't know about other motors that support DiSEqC 1.2.

 

[B.J.]

I'm a bit surprised at the above. I did the same thing a couple years ago, convinced that the receivers must simplify things by ignoring declination, however I programmed a calculator of my own that did consider declination, and compared my results to the "semi-official" USALS calculator on the web, and the calculations done by 2 of my receivers (Fortec), and all were about the same to somewhere around a couple tenths of a degree at most, if I remember right, ie possibly roundoff errors. I do remember some minor differences, however not great enough for any USALS capable dish could ever see. I remember being relatively dissappointed that they were actually doing something right.
What I never did attempt to do (didn't have any way to do it at the time) was to determine whether after calculating the angle properly, did the receivers actually send out the proper diseqC-1.2 commands, and see whether the motor actually goes to the proper angle. It might be an interesting experiment to do now that those digital levels are available, like discussed in another thread. I'd really like to have some kind of a diseqC reader to see what the receivers are actually sending, but I've never seen anything like that. I corresponded with someone a couple years ago, who put together such a device, but I never got around to trying it. I was hoping to break into a diseqC switch and find places to tap off and hopefully extract the dc diseqC signal levels instead of needing to deal with the 22khz. I just thought it would be neat to be able to monitor just what the receivers were saying to the switches and motors.
But back to the original, I'm surprised that you're seeing significant errors in the "calculations". I didn't see that with my receivers.

 

[starman345]

I just thought it would be neat to be able to monitor just what the receivers were saying to the switches and motors.

The latest Tsreader shows the raw command, either Usals or diseqc1.2 it sends. Is that what you are asking, something to monitor the actual command being sent? That would be for motor only, I don't know how you could get the switch commands.

 

[B.J.]

After posting the above, I decided to go back and look at some old posts I made on this topic over at the Sadoun site, ie:

http://www.sadoun.net/forums/installation-support/6148-usals-accuracy.html?highlight=usals#post34686


Now, I see that I was originally confused because I WAS seeing some differences in my calculations vs what the receivers were saying, however MY initial calculations were simplified by not using the more correct (but more complicated calculation) "MODIFIED DECLINATION". I then re-did my calculations considering not just declination, but the correct modified declination, and then the results matched to within roundoff error.

The above thread also includes a link to what I referred to as the "official" calculation (because I think it was done by the company that made USALS equipment), however that link no longer seems to work. However I found the
origianl at

http://www.moteck.com/product.asp?idproduct=91

 

[B.J.]

The latest Tsreader shows the raw command, either Usals or diseqc1.2 it sends. Is that what you are asking, something to monitor the actual command being sent? That would be for motor only, I don't know how you could get the switch commands.

No, that wasn't what I meant. I was wanting a piece of hardware that could be put in line between the receiver and the switches/motor, that would read what the receiver was sending on a computer.

The actual signals are a modulation of a 22khz tone, and I was hoping that I could use an old diseqC switch, thinking that it must have a detector that converts the modulated 22khz into a DC voltage, like 0/5V signals that I could maybe read off a parallel port or serial port pin with a computer. I ran across someone who had built such a diseqC reader from scratch, and wrote software to interpret it, but I was hoping to do it easier via an old switch. I think I took apart an old switch that had stopped working, hoping that it would still at least detect the signals, but I couldn't find any point in the circuit that seemed to have the signal I was looking for.

I think what started me wanting such a thing was that I have a sat meter that has a little light that indicates when it's seeing 22khz, and I've noticed that when I'm outside trying to align a dish to a sat, that I generally see that light blinking whenever I move the dish OFF the satellite. Ie if I'm on the sat, the receiver gets a lock, and is happy, but if I'm OFF the sat, the receiver loses lock, and at least some of the receivers I have will apparently think that it might be because the diseqC switch switched position, so it sends out more diseqC commands trying to get a lock. One of my receiver even goes to the lengths of if it doesn't find the lock on the switch position stored for that sat, it acutally tries other switch positions. This had me REALLY confused once, because I had 3 different dishes all aimed at the same sat all going through the same diseqC switch, and when tuning in one of the 3 dishes, all of a sudden, I lost all voltage to the lnbf. I was confused, so I went inside, and was surprised that the channel I was tuning on was playing fine on my TV, even though the lnbf didn't have voltage! Turned out that the receiver had ON IT'S OWN decided to try different diseqC switch ports looking for the channel, and switched to my other sat dish. I later repeated this strange behavior a couple more times. At that time I decided that it would be really interesting to monitor just what the receiver was actually sending out. Ie there was still a chance that it was actually sending out the proper port, but eventually sent out a garbled signal that resulted in the switch going to the wrong port or something. So I wanted to see if it was a real command.

Mainly just curious about how these things work.

EDIT: BTW, last I heard, I thought that TSREADER's implimentation of USALS didn't work. At least the version I have calculates some angles that are WAY off.

 

[pendragon]

After posting the above, I decided to go back and look at some old posts I made on this topic over at the Sadoun site, ie:

? USALS accuracy ? - Sadoun Tech Forums


Now, I see that I was originally confused because I WAS seeing some differences in my calculations vs what the receivers were saying, however MY initial calculations were simplified by not using the more correct (but more complicated calculation) "MODIFIED DECLINATION". I then re-did my calculations considering not just declination, but the correct modified declination, and then the results matched to within roundoff error.

The above thread also includes a link to what I referred to as the "official" calculation (because I think it was done by the company that made USALS equipment), however that link no longer seems to work. However I found the
origianl at

MOTORIZE YOUR WORLD = = PRODUCTS = =

I compiled a quick table comparing a number of the methods I found on the web with the calculations the Pansat 9200HD does and my own efforts. My location is 39.6 N, 104.9 W. The orbital locations I chose were 30 (only a few degrees above the horizon here), 40.5, 58, 71, 89 and 101. For fairness my calculations are for a spherical earth model not considering altitude.

The attachment contains a table that lists for each orbital position what each method calculated the motor angle to be. The resolution shown for each is what was reported. The columns are:

9200HD - what my Pansat 9200HD reports on its menus
moteck.com - BJ's link above
Direct Angle - angle from inner product of vectors to sat and true south sat
Polar Angle - my calculations incorporating declination and all rotations
ftdata.com - BJ's online calculator
satsig.net - online calculator
satlex.de - online calculator

The agreement of the 9200HD, moteck.com and the direct angle is perfect to round-off errors, with the exception of the lowest orbital position for the 9200HD. There appears to be a consistent error in the 9200HD for positions more than about 65 degrees from true south. As you can see the USALS-based calculations start diverging from mine and become significant for orbital positions more than say 30 degrees from true south. My calculations are in the ballpark of satsig.net and satlex.de, but there are minor differences. This could be partly caused by different choices of declination offset angles, but I have not investigated this conjecture. BJ's calculator varies the most from the others. My apologies if this calculator is not the one you were referring to.

 

[pendragon]

What I never did attempt to do (didn't have any way to do it at the time) was to determine whether after calculating the angle properly, did the receivers actually send out the proper diseqC-1.2 commands, and see whether the motor actually goes to the proper angle. It might be an interesting experiment to do now that those digital levels are available, like discussed in another thread.

This is fairly easy to do with a digital scope. The modulations for '0' and '1' can be clearly seen and decoded. Actually I've often used an old analog storage scope because I prefer its triggers and delay. I'm simply more used to it after all the years. Anyway I've used this technique to examine a number of PC apps that send out incorrect DiSEqC switch commands (another pet peeve of mine). I did look at a couple of the Pansat motor commands - they were the same as shown in the menu given the conversion of the DiSEqC angle steps. The Pansat shows decimal degrees to one place after the decimal point, while DiSEqC employs increments of 1/16 degree.

 

[pendragon]

EDIT: BTW, last I heard, I thought that TSREADER's implimentation of USALS didn't work. At least the version I have calculates some angles that are WAY off.

Yes! While I haven't tried tsreader, every Windows and Linux program I looked at calculated seriously wrong USALS values.

 

[starman345]

EDIT: BTW, last I heard, I thought that TSREADER's implimentation of USALS didn't work. At least the version I have calculates some angles that are WAY off.

Interesting, I can't go back and check because I sold my Skywalker device, my Twinhan 1020a won't respond to Usals commands in Tsreader, there may be a driver that allows it but I haven't come across it.
Using the Skywalker, I never noticed problems with Usals accuracy, I did figure out that my latitude needs to be set to south rather than north before it would work sensibly. I told Rod about this but he didn't change it in the software yet.

 

[Anole]

I am out of time and had to skim the last couple of posts, so pardon if this is already posted:

To read the 22khz bursts with a 'scope, I'd think it's converted to a DC level and fed to a pin on the little IC (microcontroller) in a switch.
I can't imagine the micro has the horsepower to actually read the noise, looking for 22khz itself.

Of course, I could be wrong.
Just probe the pins of the micro during command transmission, and see if there are clean demodulated pulse streams.

 

[pendragon]

I like numbers, but a graph of the calculated table is far more visual. Please find one attached.

 

[B.J.]

I compiled a quick table comparing a number of the methods I found on the web with the calculations the Pansat 9200HD does and my own efforts. My location is 39.6 N, 104.9 W. The orbital locations I chose were 30 (only a few degrees above the horizon here), 40.5, 58, 71, 89 and 101. For fairness my calculations are for a spherical earth model not considering altitude.

The attachment contains a table that lists for each orbital position what each method calculated the motor angle to be. The resolution shown for each is what was reported. The columns are:

9200HD - what my Pansat 9200HD reports on its menus
moteck.com - BJ's link above
Direct Angle - angle from inner product of vectors to sat and true south sat
Polar Angle - my calculations incorporating declination and all rotations
ftdata.com - BJ's online calculator
satsig.net - online calculator
satlex.de - online calculator

The agreement of the 9200HD, moteck.com and the direct angle is perfect to round-off errors, with the exception of the lowest orbital position for the 9200HD. There appears to be a consistent error in the 9200HD for positions more than about 65 degrees from true south. As you can see the USALS-based calculations start diverging from mine and become significant for orbital positions more than say 30 degrees from true south. My calculations are in the ballpark of satsig.net and satlex.de, but there are minor differences. This could be partly caused by different choices of declination offset angles, but I have not investigated this conjecture. BJ's calculator varies the most from the others. My apologies if this calculator is not the one you were referring to.

No, that's the one I meant. (I actually have 3 different calculators, but I checked, and all give the same result to within 0.1 deg. Your comment above about things diverging around 65 degrees is driving me crazy because there is something sticking in my memory about that angle being special, and I just can't remember what it is. It also caught my attention that your angle is 0.6 degrees different from mine at the 40.5 deg sat, as in general 0.6 is the difference between the declination of a south sat and the "modified" declination, so I'm starting to wonder if the difference between your calculation and mine is based on the declinations chosen. That 0.6 was probably just a coincidence, but I still think it's possible that the use or non-use of modified declination could be causing the differences.

Can I assume that you're rotation axis was parallel to the earth's polar axis?
...... ( Mine was tilted to the south by nearly 0.7 deg )
Did you use a declination of something like 6.2 deg??
.......( I used something close to 5.54)

The reason I think the above is important, is that if you have your axis parallel to the earth's axis and use the declination of a south sat, your dish can never aim at a sat near the horizon, like your 30 deg sat. The closest you'll get is about 0.7 deg from the sat, and it seems like there could be some variability in results depending upon whether it finds the closest point or where it matches horizontally or vertically (not sure if that makes sense).

My calculators may well have some mistakes in them. I didn't test them out at extreme angles like you did, but they did seem to be within a couple tenths on every angle I checked of agreeing with both the Motec and my Fortec receiver. You've got me interested though, and I'm curious what my Fortec will say on those extreme angles. It's not hooked up now, so I can play with the USALS without messing up my viewing.

Anyway, thanks. This is an interesting discussion. I just wish I could remember how I derived my extremely cumbersome brute force equation. I think it came from an excel spreadsheet, where I did about 6 separate calculations, then merged it all into one humongous equation. I still have that spreadsheet, so I'll have to study it a bit, and look for errors. I'm sure I'll find some. And I'm sure that I did use some approximations, one in particular being the angle that I selected for being the "extreme", ie the declination used for interpolation between that and the south declination. I can see that if my extreme wasn't out far enough that I would diverge a bit after passing that extreme (if that makes sense).

Anyway, let me plug some numbers into my old Fortec, and see how IT compares.

 

[B.J.]

EDIT: BTW, last I heard, I thought that TSREADER's implimentation of USALS didn't work. At least the version I have calculates some angles that are WAY off.

Interesting, I can't go back and check because I sold my Skywalker device, my Twinhan 1020a won't respond to Usals commands in Tsreader, there may be a driver that allows it but I haven't come across it.
Using the Skywalker, I never noticed problems with Usals accuracy, I did figure out that my latitude needs to be set to south rather than north before it would work sensibly. I told Rod about this but he didn't change it in the software yet.

OK.... maybe that south latitude thing was the "error" I had read about. I just tried changing north to south in my version of TSREADER, and now it gives correct angles. I don't know if his raw data is correct or not.
I don't think I've ever used USALS with TSREADER. I almost always use it slaved, and when I have used it direct, I've always used diseqC-1.2 .

But thanks.... good to know about that south latitude thing.

 

[B.J.]

I am out of time and had to skim the last couple of posts, so pardon if this is already posted:

To read the 22khz bursts with a 'scope, I'd think it's converted to a DC level and fed to a pin on the little IC (microcontroller) in a switch.
I can't imagine the micro has the horsepower to actually read the noise, looking for 22khz itself.

Of course, I could be wrong.
Just probe the pins of the micro during command transmission, and see if there are clean demodulated pulse streams.

Yeah, that's what I tried to do. I think the thing I did wrong was use a switch that didn't work anymore. I was hoping that my broken switch would still have the demodulated stream, but I didn't find one. I guess I have enough of those switches now that I can spare a good one, and try again.

 

[pendragon]

I am out of time and had to skim the last couple of posts, so pardon if this is already posted:

To read the 22khz bursts with a 'scope, I'd think it's converted to a DC level and fed to a pin on the little IC (microcontroller) in a switch.
I can't imagine the micro has the horsepower to actually read the noise, looking for 22khz itself.

Of course, I could be wrong.
Just probe the pins of the micro during command transmission, and see if there are clean demodulated pulse streams.

I just used a tee in the coax out of the receiver. The scope is unterminated off the tee and I normally use AC coupling to remove the polarity selection voltage. You then use a trigger to pick off the DisEqC commands as they come out. Motor commands follow any switch commands, so I dial in a delay until they appear. The 22 KHz is gated in time: 1 ms on/0.5 ms off is '0' and 0.5 ms on/1.0 ms off is '1'. With the sweep spread over a DisEqC command, each bit can be read off easily.

 

[AcWxRadar]

I took some time off from redeploying my dishes to look over a nagging problem I had called USALS. Last year I tossed a 1.2 m GEOSATpro on the roof with a PowerTech DG-380 motor. It was easy to tweak and I soon had it tracking the Clarke belt over the motor's range.

My true south is about 105 degrees, allowing me to get most of the Ku action not too far off-center. From the beginning I noticed when using my Pansat 9200HD, the farther I drove the dish from center in either direction, the greater the in-track error in positioning. In fact both east and west errors were about the same for similar offsets, with the Pansat always driving the dish not quite far enough. I realized this might simply be accumulating mechanical errors in the motor, but the consistency was concerning. In reality this wasn't causing any real trouble, because orbital locations 45 degrees from my true south were experiencing only about a 0.2 degree error. This could be easily compensated by lying to the Pansat about the orbital location. However the error quickly got larger for the lower elevation birds.

We had high winds a few weeks ago that blew the 1.2 m mount slightly off. When resetting the adjustments I again verified the satellites far off-center only had in-track errors (ie. bumping the dish up or down only reduced the signal level). I got curious what was going on. As far as I can tell, the USALS algorithms have not been openly published. There were a handful of website calculators that made some or all of the calculations, but none agreed for significant offset angles, and none agreed with my Pansat's calculated motor angles. I also looked through a number of open-source codes for controlling USALS motors, and that only increased the cacophony.

I surmised the discrepancies might have to do with different declination offset angles, and further reading found many approaches to calculating the 'optimal' declination offset angle. Of course none were the same. As the declination offset is only an approximate correction to track the arc, it appeared the differences probably resulted from different optimization criteria. For example, one approximation might minimize the tracking error for angles close to true south, at the expense of angles close to the horizon. Another might do the opposite.

Rather than re-derive each approach and figure out where they made different assumptions, I thought this was prime territory for a little linear algebra. For fun I decided to employ a non-spherical earth model and consider my altitude (this turned out to be useless for Denver because its altitude essentially offsets the earth's polar flattening). Fairly quickly I found the Pansat calculated motor angles were precisely in agreement with a zero declination offset angle, other than when it tried to calculate orbital positions more than about 65 degrees from true south and got completely nonsensical answers.

I then set up my calculations to optimize cross-track performance by varying the declination offset angle. This was all fun and good, but not terribly practical because there were many excellent fits using different optimization criteria with maximum cross-track errors of a few-thousandths of a degree. Satellites typically are only kept positioned in a box much bigger than that, even considering the folly of thinking one could adjust a dish to that accuracy.

Nevertheless to put theory into practice I hauled up the theodolite and tweaked everything until I got bored. One of the open-source programs I had come across is called xdipo and with one of my USB receivers was an excellent starting point for a better USALS controller than the Pansat. xdipo's calculations for motor offset angles are way off, but that can be fixed. I modified a number of xdipo's controls and tweaked its display of the signal levels and quality to make it into a more precise tuning instrument. It's rather convenient because the USB receiver is inside the house run by a Linux machine running xdipo remotely over wireless to display on my laptop on the roof. In some ways this turned out to be more precise than using a spectrum analyzer, and a lot faster. It didn't take long to confirm my direct calculations of the motor angle were dead-on for the given declination angle, while the Pansat was not. I was also able to calibrate out an error in the DG-380's view of what was a zero offset angle by subtracting this out in xdipo. I haven't taken the DG-380 apart, but I would like to remove this mechanical error.

I'm confident the Pansat is making the simplifying assumption that there is no declination offset angle, causing the positioning error to increase with angle. One could partially compensate for this mechanically through an intentional misalignment, at the expense of cross-track error. That wouldn't make a lot of sense.

I can't change the Pansat USALS calculations, but I could write code for Linux to build an accurate satellite positioning system. I've put that in my project to-do hopper because the Pansat has other limitations with positioning that I am no longer willing to tolerate. Whether these same approximations/errors exist in other receivers I cannot say, but hopefully some of what I've come across may explain oddities others have observed.

Pendragon,

Excellent research!

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?

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.

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?

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.

If I am correct here, I could possibly explain the inaccuracy of the motor positioning. If I am wrong, then I do have difficulty explaining the errors that you are detecting.

It does not appear to me that you are very far offset when you command the motor to drive the dish to other satellites. You are not witnessing an extreme deviation in accuracy, but you are noticing it regardless, therefore a discrepancy does exist.

I read your original post and maybe a couple follow-up replies, but I stopped at that point. I do this most of the time so that I can offer a gut reaction to the original post without being swayed by other information. I will read the rest later and maybe refine my theories.

I find your subject very interesting and I would like to investigate it further. It is very interesting to me as I recently experimented with something similar, the Sonic View 360 Premier that I mentioned above. That was an extreme example, in my opinion.

ACWxRadar

 

[pendragon]

No, that's the one I meant. (I actually have 3 different calculators, but I checked, and all give the same result to within 0.1 deg. Your comment above about things diverging around 65 degrees is driving me crazy because there is something sticking in my memory about that angle being special, and I just can't remember what it is. It also caught my attention that your angle is 0.6 degrees different from mine at the 40.5 deg sat, as in general 0.6 is the difference between the declination of a south sat and the "modified" declination, so I'm starting to wonder if the difference between your calculation and mine is based on the declinations chosen. That 0.6 was probably just a coincidence, but I still think it's possible that the use or non-use of modified declination could be causing the differences.

Can I assume that you're rotation axis was parallel to the earth's polar axis?
...... ( Mine was tilted to the south by nearly 0.7 deg )
Did you use a declination of something like 6.2 deg??
.......( I used something close to 5.54)

The reason I think the above is important, is that if you have your axis parallel to the earth's axis and use the declination of a south sat, your dish can never aim at a sat near the horizon, like your 30 deg sat. The closest you'll get is about 0.7 deg from the sat, and it seems like there could be some variability in results depending upon whether it finds the closest point or where it matches horizontally or vertically (not sure if that makes sense).

My calculators may well have some mistakes in them. I didn't test them out at extreme angles like you did, but they did seem to be within a couple tenths on every angle I checked of agreeing with both the Motec and my Fortec receiver. You've got me interested though, and I'm curious what my Fortec will say on those extreme angles. It's not hooked up now, so I can play with the USALS without messing up my viewing.

Anyway, thanks. This is an interesting discussion. I just wish I could remember how I derived my extremely cumbersome brute force equation. I think it came from an excel spreadsheet, where I did about 6 separate calculations, then merged it all into one humongous equation. I still have that spreadsheet, so I'll have to study it a bit, and look for errors. I'm sure I'll find some. And I'm sure that I did use some approximations, one in particular being the angle that I selected for being the "extreme", ie the declination used for interpolation between that and the south declination. I can see that if my extreme wasn't out far enough that I would diverge a bit after passing that extreme (if that makes sense).

Anyway, let me plug some numbers into my old Fortec, and see how IT compares.

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. In my case, the fit has a zero cross-track error at true south and reaches a maximum deviation of -0.004 degrees for an orbital position offset of 35 degrees, and crosses the track again at about a 65 degree orbital position offset. At a 75 degree orbital offset, the cross-track error is still only 0.007 degrees. I ran a quick optimization to obtain these angles, and they gave what looked to be the best practical fit. I could have reduced the errors for nominal offsets at the expense at larger offsets or vice versa. In fact the best fit would have the dish shooting slightly on the high side at true south, but that is pretty much academic. For most purposes calculating the declination from one of the multitude of possibilities is more direct than running an optimization, and there are far larger error sources in dish pointing than those differences.

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.