Quote:
Originally Posted by tom55
it happens only when USALS positioner (maybe even some other equipment but i have nothing else to try) is in-between tuner and LNB. cannot be overcurrent because:
1. LNB consume about 2W at 13V and 3W at 18V (power from wall pulled by small adapter that comes in box), and positioner can pull up to 8W when driving at high speed
2. only first time after "cold boot" (e.g. plugging in the card into USB port) this happens, but if you tune 13V first and shut it down then it will tune fine at 18V
i think better solution that should not sacrifice tuning speed would be to just make the driver tune to V pol first after loading for few hundred ms (as much as needed for stable operation) and then sets the tuner to idle. afterwards, everything will be fine from userspace, no matter which polarization is being tuned
edit: i tried the patch you sent to mailing list, it fixes the problem, but not entirely - sometimes there will be no data received e.g. black screen, and again - only reconnect the USB helps. when this happens the power draw is the same as when it works fine. surprisingly, there is no any delay in tuning speed that could be considered as a regression (windows drivers take more than bloody 30 seconds to init the card)
update: used patch from mailing list now, the solution is acceptable, no problems observed with tuning
|
The patch I submitted uses a faster slew rate than the code I posted earlier in this thread, deliberately to avoid a perceptible delay in tuning. The code above might help if the problem still lingers as it waits a longer time.
Is it looking like it is 100% reliable now? If there are still random issues, try quadrupling the slew time in the patch (drivers/media/usb/em28xx/em28xx-dvb.c) where it says:
Code:
a8293_pdata.volt_slew_nanos_per_mv = 20;
... increase to about 80 so it says:
Code:
a8293_pdata.volt_slew_nanos_per_mv = 80;
If this fixes lingering issues please let me know. If there were no issues disregard this suggestion.
I never used the 461e in Windows but the drivers taking an order of 30sec to init sounds rough. Makes me wonder if it is trying to energize your downlead, detecting the bit-7 flag (vIN undervoltage), and retrying every 2s until it gives up.
Tried your suggestion by adding the following to an unmodified kernel
to drivers/media/usb/em28xx/em28xx-dvb.c in unmodified kernel,
at function em28178_dvb_init_pctv_461e(...)
Code:
/* Init by pulling to 13V for a moment then back to 0V */
dvb->fe[0]->ops.set_voltage(dvb->fe[0], SEC_VOLTAGE_13);
usleep_range(1000000, 1500000);/*Wait 1-1.5s*/
dvb->fe[0]->ops.set_voltage(dvb->fe[0], SEC_VOLTAGE_OFF);
... just before the `return 0` line.
It did not fix the issue for me. After a reset,
Code:
tuned 0->13V -Works
quit so it is back to 0V
quickly tuned 0->18V -Works
quit so it is back to 0V
waited at least 5 minutes
tuned 0->18V -Doesn't work, bad state, needs reset.
... so the working state caused by going from 0->13V does not linger for long. It sounds like a capacitor somewhere is holding a charge between tunings. Once it loses the charge it's like a fresh boot and the issue returns unless it can be reset then charged again with 0->13V. This is probably why plugging it into a windows machine then moving it over to linux seemed to make it work right for a limited time.
Though the rated wattage draw is within the range of the power supply, does that take into account the inrush current when first energizing the downlead and whatever capacitance is on all the equipment on said downlead?
My current hyptothesis is that there are capacitors inside the 461e's power supply for its boost converters, plus capacitors in the downlead at the USALS rotor and maybe even in the LNB which draw heavy inrush current on powerup. The power system inside the dongle cannot keep up, the voltage sags, and trips vIN undervoltage error. I tried a bigger power supply and it didn't help. Apparently the current still isn't enough to trip the OCP bit. When the dongle is powered up alone it is ok, then when it energizes the downlead it is ok as well. Guess everything at once is too much for it.
Before the patch(es) posted, there were some intermediary experiments I did:
* Step-increase with each tuning 0->13->18V in the driver module. This worked and was the predecessor with the code posted above, which itself was the predecessor to the code submitted to the kernel list.
* Turn the LNB off, set the voltage, wait a short time, turn the LNB on. This only worked 50/50 randomly.
* Use all voltages supported by the a8293 and calculate an adjustable slew rate to make the transition as smooth as possible - this is what the newest version does.
* An earlier version printed the a8293 error states from its status register. That is how I was able to detect that the failure was caused by vIN undervoltage being thrown (bit 7, register 1), which then puts the frontend in a disabled error state unless the status register is read again, which the driver does not do.
Quote:
Originally Posted by Kjeld Flarup
Thanks, that saved me a lot. I may try out the kernel patch after New Year. I moved the receiver to a Raspberry Pi, with LibreELEC, making it easier to experiment.
Did You upstream the patch?
|
I submitted a patch but it had some
minor issues to be fixed.
Have been holding off a little bit to make sure it is working for other users but it's probably getting time for me to do it already.
A side-note: If your distro has it, the
command is helpful at getting the 461e back to life if it goes in a bad state w/o physically unplugging - though a forewarning it generally doesn't cause new kernel module changes to take effect. That's best done with a reboot.
More progress
