Two motorized dishes - one receiver?

[Yorks]

I think this question is receiver specific so you will probably need to be familiar with this model to follow me (and even then you will need to come down to my level - if possible).

At the moment I have 2 dishes linked up to a TM1500ci via a manual A/B switch. One is motorized (45E - 8W), the other is static (30W).

In the 'Motorized settings' I have the option 'DiSEqC Motor' set to 1.2 (although Usals works fine too), for sats from 45E to 8W. For 30W I set this option to 'OFF'. I do this on the laptop using TMeditor as the receiver motorized settings will not allow individual sat configuration. The reason that I have it set this way is to stop the motorized dish from going to 30W, if the manual switch has not been switched to the static dish, when a 30W channel is selected on the receiver.

I am planning to motorize my static dish, to allow me to get from 15W to 45W (and beyond).

My question is this...........

If I scrapped the A/B switch and replaced it with a DiSEqC switch, would it be possible using DiSEqC switching in the 'Satellite Setup' menu, to assign sat settings on the receiver to DiSEqC 1 - for 1st dish, and DiSEqC 2 - for 2nd dish, (it appears to allow several sats to share the same DiSEqC port number), and still be able to use DiSEqC 1.2 positioning in the 'Motorised settings to move the designated dish? Or can you not mix the 2 protocols. I have no experience with DiSEqC switching. :?

Is there another way? Or do I need to remember to get up off my ample arse and switch over before selecting the 'other' dish?

Regards,

Yorks.

(English version available on request).

[BGonaSTICK]

This is a long-standing question, and a scenario which I have never actually tested properly, nor had answered for me conclusively.

In theory, unless your receiver is capable of hierarchical commanding (i.e. having a second layer of DiSEqC device in-line) using something like the spaun 220F/420F, then it probably won't work.

You can understand how this could be a problem. If you took stacked switches for example, say a two-way switch nearest the receiver and then another two-way switch beyond that, on port 1 of the first switch. If the receiver sends a 'switch to port 2' command down the coax, the first switch will switch to port 2, isolating port one such that the second switch hanging off port one can never receive a 'switch to port 2' command.

You'd think that motor commands are different, and they are. As part of the DiSEqC command structure there is a hardware type identifier. IIRC it's 31 for motors and a number of other (different) values for various switches. I have a feeling though, that if you send a 'goto satellite no.3' type command to a switch, you get port three. Send the same command to a DiSEqC motor, and you get sent to whichever satellite is stored in position 3 in the motor memory.

This may well not be right in either some or all cases (dependant on makes and models), - I couldn't get my DiSEqC motor to work at all beyond my switch. Some switches allow the DiSEqC commands to pass through themselves and some don't. Same with motors I'd imagine, so this hardware identifier doesn't appear to work very well in practice.

I'm convinced that this is simply because the hardware manufacturers just want to spend the minimal amount of time and money developing their products, and don't give a stuff if 1% of their customers have problems with poor compatibility. How many people want to do the kind of crazy stuff we attempt anyway?

Switches do have a 'default position' and generally this is port 1. If you had a DiSEqC motor on port one of a DiSEqC switch, you may get some joy, but it's even less likely to work properly on port two. Having two motors on a two-way switch really hurts my head.



Sorry that's a bit of a ramble, but the short answer is - you're going to have to experiment with the specific hardware you end up with. The worst that's going to happen is that you'll have to keep your A/B switch. That's what I use now, like you.

If you ended up with a receiver that can command an uncommitted switch, then that really should work, but there are no guarantees.

[Yorks]

Thanks Stick,

Yep, I think the only way is the practical test!

'Global' DiSEqC switches seem to be as reliable as any in these multi-tasking situations.

When I get on with it, I'll let you know if it all ends in tears.

Regards,

Yorks

[Yorks]

Well I finally got a round-tuit!

