> Then let the driver provide interpreted data is the only way I can see
> to provide a common interface to userspace, althrouth this might become
> a dirty job for the cadet driver depending on what needs to be done to
> parse the stuff...
There are a lot of things that can be decoded from the bitstream. What's
available depends on the type of blocks being sent to us by the
broadcaster. The most useful ones that come to mind right off are:
- Program type (PTY) - News, Rock, other descriptions for what's on
- Program name - 8 chars, usually a station's nickname ("MAGIC FM")
- Radiotext - up to 64 chars, sometimes a song name (depends on source)
- Call sign - Kxxx or Wxxx in this country. Not sure for others...
- Clock - Assuming they have a good source, then you can sync from them
Some of these elements occur more than others in the transmissions. The
PTY, for example, is supposed to be in every type of block they send out.
Things like the radiotext only show up once every few seconds.
There are also interesting things like the traffic program / traffic
announcement flags, which are genuinely useful when clueful broadcasters
are in command. The intended purpose is to pause a CD or similar in order
to let you hear their traffic report. Around here nobody actually uses
it, so it's just a vaporware feature at best.
I can rig some code to parse the raw bits and turn it into useful data,
but we'll need a clear structure for storing it. It would also be nice to
be able to convey things directly to userspace for people with this card,
since many of the blocks are defined by the broadcaster - that is, no
existing format.
Perhaps a series of types within the struct would be best... highlevel
types like "program name" would be on both cards, but there could also be
low level types like "3A open data application raw data" for the Cadet.
