Third idea: create our own hw independent ranges and define the meaning of the bits (we could use 16 bit, for example). Better, let decide that bit 31 means auto-sr and use 16 or 24 or 30 bits for ranges.That is: if (bit31==0) (bit29-bit0)=symbol rate in baud if (bit31==1) (bit29-bit0)=symbol rate range mask bit30 reserved for future use, must be 0
Yes, I like it. We could define the ranges directly or in relation to sr_min and sr_max, but with 30 bits I'd avoid this extra complication.
We could have ranges coded this way SR_SEARCH_RANGES 1<<31 SR_RESERVED_MUST_BE_0 1<<30 SR_RANGE_30M_25M 1<<29 SR_RANGE_25M_20M 1<<28 ... SR_RANGE_6M_5M 1<<12 SR_RANGE_5M_4M 1<<11 ... SR_RANGE_500k_300k 1<<0 and use (SR_AUTO|SR_30M_25M|SR_6M_5M) in apps.
sounds hard to use. I would prefer the approach similiar to thy Zarlink Evalsoftware: pass the frequency and symbol rate ranges to the driver and then get interrupted/notified as soon something is found, thenafter continue there.
A scan looks like this from the userspace application point of view:
ioctl(PREPARE_SCAN, &setup_range_spec); ioctl(START_SCAN);
while (1) {
/* we get notified by poll() */
wait until status changes and read current parameters;
select(fe_fd, ...);
ioctl(fe_fd, FE_GET_STTAUS, &s);
ioctl(fe_fd, FE_GET_PARAMETERS, &p); if (end of range)
bail out; if (channel found)
store parameters; if (weak channel)
mark channel as weak;ioctl(CONTINUE_SCAN); }
an additional ioctl(CANCEL_SCAN) allows to interrupt running scans and to bring back the hardware into a sane state for normal tuning.
discontinous scan ranges should be handled by the application. The setup_range_spec struct might look like this for DVB-S scans:
struct dvb_fe_scan_spec {
unsigned freq_start;
unsigned freq_end;
unsigned srate_start;
unsigned srate_end;
}A similiar approach works for the mt352 DVB-T demod, there the srate fields are not required but bandwidth and the scan_weak_channels bit have to be configured. What do you think?
Holger
