Jump to content


Photo

Unicable / simultaneous recordings


  • Please log in to reply
342 replies to this topic

Re: Unicable / simultaneous recordings #181 Huevos

  • PLi® Contributor
  • 4,680 posts

+165
Excellent

Posted 7 October 2018 - 12:15

 

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.



Re: Unicable / simultaneous recordings #182 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 7 October 2018 - 12:24

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.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Unicable / simultaneous recordings #183 Huevos

  • PLi® Contributor
  • 4,680 posts

+165
Excellent

Posted 7 October 2018 - 12:55

 

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:

Attached File  before-controlword.jpg   118.28KB   1 downloads

 

After controlword is sent:

Attached File  after-controlword.jpg   64.41KB   1 downloads



Re: Unicable / simultaneous recordings #184 littlesat

  • PLi® Core member
  • 57,206 posts

+700
Excellent

Posted 7 October 2018 - 15:07

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

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Unicable / simultaneous recordings #185 Huevos

  • PLi® Contributor
  • 4,680 posts

+165
Excellent

Posted 7 October 2018 - 20:22

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.


Re: Unicable / simultaneous recordings #186 littlesat

  • PLi® Core member
  • 57,206 posts

+700
Excellent

Posted 8 October 2018 - 06:31

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.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Unicable / simultaneous recordings #187 Huevos

  • PLi® Contributor
  • 4,680 posts

+165
Excellent

Posted 8 October 2018 - 07:31

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.

Re: Unicable / simultaneous recordings #188 littlesat

  • PLi® Core member
  • 57,206 posts

+700
Excellent

Posted 8 October 2018 - 07:35

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

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Unicable / simultaneous recordings #189 Huevos

  • PLi® Contributor
  • 4,680 posts

+165
Excellent

Posted 8 October 2018 - 09:45

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.



Re: Unicable / simultaneous recordings #190 WanWizard

  • PLi® Core member
  • 70,562 posts

+1,813
Excellent

Posted 8 October 2018 - 09:46

Finding and fixing the root cause is always preferable. ;)


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: Unicable / simultaneous recordings #191 littlesat

  • PLi® Core member
  • 57,206 posts

+700
Excellent

Posted 8 October 2018 - 11:27

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.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Unicable / simultaneous recordings #192 Huevos

  • PLi® Contributor
  • 4,680 posts

+165
Excellent

Posted 8 October 2018 - 13:14

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.



Re: Unicable / simultaneous recordings #193 littlesat

  • PLi® Core member
  • 57,206 posts

+700
Excellent

Posted 8 October 2018 - 16:12

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

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Unicable / simultaneous recordings #194 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 8 October 2018 - 18:33

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:
attachicon.gifbefore-controlword.jpg
 
After controlword is sent:
attachicon.gifafter-controlword.jpg

Ok clear, thanks for the explanation.

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Unicable / simultaneous recordings #195 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 8 October 2018 - 18:36

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.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Unicable / simultaneous recordings #196 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 8 October 2018 - 18:38

 

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.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Unicable / simultaneous recordings #197 littlesat

  • PLi® Core member
  • 57,206 posts

+700
Excellent

Posted 8 October 2018 - 18:42

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

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Unicable / simultaneous recordings #198 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 8 October 2018 - 18:47

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.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Unicable / simultaneous recordings #199 Huevos

  • PLi® Contributor
  • 4,680 posts

+165
Excellent

Posted 8 October 2018 - 19:09

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.

Re: Unicable / simultaneous recordings #200 littlesat

  • PLi® Core member
  • 57,206 posts

+700
Excellent

Posted 8 October 2018 - 19:11

See the random is in the spec...

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W



6 user(s) are reading this topic

0 members, 6 guests, 0 anonymous users