Social Feed

Just a couple comments:

If I drive the dish east/west and move it around with the DiSEqC commands until I acheive the best possible signal quality from a particular TP on Hispasat, I need to SAVE and RECALCULATE that NEW position somehow if it has already been assigned previously.

Therefore, I am thinking that I need to select the option "RESETTING" and press OK (when I do this, it removes the (P1) notation from the satellite name). Originally, Hispasat was displayed as 30.0W (P1) Hispasat 1 because I originally used DiSEqC 1.2 to locate and SAVE it.

After relocating the sat and selecting and OK'ing the RESETTING option, the indication reverts to "30.0W Hispasat 1".

Click to expand...

I had previously assumed that the "resetting" just sent a "resync" command. However your comment above that i removed the P1 designation tells me that that isn't the case, ie that all resetting must do is to remove the diseqC-1.2 sat number (1 in this case) from that sat's parameters. In a previous message in some thread, I had complained that there was apparently no way to do this, but I guess that there is.
However related to what you're trying to do above, I don't see any reason why you'd want to use the resetting command. That would only be used if you wanted to change what sat number you were using, or, if you no longer intended to used diseqC-1.2 for that sat, like if you were only viewing that sat slaved to another receiver or something. If you just wanted to update the sat's position, generally, you'd just use the "SAVE" command, and it will send the new position to the motor. No need to delete that number, and save again. In fact doing that, would probably end up giving you a new sat number, unless you assigned one manually. On my other receivers, I routinely just save over the previous location.
This, however is dissappointing, as apparently now it seems that there is no resync command, so I guess that if you want to do a resync, you need to connect another receiver that has that command, however that could be complicated since you'd have to make sure that you were on the same sat number with the new receiver I think.

If I do not access the "RESETTING" option, and try to SAVE a new position for Hispasat via DiSEqC 1.2, then I end up with 30.0W (P2) Hispasat. Now I have TWO positions to select from to find the one same satellite.

Do you guys follow me? Try repeating my steps and observe what it does.

Click to expand...

NO. Mine does NOT behave like yours behaves. What you describe shouldn't happen. All the other receivers I've used will continue to use the same already saved sat number, unless you reassign it. I'm running 0.9.4585 firmware BTW.

Here's what I've found using a SG6000 motor:

'Resetting' shuffles DiSEqC locations. You will have to relocate some sats.

.......

All of that being said, DiSEqC settings do not shuffle with my Gbox. Only the sg6000.

Click to expand...

Now this is strange, although I'm not sure I understand what you're saying relative to shuffling the locations. Are you saying that the sat position numbers get changed??? Clearly, from what Radar said above (and I confirmed) about the sat number going away after resetting, then coming back if you save, it isn't shuffling the position numbers. Also these position numbers are ONLY on the receiver, so the resetting command shouldn't be doing ANYTHING to the motor, and it shouldn't matter WHAT motor you were using, or whether you were using a motor or Gbox, etc. The only way it would be affecting the MOTOR, and/or shuffling the locations is if this is in fact a RESYNC command, like I originally thought. A RESYNC command is SUPPOSED to change ALL the sat positions, by the same amount. Say you had positions saved, went to a sat, but found that you were 5 clicks off. If you then send a resync command, it should change the positions of ALL the sats by 5 clicks.

So I am now starting to wonder if perhaps some firmware versions use RESETTING as a RESYNC command, and other firmware versions use RESETTING only to remove your previously saved position number.

Anyway, these two posts don't seem to jive to me. I would check this out, except that I don't use my Azbox with a motor, since it is dedicated slaved to my C-band dish. However next time I hook the Az up to my Ku dish, I'll play with it a bit.

B.J. said:

Just a couple comments:



Now this is strange, although I'm not sure I understand what you're saying relative to shuffling the locations. Are you saying that the sat position numbers get changed???

Click to expand...

No the numbers don't change. I'm saying that the locate points are lost. I've never quite found out exactly what happens. It's seems, for instance, that if you use 'resetting' while on (P4), (P5) shuffles into that position and all follow. It's a mess that requires me to reassign all locate points. Note: Only happens with DiSEqC on the sg6000, not the Gbox.

putney said:

No the numbers don't change. I'm saying that the locate points are lost. I've never quite found out exactly what happens. It's seems, for instance, that if you use 'resetting' while on (P4), (P5) shuffles into that position and all follow. It's a mess that requires me to reassign all locate points. Note: Only happens with DiSEqC on the sg6000, not the Gbox.

