On Mon, 2 Aug 2004 14:06:38 +0200 Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> It's amazing what one can do with proper frontend hardware :-) To be honest, my first approach was even more ambitious, I wanted the ability to detect even analogue channels. I tried to use the mt312 as a spectrum analyzer and got some moderately interesting plots, but the bandwidth before the power meter is too large, so weak signals near strong signals are easily masked out. After investigating if I could disable the AGC, run the QPSK demodulator in unlocked mode, and get some useful results from the I-Q sample register, which was designed to draw a scatter diagram, I decided to let it go. > > The patch has a few small improvements easily acceptable for inclusion, > > but there are two issues: > > 1) added a new ioctl (as other frontends may support the same > > functionality, I don't think it should be very controversial) > > 2) brutally hacked the symbol_rate parameter; I use low values > > (0-0xfff, well below symbol_rate_min) to ask for auto symbol rate; > > I don't see an easy and elegant way to achieve abstraction from > > hardware (this is very mt312 specific) without sacrifying > > functionality (such as multi frequency ranges) or seriously extending > > the API (set min and max symbol rate separately, at minimum). > > If we could come up with a proper API I would add this > to CVS immediately. However, I don't know about the scanning > features of the mt312, mt352 or other frontends. > Is there someone who does? As regards the API, I'd like to see some discussion on this list to find the best solution. As regards other frontends, mt312 is OK: I used a mt312 datasheet for my vp310, as until yesterday I didn't even know that I had a vp310 and not a mt312 (!). In fact, I've added a printk to avoid confusion. The frequency offset is probably available on many frontends. The auto sr is missing sometimes, IIRC the Skystar2 2.6 (so stv0299) can't do it. Here I'm talking about hardware capabilities, because nothing is implemented in other frontends, at first look. The sr ranges are really complicated, some details follow (more or less what I've written in the code). The mt312 has 12 bits, each one representing a range. These ranges are decimations of the system clock, for example the first range is SYSCLK/2 to SYSCLK/3, the second SYSCLK/3 to SYSCLK/4. So, they don't have the same linear or logarithmic size. Add to that that the SYSCLK is not well known, as the vp310 is switched between 60MHz and 90MHz, with 90MHz used only if sr>30Mbaud for power reasons. I decided to always switch to 60MHz when sr=auto and so the bands are fixed and blindscan can assume it's 60MHz (this means that auto sr works only up to 30Mbaud, I thought it was acceptable, as signals >27.5Mbaud are rare and definitively not transient). You put a 1 in the bit to activate searching in that range. Having too many bits on and activating distant ranges should work, but doesn't work in my tests (why? please test and report results). At the moment the userspace directly decides the 12 bits by asking for symbol rate 0x001-0xfff. This sucks because we're very hw specific and using values below the advertised symbol_rate_min. What I'm doing now is not uncorrect or dangerous, just not elegant. The frontend should refuse our sr, but the mt312 decides to accept it as it "understands the message". But if there is a different autosr frontend with an obviously different range selection, what happens? Userspace has to detect the frontend and switch its "language". If userspace has to be modified to support new hardware, the kernel is not doing his work. First idea: pass an approximation of the symbol rate and signal that we want auto search, for example using a negative number (-5000000 means around 5Mbaud). We could validate the absolute value against sr_min and sr_max and turn on one or maybe three ranges around the suggestion. This would be not hw specific, but functionality is lost. And sr is currently unsigned. Second idea: pass an interval (4-8Mbaud) and let the fe driver choose the bits. But pass how? By calling set frontends multiple time with a special pattern? Extending the API? Ugly, and functionality is lost in this case too. Better if multiple ranges could be specified, but how pass a list of intervals, or a list of symbol rates (each representing a +- x% interval)? 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. We could also specify that: - the frontend CAN refuse particular combinations of ranges - the frontend SHOULD ALWAYS accept a 1bit range which is not entirely out of sr_min-sr_max interval. - the frontend CAN lock on signals out of the specified ranges (the mt312 can't search between 25M and 30M without locking on a 22M) Obviously we'd have to define FE_CAN_SR_AUTO. No compatibility broken, good hardware independence. I'm open to comments on this matter. BTW, is there any other frontend on which auto sr can be achieved? I suspect we could let the mt312 write the rules and stop worrying. Regards. -- Roberto Ragusa mail at robertoragusa.it
