azbox and SG2100 dont mix??

BJ
I dont know why its doing that on Diseqc 1.2 but I tried it the other day again

Moved dish to 93W (my true south) and reset motor (with the paperclip)
hooked up azbox and locked in 93W as P1
scanned in azteca at a 75 quality
moved dish to 89W and saved as P11 (I use 1 as true south, then start at east limit of 61.5 as 2 then go across the arc)
scanned in ABCNews Now at 72 quality
then selected Azteca 7 and dish moved
quality down to 34
nudged dish east and then back to 75 and saved

so its still happening. What is weird is the motor seems to move on the same transponder. I hit channel up to Azteca 13 and all of a sudden the quality went down to low 50's

Its a moot point now as I redid my dish setup and need the azbox to be slaved. With G16 back in the mux (had the dish at 87W) and its HD/4:2:2/AC-3 channels along with 121 C-Band and 125 KU fixed setup I need to use it for AC-3 :)

Very strange. I guess that I'll keep mine slaved too. The only reason I'd switch over to controlling a dish would be if they ever fix that PLUS version, and make a 2nd DVB-S2 tuner available (I read where the people who got that receiver say that it only has one tuner). THEN, I'd like to connect C-band to one and Ku to the other tuner, but until then, I guess I'll just keep mine slaved.

I'm curious whether you have all the non-visible sats in your sat list. After playing with the diseqC-1.2, I TRIED to go back to my original sat list. I first tried by just FTP'ing my old DVBS.DAT file back to the Azbox. I transferred it, but when I rebooted, it had moved the BIG file back in again from the protected backup directory.
So next I tried the old Azboxedit program that was made for the 2880 firmware. This worked for me before, and allowed me to transfer all the files, and it kept the proper DVBS.DAT file. However with the new firmware, when I transferred the files, then rebooted, again, it replaced the DVBS.DAT file I just uploaded with the big backup file. I then tried to use the newest version of MAZ. It didn't work either. I also tried moving files from the Azbox to the computer via MAZ, then deleting sats, but MAZ isn't able to delete the sats. Or actually, it deletes them, but once you've deleted all the unwanted sats, save and load them back in, they all have the default names of the sats you can't see! Ie I deleted all the east longitude sats, but then when I loaded the data back into MAZ all my sats were ONLY the eastern longitude sats, and I had lost ALL the sats that I DIDN'T delete. I think that it's because in addition to longitudes, MAZ, or the Azbox numbers all the sats, and apparently when you delete sats, it re-names them using the numbers from the default sat list. VERY WEIRD. I would definately recommend avoiding MAZ.

I am VERY tempted to unprotect that backup directory, and move MY DVBS.DAT file in there, then re-protect it again. But for now, I just MANUALLY deleted all the unwanted sats using the remote. Took about an hour. So I'm back to where I started, and things seem to be working again, but I'm not fooling with the diseqC-1.2 again for a while. I'll just move my Ku dish with my Diamond, and the C-band dish with my Monty-55.

FOOEY. I sure hope that they fix these basic things, and PARTICULARLY give us a channel editor that will allow us to at least delete satellites again. I swear that I was able to do this with the 2880 editor back when I was using 3877, but you can't do it now for some reason.

EDIT: BTW, Iceberg, the only reason I can think of that would explain what YOU're seeing is that somehow the Azbox is sending a resync command that is changing the motor's zero just a bit. I'd be curious whether your motor is going back to the real zero now when you do a goto reference. Otherwise I don't understand, because the positions should be stored in the motor, and if the Az tells it to go to position 1, then the motor should go there, unless the zero somehow changed.
 
BJ
since you have original DVBS.dat in /DISK1/DISK2_backup dir you will have problems like this. nothing is wierd.
if you afraid you can store your original dvbs.dat in your comp just in case, and play with your own list.
but, you gotta edit a xml template then make a dvbs.dat from EDITED template, etc...
i agreed, maz sux

azbox elite, f/w 3877
 
