DVB S/S2 cards on legacy PCI interface. (1 Viewer)

[Kotik]

EDIT:
I am having a look and I wonder is it possible to add a delay?

[2016-10-17 01:11:25,474] [Log ] [21 ] [INFO ] - DiSEqC: goto position 4

Delay 3 seconds.

[2016-10-17 01:11:25,896] [Log ] [21 ] [INFO ] - dvbubmiting tunerequest Channel:TVCI new subChannel:0

Cause the way I understand it now we send the move command to the motor and the tunerequest command exactly at the same moment.

This way I could try if this will resolve the issue.

 

[mm1352000]

I am having a look and I wonder is it possible to add a delay?

In short: you'd have to modify the code if you want to add a delay.

 

[Kotik]

That is what i feared.....

I am currently emailing TBS to see if there is something that can be done on the driver level.


Sent from my GT-I9205 using Tapatalk

 

[Kotik]

So latest info.

I resolved the No Signal error by a fresh installation of MP which resulted in fresh satellites positions. I also was able to find out why the dish would move to the wrong direction "randomly",
it is not random after all, if while MP TV Service is running u move the dish manually or with another program and then instruct MP to move the dish to a predefined position then the motor is getting confused as a result the dish will move half way or move to a wrong direction. In order to avoid this issue i am now always stopping TV Service if i want to micro adjust the dish manually.

I also finally fully understand why i am getting a No PMT Found error.

Correct me if i am wrong.

I tested 2 cards and both had issues regarding DiseqC motor within MP, both are actually moving the dish perfectly fine!

But they both fail when it comes to channel switching. It all comes down to the LockInOnSignal time out implementation of the manufacturer.

1. SkystarHD2, has a short time out, meaning, it would give up trying to lock in very fast. As so it would always result in a No Signal error that left the user with the ability to re tune the same channel one more time and be able to successfully watch TV.

2. TBS 6902, has a huge time out, meaning,it will fight till the end (actually till it finds signal) As a result it is prone into reporting a successful Lock On the moment it finds a similar frequency with the one it is actually being instructed to search for. This part is beyond me since i don't know exactly the method being used to LockInOn signal. The reason for that is either cause the tuner doesn't get strict information regarding its new tuning details, or because these details are not meant to be sent to the tuner before the tuner actually arrives to the proper position. As a result the tuner will lock on a totally wrong position while the dish is still moving and will report to MP a successful LockInOn, the moment MP receives this info it will start looking for PMT but there wont be any PMT to be found cause the dish is still moving.

To prove this theory i added two satellites that are far away from each other, this way i would increase the chances of TBS locking into the wrong satellite frequency, so i went for 35.9E and 19.2E, i then measured the time my motor needs to cover this distance by sending a simple GoToX command manually from the MP DiseqC motor tab and observing the dish movement, the result is 12 seconds. I then instructed Mp to switch to a channel from 35.9E to 19.2E, if my theory was right then the Lock On would appear in tv server logs earlier than the 12 second mark, this would indicate that the lock on happened at the wrong position and during dish movement. Below are the results:


