LinuxQuestions.org - PCTV DVB-S2 Stick (461e) not feeding LNB

- Linux - Hardware (https://www.linuxquestions.org/questions/linux-hardware-18/)

- - PCTV DVB-S2 Stick (461e) not feeding LNB (https://www.linuxquestions.org/questions/linux-hardware-18/pctv-dvb-s2-stick-461e-not-feeding-lnb-4175529374/)

PCTV DVB-S2 Stick (461e) not feeding LNB

I bought a PCTV DVB-S2 Stick (461e) because it was on the supported list on linuxtv.org ( http://www.linuxtv.org/wiki/index.ph...2_Stick_(461e) )

However when I inserted it into my mediaserver with kaffeine it did not find any channels. Only once it looked like it got some signal.

Trying to attach a satellite finder indicated that no power was put on the cable for the LNB. Trying to insert the stick into a Windows 8 machine and installing the PCTV software, proved that the stick indeed did feed the LNB with power.

Next I tried to insert the stick to my laptop, with the satellite finder too. When running scandvb the sattelite finder went active for a few seconds, and the got silent. Rerunning scandvb gave no response. But removing the stick and reinserting it would repeat this when running scandvb.

This leaves me to suspect that the stick is reset during the scan.
Im running a Fedora 20 with Linux 3.17.7-200.fc20.x86_64

When inserting I get these messages in /var/log/messages
Dec 28 02:36:08 kjeldpc kernel: [406859.995473] usb 2-1.2: new high-speed USB device number 7 using ehci-pci
Dec 28 02:36:08 kjeldpc kernel: usb 2-1.2: new high-speed USB device number 7 using ehci-pci
Dec 28 02:36:08 kjeldpc kernel: [406860.081489] usb 2-1.2: New USB device found, idVendor=2013, idProduct=0258
Dec 28 02:36:08 kjeldpc kernel: [406860.081500] usb 2-1.2: New USB device strings: Mfr=3, Product=1, SerialNumber=2
Dec 28 02:36:08 kjeldpc kernel: [406860.081505] usb 2-1.2: Product: PCTV 461
Dec 28 02:36:08 kjeldpc kernel: [406860.081510] usb 2-1.2: Manufacturer: PCTV
Dec 28 02:36:08 kjeldpc kernel: [406860.081513] usb 2-1.2: SerialNumber: 0011421225
Dec 28 02:36:08 kjeldpc kernel: [406860.081945] em28xx: New device PCTV PCTV 461 @ 480 Mbps (2013:0258, interface 0, class 0)
Dec 28 02:36:08 kjeldpc kernel: [406860.081950] em28xx: DVB interface 0 found: isoc
Dec 28 02:36:08 kjeldpc kernel: [406860.082094] em28xx: chip ID is em28178
Dec 28 02:36:08 kjeldpc kernel: usb 2-1.2: New USB device found, idVendor=2013, idProduct=0258
Dec 28 02:36:08 kjeldpc kernel: usb 2-1.2: New USB device strings: Mfr=3, Product=1, SerialNumber=2
Dec 28 02:36:08 kjeldpc kernel: usb 2-1.2: Product: PCTV 461
Dec 28 02:36:08 kjeldpc kernel: usb 2-1.2: Manufacturer: PCTV
Dec 28 02:36:08 kjeldpc kernel: usb 2-1.2: SerialNumber: 0011421225
Dec 28 02:36:08 kjeldpc kernel: em28xx: New device PCTV PCTV 461 @ 480 Mbps (2013:0258, interface 0, class 0)
Dec 28 02:36:08 kjeldpc kernel: em28xx: DVB interface 0 found: isoc
Dec 28 02:36:08 kjeldpc kernel: em28xx: chip ID is em28178
Dec 28 02:36:09 kjeldpc kernel: [406860.444891] em28178 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x033c70a0
Dec 28 02:36:09 kjeldpc kernel: [406860.444897] em28178 #0: EEPROM info:
Dec 28 02:36:09 kjeldpc kernel: [406860.444900] em28178 #0: microcode start address = 0x0004, boot configuration = 0x01
Dec 28 02:36:09 kjeldpc kernel: em28178 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x033c70a0
Dec 28 02:36:09 kjeldpc kernel: em28178 #0: EEPROM info:
Dec 28 02:36:09 kjeldpc kernel: em28178 #0: microcode start address = 0x0004, boot configuration = 0x01
Dec 28 02:36:09 kjeldpc kernel: [406860.453978] em28178 #0: AC97 audio (5 sample rates)
Dec 28 02:36:09 kjeldpc kernel: [406860.453985] em28178 #0: 500mA max power
Dec 28 02:36:09 kjeldpc kernel: [406860.453989] em28178 #0: Table at offset 0x27, strings=0x148c, 0x1874, 0x0a6a
Dec 28 02:36:09 kjeldpc kernel: [406860.454096] em28178 #0: Identified as PCTV DVB-S2 Stick (461e) (card=92)
Dec 28 02:36:09 kjeldpc kernel: [406860.454101] em28178 #0: dvb set to isoc mode.
Dec 28 02:36:09 kjeldpc kernel: [406860.454218] em28178 #0: Binding DVB extension
Dec 28 02:36:09 kjeldpc kernel: em28178 #0: AC97 audio (5 sample rates)
Dec 28 02:36:09 kjeldpc kernel: em28178 #0: 500mA max power
Dec 28 02:36:09 kjeldpc kernel: em28178 #0: Table at offset 0x27, strings=0x148c, 0x1874, 0x0a6a
Dec 28 02:36:09 kjeldpc kernel: em28178 #0: Identified as PCTV DVB-S2 Stick (461e) (card=92)
Dec 28 02:36:09 kjeldpc kernel: em28178 #0: dvb set to isoc mode.
Dec 28 02:36:09 kjeldpc kernel: em28178 #0: Binding DVB extension
Dec 28 02:36:09 kjeldpc kernel: [406860.459336] i2c i2c-17: Added multiplexed i2c bus 18

Dec 28 02:36:09 kjeldpc mtp-probe: checking bus 2, device 7: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2"
Dec 28 02:36:09 kjeldpc mtp-probe: bus: 2, device: 7 was not an MTP device
Dec 28 02:36:09 kjeldpc kernel: i2c i2c-17: Added multiplexed i2c bus 18
Dec 28 02:36:09 kjeldpc kernel: [406860.517596] m88ts2022 18-0060: m88ts2022: Montage M88TS2022 successfully identified
Dec 28 02:36:09 kjeldpc kernel: [406860.518635] i2c i2c-17: a8293: Allegro A8293 SEC attached
Dec 28 02:36:09 kjeldpc kernel: [406860.518639] DVB: registering new adapter (em28178 #0)
Dec 28 02:36:09 kjeldpc kernel: [406860.518643] usb 2-1.2: DVB: registering adapter 0 frontend 0 (Montage M88DS3103)...
Dec 28 02:36:09 kjeldpc kernel: [406860.519594] em28178 #0: DVB extension successfully initialized
Dec 28 02:36:09 kjeldpc kernel: [406860.519599] em28178 #0: Registering input extension
Dec 28 02:36:09 kjeldpc kernel: m88ts2022 18-0060: m88ts2022: Montage M88TS2022 successfully identified
Dec 28 02:36:09 kjeldpc kernel: [406860.520513] Registered IR keymap rc-pinnacle-pctv-hd
Dec 28 02:36:09 kjeldpc kernel: [406860.520619] input: em28xx IR (em28178 #0) as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/rc/rc0/input28
Dec 28 02:36:09 kjeldpc kernel: [406860.520681] rc0: em28xx IR (em28178 #0) as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/rc/rc0
Dec 28 02:36:09 kjeldpc kernel: [406860.521133] em28178 #0: Input extension successfully initalized
Dec 28 02:36:09 kjeldpc kernel: i2c i2c-17: a8293: Allegro A8293 SEC attached
Dec 28 02:36:09 kjeldpc kernel: DVB: registering new adapter (em28178 #0)
Dec 28 02:36:09 kjeldpc kernel: usb 2-1.2: DVB: registering adapter 0 frontend 0 (Montage M88DS3103)...
Dec 28 02:36:09 kjeldpc kernel: em28178 #0: DVB extension successfully initialized
Dec 28 02:36:09 kjeldpc kernel: em28178 #0: Registering input extension
Dec 28 02:36:09 kjeldpc kernel: Registered IR keymap rc-pinnacle-pctv-hd
Dec 28 02:36:09 kjeldpc kernel: input: em28xx IR (em28178 #0) as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/rc/rc0/input28
Dec 28 02:36:09 kjeldpc kernel: rc0: em28xx IR (em28178 #0) as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/rc/rc0
Dec 28 02:36:09 kjeldpc kernel: em28178 #0: Input extension successfully initalized

Running sudo scandvb -v -s 0 /usr/share/dvb/dvb-s/Hotbird-13.0E
adds this output

Dec 28 02:38:04 kjeldpc kernel: [406976.212089] i2c i2c-17: m88ds3103: found a 'Montage M88DS3103' in cold state
Dec 28 02:38:04 kjeldpc kernel: [406976.212147] i2c i2c-17: m88ds3103: downloading firmware from file 'dvb-demod-m88ds3103.fw'
Dec 28 02:38:04 kjeldpc kernel: i2c i2c-17: m88ds3103: found a 'Montage M88DS3103' in cold state
Dec 28 02:38:04 kjeldpc kernel: i2c i2c-17: m88ds3103: downloading firmware from file 'dvb-demod-m88ds3103.fw'
Dec 28 02:38:05 kjeldpc kernel: [406976.497881] i2c i2c-17: m88ds3103: found a 'Montage M88DS3103' in warm state
Dec 28 02:38:05 kjeldpc kernel: [406976.497890] i2c i2c-17: m88ds3103: firmware version 3.B
Dec 28 02:38:05 kjeldpc kernel: i2c i2c-17: m88ds3103: found a 'Montage M88DS3103' in warm state
Dec 28 02:38:05 kjeldpc kernel: i2c i2c-17: m88ds3103: firmware version 3.B

I also tried to remove the firmware file, in which case to activity was registered on the satellite finder. And when putting it back I could repeat the activity without unmounting it first.

Anyone have some good ideas

Didn't find a solution but a workaround.
I installed VirtualBox with a Windows host, in which I loaded the PCTV disk.
Running the accompanying software worked ad I got signal from the DVB stick.
After closing down VirtualBox and Windows, it now worked in Linux. Event after power off's!

So obviously the Windows software must have done something to the DVB stick, which leads me to the conclusion, that the Linux drivers may have been tested on sticks which already had been used on Windows systems.
Thus the drivers for the card doesn't do all that is required for a factory fresh DVB stick.

Hmm, I'm confused. Didn't you originally put the stick into a Windows 8 machine, install PCTV software and note that the LNB got power in your first post? So your stick should already have been initiated by Windows 8 and the PCTV software if that was the problem; it wasn't really "factory fresh". Or did I misunderstand?

Don't get me wrong, I'm happy you have a working 461e, I'm just not convinced about the solution.

I've got one of these sticks too, which I've already tried under Windows but have yet to try under Linux. Mine doesn't seem able to find the the sat signal using the PCTV software under Windows, though my OpenBOX S9 finds it just great... don't know if that's a hardware inadequacy of the stick vs the S9 receiver or a faulty/out of date transponder list in the PCTV software.

When I get the chance I'll try it under Linux and see what I get. I can't comment on your problem at this point since my LNB gets power anyway from the other sat boxes. If you have any more problems, post again and I'll try duplicating by disconnecting everything but the 461e.

Maybe I should do a more thorough power off test.
Does the stick provide power to the LNB when You insert it into Windows?

As I said, i haven't tested that yet since the LNB gets power anyway from the S9. But I can try unplugging everything else this weekend if I get the chance and I'll let you know.

Here's what I found out:

The stick only powers the LNB when, in Windows 7 (running in a VM) is actually running the TVCenter program. Windows doesn't power the LNB just plugged in.

Under Linux, I tried w_scan as in "w_scan -fs -s S13E0" for your satellite, but that does not power the LNB either, although the device is recognized and scanned.

Code:

$w_scan -fs -s S13E0

 

w_scan version 20141122 (compiled for DVB API 5.10)

using settings for 13.0 east Hotbird 6/7A/8

scan type SATELLITE, channellist 69

output format vdr-2.0

WARNING: could not guess your codepage. Falling back to 'UTF-8'

output charset 'UTF-8', use -C <charset> to override

Info: using DVB adapter auto detection.

        /dev/dvb/adapter0/frontend0 -> SATELLITE "Montage M88DS3103": very good :-))



Using SATELLITE frontend (adapter /dev/dvb/adapter0/frontend0)

-_-_-_-_ Getting frontend capabilities-_-_-_-_ 

Using DVB API 5.10

frontend 'Montage M88DS3103' supports

INVERSION_AUTO

DVB-S

DVB-S2

FREQ (0.95GHz ... 2.15GHz)

SRATE (1.000MSym/s ... 45.000MSym/s)

using LNB "UNIVERSAL"

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ 

trying 'S  f = 10719 kHz V SR = 27500  5/6 0,35  QPSK  (0:0:0)'

(time: 00:00.063)

.....

....

and here's the journalctl entries:

Code:

Apr 04 10:35:09 bozo kernel: usb 4-1.8.1: new high-speed USB device number 21 using ehci-pci

Apr 04 10:35:09 bozo kernel: em28xx: New device PCTV PCTV 461 @ 480 Mbps (2013:0258, interface 0, class 0)

Apr 04 10:35:09 bozo kernel: em28xx: DVB interface 0 found: isoc

Apr 04 10:35:09 bozo kernel: em28xx: chip ID is em28178

Apr 04 10:35:09 bozo kernel: em28178 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0xf83c72a0

Apr 04 10:35:09 bozo kernel: em28178 #0: EEPROM info:

Apr 04 10:35:09 bozo kernel: em28178 #0:        microcode start address = 0x0004, boot configuration = 0x01

Apr 04 10:35:09 bozo kernel: em28178 #0:        AC97 audio (5 sample rates)

Apr 04 10:35:09 bozo kernel: em28178 #0:        500mA max power

Apr 04 10:35:09 bozo kernel: em28178 #0:        Table at offset 0x27, strings=0x148c, 0x1874, 0x0a6a

Apr 04 10:35:09 bozo kernel: em28178 #0: Identified as PCTV DVB-S2 Stick (461e) (card=92)

Apr 04 10:35:09 bozo kernel: em28178 #0: dvb set to isoc mode.

Apr 04 10:35:09 bozo kernel: em28178 #0: Binding DVB extension

Apr 04 10:35:09 bozo kernel: i2c i2c-12: m88ds3103_attach: chip_id=70

Apr 04 10:35:09 bozo kernel: i2c i2c-12: Added multiplexed i2c bus 13

Apr 04 10:35:09 bozo kernel: m88ts2022 13-0060: Montage M88TS2022 successfully identified

Apr 04 10:35:09 bozo kernel: i2c i2c-12: a8293: Allegro A8293 SEC attached

Apr 04 10:35:09 bozo kernel: DVB: registering new adapter (em28178 #0)

Apr 04 10:35:09 bozo kernel: usb 4-1.8.1: DVB: registering adapter 0 frontend 0 (Montage M88DS3103)...

Apr 04 10:35:09 bozo kernel: em28178 #0: DVB extension successfully initialized

Apr 04 10:35:09 bozo kernel: em28178 #0: Registering input extension

Apr 04 10:35:09 bozo kernel: Registered IR keymap rc-pinnacle-pctv-hd

Apr 04 10:35:09 bozo kernel: input: em28xx IR (em28178 #0) as /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.8/4-1.8.1/rc/rc0/input51

Apr 04 10:35:09 bozo kernel: rc0: em28xx IR (em28178 #0) as /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.8/4-1.8.1/rc/rc0

Apr 04 10:35:09 bozo kernel: em28178 #0: Input extension successfully initalized

Apr 04 10:35:20 bozo kernel: i2c i2c-12: m88ds3103: found a 'Montage M88DS3103' in cold state

Apr 04 10:35:20 bozo kernel: i2c i2c-12: m88ds3103: downloading firmware from file 'dvb-demod-m88ds3103.fw'

Apr 04 10:35:20 bozo kernel: i2c i2c-12: m88ds3103: found a 'Montage M88DS3103' in warm state

Apr 04 10:35:20 bozo kernel: i2c i2c-12: m88ds3103: firmware version 3.B

So I agree; I'm not sure what "TVCenter" under Windows does with the thing to power it up.

So my wife wanted to se her russian new year show. And this time, the receiver did not work until I started up a virtual box with a windows app.
Indeed it seems that something is needed to activate it.

Hi, two questions since I recently bought a 461e and also find no channels:

was this issue ever fixed?

if not, does this mean one has to start a Windows App (in Virtualbox or so) after every boot to fix that?

Greetings,
bku

And two additional questions - in case of the Stick not feeding the LNB where would this issue be caused? Is that driver related (in kernel since 3.14) or part of the user space software w_scan ?

The error description tells that some windows user software can trigger the LNB feed voltage, but maybe it triggers only some driver code - does anybody know where to ask for more details? linuxtv.org or kernel driver maintainer?

Greetings,
bku

It is not my impression that You have to start it up on every boot.
It's been a while since I used the system.

Well I bought the stick as receiver for a MythTV box. Would be bad if it powers up during the night to do a record and then the stick fails... have to plug it to a windows PC and try if it finds channels there at least.
Its annoying that there is so few information about that problem and that the information is 6 years old.
Thanks for your reply by the way.

After frustrating trial-and-error I found a partial workaround that doesn't require windows:

1. Disconnect the 461e completely - the USB, power cable, RF cable, everything.

2. Connect the power cable

3. Connect the USB cable

DON'T connect the RF cable yet.

4. Start your tuning software and try to tune to a specific channel - something that will set the frequency, voltage, tone, etc and is trying to obtain a transponder lock.

5. NOW connect the RF cable.

It should start working.

6. When finished, disconnect the RF cable FIRST, then stop the tuner software.

If done correctly, the next time around only needs steps 4-6. If these steps aren't done in this order- just once - the dongle will be in a bad state and you will need to start again at step 1.

There was a period of time when my 461e worked fine in linux. Using w_scan seems to cause the dongle to act this way. dvbv5-zap does not cause the problem but is certainly affected by it. The change survives reboots and the dongle being completely disconnected. Somehow I had gotten it back in working order for a while but I have no idea at this time what it was I did as it was just a flurry of reboots, usbresets, power cycling, connecting/disconnecting. Nothing fixed it the first time around. It just decided to behave again. Right now it's misbehaving.

Also verified it really is failing to send LNB power with a multimeter (and satellite finder).

Is there a sensor on this dongle for detecting when connected? How about a short detector? Perhaps it is falsely detecting a short and shutting down until it is unplugged and replugged?

UPDATE: Wrote some C code to call ioctl and send a FE_DISEQC_RESET_OVERLOAD command but it returns 524 (oepration not supported).

Sorry to double-post but it apparently doesn't let me edit my last post after a while.

When the LNB voltage is brought to 18V from 0V, the dongle goes into a bad state where it needs to be reset. However, going to 13V is fine, and going from 13V to 18V is apparently fine too.

This sounded to me like some sort of overcurrent issue. Looking at the datasheet for the Allegro A8293 LNB-voltage frontend there is a protection circuit pin which can be disabled but in my attempts, doesn't fix anything or seem to even do much:

"When the LNB output is shorted, the LNB output current is limited to 700 mA typical,
and the IC will be shut down if the overcurrent condition lasts
for more than 48 ms. If this occurs, the A8293 must be reenabled
for normal operation."

And...

"At start-up or during an LNB reconfiguration event, a tran-
sient surge current above the normal DC operating level can be
provided by the A8293. This current increase can be as high as
700 mA, typical, for as long as required, up to a maximum of
48 ms."

... so ideally some sort of polling operation should occur to check if it overloads and perform an appropriate reset. I haven't figured out how to do that from the kernel module, however I did write up a hack to the kernel module which will use the different voltage settings on the A8293 to somewhat-gradually ramp it to the needed voltage on a nanoseconds-per-millivolt to reduce the risk of an overcurrent. Here is the modified file from linux/drivers/media/dvb-frontends/a8293.c:

Quote:

// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Allegro A8293 SEC driver
*
* Copyright (C) 2011 Antti Palosaari <crope@iki.fi>
*/

#include "a8293.h"

struct a8293_dev {
struct i2c_client *client;
u8 reg[2];
};

static int a8293_set_voltage(struct dvb_frontend *fe,
enum fe_sec_voltage fe_sec_voltage)
{
struct a8293_dev *dev = fe->sec_priv;
struct i2c_client *client = dev->client;
int ret;
u8 reg0,reg1;
int new_volt_idx;
const int idx_to_mv[] = {0, 12709, 13042, 13375, 14042, 15042, 18042, 18709, 19042};
const u8 idx_to_reg[] = {0x00, 0x20, 0x21, 0x22, 0x24, 0x27, 0x28, 0x2A, 0x2B};
u8 odt_flag = 0x10;
int min_nanos_per_mv = 100;
int this_volt_idx;

int prev_volt_idx;
switch (dev->reg[0] & 0x2F) {
case 0x00:
prev_volt_idx = 0;
break;
case 0x20:
prev_volt_idx = 1;
break;
case 0x21:
prev_volt_idx = 2;
break;
case 0x22:
prev_volt_idx = 3;
break;
case 0x24:
prev_volt_idx = 4;
break;
case 0x27:
prev_volt_idx = 5;
break;
case 0x28:
prev_volt_idx = 6;
break;
case 0x2A:
prev_volt_idx = 7;
break;
case 0x2B:
prev_volt_idx = 8;
break;
default:
prev_volt_idx = 0;
}

dev_dbg(&client->dev, "fe_sec_voltage=%d\n", fe_sec_voltage);

switch (fe_sec_voltage) {
case SEC_VOLTAGE_OFF:
new_volt_idx = 0;
break;
case SEC_VOLTAGE_13:
new_volt_idx = 2;
break;
case SEC_VOLTAGE_18:
new_volt_idx = 6;
break;
default:
ret = -EINVAL;
goto err;
}

//printk(KERN_INFO "a8293: prev_volt_idx=%d\n", prev_volt_idx);
//printk(KERN_INFO "a8293: new_volt_idx=%d",new_volt_idx);

//TODO: encapsulate in if() and next if() should be an else()
this_volt_idx = prev_volt_idx;
if(this_volt_idx < new_volt_idx) {
while (this_volt_idx < new_volt_idx ) {
int delta_mv = idx_to_mv[this_volt_idx+1] - idx_to_mv[this_volt_idx];
int min_wait_time = delta_mv * min_nanos_per_mv;
reg0 = idx_to_reg[this_volt_idx+1];
reg0 |= odt_flag;

//printk(KERN_INFO "a8293: this_volt_idx=%d\n", this_volt_idx);
//printk(KERN_INFO "a8293: delta_mv=%d\n", delta_mv);
//printk(KERN_INFO "a8293: min_wait_time=%d\n", min_wait_time);
//printk(KERN_INFO "a8293: reg0=0x%.2X\n",reg0);
ret = i2c_master_send(client, &reg0, 1);
if (ret < 0)
goto err;
dev->reg[0] = reg0;
this_volt_idx++;
usleep_range(min_wait_time, min_wait_time * 2);
}
} else {
reg0 = idx_to_reg[new_volt_idx];
reg0 |= odt_flag;
ret = i2c_master_send(client, &reg0, 1);
if (ret < 0)
goto err;
dev->reg[0] = reg0;
}
/* TMODE=0, TGATE=1 */
reg1 = 0x82;
if (reg1 != dev->reg[1]) {
ret = i2c_master_send(client, &reg1, 1);
if (ret < 0)
goto err;
dev->reg[1] = reg1;
}

usleep_range(1500, 5000);
return 0;
err:
dev_dbg(&client->dev, "failed=%d\n", ret);
return ret;
}

static int a8293_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct a8293_dev *dev;
struct a8293_platform_data *pdata = client->dev.platform_data;
struct dvb_frontend *fe = pdata->dvb_frontend;
int ret;
u8 buf[2];

dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (!dev) {
ret = -ENOMEM;
goto err;
}

dev->client = client;

/* check if the SEC is there */
ret = i2c_master_recv(client, buf, 2);
if (ret < 0)
goto err_kfree;

/* override frontend ops */
fe->ops.set_voltage = a8293_set_voltage;
fe->sec_priv = dev;
i2c_set_clientdata(client, dev);

dev_info(&client->dev, "Allegro A8293 SEC successfully attached\n");
return 0;
err_kfree:
kfree(dev);
err:
dev_dbg(&client->dev, "failed=%d\n", ret);
return ret;
}

static int a8293_remove(struct i2c_client *client)
{
struct a8293_dev *dev = i2c_get_clientdata(client);

dev_dbg(&client->dev, "\n");

kfree(dev);
return 0;
}

static const struct i2c_device_id a8293_id_table[] = {
{"a8293", 0},
{}
};
MODULE_DEVICE_TABLE(i2c, a8293_id_table);

static struct i2c_driver a8293_driver = {
.driver = {
.name = "a8293",
.suppress_bind_attrs = true,
},
.probe = a8293_probe,
.remove = a8293_remove,
.id_table = a8293_id_table,
};

module_i2c_driver(a8293_driver);

//Modified by Chuck Ritola (cjritola@gmail.com)

MODULE_AUTHOR("Antti Palosaari <crope@iki.fi>");
MODULE_DESCRIPTION("Allegro A8293 SEC driver");
MODULE_LICENSE("GPL");

... if this still doesn't fix it, try doubling min_nanos_per_mv. There's probably a limit to how hard this frontend can drive the downlead equipment but I was able to run a USALS rotor followed by a LNB after this change. There is a noticeable delay when setting the LNB to higher voltages due to this ramping effect.

I found it easiest to apply the module fix by downloading the kernel source, applying the modification, then building a new kernel from the source. When I tried the linux-media instructions there were so many snags it was not worth it. Many version mismatches and signed drivers issues. Much more straightforward to just build a new kernel and boot from it.

Here are the instructions I used to build the kernel. There are plenty of others out there. Distros vary, I can't help much with that.

So the next step would be to get this fix into the kernel. I doubt they would like it as-is, as it changes the a8293 driver's behavior across the kernel and other tuners which use it may not benefit at all. Perhaps another function in the Allegro module just for setting the voltage, then changing the 461e kernel code to incorporate the ramping capabilty.

Quote:

Originally Posted by critola (Post 6294083)

When the LNB voltage is brought to 18V from 0V, the dongle goes into a bad state where it needs to be reset. However, going to 13V is fine, and going from 13V to 18V is apparently fine too.

first time after plugging in the card into USB port

0->13V OK
0->18V BAD
13->18V OK

if you tune 13V first and don't reconnect the card

0->13V OK
0->18V OK
13->18V OK

Quote:

Originally Posted by critola (Post 6294083)

This sounded to me like some sort of overcurrent issue. Looking at the datasheet for the LNB-voltage frontend there is a protection circuit pin which can be disabled but in my attempts, doesn't fix anything or seem to even do much:

"When the LNB output is shorted, the LNB output current is limited to 700 mA typical,
and the IC will be shut down if the overcurrent condition lasts
for more than 48 ms. If this occurs, the A8293 must be reenabled
for normal operation."

And...

"At start-up or during an LNB reconfiguration event, a tran-
sient surge current above the normal DC operating level can be
provided by the A8293. This current increase can be as high as
700 mA, typical, for as long as required, up to a maximum of
48 ms."

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

Quote:

Originally Posted by critola (Post 6286671)

1. Disconnect the 461e completely - the USB, power cable, RF cable, everything.

2. Connect the power cable

3. Connect the USB cable

DON'T connect the RF cable yet.

4. Start your tuning software and try to tune to a specific channel - something that will set the frequency, voltage, tone, etc and is trying to obtain a transponder lock.

5. NOW connect the RF cable.

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?