Stackable switches

[Brct203]

it did not work - it seems that as soon as there's a 1.0 command, it messes up the 1.1 state. I don't remember exactly what the 1.1 switch did when the 1.0 switch was on port 8 of the 1.1, i think it would randomly end up on port 6, but i'm not sure. In any case it was not working right.

Interestingly, when i connected the 1.0 switch to port 1 of the 1.1, the port it would end up switching to by error was port 5 (just like it would end up on port 8 in my earlier test with the cascading on port 4 - in both cases it went to the port number (cascading port+4)... Weird

 

[Keith Brannen]

Definitely strange. I think Magic Static's reader is the only way to determine whether it is the fault of the receiver's commands, or whether it is the switch at fault. Even though the Pansat is an uncommitted only switch, when it fails it acts like a committed/uncommitted switch in that port 1 is paired with port 5, port 2 in paired with port 6, etc. I am not sure whether that pairing is standard in any 8x1 switch or not, nor whether that is the natural reaction of the switch due to a failure to understand the receiver's commands.

My EMP Centauri 8x1 is an example of a committed/uncommitted switch where port 1 is defined as A(or 1) committed, A(or 1) uncommitted, port 5 is A(or 1) committed, B(or 2) uncommitted, etc. (I use 1.2 protocol for "motor" positions since it is on port 1 of my 4x1. There is a different version of the same switch which allows it to be a committed/uncommitted switch, or an uncommitted only switch, or 1.2 switch.)

 

[a33]

it did not work - it seems that as soon as there's a 1.0 command, it messes up the 1.1 state. I don't remember exactly what the 1.1 switch did when the 1.0 switch was on port 8 of the 1.1, i think it would randomly end up on port 6, but i'm not sure. In any case it was not working right.

Interestingly, when i connected the 1.0 switch to port 1 of the 1.1, the port it would end up switching to by error was port 5 (just like it would end up on port 8 in my earlier test with the cascading on port 4 - in both cases it went to the port number (cascading port+4)... Weird

Well, your switch is more confused than simply 'when confused, have a preference for port 8', obviously!

As for your first tests, it seemed that the first time a diseqc 1.0 command was added to the 1.1 command, the switching went OK. And only with a second 1.0 command, the weird switching began. Has that, indeed, been a consistent outcome, also in your later tests?

Does your receiver have the posssibility of diseqc 1.1 commands going up to 16? Or only up to 8, as you wrote earlier?
If you can set 9 to 16, does it behave the same as with 1 to 8?

I am not sure whether that pairing is standard in any 8x1 switch or not, nor whether that is the natural reaction of the switch due to a failure to understand the receiver's commands.

If a switch doesn't understand a command, because it isn't exactly matching the command(s) the switch is made for, the switch should normally ignore the command. So that would be the 'natural' reaction.

There are, of course, multi-diseqcmode switches, that work on 'autodetect'. So a 1.1/1.2 autodetect switch would only react to motorcommands and ignore 1.1 commands, when after powering up a motorcommand is received (as in the example I gave earlier).
I guess for a 1.1 or 1.1/1.0 autodetect switch, the same applies: when after powering up a 1.0 command is received, I guess the mixed mode of 1.1/1.0 is followed.

Brct203 : Did you notice that the 8/1 switch reacts to 1.0 commands (with 1.1 disabled)?


greetz,
A33

 

[Keith Brannen]

If a switch doesn't understand a command, because it isn't exactly matching the command(s) the switch is made for, the switch should normally ignore the command. So that would be the 'natural' reaction.

Yes, but my point is that the switch (after the receiver's command) is reacting by switching to its paired port (1-5, 2-6, 3-7, 4-8, which from looking at the Eutelsat documents is the same for committed/uncommitted switches or uncommitted switches).

From Brct203 report, it works fine on port 4 (uncommitted) when going from 1 to 4 (committed) but when going back to port 4 (uncommitted) and port 3 (committed) is when it changes to port 8 (uncommitted) (in other words the bit is changed/interpreted that it is to switch to port 8 (its paired port). Hence, when the 4x1 was on port 1, it changed/interpreted it to switch to its paired port (port 5). If Brct203 tried the 4x1 on port 2 or 3, then it probably would switch to their paired ports. It would be interesting to see where it would jump if the 4x1 is on ports 5-8.

So whatever the receiver is sending, either the receiver is sending the wrong code, or the switch is interpreting it incorrectly (may be it is ignoring part of the data burst, and implementing what it can, and incorrectly).

 

[primestar31]

I'd like to see what happens, IF he resets the receiver to defaults, reboots, re-flashes the firmware, and resets to defaults again. Then does normal setup...

One of my MicroHD's went wonky some time back, and a re-flash/reinitialize fixed it up. It appeared as if almost everything was fine, but some of the menu's acted weird. So not obvious the firmware got corrupted, but it did somehow.

 

[a33]

Yes, but my point is that the switch (after the receiver's command) is reacting by switching to its paired port (1-5, 2-6, 3-7, 4-8, which from looking at the Eutelsat documents is the same for committed/uncommitted switches or uncommitted switches).

Well, we've only seen in his reports: 4-8, 1-5, and 8-6 (this 6 he was not sure about).

It is not a consistent pattern, yet, if I understand Brct203 correctly; and the text in his post #33 shows more nuance in the problem than shows in the schematic he posted also.
This part:

it works fine on port 4 (uncommitted) when going from 1 to 4 (committed)

is not supported by his verbal report, in my understanding.

It still is a puzzling problem....

Added: Brct203 : Don't you have another receiver, with which you can test?

greetz,
A33

 

[Keith Brannen]

OK, I see what you mean, there may have been momentary light ups of the some of the correct ports, before it jumped to port 8.

Like I said, I would not be surprised if the test was done on ports 2 and ports 3, that it then jumped to ports 6 and 7 respectively (and would be very curious as to what ports it jumped to when the 4x1 was on ports 5 to 8).

Even if there is a pattern, I don't see how we would be any closer to an explanation/solution! LOL!

 

[Brct203]

OK, I see what you mean, there may have been momentary light ups of the some of the correct ports, before it jumped to port 8.

Like I said, I would not be surprised if the test was done on ports 2 and ports 3, that it then jumped to ports 6 and 7 respectively (and would be very curious as to what ports it jumped to when the 4x1 was on ports 5 to 8).

Even if there is a pattern, I don't see how we would be any closer to an explanation/solution! LOL!

yes indeed there is usually a moment where it looks right before it fails and goes to the wrong port (port 8 in the PDF i attached earlier.

I do have other receivers but they are older and support only one DiSEqC type at a time, so i can't test with those.

I did re-flash the receiver a few months ago, but had observed problems with stacking DiSEqC switches before and after, so i dont think that would fix it.

Right now i'm trying to visualize the DiSEqC commands using a simple solution: Simple DiSEqC monitor and signal analyzer · One Transistor

before I use it with my Amiko, I'm testing this contraption with an old DVB-S receiver (no big loss if I fry it...). So far so good, I'm able to see the DiSEqC waveforms, now I need to try to translate it to binary than to Hex and look it up. Not exactly as convenient as a DiSEqC decoder, but has the advantage of also showing the timing between the DiSEqC commands.

 

[a33]

So far so good, I'm able to see the DiSEqC waveforms, now I need to try to translate it to binary than to Hex and look it up. Not exactly as convenient as a DiSEqC decoder, but has the advantage of also showing the timing between the DiSEqC commands.

The old handwork, .... nice!
I found the oscilloscope picture on this webpage clarifying for the decoding, as it clearly indicates the E0 10 38 F3 command: DiSEqC (TM) Analyser – RASPberry PI THermostat and INstrumentation

greetz,
A33

Edit, the command in your web-link (second oscilloscope picture) would be E0 10 38 F2; as you probably figured out already?

 

[Brct203]

The old handwork, .... nice!
I found the oscilloscope picture on this webpage clarifying for the decoding, as it clearly indicates the E0 10 38 F3 command: DiSEqC (TM) Analyser – RASPberry PI THermostat and INstrumentation

greetz,
A33

Edit, the command in your web-link (second oscilloscope picture) would be E0 10 38 F2; as you probably figured out already?

yep, in my case I was able to read the command E0 10 38 FB. I think I had the receiver on DiSEqC 1.0 Port C , 22 kHz on and on a Horizontal transponder, and that matches what i'm seeing in the Eutelsat documentation.

Tomorrow i'll try to test the Amiko commands.

 

[a33]

Which program did you use? An audioprogram, or an oscilloscope program? Which one?

I've always read websites about this with interest, but never had an urgent enough problem to try it out....

greetz,
A33

 

[Brct203]

Well, Ladies and Gentlemen, I have some update...

A33, to answer your software question, I used Audacity, as suggested in the page I linked earlier, and fed the signal to the PC line-in jack. I inspected it first with a PC-based oscilloscope to make sure I was not going to fry the PC. (The oscilloscope made it hard to navigate the signal to zoom in on the DiSEqC commands, otherwise would have been a preferred method.

In doing the above testing of my ability to "read" DiSEqC commands with my old REX receiver (DVB-S, no blind scan), I noticed that if I select DiSEqC 1.1, then it has a submenu that allows me to select DiSEqC 1.0 port, DiSEqC 1.1 port, Tone Burst and Repeating...

Si I decided to do the LED test like I had done with the Amiko, while at the same time recording the commands with the computer

The result: Exactly the same behavior as with the Amiko:
DiSEqC 1.0 connected to DiSEqC 1.1 port 1
Commands to use DiSEqC 1.0 port B(2) and DiSEqC 1.1 port 1
the switch ends up on DiSEqC 1.1 port 5, just like was noted above with the Amiko
I looked at the recording and it clearly showed the DiSEqC 1.0 command as E0 10 38 F5 (Port B, 22 kHz on, Vertical), followed by DiSEqC 1.1 command E0 10 39 F0 (Port1).
I tried setting Repeat to 1 or even 2, no difference in the switch behavior. (It seems that Repeat adds the DiSEqC 1.0 command again after the DiSEqC 1.1 command

See the results on the attached pics. Note that those unshielded wires are getting a lot of 60Hz, which could possibly be a problem, but since I know the switch was not giving the expected results when testing with proper coax and LNBFs, I don't think it's likely to be the root of the problem.

So at this point I think it's fair to say that the problem is likely with the DiSEqC 1.1 switch, since:
- the DiSEqC commands I read seemed compliant with the on-screen settings and with the Eutelsat documents
- The results were the same with both receivers

One thing I want to test next is what the DiSEqC commands look like After going through a switch, and what happens if I reverse the switches, meaning having LNB - DiSEqC 1.1 - DiSEqC 1.0 - Receiver (which does not seem to be a supported configuration)

 

[Keith Brannen]

One thing I want to test next is what the DiSEqC commands look like After going through a switch, and what happens if I reverse the switches, meaning having LNB - DiSEqC 1.1 - DiSEqC 1.0 - Receiver (which does not seem to be a supported configuration)

Certainly does look like a problem with the switch, but I definitely would like to see the results of reversing the switches, as that seems to be how the receiver is sending the commands, 1.0 first, then 1.1. I don't think it makes any difference, but I would be inclined to put the 1.1 switch on port 1 of the 1.0 switch.

I have searched and have not found where anyone had a problem with the Pansat 8x1, but also did not find anyone cascading the switch (or if they are, then they aren't posting about a problem).

 

[a33]

A33, to answer your software question, I used Audacity, as suggested in the page I linked earlier, and fed the signal to the PC line-in jack. I inspected it first with a PC-based oscilloscope to make sure I was not going to fry the PC. (The oscilloscope made it hard to navigate the signal to zoom in on the DiSEqC commands, otherwise would have been a preferred method.

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

It seems that Repeat adds the DiSEqC 1.0 command again after the DiSEqC 1.1 command

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.


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?

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

As for your first tests, it seemed that the first time a diseqc 1.0 command was added to the 1.1 command, the switching went OK. And only with a second 1.0 command, the weird switching began. Has that, indeed, been a consistent outcome, also in your later tests?

Does your receiver have the posssibility of diseqc 1.1 commands going up to 16? Or only up to 8, as you wrote earlier?
If you can set 9 to 16, does it behave the same as with 1 to 8?

Did you notice that the 8/1 switch reacts to 1.0 commands (with 1.1 disabled)?

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

Greetz,
A33

 

[Brct203]

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

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

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.

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

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?

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

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

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!

 

[a33]

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.

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

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

 

[Brct203]

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

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

 

[a33]

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

I was expecting that the 1.1 switch responded to a certain bit (or combination of bits) in the 1.0 command, so your findings do not fully surprise me. Have not analized your data as to what bit(s) that would be.

A question first:
The 8/1 switch could react to the position bit, the option bit, the polarization bit, and the band bit (the 4 switching levels of diseqc 1.0).
Have you tried not only port 1-4 (i.e. position and option) differences, but also switching to different transponders H/V and high/low-band? For instance when choosing 1.0 port 2, with the 1.1 switch attached to it?
Are the results the same as in your last test, or do they alter somewhat?

Funny puzzle, isn't it?

greetz,
A33

 

[Brct203]

I was expecting that the 1.1 switch responded to a certain bit (or combination of bits) in the 1.0 command, so your findings do not fully surprise me. Have not analized your data as to what bit(s) that would be.

A question first:
The 8/1 switch could react to the position bit, the option bit, the polarization bit, and the band bit (the 4 switching levels of diseqc 1.0).
Have you tried not only port 1-4 (i.e. position and option) differences, but also switching to different transponders H/V and high/low-band? For instance when choosing 1.0 port 2, with the 1.1 switch attached to it?
Are the results the same as in your last test, or do they alter somewhat?

Funny puzzle, isn't it?

greetz,
A33

i have not thought of testing that... I did notice that 1.0 had those various levels (something I was not aware of prior to this exercise...). What I can say is that usually within a test I did not change low/high band or 22k or pol, but might have changed between tests. I'll test that later tonight or tomorrow

 

[a33]

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.

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