[2016-10-18 13:00:41,722] [Log ] [20 ] [INFO ] - dvbs: TuneVBS:tv:BetaDigital DMAX Freq:12480000 ONID:133 TSID:33 SID:63 PMT:0x6C FTA:True LCN:10000 SymbolRate:27500 Modulation:ModNotSet Polarisation:LinearV InnerFecRate:Rate3_4 DisEqc:None band:Universal Pilot:NotSet RollOff:NotSet
[2016-10-18 13:00:41,722] [Log ] [20 ] [INFO ] - dvbs: TuneVBS:tv:BetaDigital DMAX Freq:12480000 ONID:133 TSID:33 SID:63 PMT:0x6C FTA:True LCN:10000 SymbolRate:27500 Modulation:ModNotSet Polarisation:LinearV InnerFecRate:Rate3_4 DisEqc:None band:Universal Pilot:NotSet RollOff:NotSet
[2016-10-18 13:00:41,722] [Log ] [20 ] [INFO ] - dvb:GetNewSubChannel:0 #0
[2016-10-18 13:00:41,722] [Log ] [20 ] [INFO ] - TvDvbChannel ctor new subchIndex:0
[2016-10-18 13:00:41,722] [Log ] [20 ] [INFO ] - card: AddTuneEvent card: 4 / subch: 0
[2016-10-18 13:00:41,737] [Log ] [20 ] [INFO ] - LNB low:9750 hi:10600 switch:11700
[2016-10-18 13:00:41,737] [Log ] [20 ] [INFO ] - ProfRed DVB-S2 modulation set to:ModNotDefined
[2016-10-18 13:00:41,737] [Log ] [20 ] [INFO ] - ProfRed DVB-S2 Pilot set to:NotSet
[2016-10-18 13:00:41,737] [Log ] [20 ] [INFO ] - ProfRed DVB-S2 RollOff set to:NotSet
[2016-10-18 13:00:41,737] [Log ] [20 ] [INFO ] - ProfRed DVB-S2 fec set to:Rate3_4
[2016-10-18 13:00:41,753] [Log ] [20 ] [INFO ] - dvbs:channel modulation is set to ModNotDefined
[2016-10-18 13:00:41,753] [Log ] [20 ] [INFO ] - dvbs:channel FECRate is set to Rate3_4
[2016-10-18 13:00:41,753] [Log ] [20 ] [INFO ] - ProfRed: already no diseqc used
[2016-10-18 13:00:41,878] [Log ] [20 ] [INFO ] - DiSEqC: goto position 3
[2016-10-18 13:00:41,972] [Log ] [20 ] [INFO ] - ProfRed: setdiseqc returned:0
[2016-10-18 13:00:42,175] [Log ] [20 ] [INFO ] - ProfRed: setdiseqc returned:0
[2016-10-18 13:00:42,284] [Log ] [20 ] [INFO ] - dvbubmiting tunerequest ChannelMAX subChannel:0
[2016-10-18 13:00:42,284] [Log ] [20 ] [INFO ] - dvb:using existing subchannel:0
[2016-10-18 13:00:42,284] [Log ] [20 ] [INFO ] - dvbubmit tunerequest size:1 new:0
[2016-10-18 13:00:42,284] [Log ] [20 ] [INFO ] - subch:0 OnBeforeTune
[2016-10-18 13:00:42,284] [Log ] [20 ] [INFO ] - dvbubmit tunerequest calling put_TuneRequest
[2016-10-18 13:00:44,613] [Log ] [20 ] [INFO ] - dvbubmit tunerequest done calling put_TuneRequest
[2016-10-18 13:00:44,613] [Log ] [20 ] [INFO ] - subch:0 OnAfterTune
[2016-10-18 13:00:44,613] [Log ] [20 ] [INFO ] - RunGraph
[2016-10-18 13:00:44,613] [Log ] [20 ] [INFO ] - subch:0 OnGraphStart
[2016-10-18 13:00:44,613] [Log ] [20 ] [INFO ] - dvb: RunGraph
[2016-10-18 13:00:45,753] [Log ] [20 ] [INFO ] - dvb: LockInOnSignal ok
[2016-10-18 13:00:45,753] [Log ] [20 ] [INFO ] - subch:0 OnGraphStarted
[2016-10-18 13:00:45,753] [Log ] [20 ] [INFO ] - subch:0 SetupPmtGrabberid 6C sid:3F
[2016-10-18 13:00:45,769] [Log ] [20 ] [INFO ] - subch:0 set pmt grabber pmt:6C sid:3F
[2016-10-18 13:00:45,769] [Log ] [20 ] [DEBUG] - TimeShifter.OnAfterTune: resetting audio/video time
[2016-10-18 13:00:45,769] [Log ] [20 ] [DEBUG] - WaitForPMT: Waiting for PMT 6C
[2016-10-18 13:00:55,770] [Log ] [20 ] [DEBUG] - WaitForPMT: Timed out waiting for PMT after 10.0010931 seconds. Increase the PMT timeout value?
[2016-10-18 13:00:55,770] [Log ] [20 ] [DEBUG] - Setting to 0 to search for new PMT.
[2016-10-18 13:00:55,770] [Log ] [20 ] [INFO ] - subch:0 SetupPmtGrabberid 0 sid:3F
[2016-10-18 13:00:55,770] [Log ] [20 ] [INFO ] - subch:0 set pmt grabber pmt:0 sid:3F
[2016-10-18 13:00:55,770] [Log ] [20 ] [DEBUG] - TimeShifter.OnAfterTune: resetting audio/video time
[2016-10-18 13:00:55,786] [Log ] [20 ] [DEBUG] - WaitForPMT: Waiting for PMT 0
[2016-10-18 13:01:05,787] [Log ] [20 ] [DEBUG] - WaitForPMT: Timed out waiting for PMT after 10.0010899 seconds. Increase the PMT timeout value?
[2016-10-18 13:01:05,787] [Log ] [20 ] [DEBUG] - Setting to 0 to search for new PMT.

