> Hmmm. My idea was a bit different:
> Octet 0: LSB of Block A
> Octet 1: MSB of Block A
> Octet 2: LSB of Block B
> ...
> Octet 7: MSB of Block D
>
> with an ioctl which tells the kernel whether the user wants to see corrected
> and/or error packets.
I originally considered something similar, but decided on a more
minimalist approach. I'd as soon do all of the protocol-specific
processing (i.e. group layer and above) in user space, where debugging is
far easier and impact on memory footprint far less.
> Maybe we have to add a more flexible solution, since the capabilities of
> the hardware may be different.
> Possibilities I can imagine:
> 1. Raw Data
> For the simplest case where you get just the clock and data bit streams from
> the hardware. IMO the kernel should in this case only provide some basic
> synchronisation and left decoding/error correction to the user.
> 2. Semi cooked Data
> Your Example.
> 3. Cooked Data
> My example.
Only in the case of the Cadet, the syncronisation and error detection is
done in the hardware, so no "raw" format would be available. I think
these facilities need to be in the kernel, so as to at least be able to
ensure reliable data reception (e.g. TCP sockets).
> Additionally I think we need an user library which hides the details of
> the kernel access, completely decodes the packets (so you can, eg. get
> the station name, a list of alternate frequencies etc...) and allows some
> additional decoders to be loaded (pager module, etc...). Here in germany
> there is one station which transmits GPS differential corrections over
> RDS, and to get this information I started writing the rds decoder.
> Unfortunately the protocol isn't available, so I have to make some good
> guesses... Another interesting additional decoder is TMC (Traffic Message
> Channel), where traffic announcements are sent. They are sent as numbers
> instead of text, and all important streets/exits/etc.. and events (traffic
> jam...) are numbered, so it is possible to get the message in your language.
Agreed. This project is next on my list after I get the driver completed.
What I've got in mind is a system that would spawn a child process to
monitor the RDS datastream and then raise SIGUSR back to the parent when a
group of interest has been received. The data could then be read over a
pipe. What group types would be "of interest" (e.g. group 0, group 1,
etc.) would be defined as part of the call to initialize the system, so
the calling application doesn't have to be bothered with handling RDS data
types that it doesn't know/care about.
> What are MBS blocks?
MBS is a protocol that was a precursor to RDS. It is used in paging
systems. RDS was crafted to be able to coexist with it on the same
subcarrier. Details are in the RDS spec.
> Maybe we should also add an RDS private ioctl to and turn on/off rds decoding,
> since this may be cpu intensive (in the raw data example, the hardware may
> generate about 1100 interrupts/sec, which is too much if you only want the
> audio and not the rds data)
Good idea. Instead of an ioctl though, how about designing the driver so
that the RDS decode does not actually start until the initial read() on
the device? Accomplishes the same thing without the need for a special
ioctl, as nothing but an RDS-aware application will do a read() on a
/dev/radio device.
|Frederick F. Gleason, Jr.|WAVA Radio - 105 FM |Voice: 1-(703)-807-2266 |
| Chief Engineer |1901 N. Moore Street| FAX: 1-(703)-807-2248 |
| |Arlington, VA 22209 | Web: HTTP://www.wava.com|
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/