239 replies to this topic

[MCelliotG]

 

 

For me the image quality of Mut @ nt 51HD or Zgemma H7S/C  is above quality that Octagon SF 4008 lends.
Practically if this bug does not exist for the users that use motorized antenna, they would be the two devices with more quotation in market in general. Better than those of VU and of other marks.

 

 

And this tested on a real Sony KD-55A1 TV OLED

 

Agreed fully, I own a Mutant and apart from the very serious tuner bugs, the receiver is top notch.

And where did you see that I was searching for revenge, I wonder! I only reply to ridiculous statements.

Whoever blamed the motors, it's simply irrational to claim that it's the motors' problem and not the driver's where it's clearly the support the manufacturers offer in this case.

Vu and Octagon have better support for the tuner driver, Octagon reports the signal correctly, Zgemma/Mutant has a very faulty driver with the motor bug on top of that. Nobody but Dreambox has blindscan. That's the case now and it's all it is.

Edited by MCelliotG, 9 March 2018 - 01:20.

[el bandido]

Does this motor bug exist in both USALS and diseqc 1.2 modes?

[MCelliotG]

Yes, same behaviour. The bug has three different issues as far as I've seen:

1. on adjacent satellites (up to 3 degrees) no problem both west and east

2. on distant satellites

a) it will either go to the position but not find lock up to 50 seconds or so

b ) it will either begin moving to the position but stop after a couple of seconds

c) it will either move to the position but instead of having a constant speed, it will slow down severely.

This behaviour seems to be less apparent when the dish moves from east to west (different voltage) and more severe the other way around.

 

So far each motor reported has these issues, some all of these, some a few of these. My motor is case b for instance. Other motors are case a and c.

Either way it seems that the driver has issues with the voltages, but to blame the motors is out of the question when any other receiver will move them correctly!

Edited by MCelliotG, 9 March 2018 - 11:52.

[el bandido]

Has anyone tested for this problem using a diseqc 1.2 dish mover or dish positioner such as a Vbox or Gbox?
 

I do not think there is anything wrong with the software. It looks like more of a power supply problem. The pictures I can find of the HD51 show an external 12 volt 2.5 amp power supply rating. Some have said they do not have this problem, so I wonder if the power supply is defective or weak?

I made a very basic tester so the power requirements of lnbs and switches could be measured. This tester only costs a few dollars to make, and it may show what the problem is if it could be installed on the tuner output of the HD51. I will attach a couple of pictures showing how it works.
 

Attached Files

•  Volt_Ma_Tester.jpg   193.72KB   8 downloads
•  Volt_Ma_Tester1.jpg.jpg   151.96KB   8 downloads

[dzumba]

 

It looks like more of a power supply problem. 
 

There is no power problem!, with all the software in 2016, there are no problems, this bug comes out in the middle of 2017. It is similar to Zgemma H7S! It is also noticeable for Formuler F,1 that does not have a s2x tuner!

Nearly half of the Linux receivers are experiencing problems with usals and DISEqC 1.2 protocols after mid-2017!

[Neo64]

Something new for the function issue of USALS?????

[kalehrl]

You can work around this issue.

init 4

Change a line which looks like this:

config.Nims.0.advanced.lnb.1.powerMeasurement=true

to:

config.Nims.0.advanced.lnb.1.powerMeasurement=false

then:

init 3

[Huevos]

 

 

It looks like more of a power supply problem. 
 

There is no power problem!, with all the software in 2016, there are no problems, this bug comes out in the middle of 2017. It is similar to Zgemma H7S! It is also noticeable for Formuler F,1 that does not have a s2x tuner!

Nearly half of the Linux receivers are experiencing problems with usals and DISEqC 1.2 protocols after mid-2017!

 

Please be specific. Making wild statements like this is no help finding the problem. I own Vu+ Uno, Ultimo, Duo, Solo2, Solo4K, Os Mini+, OS Mega, SF4008, LX3, etc, and have not motor problems on any.

[dzumba]

MutantHD51,Zgemma7S,FormulerF1

 

I did an experiment! I edited the config file:

I changed

config.Nims.0.powerMeasurement =false

as

config.Nims.0.powerMeasurement = true

and starts working normally with a OpenPLi, with a note while the antenna rotates, an inscription stands on the screen for Tune Failed!