As u can see the tuner locked on approximately 5 seconds after the DiSEqC: goto position 3 which confirms my theory.

After saying all that i got some questions:

1. Are there any other cards out there that are using a somehow different logic regarding the LockInOn mechanism? Cause as u can see Low Time Out will result in No Signal and High Time Out will result in No PMT, so i would like to know is there another way? In our Wiki we list some TBS cards that are working with DiseqC motor, i would love to know how? cause one thing is for sure, MP behavior remains the same no matter the card. MP will send tune request 250ms right after the GoToX command. The only other possible mechanism i can think of that would work is if the card would re check signal status 500ms after initial lock and if signal is found still stable it would THEN report a successful lock, otherwise it would try to re lock.

2. Are u sure that adding a delay would solve these issues? The delay would then have to be dynamic and depend on the degree difference between the satellites of the two channels. Adding a small static delay would improve the issue between satellites that are located close to each other, but would it NOT also increase tune times between channels located on the same satellite?

Thanx in advance.

 

[mm1352000]

I resolved the No Signal error by a fresh installation of MP which resulted in fresh satellites positions. I also was able to find out why the dish would move to the wrong direction "randomly"...

Great.
Strange that the motor would get confused in that way though. I would've thought that the motor would keep track of its position in terms of degrees/steps in rotation and/or elevation relative to a reference position, and that each stored position would just be a count of steps away from that same reference position. Therefore the motor would be able to go to any stored position from any arbitrary position with great precision. Seems I'm wrong.

1. SkystarHD2, has a short time out, meaning, it would give up trying to lock in very fast. As so it would always result in a No Signal error that left the user with the ability to re tune the same channel one more time and be able to successfully watch TV.

Well, the SkyStar HD2 puzzles me. We've previously discussed the driver's "relock monitor" variables. I don't understand why those variables don't seem to have any effect for you.

This part is beyond me since i don't know exactly the method being used to LockInOn signal.

From TV Server's perspective it's very simple. Tuners provide some information about the connected signal state:

• is the tuner locked onto signal (yes/no)
• is signal detected [even if not locked] (yes/no)
  
• strength
• quality

The method of locking on signal is simply to check the first detail ("is the tuner locked...") every 20 ms until the value changes to "yes". There's also a time limit which is the tune time-out setting that we've previously discussed.

Code here:
https://github.com/MediaPortal/Medi...tations/DVB/Graphs/TvCardDvbBase.cs#L793-L835

I can't tell you anything about the internal driver or hardware logic that sets the values of the above details.

The reason for that is either cause the tuner doesn't get strict information regarding its new tuning details...

We pass on all the details that you see in the user interface: frequency, polarisation, symbol rate etc. This should be enough to uniquely identify a transponder unless the transponder details on 2 satellites are identical.

I don't know a lot about the internal workings of tuner drivers and their hardware, but I do know that some tuners auto-detect some parameters instead of using the details that we provide. We can't force the tuner to use specific details.

1. Are there any other cards out there that are using a somehow different logic regarding the LockInOn mechanism?

From the TV Server side: it's always the same method. There are no relevant differences from tuner to tuner.
From the tuner side (setting the value of signal details, and the tuning algorithm in general): I have no comment because tuner drivers are closed source, which means I can't check and compare their code.

Cause as u can see Low Time Out will result in No Signal and High Time Out will result in No PMT...

With the greatest respect, I think this view is too simple. The reality is more complex. For example, I've tried to explain that some tuners will try to lock on signal repeatedly/continuously. For those tuners, high time out should result in success.