I have added a second motorised dish to my system - my first attempt at installing a motorised system , and have both dishes working fine (if a bit quirky) on my TM1500 receiver.

There could well be compatability issues, with different combinations of equipment (some may work better some may not work at all), so I will give a full inventory of my system:-



Dish 1:Triax 88cm solid dish with Lemon 0.2 lnb and Fortec Star FS2100 motor.
This dish is situated at rear of house tracking the arc from 53E to 8W.

Dish 2:Raven Aries 80cm mesh dish with Lemon 0.2 lnb and Moteck SG2100A motor.
This dish is situated at front of house tracking the arc from 12.5W to 58W.

Technomate TM1500 CI+ Super receiver.

Global 2x1 DiSEqC switch (connecting dishes to receiver).




I have tried several combinations of DiSEqc switch settings - these work best for me:-

Dish 1 is connected to 'LNB A' on Global 2x1 DiSEqC switch and Dish 2 is connected to 'LNB B'.

In the 'Motorized Setting' menu I have tried 1.2 and Usals - both work equally well.

As you can see from attached photos below, in the 'Satellite Setup' menu, I am using DiSEqC 1.0 on dish/motor 1, and DiSEqC 1.0 and 1.1 on dish/motor 2.

The quirk is this. When I switch from Dish 2 to Dish 1 by selecting a channel or sat, the motor 'misses' the initial 1.2/Usals command and does not move. I think that the DiSEqc 1.0 command is taking priority - as dish 2 doesn't try to move instead - fortunately. The result is that if Dish 1 is already parked at the chosen satellite - then it switches to LNB A and works. If not - it reports 'moving to ....', and after a few seconds times out. After it has timed out, by selecting a different sat on dish 1 (it thinks it's already at the one chosen in the first place, so selecting the same one again doesn't work!) - it receives the command and moves to that position. After that, it skips between sats on that dish fine. I can live with that!

I had the same 'quirk' on Dish 2 when switching from Dish 1, but by using a combination of DiSEqC 1.0 and 1.1 - any number from 1-16, it moves fine - on it's first instruction! (If DiSEqc 1.0 is switched off it doesn't work). This combination doesn't work with Dish/motor 1.

Another quirk is that Dish/motor 1 won't nudge when rooted through the Global switch on either LNB A or B connection, but Dish 2 will nudge on LNB B but not on LNB A - although it will receive initial command on LNB A and move to relevant sat. I have tried all DiSEqC combinations and think this must be down to the switch. Dish 1/motor 1 behave the same on LNB A and LNB B switch terminal, so Dish 2/motor 2 is better suited to LNB B, giving full functionality on positioning and nudging.
To fine tune dish 1 if required (seldom now there is no Fox Sport ME), I just bypass Global switch and plug directly into receiver.

The newer SG2100A motor copes better on my system, although it could be a combination of receiver, switch and motor and DiSEqC protocol. A different combination would no doubt give different results.

So basically YES it does work - suffice to say that I've ditched the manual A/B switch, and my arse is getting wider by the minute!

Regards,

Yorks.


DiSEqC settings for Dish 1 (Top Photo) on 28.2E at the time

DiSEqC settings for Dish 2 (Bottom Photo) on 30W at the time

[BGonaSTICK]

Interesting - thanks for that

I sort of followed it, and I guess it sort of makes sense, but some of it is just weird. It just goes to show that there is no real standard for DiSEqC equipment. Switches are particularly Schizo!

I would love to experiment with that on my Dreambox - the DiSEqC configuration menus gives you a lot more flexibility - you can combine commands and even introduce delays I believe.

Anyway, good stuff. It all adds to the understanding of how crazy this stuff gets when you start bolting on loads of devices

[Yorks]

Yes. I think if I could delay the 1.2/Usals command, so that it was sent after the DiSEqC 1.0 command then it may work 100%. But as I have a way around it (albeit an extra key press :spite, it's cool .

Regards,

Yorks.