342 replies to this topic

[Huevos]

 

config.sec.delay_after_enable_voltage_before_motor_command let's us set sufficient time for the LNB to boot from cold where the LNB/switch is not using a power inserter or PSU.

I see several items that might help, even though their name doesn't directly suggests so.

 

Beware that "voltage" means "voltage change" here and not "power on".

 

Please suggest which so I can test.

 

But there is nothing related to command queues, only things sent to a conventional system where the cable is not shared.

[Erik Slagter]

That's where the confusion comes from. These properties have names that suggest they're only used on conventional, but that's not true. Even though SCR doesn't use DiSEqC, they are using the lower layers of DiSEqC (signalling, framing), so many of the code is shared. The SCR code was added after the DiSEqC code and the names of the properties weren't updated (what's new). So I really think one or more of these will give the solution.

 

Internally, SCR just adds not-completely-standard-adhering DiSEqC commands to the SEC queue in enigma. That's why it's quite easy to implement it, no specific hardware or driver support is required.

[Huevos]

 

Above you can see two tuners trying to tune, the tuner 0-A succeeds with status 1f, the tuner 1-B fails with status 7.
Then tuner B, tries several times, and it never tunes. It always fails with last status reported from tuner 7.
So the real question here is: Why tuner never got LOCK? Why re-tune failed?

In case you wonder what 7 or 1f is:
7 = FE_HAS_SIGNAL | FE_HAS_CARRIER | FE_HAS_VITERBI
1f = FE_HAS_LOCK | FE_HAS_SYNC | FE_HAS_VITERBI | FE_HAS_CARRIER | FE_HAS_SIGNAL

That is plain weird. It suggests a signal is seen but can't be locked to. OTOH it suggests the '7' options are simply always on, because the tuner can't detect them (or the driver doesn't export this information).

 

And like you said, the first try failing can be explained, the next not. Unless not only the first tuner but all tuners are retried, then you get the same collision over and over again.

 

Ok, just so everyone can understand this better...

 

When the LNB first boots from cold (no voltage) the output is identical to a Universal LNB in low band vertical. This is so people without a Unicable compatible meter can adjust the dish.

 

Once the control word is sent to the LNB the display clears and only one user band shows on the spectrum. From that point on only active user bands ever show.

 

This means there is an active "wrong" signal where the "correct" user band will appear on successful tuning of the LNB.

 

Before controlword is sent:

 before-controlword.jpg   118.28KB   1 downloads

 

After controlword is sent:

 after-controlword.jpg   64.41KB   1 downloads

[littlesat]

So actually it can somehow be checked when the LNB did reboot as soon you directly tuned in and receive the transponder and than once receiver switch to unicable/jess....?

[Huevos]

So actually it can somehow be checked when the LNB did reboot as soon you directly tuned in and receive the transponder and than once receiver switch to unicable/jess....?

My tests show that either...

• The control word is junk, i.e. multiple control words without any "guard silence" or,
• The control word is not sent at all on the first attempt.

 

Since others don't seem to suffer the bug, the second is unlikely. But people that don't seem to be able to reproduce the bug have not supplied logs. In my logs, even when the bug seemed to be fixed there were multiple attempts to retune before the LNB was successfully tuned.

Edited by Huevos, 7 October 2018 - 20:23.

[littlesat]

So at the end it tuned... after ‘tons’ of retunes...?
Wierd as I can imagine the lnb may need Some time to proces a control word... and when it needs time a ‘simple’ delay between them should solve it... do you have a scope to see the real ‘diseqc’ like controls?

Edited by littlesat, 8 October 2018 - 06:33.

[Huevos]

With the current cpp code sometimes it will tune after several minutes. Other times not at all.

If you set 3 recordings, none start. Cancel one and the other 2 start immediately.

The analyser doesn't show diseqc commands.

[littlesat]

And the one sec delay work-a-round in recordings.py does not help

[Huevos]

And the one sec delay work-a-round in recordings.py does not help

Yes, the one second record delay works for me, but that is just a workaround. I thought Erik/Athoik were in favour of finding the root cause.

[WanWizard]

Finding and fixing the root cause is always preferable.

[littlesat]

When the second pause work-a-round works it looks like the diseqc commands do collapse somehow... maybe we should arrange that per lnb input only one diseqc command can be given at once...
The one second work-a-round also solves (work-a-rounds) a different issue regarding softcam issues....

Edited by littlesat, 8 October 2018 - 11:29.

[Huevos]

When the second pause work-a-round works it looks like the diseqc commands do collapse somehow... maybe we should arrange that per lnb input only one diseqc command can be given at once...

That still wouldn't work because you might join 2 tuners together with a splitter. So, one cable comes from the LNB and splits to 2 cables at the STB to supply multiple tuners.

[littlesat]

When are you doing that.... but also in one cable you could have multiple receivers (and between two receivers given commands over the cable fully independently) and also they can collide.... so the random idea I noticed here is not that bad... so I’m also afraid there is some kind of totally incorrect design here...

[Erik Slagter]

Ok, just so everyone can understand this better...
 
When the LNB first boots from cold (no voltage) the output is identical to a Universal LNB in low band vertical. This is so people without a Unicable compatible meter can adjust the dish.
 
Once the control word is sent to the LNB the display clears and only one user band shows on the spectrum. From that point on only active user bands ever show.
 
This means there is an active "wrong" signal where the "correct" user band will appear on successful tuning of the LNB.
 
Before controlword is sent:
before-controlword.jpg
 
After controlword is sent:
after-controlword.jpg

Ok clear, thanks for the explanation.

[Erik Slagter]

My tests show that either...

• The control word is junk, i.e. multiple control words without any "guard silence" or,
• The control word is not sent at all on the first attempt.

Since others don't seem to suffer the bug, the second is unlikely. But people that don't seem to be able to reproduce the bug have not supplied logs. In my logs, even when the bug seemed to be fixed there were multiple attempts to retune before the LNB was successfully tuned.

I would be nice to have a DiSEqC protocol analyser here

 

If in the meantime there hasn't been any progress, I might have a go on friday, planning two recordings from the same switch at the same time.

[Erik Slagter]

 

And the one sec delay work-a-round in recordings.py does not help

Yes, the one second record delay works for me, but that is just a workaround. I thought Erik/Athoik were in favour of finding the root cause.

 

 

Finding and fixing the root cause is always preferable.

 

If only because the workaround introduces delays. We don't want to go where dvbadenin used to go, adding "random" delays extensively until the whole tuning becomes sluggish.

[littlesat]

You ca also have two or more boxes looped on one cable that can collide... so we always need some kind of retry/resend mechanism.... and sometimes a randomized is used in such situation so one box does rarely resend something at the same time as another

[Erik Slagter]

You ca also have two or more boxes looped on one cable that can collide... so we always need some kind of retry/resend mechanism.... and sometimes a randomized is used in such situation so one box does rarely resend something at the same time as another

Why don't you first read the standards before repeating this over and over again. What we need to do it adhere to the standards, not starting with working around somwething we really don't completely understand.

[Huevos]

Did you read the jess.pdf I posted? It says timeslots are one second long and only one resend per slot and that resend occurs at a random point withon the one second time slot.

[littlesat]

See the random is in the spec...