[MCelliotG]

I can confirm that the power measurement workaround works on OpenPLI (only). We lose the moving dish notification but works very well.

However only when usals is set, on more complex combinations there are several problems.

This could work for now, however it is not a fix for the faulty driver, simply a temporary solution!

 

I wonder, why is not the power measurement configurable as an option in the tuner settings menu?

[Huevos]

I wonder, why is not the power measurement configurable as an option in the tuner settings menu?

Because the relevant /proc's are missing, and those settings only show if they are present. And anyway don't forget, this is just a workaround.

[dzumba]

Fehler!

Edited by dzumba, 21 March 2018 - 06:17.

[Robinson]

I will test this workaround when I get my box back from a friend of mine.

Anyway, I am pretty sure powerMeasurement set to false can have some negative impact on other things. Has someone found what they are?

[MCelliotG]

Exactly, this is why I specifically say it's a workaround, not a fix or a permanent solution. The setting works fine with usals, in fact exceptionally well, however you can't see where the dish is moving.

But when you have a more complex tuner configuration problems begin.

In my case I had some satellites set with usals and some other stored manually. This created multiple entries with the powermeasurement value. If all set to true, the motor works until you reboot your machine. Then the tuner becomes inactive and you have to revert your settings to get it back.

 

Anyway, still hoping a new driver will appear at some point, since Mutant and the rest that use the same generic utterly problematic Silabs driver revision seem more than unwilling to provide a real solution....

[Neo64]

We will wait carefully, because if they want to sell their tackle they should press their butts a little.  

[WTE]

@dzumba

Great find that you proven it was not a driver issue but enigma bug.

 

It seems PLi works fast as the new fix solves the problems finally with the motor.

I hope that a new image will been available soon with the latest fixes

[Huevos]

@dzumba

Great find that you proven it was not a driver issue but enigma bug.

Actually the commit proves it was a driver issue.

 

the dish is
assumed to have reached the desired orbital position when it has had a
lock for 5 consecutive times.

However, this only works assuming that frontend drivers (or hardware)
will keep trying to get a lock forever, without using any internal
timeouts.
This is not the case. Most frontend drivers will eventually timeout,
reporting an FE_TIMEDOUT event.

[WTE]

 

@dzumba

Great find that you proven it was not a driver issue but enigma bug.

Actually the commit proves it was a driver issue.

 

the dish is
assumed to have reached the desired orbital position when it has had a
lock for 5 consecutive times.

However, this only works assuming that frontend drivers (or hardware)
will keep trying to get a lock forever, without using any internal
timeouts.
This is not the case. Most frontend drivers will eventually timeout,
reporting an FE_TIMEDOUT event.

 

 

The frontend should not try to lock continues, it seems many manufactures add this hack to workaround the enigma bug.

I am happy to see this is not need anymore and that frontend will stop lock when e2 request it.
 

Edited by WTE, 23 March 2018 - 14:18.

[MCelliotG]

And how convenient it is to fault enigma2 and call this a bug instead of adding pressure to the manufacturers to issue a driver update from Silabs, that is already implemented in Dreamboxes....

Workarounds work only for specific tuner setups. So, let's simply set the powermeasurement to true and

1. have non-usals setups messed up. When you have a usals and a non-usals combination setting the measurement to true renders the tuner inoperative after a reboot...

2. have complex setups messed up. When you have a usals motor in conjuction with a single satellite, the latter stops working properly.

 

Or even better

Let's have this workaround and never expect Mutant and its variants to show live tuner values properly (they only show 10600 and 9750 as frequencies), something that both Octagon and Vu+ have issued and fixed with guess what... a driver update

And on top of that

Let's never expect Mutant and non-Dreambox receivers push Silabs to issue a driver update to enable blindscan in hardware, even if the hardware is more than capable of blindscan.

 

I guess that's why there's a huge barrier between what sellers tell you and what developers do plus what the buyers expect....

But hey, that's my unimportant opinion, isn't it?

[Neo64]

I hope that dear Team will implement the same options indicated for motorized parabolic that are already implemented by Pure2 Team.

At least it will be a solution for a long time, only we who use images of Open Pli will not give joy and we do not have to look for images of other .

Thanks!

Edited by Neo64, 25 March 2018 - 09:34.