Social Feed

a33 said:

OK. So do I understand right, that they both are suitable, but that there is a difference in navigation/zooming possibilities, and maybe 'recording' possibilities (to do the analysis afterwards), that made audacity the best choice? (I've never worked with either of them, hence my question.)

Click to expand...

yes I'm quite sure that I could have done the same with the oscilloscope program. It's a Sainsmart DS120, a cheap pc-baced oscilloscope sold on Amazon. It's of course not comparable to a good oscilloscope with memory, and the controls are not always intuitive and to be honest I have not used those in many years so maybe the problem is also with the operator... I was able to record but could not figure out how to replay in a useable manner, and the graph screen is very small compared to what Audacity shows. Of course Audacity is no oscilloscope, and you have to be certain that your input signal will conform to the limits of an audio signal. In this case it was a good fit. And it was indeed very easy to select and zoon in on the portion of signal that interested me

a33 said:

Interesting, that only the 1.0 command is repeated. And that 1.0 command comes first; I believe normally that is the other way round.

Click to expand...

I will check that again to be certain. And will also check what the Amiko is sending

a33 said:

Bad or 'strange' switch seems to be the right conclusion, indeed.
I wonder if it could be still useable in a certain way, in a cascaded setup?

Click to expand...

A quick test yesterday with the LEDs seemed to indicate that reversing the order of the switches was working fine with the Rex receiver. LNB-(1.1)-(1.0)-Receiver. I do remember testing that last year with the Amiko (and a different 1.0 switch ) without success though. More testing needed there...

a33 said:

I'd still be interested in the answer to these questions:

(The first question, of course, has a link to the reversed switch-order test, that you want to do.)

Greetz,
A33

Click to expand...

I think a first 1.0 command added to a 1.1 command would sometimes fail, I don't think there was a clear pattern there

Both receivers can go up to 16... I think I saw that the 1.1 switch was simply ignoring any command above 8, but I will try again. I like the idea... In the case of the Amiko, for 1.1 it has 25 choices: Disabled, 1/8 thru 8/8, then 1/16 through 16/16. I am interested in seeing how that plays out in actual commands, since my understanding is that the commands are simply E0 10 39 F0 through FF, with no distinction of 8 port vs 16 port. But I'm still only beginning to get familiar with DiSEqC commands so might be missing something.

I still need to see if the 1.1 switch reacts in any way to 1.0 commands only

Thanks for all the ideas!

Just read some eutelsat documents again. I can see that they propose sending 1.0 command first, and then in the 100 ms (repeat)pause send the 1.1 command. Clever thinking!
However the 1.1 - 1.0 command order usually works (for RX - 1.1 - 1.0 - LNB) without a pause, I believe; so the 100ms pause is not always necessary. Then the order, without the pause, can be changed again to 1.1 - 1.0, without repeats.

Brct203 said:

Both receivers can go up to 16... I think I saw that the 1.1 switch was simply ignoring any command above 8, but I will try again. I like the idea... In the case of the Amiko, for 1.1 it has 25 choices: Disabled, 1/8 thru 8/8, then 1/16 through 16/16. I am interested in seeing how that plays out in actual commands, since my understanding is that the commands are simply E0 10 39 F0 through FF, with no distinction of 8 port vs 16 port. But I'm still only beginning to get familiar with DiSEqC commands so might be missing something.

I still need to see if the 1.1 switch reacts in any way to 1.0 commands only

Click to expand...

The 8/1 switch should work on 9/16 through 16/16.
Come to think of it, I don't think the switch will react to the 1.0 commands less problematically as with 1/16 through 8/16, though.

BTW: Does your receiver have the possibility to give raw diseqc commands?
As the 1.1 switch reacts strangely to the 'collective' 1.0-command E0 10 38 Fx, that doesn't mean it would react strangely to the individual switch-level commands E0 10 22/23/26/27

Greetz,
A33

a33 said:

Just read some eutelsat documents again. I can see that they propose sending 1.0 command first, and then in the 100 ms (repeat)pause send the 1.1 command. Clever thinking!
However the 1.1 - 1.0 command order usually works (for RX - 1.1 - 1.0 - LNB) without a pause, I believe; so the 100ms pause is not always necessary. Then the order, without the pause, can be changed again to 1.1 - 1.0, without repeats.



The 8/1 switch should work on 9/16 through 16/16.
Come to think of it, I don't think the switch will react to the 1.0 commands less problematically as with 1/16 through 8/16, though.

BTW: Does your receiver have the possibility to give raw diseqc commands?
As the 1.1 switch reacts strangely to the 'collective' 1.0-command E0 10 38 Fx, that doesn't mean it would react strangely to the individual switch-level commands E0 10 22/23/26/27

Greetz,
A33

Click to expand...

I did not see any option in either receiver for raw DiSEqC

I just did some more testing...
I looked at the commands when Repeat is set to 1 in the Rex. I confirm it sends 1.0, then 1.1, then 1.0 again

Now remember how i said earlier that cascading the other way (LNB to 1.1 to 1.0 to receiver) worked with the LEDs. Well, there's an unexpected twist to it:
I tested with the REX receiver
if the 1.1 goes to 1.0 port 1: all good, works exactly as the receiver says
if the 1.1 goes to 1.0 port 2: the ports on the 1.1 are shifted by 4, for example, selecting port 4 lights up port 8 etc.
if the 1.1 goes to 1.0 port 3: the ports are shifted by 8, to get port 1 i have to select 1.1 port 9 etc.

As for the 1.1 responding to port 9-16 commands, on the Rex it's NO

However when i tested with the Amiko and various dishes with the same config as above, with port 3 cascading to the 1.1, it was working fine with port 1 through 8 on the Amiko. Go figure...

Brct203 said:

if the 1.1 goes to 1.0 port 1: all good, works exactly as the receiver says
if the 1.1 goes to 1.0 port 2: the ports on the 1.1 are shifted by 4, for example, selecting port 4 lights up port 8 etc.
if the 1.1 goes to 1.0 port 3: the ports are shifted by 8, to get port 1 i have to select 1.1 port 9 etc.

Click to expand...

Trying to schematize:
With the Rex it seems as follows (assuming, that the band and polarity command of diseqc 1.0 have no impact as yet (till you tested it otherwise)):

with diseqc 1.0=port1, you can reach diseqc 1.1 port 1/8 through command 1/8
with diseqc 1.0=port2, you can reach diseqc 1.1 port 1/8 through command 5/12
with diseqc 1.0=port3, you can reach diseqc 1.1 port 1/8 through command 9/16
with diseqc 1.0=port4, you can reach diseqc 1.1 port 1/8 through ...command 13/16 and 1/4????? (you didn't test or mention this yet).

I guess the diseqc 1.0 command was repeated, during this test? Or I don't see how the diseqc 1.0 command would otherwise reach and influence the 1.1 switch.
By the way. I know of no diseqc command, that could shift ports like is happening here. Very strange!


But with the Amiko, all is reacting normally, with this switch order? Does the Amiko have diseqc repeat?

greetz,
A33

a33 said:

Trying to schematize:
With the Rex it seems as follows (assuming, that the band and polarity command of diseqc 1.0 have no impact as yet (till you tested it otherwise)):

with diseqc 1.0=port1, you can reach diseqc 1.1 port 1/8 through command 1/8
with diseqc 1.0=port2, you can reach diseqc 1.1 port 1/8 through command 5/12
with diseqc 1.0=port3, you can reach diseqc 1.1 port 1/8 through command 9/16
with diseqc 1.0=port4, you can reach diseqc 1.1 port 1/8 through ...command 13/16 and 1/4????? (you didn't test or mention this yet).

I guess the diseqc 1.0 command was repeated, during this test? Or I don't see how the diseqc 1.0 command would otherwise reach and influence the 1.1 switch.
By the way. I know of no diseqc command, that could shift ports like is happening here. Very strange!


But with the Amiko, all is reacting normally, with this switch order? Does the Amiko have diseqc repeat?

greetz,
A33

Click to expand...

on the Rex:
with diseqc 1.0=port1, i can reach diseqc 1.1 port 1/8 through command 1/8
with diseqc 1.0=port2, i can reach diseqc 1.1 port 1/8 through command 5/12
with diseqc 1.0=port3, i can reach diseqc 1.1 port 1/8 through command 9/16
with diseqc 1.0=port4, i can reach diseqc 1.1 port 1/8 through ...command 13/16 then 1-4

on the Amiko:
with diseqc 1.0=port1, i can reach diseqc 1.1 port 1/8 through command 1/8
with diseqc 1.0=port2, i can reach diseqc 1.1 port 1/8 through command 5/12
with diseqc 1.0=port3, i can reach diseqc 1.1 port 1/8 through command 1/8
with diseqc 1.0=port4, i can reach diseqc 1.1 port 1/8 through command 5/12

i could see sometimes some hesitation on the 1.1, where it would go to the port matching the command at first and then fall back on the port mentioned above. It seems that it's having some problems with the bits marking the 4 and 8 in the last nibble of the 1.1 command.

the repeat setting does not seem to have any impact. I did not inspect the actual commands on the Amiko so I don't know if there's any repeating

as to how it would reach, well, keep in mind that the DiSEqc commands are actually repeated at regular intervals, like every second or half second, so if it's not getting it the first time, it will get it on the next round

Brct203 said:

.. keep in mind that the DiSEqc commands are actually repeated at regular intervals, like every second or half second,

Click to expand...

Normally a receiver only sends a diseqc command when changing channels.
And only when that doesn't give a lock on the wanted channel, a receiver tries the diseqc command again, and repeats.
(BTW That is also important, because if 22kHz(continuous) is ON, a diseqc repeat would interfere with that.)

So I guess the repetition you mention is the 'no-lock repeat'. The interval for that is quite different over various receivers, I noticed.

greetz,
A33

a33 said:

Normally a receiver only sends a diseqc command when changing channels.
And only when that doesn't give a lock on the wanted channel, a receiver tries the diseqc command again, and repeats.
(BTW That is also important, because if 22kHz(continuous) is ON, a diseqc repeat would interfere with that.)

So I guess the repetition you mention is the 'no-lock repeat'. The interval for that is quite different over various receivers, I noticed.

greetz,
A33

Click to expand...

That is not my understanding when it comes to cascading switches. The commands are sent more than once. For an explanation, see the below Spaun document (Page 7 starts the "Combination OF DiSEqC Components) 9.2.1 Example explains it.

http://www.spaun.com/files/8df79_en_DiSEqC_for_Technicians.pdf

Keith Brannen said:

The commands are sent more than once.

Click to expand...

That depends entirely on how the receiver's manufacturer has made it.
It can be once, or twice (or more), or settable by user.

The 'once' gives problems e.g. when cascading a 4/1 1.0 switch with a monoblock LNB (both switching on 'position' command).

And the lack of diseqc 1.1 repeat caused also a problem here, switching 20 LNBs in a rather special setup (sorry, in Dutch!): DISEqC, 20 lnb's schakelen

Not everything on the internet about diseqc is right. Also the wikipedia page about diseqc I find partly mis-informing, alas!
Even the eutelsat documents are not uptodate; some (motor)commands are missing.
The spaun document is indeed better than wikipedia. That sometimes repeats are needed is clear, but that doesn't mean that they actually happen.

Greetz,
A33

Just to clarify, it would not be possible to stack two 4x1 switches, correct?

comfortably_numb said:

Just to clarify, it would not be possible to stack two 4x1 switches, correct?

Click to expand...

When they switch on the same commands: NO, pretty useless.
Only one port of the second switch would be reached; so the presence of the second switch would bring nothing.

When they switch on different commands: YES.
Can be done with a 4/1 diseqc 1.0 switch plus a 4/1 diseqc 1.1 switch.
Or with 2 4/1 diseqc 1.1 switches, that can be setup to use different uncommitted commandlevels (e.g. Spaun SUR420).
Or combined with a switch that switches on diseqc 1.2 commands.

8/1 switches I find easier than stacking two 4/1 switches; however with two dishes at separate locations stacking multiple switches could be easier.

greetz,
A33

I only see Diseqc 1.0 and 2.0 switches available that are of the 4x1 variety. Would one 1.0 and one 2.0 4x1 be stackable?

comfortably_numb said:

I only see Diseqc 1.0 and 2.0 switches available that are of the 4x1 variety. Would one 1.0 and one 2.0 4x1 be stackable?

Click to expand...

no they would not as they use the same commands (a 2.0 switch is like a 1.0 that can give feedback to the receiver)

a33 said:

That depends entirely on how the receiver's manufacturer has made it.
It can be once, or twice (or more), or settable by user.

The 'once' gives problems e.g. when cascading a 4/1 1.0 switch with a monoblock LNB (both switching on 'position' command).

And the lack of diseqc 1.1 repeat caused also a problem here, switching 20 LNBs in a rather special setup (sorry, in Dutch!): DISEqC, 20 lnb's schakelen

Not everything on the internet about diseqc is right. Also the wikipedia page about diseqc I find partly mis-informing, alas!
Even the eutelsat documents are not uptodate; some (motor)commands are missing.
The spaun document is indeed better than wikipedia. That sometimes repeats are needed is clear, but that doesn't mean that they actually happen.

Greetz,
A33

Click to expand...

And my point was that a manufacturer (Spaun) of switches stated that when cascading switches the commands are required/need to be sent more than once for proper switching. Whether manufacturers of receivers follow those guidelines or not is at their peril as to whether they can properly control cascading switches if/when they don't follow those guidelines.

EDIT: If not sending the commands more than once, I can also see where a "no lock, repeat" could fail to happen if the command sent only once happened by chance to lock on a same frequency signal as the required channel.

Update on my attempts at cascading diseqc 1.0 and 1.1.

Earlier in this threads I reported results of my unsuccessful attempts at cascading using a Pansat 1.1 switch.

Well, I recently bought a GeoSatPro 1.1 8-port switch, and now the cascading is working flawlessly.

So that would confirm a limitation in the Pansat 1.1 switch (but the Pansat works fine when used standalone, without cascading)