Possible Errors w/Older H-H Motors

[Fizbi]

I was just re-reading the manual for my ancient DiSEqC 1.2 H-H Motor.

The motor manual says I can store 60 bird locations.
The MicroHD says I can store up to 99 birds in memory.

How does the data work between the motor and receiver?
If I save a bird location at 99 in the receiver, how does the motor react?

Maybe this explains why a couple of sat locations keep getting confused.
Thoughts anyone?

 

[updatelee]

In theory the diseqc protocol supports 255 saved positions. Doesnt mean the motor actually does though, the diseqc protocol states "The maximum number of positions to be stored is not
defined, but it should not be less than 8. 30 or 40 satellites may be more typical, particularly if the motor unit has pre-stored satellite position data in its ROM (for automatic installation)."

If you attempt to save a higher position then supported by the motor in theory it should just ignore it.

UDL

 

[Fizbi]

UDL, Not quite right. From what I read of the diseqc specifications, it is the range of 256 degrees that can be stored, not 256 positions. I have reviewed all the specifications and application notes for diseqc 1.2 and I find interesting comments and papers relating to positioning quality from receiver to receiver and motor to motor. The bottom line here is - How good is the engineering in my new receiver and how good is the electronics and software in my old motor? My SG2100 is an older model and can only handle "60" memorized bird locations.
Looking at the newer SG2100s, I see they can go up to "99" memorized bird locations. My question is how good is the programming in my motor? I don't really know and I think only the engineers who designed the "60" memory version really know. If I decide to save a bird at location "99" (really only a software marker for a NVM location), then how will my motor read this? If my motor software is only expecting a range of 00 to 59, then it could possibly convolute a value of 99 into say something like 00, thus rolling over the data. After all the information I have read, I then conclude that my best bet is to not save any bird locations above label "59".

So, I was having problems with my motor not driving accurately to a couple of birds. I was only saving three or four above "59" and decided to set them back as a precaution.
The other thing I found was one site setup was accidently set to USALS instead of diseqc. After making those adjustments, my motor is behaving better. It seems USALS was overriding my diseqc settings. I'm not sure how the MicroHD priortizes a satellite setting, I just know when I made these changes, the motor started working better.

I may update my motor in the future and this may solve some drift problems I've had over the years where I need to nudge a couple of memory locations every so often, maybe due to some bad memory in the motor.

 

[updatelee]

http://www.eutelsat.com/satellites/pdf/Diseqc/associated docs/position_app_note_v1.pdf

page 6 & 9

diseqc cmd 0x6A Store nn Store Satellite Position & Enable Limits

it only takes one argument, the position number, the motor knows at all times its current degree's. I think your thinking of USALS, you send the degree's with USALS. not stored positions.

nn is a hex value of 0x00 - 0xFF, but 0x00 is a reference position.

"The parameter byte ‘00’ (i.e. Satellite Position 0) is reserved as a “reference position” which is not valid for storing satellite position data. However, some applications may require a specific command to Enable (Soft) Limits, so all Masters (i.e. Tuner-receiver/IRDs) should be capable of transmitting command ‘6A’ with a data byte ‘00’, either specifically as an “Enable Limits” user-command, or by allowing “Position 0” to be selected for the “Store Satellite Position” installation command."

UDL

 

[Fizbi]

More fun reading... http://www.eutelsat.com/satellites/4_5_5.html

 

[updatelee]

yup that would be where I got the link I posted

UDL

 

[Fizbi]

....

nn is a hex value of 0x00 - 0xFF, but 0x00 is a reference position....
UDL

The MicroHD wants a decimal value up to "99".

 

[updatelee]

hex - decimal, same thing, all integers, just different base.

USALS takes degree's as the input, maybe thats what your thinking of. accurate to a 1/16th of a degree according to specs, but many motors its a 1/10th of a degree or less.

UDL

 

[Fizbi]

USALS takes degree's as the input, maybe thats what your thinking of. accurate to a 1/16th of a degree according to specs, but many motors its a 1/10th of a degree or less.

You bring up something I hadn't considered...the accuracy of my positioning system. When I first bought my dish, years ago, I never even considered position resolution. All I cared about was buying a cheap system that works. Looking at my small dish of a mere 80cm, I believe that may be half my problem when coupled to a sloppy motor. Checking the specs for other motors, that's a big difference from 0.10 to 0.30 in angle adjustments.

I bet I'll see a big improvement when I upgrade my motor to 0.10 angle adjustments and my dish to 120cm.

 

[updatelee]

repeatability is the big problem, and not easy to solve

pick a satellite on an the extreme edge of the arc, near the horizon. Now tell the motor to goto that satellite on the down stroke, now tell it to goto the same satellite on the upstroke.

ie

for me I could use 72w as my test.

goto 87w then tell it to goto 72w
goto 61.5w then tell it to goto 72w

are your signal quality levels identical? a good motor will, most wont.

UDL

 

[Tron]

Add to that the factor of slack (backlash), which would make a difference even if there was the slightest amount of it. Loose backlash would put the motor at opposite ends of the "backlash play" depending on whether it was on the upstroke or downstroke.