...so i would like to know is there another way?

I've already answered this question as best as I can in this and other replies. Sorry, I have nothing to add.

In our Wiki we list some TBS cards that are working with DiseqC motor, i would love to know how?

The wiki's "DiSEqC - motor" column is not a claim that certain tuners are working with DiSEqC motors. Rather, it's an indication that TV Server has the capacity to send DiSEqC motor control commands for those tuners. The "working" part is your interpretation. In reality, we don't have the access or ability to individually test all those tuners. In fact, I don't think any of the active team members currently have a motor.

cause one thing is for sure, MP behavior remains the same no matter the card.

Yes, that's true. Tuner behaviour varies, and we don't have the ability to test all tuners.

The only other possible mechanism i can think of...

Yes, I agree... but this is not in our control.

2. Are u sure that adding a delay would solve these issues?

I don't think I've said that adding a delay would solve the problem. You asked if it would be possible to add delay, and I answered that code modifications would be required. That's all. Please keep in mind that I've never owned a motor myself. Therefore even if I said something like that, I should never be so confident that I would say that I'm sure.

The delay would then have to be dynamic and depend on the degree difference between the satellites of the two channels.

We've talked about this before:
https://forum.team-mediaportal.com/...d2-need-a-new-card.134744/page-2#post-1190214

Adding a small static delay would improve the issue between satellites that are located close to each other, but would it NOT also increase tune times between channels located on the same satellite?

No. TV Server is smart enough to know that it doesn't need to resend the "goto X" command when the motor/dish is already be in the right position. If you added the delay where the commands are sent, the delay would only be applied when the motor has to move.

 

[Kotik]

Hello @mm1352000

Thanx for the reply, i am currently trying to see if i can work the issue out with TBS, on a driver level.

They instructed me in testing DVBDream and indeed there everything is working, i am still trying to see if they are willing to review their driver's LockOn mechanism. Somehow i dont feel that anything positive will come up from their side. They claim that their tuners just follow DiseqC instructions and if it works in one program but not in another then i have to resolve the issue with the program itself. I dont blame them, after all DVBDream seems to be the only software that actually respects motor movement and applies a dynamic delay before sending tuning details.

Meanwhile i started working on a solution of my own. I researched and find out board schematics for my DiseqC motor, i already got myself a small 12V relay switch that i am planning into adding to the board. This relay will control the LNB circuit, if the motor is not moving the circuit will be in a CLOSED state and as so allow the LNB to be powered on but if the motor starts moving then the relay will instantly open the circuit and as a result power off completelly the LNB, once movement is over the relay will return into a closed state and the LNB will be powerd up once again. Detecting motor movement is simple enough since the motor itself has a board controlling its West/East movement with 2 relays. All i have to do is connect my relay to the board and detect movement instructions from the chip to the motor's two relays.

Essentially what i will achieve is an automated Power On/Off LNB dependant on motor movement. This will, as u can understand, prevent the tuner from locking anywhere while the motor is moving.

As a backup plan i started looking at TVE3.0 source code from master branch, but i dont seem to be able to find anywhere the 250ms hardcoded delay regarding tuning details. Would u please point me out to the right direction as i would like to increase the delay to 3000ms and see how it will pan out. FYI setting this delay to 3000 ms in ProgDVB (delay for DiseqC commands) results in sucesfully channel switching there.

Thanx in advance.

Sent from my GT-I9205 using Tapatalk

 

[mm1352000]

They instructed me in testing...

Mmmm, it's not their DiSEqC method that they would have to fix. There doesn't seem to be anything wrong with that. If anything, it's their tuning method. In my opinion they should stick to the provided tuning parameters.

Consider the DMAX to THT transition again:
1. DMAX
19.2E
12480 V DVB-S
MPEG-2 27500
3/4

2. THT
13.0E
11034 V DVB-S
MPEG-2 27500
3/4

