Messages in this thread | | | Date | Wed, 14 Apr 1999 11:09:16 -0400 (EDT) | From | "Frederick F. Gleason" <> | Subject | Re: RFC: RDS Extensions to Video4Linux API |
| |
On Wed, 14 Apr 1999, Martin Schaller wrote:
> 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/
| |