Last edited:
BJ
since you have original DVBS.dat in /DISK1/DISK2_backup dir you will have problems like this. nothing is wierd.
if you afraid you can store your original dvbs.dat in your comp just in case, and play with your own list.
but, you gotta edit a xml template then make a dvbs.dat from EDITED template, etc...
i agreed, maz sux

azbox elite, f/w 3877
I think if I still had the 3877 firmware in there I wouldn't be nervous about replacing the DVBS.dat backup file, but since upgrading the firmware, my Azbox has been less stable, and I'm still not 100% certain that I understand just which directories/partitions come in with new firmware, which are wiped out when you reformat the application area, etc, etc. I've had my fairly new firmware going for about a month now, and it hasn't reverted to the BIG file, and I'm confident now that I can get back to the small file quickly if it does revert. Since I only use my Azbox slaved on C-band, it doesn't get the use as some of my other receivers. I won't use it more unless they fix some of the bugs with the box, and I'm a bit slow relative to learning how the thing works since I don't use it heavily.
But I DO have multiple copies of al the various files, so as long as I have ftp/telnet access, I can get the thing back in business after a problem. My main fear is wiping out something that isn't compatable with firmware updates, and getting the box into some reboot cycle where I can't get ftp/telnet access, but I think that I really shouldn't worry about that unlikely senario.
 
B.J. and Ice and others following this subject...

Obviously things with the AZBox are not as we expect them to be. Personally, I am confused with just the general operation of the AZBox's motor control system. There ARE defects and quirks for certain. However, I have noticed a few things during "experimentation" that may be worthy of discussion.

If you select SETTINGS > TV Channel > Tuner xyz DBS > ANTENNA SETUP > POSITIONER SETUP > DiSEqC 1.2 (and make adjustments).....

Notice the COMMAND MODE option from here, after you have dialed in a sat with DiSEqC 1.2 controls to peak your dish on a particular sat/TP.

You should notice the following options:

GO TO POSITION

GO TO 0

SETTING EAST LIMIT

SETTING WEST LIMIT

DISABLING LIMITS

SAVE (with sub-options of AUTO or selections for your own position number between 1 and 125)

RESETTING

Bare with me for a moment now, and let's say that I wish to reposition my one and only satellite that uses DiSEqC 1.2 (30.0°W Hispasat) to a new coordinate or position.

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

If I like the NEW DiSEqC 1.2 location that I have found for Hispasat, I next change the COMMAND MODE from RESETTING to SAVE (and select AUTO) and press OK. Now, it resets the setting (position of) Hispasat to the NEW position and stores it as "30.0W (P1) Hispasat 1". Notice that it has now replaced the "P1" indication to the sat name.

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. I think I figured out a little bit of what is going on here (although it is a very simple item). There are bigger problems here to contend with, but in my mind I understand one little portion of this mess just a little bit more.

Granted, this system is still fouled in my opinion. However, I see something new and a bit more logical now. Let me know how you percieve it.

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

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

Save. After saving a sat it is necessary to 'go to position' and select. This prevents the motor from 'walking' after you exit the menus.

Software editors mess with DiSEqC. Positions shuffle! All bad. If you find one that plays nice with DiSEqC , please let me know!

...and for some reason, without warning, some sat settings get cleared; LNB -Freq 0. DiSEqC -OFF, 22khz -OFF, 0/12v -0v, LNB Power -Off. TP -0mhz, Positioner -Off network -Nit. Sometimes rebooting fixes this. Sometimes not.

All of that being said, DiSEqC settings do not shuffle with my Gbox. Only the sg6000. USALS is preferred with the sg6000 and works flawlessly. If USALS is off by a bit, I create a new sat and give it a new position. I reserve DiSEqC for the Gbox.
 
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".


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.

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.

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

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

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). "
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.
 
Last edited:
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.

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
 
Last edited:
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.
 

Elite boot issue

DVD

Users Who Are Viewing This Thread (Total: 0, Members: 0, Guests: 0)

Who Read This Thread (Total Members: 1)