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