If your theory is correct (...and I can only assume that it is, because I haven't got any better theory! ), I guess the reason for the failure is that the tuner is locking onto 19.2E 11038.00 V DVB-S QPSK 22000 5/6 (link). This guess is based on the similarity of the frequencies. However the symbol rates and FEC code rates don't match. Therefore I would say that the tuner should be skipping/ignoring it.

Meanwhile i started working on a solution of my own.

Nice idea.

As a backup plan i started looking at TVE3.0 source code from master branch, but i dont seem to be able to find anywhere the 250ms hardcoded delay regarding tuning details. Would u please point me out to the right direction as i would like to increase the delay to 3000ms and see how it will pan out. FYI setting this delay to 3000 ms in ProgDVB (delay for DiseqC commands) results in sucesfully channel switching there.

Sure!
It's here:
https://github.com/MediaPortal/Medi...entations/DVB/DisEqC/DiSEqCMotor.cs#L432-L452

There you can see:

• first go-to command
  
• 100 ms delay
• repeated go-to command
• 100 ms delay

According to the DiSEqC specifications each message bit takes 1.5 ms to transmit. Since each go-to command contains 4 bytes (=> 32 bits), each command will take 48 ms to transmit. The driver may also add its own delays.

In that class/function you have access to _currentPosition - TV Server's record of the motor's current position. That will be correct as long as you don't use some external agent to move the motor. Since you know the mappings between position numbers and longitudes (eg. position #1 is 19.2E), you could calculate approximately how far the motor has to move. Therefore you could also make the delay proportionate to the distance.

Note that the motor will move faster or slower depending on the polarisation of the currently tuned transponder, because that determines the voltage on the cable. If the tuner is tuned to a horizontal or circular left transponder the voltage will be 18 V; otherwise the voltage will be 13 V (=> slower movement). That class/function does not have access to the current transponder details, so it would be safest to assume slow movement. However if wanted you could pass in the polarisation as an extra parameter.

 

[Kotik]

I like what u did there, finding similar frequencies in the movement path might prove my theory even more. It might actually pressure TBS in having a more serious look.

To support ur assumption i can explain to u how the same issue appears in ProgDVB. There i am able to see Signal Level and Quality indicators while the dish is moving! Which greatly helps me in seeing what the card is actually reporting while dish is moving. I can confirm that if during movement the Quality elevel jumps above 50% then ProgDVB will instantly try to search for PMT, and of course fail cause 1 second later the quality level drops to 0% since the dish is moving. ProgDVB behaves the same way with MP, i dont even need to test things in MP. If it fails in ProgDVB it will always fail in MP.

I am going to apply ur frequency hunting theory on other sats since i got a huge list of failing channels already at hand.
--- Post updated ---
@mm1352000 look what I found

From
36.0E 12690.00 H DVB-S QPSK 1450 5/6
To
19.2E 12480.00 H DVB-S QPSK 27500 3/4
Will always fail, the reason.........
31.5E 12480.00 V DVB-S2 8PSK 30000 3/4

Damn I am mad.
--- Post updated ---
It seems they are totally ignoring FecRate values, Polarity values and other things aswell, they only respect the frequency value.. wtf is this one? Are they serious?

 

[mm1352000]

Damn I am mad.
It seems they are totally ignoring FecRate values, Polarity values and other things aswell, they only respect the frequency value.. wtf is this one? Are they serious?

Please don't send an angry email to TBS without establishing the facts. My explanation is just a theory. I could be wrong.

Please also remember what I said about some tuner hardware/drivers auto-detecting certain parameters. It's very possible that TBS are not able to specify parameters like the symbol rate and FEC code rate because the hardware always auto-detects it and can't be forced.
[edit: ...and TBS would not be the only company affected by such a situation.]

 

[Kotik]

I wont send an angry email without 1st making a huge list of information that proves my point, my previous findings prove ur theory, it is as good as a prove that they will get, they will have to test it out themselves if they want a better prove, I cannot prove something to someone that is not willing to believe me in the 1st place.

Having said that, a card that costs 80 euro should be at least able to respect tune parameters. But I will make sure to back up this theory with as much info as I can.

To be honest, for me it is currently crystal clear. It is up to them now to either correct the issue, if it can be corrected, via drivers, or ignore my findings and lose a customer.
--- Post updated ---
@mm1352000 check this out http://www.tbsdtv.com/forum/viewtopic.php?f=183&t=10115, I will now add more info there, but as u can see I already pointed them to that direction.