Click to expand...

I've seen one receiver, the Fortec Mercury II, which, if you delete a sat, it will shift all the position numbers, actually not in numerical order, but pretty much just scrambles them depending upon which sat was saved first, giving position numbers to sats that have never been given a diseqC-1.2 position, etc. It's a real mess with that receiver. But with this Azbox, at least with the firmware I'm using, the position numbers don't change, which means that I don't see ANY way that the positions would get scrambled, because all those positions are stored in the motor (or GBOX), and there is no diseqC-1.2 command to scramble or rearrange positions. There IS a resync command, but that doesn't rearrange positions, it will just shift ALL the positions by some angle, and this is what I initially thought that this resetting command did, but it doesn't seem like it does that, but maybe it does.
I think that today, I'll hook up my channel master meter to the Azbox and try the resetting command. THe Channel Master meter has a little light that lights up if any 22khz signal is detected. This should determine whether any diseqC-1.2 signal is actually being sent to the motor, or if the resetting command only deletes the position number. It is possible that it does BOTH, and the operation is highly dependent upon the order of the commands given. Ie perhaps if somehow, you give a resetting command when the Azbox thinks that your current sat is some other sat, that it will actually send a resync command, which WILL shift all the sats by multiples of the 2 deg sat separation and appear to scramble the positions. Perhaps the Azbox is deleting the position number, making the Azbox think that the last sat it went to was some other sat, then maybe it's sending a resync command making the motor shift the positions of all the sats to some position which is off by multiples of 2 deg separation??? I'm just guessing here, but there is clearly something wrong with the Azbox if all of the above observations are true, and the first thing to discover is whether it's actually sending diseqC commands when the resetting command is given.

Well, I played with this for a bit. As I mentioned, I'm slaved, so none of my sats actually control anything, but I had previously set up 3 Atlantic sats as diseqC-1.2 just for an experiment, even though it doesn't do anything except annoy me when the Azbox occasionally pops up a "moving to" sign, even though I know it isn't moving anywhere.

