Diseqc rotor support

[jandy123]

I'm working on getting a SG2100 rotor to work on the Digibit box. Initial tests allow me to position to a certain satellite using the goto X command (diseqc cmd 0x6e).

Now the question is how to integrate it with the software. Problem is that diseqc rotors are not supported by the sat>ip specifications, so we need to abuse it a bit to work with minisatip. Does anyone have ideas regarding an integration with tvheadend and/or minisatip ?

My own idea is to abuse the 'src' stream parameter. By default 'src=1' for most configurations (???) I could hack it into minisatip so that it points to a specific sattelite, e.g., 'src=18.2E' to point to Astra 2G. Would this be workable ? Are there batter alternatives ?

Please share your opinions here.

[floongle]

Hi, that's as good a place as any. Here's my thinking. Some of this is over-thinking it, but I'm trying to cover all the bases I can think of:

• But what about those with multiple rotors? - Probably fine as 18.2E on Rotor 1 is the same as 18.2E on Rotor 2 (?) - would there ever be a time where different rotor gave a different result? I suppose two dishes on rotors might have different views of the satellite arc, so (for example) only rotor 1 could see 18.2E but then that would just be another contention to manage elsewhere. Perhaps expand it out to be src=:? if you wanted to be really explicit? (and default to rotor 1 if : isn't given)
• But what about optimisation? Say 28.2E was static on src=1, but the user asks for "src=28.2E" Probably fine as this could be optimised out later (?)

So that sort of mis-use of the src parameter might be OK. And on the plus side, so long as you only put it in "this is a Rotor request" mode if it spots ^\d\d.\d[EW]$ (or something similar based on putting the rotor number in) in the src parameter, there shouldn't be any overlap between that and the "official" uses.

(I'm sure those wiser than me will point out reasons not to do so :) but having rotor control would be useful to many I'm sure. )

[jandy123]

@floongle: I'm sorry but I do not really get your first bullet. Could one dish have multiple rotors ?

I'm more concerned with getting tvh work with such a setup. The sat>ip specification does not support rotors, and as far as I could tell, tvh doesn't support this either. What would be the workflow/usage of tvh with such a setup ? Say, passing sat. using
"src=28.2E" ? How could I setup tvh to do what I want ? Any idea here ?

Thanks !

[perexg]

The rotor must be bound to tuner/frontend (fe=) argument. The src= argument is integer and I think that in this case, we should avoid to use it. I would add something like 'sat=28.2E' argument or so. Also, the server must report the delay to finish the rotation and client should handle it (custom RTSP header in the answer?).

• extend the description (identify rotor and describe allowed range?) (DESCRIBE RTSP)
• implement sat= argument handling (SETUP, PLAY)
• return the time (delay) for the positioning (RTSP answer)

TVH must be modified to handle this, too. I don't see a way to do this without modifications.

EDIT: Think about compatibility with other SAT>IP devices which supports only the SAT>IP standard. Perhaps, the rotors should not be visible for them at all.

[jandy123]

@perexg: Thanks again for your reply !

I would add something like 'sat=28.2E' argument or so.

Yes, I was considering adding an additional parameter and avoid using src.

Also, the server must report the delay to finish the rotation and client should handle it (custom RTSP header in the answer?).

The timing could be estimated (I have code which does this.) Wouldn't be better to just pass it in the sat argument ? Say something like "sat=28.2E30s" where the delay is 30 sec.

In your bullets, what do you mean with (DESCRIBE RTSP), (SETUP, PLAY) and (RTSP answer) ?

TVH must be modified to handle this, too. I don't see a way to do this without modifications.
Perhaps, the rotors should not be visible for them at all.

Hmm, this is interesting, but how could this be implemented ?

Thanks again for your ideas !

[perexg]

Refer the SAT>IP specification - RTSP protocol: http://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf . Those are RTSP commands.

For the rotor and tuner description, perhaps, the custom XML tag may be used and the rotors should not be advertised in <satip:X_SATIPCAP xmlns:satip="urn:ses-com:satip"> tag.

Hmm, this is interesting, but how could this be implemented ?

The SAT>IP client code must be updated.

[floongle]

@floongle: I'm sorry but I do not really get your first bullet. Could one dish have multiple rotors ?

Hi @jandy123, it looks as if you and Perexg have moved the conversation onwards, but to answer your question, I was imagining a situation where one SAT>IP device was connected to more than one dish, and more than one of those dishes had a rotor.

[perexg]

The timing could be estimated (I have code which does this.) Wouldn't be better to just pass it in the sat argument ? Say something like "sat=28.2E30s" where the delay is 30 sec.

Perhaps, it would be better to do this on the server side? Don't? The rotors may have different timing (speed) and it may be handy to configure this on one place. My idea was: client - change position, server - ok, changing, it will took 10 seconds. So it's just about to pass the delay back to the client.

[jandy123]

@floongle: Huh, good one, I see your point...

@perexg: Yes, indeed, only the server knows the timing/delay not the client.

But, I really liked your idea of clients not knowing anything about the rotor. Would such an approach simplify the changes required to tvh ? I mean, tvh can be setup to believe it has multiple positions AA, AB, et

[jandy123]

@floongle: Huh, good one, I see your point...

@perexg: Yes, indeed, only the server knows the timing/delay not the client.

But, I really liked your idea of clients not knowing anything about the rotor. Would such an approach simplify the changes required to tvh ? I mean, tvh can be setup to believe it has multiple positions AA, AB, etc., corresponding to different networks. Then, it makes a request and the server alone decides whether to spin the antenna or not. Is what I'm saying valid ? (I'm really a beginner with tvh and this is why I'm so concerned with modifying it ;).

[jandy123]

Sorry, I closed by mistake the discussion.

[jandy123]

@perexg: Regarding workflow for tvh.

Say I want two satellites. In tvh, I add two DVB-S networks corresponding to the two satellites and assign them SAT->IP source numbers 0 and 1. I also set each tuner to have two positions and assign to each position one network. When now a client requests tvh for a channels, would tvh pass now the correct "src" parameter to minisatip server on the digibox ? If this works, then I just need a minisatip-side configuration connecting the src parameter to the desired satellite, right ?

[perexg]

Basically yes, but it does not resolve the common configuration and the delay notification. I think that there's 5 seconds limit to wait for the stream in tvh by default.

[jandy123]

Basically yes, but it does not resolve the common configuration and the delay notification. I think that there's 5 seconds limit to wait for the stream in tvh by default.

True, I'll have to look into the delay issue. What do you mean with the common configuration ? Your first bullet above ?

What would be the best place to modify the minisatip sources to include the rotor commands ?

[jandy123]

@perexg: Well, I've managed to setup tvh so that each tuner has two positions and has assigned to each position one network (satellite position) identified by an index in sat>ip "src" parameter. So, with this setup, and for a simple antenna configuration (quad LNB with rotor on first tuner), it's all fine and the correct "src" parameter gets passed to the minisatip server. And this without modifying tvh :).

Now, I have a function which given sat & site longitudes and site latitude, computes the params of the rotor command gotox (function 0x6e) and outputs to a specified fe. Now I need to make i) the link between the src parameter and the desired satelites (easy, e.g., via the command line of minisatip) and ii) the modification of minisatip.

Would you please help and tell me where is a good place in the minisatip workflow to integrate the rotor command ? For now a large delay for moving the rotor before streaming (say 10 seconds) is good enough.

Thanks !