Em Fri, 6 Jul 2018 15:04:08 +0900
"Katsuhiro Suzuki" <suzuki.katsuhiro@xxxxxxxxxxxxx> escreveu:
> Here is the log of dvb-fe-tool on my environment.
>
> --------------------
> # ./utils/dvb/.libs/dvb-fe-tool -d isdbs
> Changing delivery system to: ISDBS
> ERROR FE_SET_VOLTAGE: Unknown error 524
Hmm... ENOTSUPP. Doesn't the device supposed to be able to power on the
LNBf?
Anyway, I changed the error print message to be clearer, displaying
instead:
ERROR FE_SET_VOLTAGE: driver doesn't support it!
>
> # ./utils/dvb/.libs/dvb-fe-tool
> Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> CAN_FEC_AUTO
> CAN_GUARD_INTERVAL_AUTO
> CAN_HIERARCHY_AUTO
> CAN_INVERSION_AUTO
> CAN_QAM_AUTO
> CAN_TRANSMISSION_MODE_AUTO
> DVB API Version 5.11, Current v5 delivery system: ISDBS
> Supported delivery systems:
> [ISDBS]
> ISDBT
> Frequency range for the current standard:
> From: 470 MHz
> To: 2.07 GHz
> Step: 25.0 kHz
> Symbol rate ranges for the current standard:
> From: 0Bauds
> To: 0Bauds
That seems a driver issue. The ISDB-S ops.info should be
filling both symbol_rate_min and symbol_rate_max.
I suspect that both should be filled with 28860000.
The dvb_frontend.c core might hardcode it, but, IMHO,
it is better to keep those information inside the
tuner/frontend ops.info.
> SEC: set voltage to OFF
> ERROR FE_SET_VOLTAGE: Operation not permitted
>
>
> # ./utils/dvb/.libs/dvb-fe-tool -d isdbt
> Changing delivery system to: ISDBT
> ERROR FE_SET_VOLTAGE: Unknown error 524
>
> # ./utils/dvb/.libs/dvb-fe-tool
> Device Socionext SC1501A (/dev/dvb/adapter0/frontend0) capabilities:
> CAN_FEC_AUTO
> CAN_GUARD_INTERVAL_AUTO
> CAN_HIERARCHY_AUTO
> CAN_INVERSION_AUTO
> CAN_QAM_AUTO
> CAN_TRANSMISSION_MODE_AUTO
> DVB API Version 5.11, Current v5 delivery system: ISDBT
> Supported delivery systems:
> ISDBS
> [ISDBT]
> Frequency range for the current standard:
> From: 470 MHz
> To: 2.07 GHz
> Step: 25.0 kHz
The rest looks OK for me.
> > > For example, Helene uses these info for only Ter or Sat freq ranges:
> > >
> > > .name = "Sony HELENE Ter tuner",
> > > .frequency_min_hz = 1 * MHz,
> > > .frequency_max_hz = 1200 * MHz,
> > > .frequency_step_hz = 25 * kHz,
> > >
> > > .name = "Sony HELENE Sat tuner",
> > > .frequency_min_hz = 500 * MHz,
> > > .frequency_max_hz = 2500 * MHz,
> > > .frequency_step_hz = 1 * MHz,
> > >
> > > Is this better to add new info for both system?
> > >
> > > .name = "Sony HELENE Sat/Ter tuner",
> > > .frequency_min_hz = 1 * MHz,
> > > .frequency_max_hz = 2500 * MHz,
> > > .frequency_step_hz = 25 * kHz, // Is this correct...?
> >
> > That is indeed a very good question, and maybe a reason why we
> > may need other approaches.
> >
> > See, if the tuner is capable of tuning from 1 MHz to 2500 MHz,
> > the frequency range should be ok. It would aget_frontend_algoctually be pretty cool
> > to use a tuner with such wide range for SDR, if the hardware supports
> > raw I/Q collect :-D
> >
> > The frequency step is a different issue. If the tuner driver uses
> > DVBFE_ALGO_SW (e. g. if ops.get_frontend_algo() returns it, or if
> > this function is not defined), then the step will be used to adjust
> > the zigzag interactions. If it is too small, the tuning will lose
> > channels if the signal is not strong.
> >
>
> Thank you for describing. It's difficult problem...
I double-checked the implementation. We don't need to worry about
zigzag, provided that the ISDB-S implementation at the core is correct.
For satellite/cable standards, the zigzag logic takes the symbol
rate into account, and not the stepsize:
case SYS_DVBS:
case SYS_DVBS2:
case SYS_ISDBS:
case SYS_TURBO:
case SYS_DVBC_ANNEX_A:
case SYS_DVBC_ANNEX_C:
fepriv->min_delay = HZ / 20;
fepriv->step_size = c->symbol_rate / 16000;
fepriv->max_drift = c->symbol_rate / 2000;
break;
For terrestrial standards, it uses the stepsize:
case SYS_DVBT:
case SYS_DVBT2:
case SYS_ISDBT:
case SYS_DTMB:
fepriv->min_delay = HZ / 20;
fepriv->step_size = dvb_frontend_get_stepsize(fe) * 2;
fepriv->max_drift = (dvb_frontend_get_stepsize(fe) * 2) + 1;
break;
So, having a value of 25 kHz there won't affect the zigzag algorithm
for ISDB-S, as it will be used only for ISDB-T.
> > In the specific case of helene, it doesn't have a get_frontend_algo,
> > so it will use the step frequency.
> >
> > I'm not sure how to solve this issue. Maybe Abylay may shed a light
> > here, if helene does sigzag in hardware or not.
> >
>
> As far as I know, Helene does not have automatic scan mechanism in
> hardware.
Ok, so the driver is doing the right thing here.
> > If it does in hardware, you could add a get_frontend_algo() routine
> > at helene driver and return DVBFE_ALGO_HW. The tuning zigzag software
> > algorithm in the Kernel will stop, as it will rely at the hardware.
> >
> > Please notice that, if the hardware doesn't do zigzag itself, this
> > will make it lose channels. On the other hand, if the hardware does
> > have sigzag, changing to DVBFE_ALGO_HW will speedup tuning, as the
> > Kernel won't try to do sigzag itself.
> >
>
> ISDB-T uses 6MHz bandwidth per channel (in Japan), ISDB-S for
> BS/CS110 uses 38.36MHz bandwidth. Maybe 1MHz zigzag step is large for
> ISDB-T system and 25kHz is small for ISDB-S system.
Yeah, but, after double-checking the logic, for ISDB-S, it will
use:
c->symbol_rate = 28860000;
c->rolloff = ROLLOFF_35;
c->bandwidth_hz = c->symbol_rate / 100 * 135;
That would actually set the ISDB-S channel separation to 38.961 MHz.
By setting symbol_rate like that, the zigzag for ISDB-S will
be defined by:
fepriv->step_size = c->symbol_rate / 16000; /* 38.961MHz / 16000 = .002435 - e. g. steps of ~25 kHz */
fepriv->max_drift = c->symbol_rate / 2000; /* 38.961MHz / 2000 = .0194805 - e. g. max drift of ~195 kHz */
Funny enough, it will be using about 25 kHz as step size for ISDB-S.
I have no idea if the ISDB-S standard defines the zigzag logic,
but I would be expecting a higher value for it. So, perhaps
the ISDB-S zigzag could be optimized.
Thanks,
Mauro