Anyway, I hooked up my meter, and I went to one of these sats (actually I didn't, but the Azbox thought I did). The 22khz light blinked once, apparently as it sent the "goto position 1" signal. Once there (not), if I tried changing transponders, each time I did that, it would also blink, again apparently sending a goto P1 signal.
Then, I went into the diseqC-1.2 menu, went to "RESETTING", and hit "OK" to run that command. AGAIN IT BLINKED! And, as mentioned before, the (P1) designation went away, and two other sats I artificially had set up as (P2) and (P3) kept those designations. Clearly, there is no reason why it should be sending any diseqC-1.2 signal if it is just removing the position number from the receiver's parameters. The only reason I can think that it might be sending that diseqC signal is if it's sending a "RESYNC" signal, like I had originally thought. The problem is though, what is it resyncing to??? Ie I have been assuming all along that a RESYNC command is the same as is used on analog receivers, where you go to a sat, then move a bit to peak the sat, then do a resync, and the receiver (since with analog receivers it's the receiver that keeps the positions, not the motor) is supposed to figure out how much it has moved from it's stored position, then adjust ALL the sats relative to that position.
However, I started to think that maybe this isn't what the resync command actually does, so I looked up the definition in the Eutelsat spec. It says:

"3.9. "(Re-) Calculate Satellite Positions"
Command byte '6F' with various data parameters can give the user/installer
various types of "short-cut" to setting up or aligning the system. The basic
command has the (first) parameter byte set to zero, i.e. command '6F 00'
which can initiate any appropriate function, defined by the manufacturer of
the Positioner Motor Unit. In general, the user/installer will manually drive
the antenna to receive a strong signal from a suitable satellite and then the
command '6F 00 {00 00}' will cause the embedded software in the Positioner
Motor Unit to calculate the (approximate) positions of all the other satellites
in its memory (ROM) relative to the known position. The user/installer may
then need to optimise each position in turn with reference to the received
signal strength.
It is preferred that Tuner-receiver/IRDs with Menu systems should support 3
(signed) binary parameter bytes for the "Calculate Satellite Positions"
command. Again, their exact function will be defined in the documentation
for the Positioner Motor Unit, but they typically may be used for, "Satellite
Number", "X-Value" (e.g. Site Longitude in degrees) and "Y-Value" (e.g.
Site Latitude in degrees). Thus if the user/installer can receive any
(identifiable) satellite signal, then the command can contain sufficient data to
calculate the positions of all other satellites stored in the Positioner Motor
Unit's ROM.


Strictly, the "X-Value" data byte cannot define a unique Longitude in the
World because its range is only 256 degrees. However, a suitable range can
be inferred from the range of satellites for which data is stored (i.e. those
expected to be above the horizon in the relevant continental region). In
Europe and Africa the "X-Value" can be signed binary (positive to the East)
so that it defines longitudes from 128° West to 127° East. In the Middle East
and Asia the "X-Value" can be unsigned binary so that it defines longitudes
from 0° to 255° East (i.e. to 105° West). In the Americas the "X-Value"
generally would be unsigned binary to the West, so that it defines longitudes
from 0° to 255° West (i.e. to 105° East). "

Click to expand...

Reading the above, I am no longer confident that I understand at all what the resync command is doing, and in fact it appears that the command may do different things to different motors. It sounds like in some cases, a resync might be used with respect to something else that has confused me over the years, ie why some motors, such as the early versions of SG2100, have pre-defined sat locations, all of which were European sats. It sounds like the recalculate command would allow you to enter the position of one sat, and the motor would then do some kind of recalculation to reposition ALL pre-defined sats. This is sort of like the resync command used by analog receivers, except that the above document mentions the command using LAT/LON data for the USER as part of the calculation, so apparently the recalculate command is NOT intended to be the same as the simple RESYNC command of analog receivers, and this would explain why the GBOX doesn't respond to it, since it would be completely meaningless to an actuator system if a calculation involving LAT/LON were requirred.

But right now, I have NO IDEA of just what typical diseqC-1.2 motors are actually doing when they receive a recalculate command, particularly since most receivers don't use user LAT/LON parameters if you're using diseqC-1.2. It COULD be that they are just doing the simple angle shift that analog receivers do, or it could be assuming the user is on the equator or something, I don't know. I think the last few receivers I've purchased don't even have a recalculate command, only the early receivers that were assuming motors with the pre-defined European sats had this command. Anyway, I think it could be risky to use the recalculate command, not knowing what it might do with any particular motor.

I did notice also when reading the SPEC, that most diseqC-1.2 commands are 3 bytes, plus data bytes, ie a Framing byte, which designates whether a reply is required, etc, then an address byte, which designates the type receiver, such as switch or positioner, and then a command byte, which designates the command, 6F in this case. Following this, are any requirred data bytes.
The command description indicates that the recalculate command can have either 4 or 6 bytes. Perhaps the 4 byte recalculate is the simple analog style resync, ie the single data byte just containing the sat position number to use for the offset against, but the 6 byte command might be the more complicated command using LAT/LON info contained in the 2 extra bytes? I'm just guessing here. But we're also guessing with respect to whether the Azbox is sending a 4 byte command or a 6 byte command. Ie it may be that if you've set up some sats as USALS, entering LAT/LON, that maybe it sends out the lat lon info, and who knows what a motor might do with THAT info.
But in any event, whatever is being done, it is clear to me, that the Azbox isn't doing it right, and this command should be avoided.


One other thing I observed with my meter, and that is, if you do the RESETTING command first, and THEN do the GOTO POSITION command, no diseqC signals are sent at all, ie nothing seems to be done. This makes sense since there is no longer any position to go to.

B.J. said:

Just a couple comments:

I had previously assumed that the "resetting" just sent a "resync" command. However your comment above that i removed the P1 designation tells me that that isn't the case, ie that all resetting must do is to remove the diseqC-1.2 sat number (1 in this case) from that sat's parameters. In a previous message in some thread, I had complained that there was apparently no way to do this, but I guess that there is...........

..............So I am now starting to wonder if perhaps some firmware versions use RESETTING as a RESYNC command, and other firmware versions use RESETTING only to remove your previously saved position number.

Click to expand...

B.J.

This a comment and response to one on your previous posts, but not your most recent post.

I don't know if I can explain it, as I truly don't know what the programmer(s) of the AZBox intended. I am just guessing on a lot of items here, so don't take my words as being anything concrete.

However, when you speak of the "resync" command and I speak of the "resetting" command, I believe that they are two different things.

The "resetting" command that I had referred to previously, I believe, simply reschedules the satellite position. If it had been manually assigned previously via DiSEqC 1.2 methods, it would simply "erase" this assignment and prepare it to be reassigned with a new location.

The "resync" command that you referred to is something that I am not aware of in the menus of the AZBox. I mean to say that at least the AZBox menu selections do not identify it with that identical terminology. When you state "resync" I think of something quite different than simply just erasing one satellite position and preparing it for a new location.

Resetting? Now I understand the process of "resetting" as deleting the previous location of ONE satellite and then restoring it (saving a new location for it or rewriting the old). This makes sense to me, although I am unsure exactly what they are doing in the software to accomplish this. Therefore, I am vague with my overall understanding.

When you state "resync", I think of something slightly different. I think of retaining the same recorded positions, but that the motor returns to the ZERO position and then redefines and relocates the satellite position from there, from that reference point.

Resyncing seems to instill in my mind a more elaborate calibration method. A method which ensures that the receiver and motor have re-identified the starting point and recalculated all the sat positions from there. But, I also think that much of this is all a matter of semantics.

I find the whole strategy easy to comprehend with my Coolsat 5000, but not so well with my AZBox Premium. The AZBox has inherent problems with their software and programming and they confuse me much more.

RADAR

AcWxRadar said:

B.J.

This a comment and response to one on your previous posts, but not your most recent post.

I don't know if I can explain it, as I truly don't know what the programmer(s) of the AZBox intended. I am just guessing on a lot of items here, so don't take my words as being anything concrete.

However, when you speak of the "resync" command and I speak of the "resetting" command, I believe that they are two different things.

Click to expand...

Well, I think that we're all just guessing here relative to what the Azbox command does, but there are really 3 terms involved here, not just two, ie RESETTING, RESYNC, and RECALCULATE. Of the 3, the meaning of one is clear, as it is an analog / C-band term that's been around before these FTA receivers/motors appeared.
RESYNC just refers to a motorized system where positions are stored in terms of counts, say sats are at 10,20,30 counts. Now, if some counts get missed, so that when it thinks it's on the 10 sat, it's really on 12, then all the positions would be off by 2. With resync, you go to a sat like 10, manually move to peak it, then hit resync, which basically just tells the receiver hey, you weren't on 10, you were really on 12, but NOW you are on 10, and after the resync, all the sats are back again. This RESYNC thing is pretty much just like changing the zero position on an FTA or altering the home longitude in USALS.

Now, the other two terms...
RECALCULATE ... this is a term defined in the diseqC-1.2 spec, which I quoted above. Before actually reading the spec, I had always assumed that RECALCULATE was just the same as the old analog RESYNC command, but apparently it is, or can be much more complicated. The spec mentions that it can be with either 1 or 3 data bytes. I am just guessing here, but I STILL think that if the 1 data byte version is sent, that it is probably the same or very similar to a RESYNC command, but in the 3 byte version, it looks like the 2nd and 3rd bytes represent the user's LAT/LON position, and the motor must be applying some complicated calculation to adjust all the pre-defined positions. I really don't have any clue as how this can possibly work, except relative to default positions that have been preprogrammed into a motor, such as the 25 or so European sats that were preprogrammed into my SG2100. But for users around the world, I just don't see how or what this command can possibly do, since users will have stored sat locations without telling the motor what longitude the sat is at, and without telling the motor what longitude the user is at, so there is no possible way that the motor can use the user's LAT/LON position in a 3 data byte RECALCULATE command, as there is nothing to compare it to. For that reason, I STILL have to assume that receivers like the Azbox SHOULD be only using a 1 data byte RECALCULATE command, which SHOULD be the same as a RESYNC command, which to me would be nothing more than changing the zero reference position to account for the position error found after the manual re-peaking of a sat. This is what I THINK RECALCULATE should do, but I have NO idea of whether it actually works that way or not. I have used the RECALCULATE command a few times with other receivers, and it seemed to work that way, but I was never positive. But anyway, whatever recalculate is, it is some recalculation of either all the stored sat positions or of the reference zero position to account for changes in where the motor thinks that it is.

Now.... RESETTING....

AcWxRadar said:

The "resetting" command that I had referred to previously, I believe, simply reschedules the satellite position. If it had been manually assigned previously via DiSEqC 1.2 methods, it would simply "erase" this assignment and prepare it to be reassigned with a new location.

Click to expand...

I really don't know why this would ever be necessary. There is no need to prepare the motor for a store command, you just send the store command. You can erase the position number in the receiver, which leaves the receiver in an unassigned state, waiting to be assigned a new position (which the Azbox seems to be doing), but there is no need to erase any stored data in the motor, and clearly the Azbox is telling the motor something, because it is sending some diseqC-1.2 command, and there is no diseqC-1.2 command which erases any stored position preparing to store a new position, unless it is in some spec later than the diseqC-1.2 spec that I have.

AcWxRadar said:

The "resync" command that you referred to is something that I am not aware of in the menus of the AZBox. I mean to say that at least the AZBox menu selections do not identify it with that identical terminology.

Click to expand...

This is true. The Azbox never mentions RESYNC, and it never mentions RECALCULATE. I was just guessing that RESETTING must be a diseqC-1.2 command, and if so I was guessing that it must be a RECALCULATE command, and I was just guessing that RECALCULATE must be the same as RESYNC. A LOT of guessing, so the odds are pretty high that I'm way off base here.

AcWxRadar said:

....
Resetting? Now I understand the process of "resetting" as deleting the previous location of ONE satellite and then restoring it (saving a new location for it or rewriting the old). This makes sense to me, although I am unsure exactly what they are doing in the software to accomplish this. Therefore, I am vague with my overall understanding.

Click to expand...

But there is no diseqC-1.2 command to delete a location. If you want to save a new location, you just SAVE or STORE that new location. No need to erase the old one, and no command to do the delete or erase even if you wanted to. Now, the deleting the previous location DOES make sense, if you are talking about the (P1) designation that's stored in the AZBOX, and that DOES seem to be happening. Ie when you hit RESETTING, the (P1) goes away so that now the AZBOX no longer knows what position number is assigned to the current sat, and you can either do an automatic save, which just choses the lowest available number, OR you can select a number manually when you do your STORE command. HOWEVER, the problem here, is that if deleting the (P1) designation is what RESETTING does, then there is absolutely no need for any diseqC-1.2 command to be sent to the motor, since this is completely an AZBOX function that doesn't involve the motor. THis is what is confusing me, because the RESETTING command seems to be doing TWO THINGS, ie both deleting the sat position number in the AZBOX memory AND it seems to be sending some command to the motor, and since the position number has been deleted from the AZBOX, I can't imagine what it could be sending to the motor.

AcWxRadar said:

When you state "resync", I think of something slightly different. I think of retaining the same recorded positions, but that the motor returns to the ZERO position and then redefines and relocates the satellite position from there, from that reference point.

Resyncing seems to instill in my mind a more elaborate calibration method. A method which ensures that the receiver and motor have re-identified the starting point and recalculated all the sat positions from there. But, I also think that much of this is all a matter of semantics.

Click to expand...

As above, which I think is similar to what you're saying, the traditional RESYNC comand just redefines where the motor thinks it is, which is the same as altering the reference zero position, so that all the previously stored locations can be related to a corrected reference. I just don't know if that is really what RECALCULATE does or if it's something more complicated.

AcWxRadar said:

I find the whole strategy easy to comprehend with my Coolsat 5000, but not so well with my AZBox Premium. The AZBox has inherent problems with their software and programming and they confuse me much more.

RADAR

Click to expand...

Yeah... the one thing that IS clear, is that whatever the AZBOX is trying to do when you hit RESETTING, it is doing it wrong.

Things seemed more simple back when I was using my Fortec Lifetime and Fortec Lifetime Ultra, and also with my Diamond 9000. My two Fortec receivers had a recalculate command, but I don't think they had any reset command.
Interestingly, my Diamond 9000 has BOTH a RECALCULATE _AND_ a "RESET SYSTEM" command. I have NO idea of what the reset system command does, since as I said above, I don't think that there is any such command in the diseqC spec. I'm going to have to look through my Diamond manual to see if that is defined there. It IS possible that there are some undocumented commands that are being used by motor manufacturers and receiver manufacturers that aren't really part of the spec. There are several "reserved" commands that aren't defined. When I first saw the RESET SYSTEM command in the Diamond, I assumed that it just wiped out all the diseqC parameters that were stored in the receiver, and didn't involve the motor, but perhaps that is wrong.

Anyway, I'm still confused, but I'm convinced that the Azbox isn't programmed correctly regardless of what it's trying to do.