Date: Sat, 26 Jun 1999 13:11:27 -0400 From: Randall Hopper <aa8vb@ipass.net> To: Frode Vatvedt Fjeld <frodef@acm.org> Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: bt848 channel frequencies Message-ID: <19990626131127.A3726@ipass.net> In-Reply-To: <2hvhcb9ngw.fsf@dslab7.cs.uit.no>; from Frode Vatvedt Fjeld on Sat, Jun 26, 1999 at 02:05:03PM %2B0200 References: <374AA5BB.7C87D8C2@cs.strath.ac.uk> <2hogj9f0p6.fsf@dslab7.cs.uit.no> <3.0.6.32.19990626090820.007ad510@alicia.nttmcl.com> <2hemj0b617.fsf@dslab7.cs.uit.no> <2hzp2tfr3t.fsf@dslab7.cs.uit.no> <374AA5BB.7C87D8C2@cs.strath.ac.uk> <2hogj9f0p6.fsf@dslab7.cs.uit.no> <2hpv2kba67.fsf@dslab7.cs.uit.no> <19990625190008.A2443@ipass.net> <2hvhcb9ngw.fsf@dslab7.cs.uit.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Frode Vatvedt Fjeld:
|> 4) So it seems to me there are 2 levels of mapping that libtv needs to
|> handle:
|>
|> StationName -to- Frequency Name (configurable locally)
|> FrequencyName -to- Frequency (doesn't need configured)
|
|So you are saying that these are actually two more or less independent
|types of mappings that should be separated in the database and the
|API?
Separate in the DB?, yes. This is because the second mapping could be
statically delivered with FreeBSD/libtv, allowing the user to define the
first mapping in terms of the second (i.e. things they know, channel
numbers, in the US; channel names in Europe) rather than MHz frequencies.
The StationName-to-FreqName mapping is very, very user-location and
service-provider specific, so that wouldn't be delivered with the
OS/driver/libtv; just the FreqName-to-Freq mapping.
For example, for the frequency set NABCST, channel "7" (frequency name
"7") is always frequency <insert-frequency-here> -- 175.25MHz for
example. On the local cable channel here, this happens to be NBC:
NABCST: "NBC" -> "7" -> 175.25 MHz
Currently both StationName and FrequencyName (channel number) are displayed
on the TV window. Also, you can key in either "NBC" or "7" to get to this
station.
So these mappings would need to be available separately in the API as well.
Separate in the DB so the user can conveniently configure "NBC" to be
channel "7" rather than NBC is frequency 175.25MHz. Separate in the API so
the user can use either "NBC" or "7" to tune in 175.25MHz.
Here are a few Use Cases and possible ways they could be handled (just for
discussion purposes):
1) User is on a channel, and moves to the next channel with "+".
- App calls driver and gets current frequency
- This freq may or may not be a freq registered with a freq name
in libtv
- App calls libtv to get the frequency name which has a frequency
frequency higher and closest to the current frequency
- App calls libtv to get the station name of this frequency name
- App calls the driver and sets the frequency
- App displays the station name and frequency name in the TV window
Alternatively, libtv could just hand the mapping sets to
applications on startup, and let it do all the lookups. Up to you.
2) User keys in a channel number to change stations ("10").
- libtv gives app frequency and station name for freq name "10"
3) User keys in a station name to change stations ("UPN").
- libtv gives app frequency and frequency name for station "UPN".
4) User tunes to a specific frequency 147.225MHz.
- libtv gives app frequency name and station name for freq 147.225.
5) User changes from antenna to cable.
- get freq from driver
- libtv gives app what frequency name and station name
the current frequency maps to in the new channel set ("it doesn't"
is certainly one possibility).
Again, libtv might chose to just hand the mapping sets to applications on
startup, and let it do all the lookups in local arrays. I don't think we'd
really lose anything if we went this route, and it simplifies the libtv
API. Maybe something as simple as:
LIBTV_GetStationByIndex( int i, NAME *out1, FREQ_OR_FREQ_NAME *out2 )
LIBTV_GetFreqByIndex ( int i, NAME *out1, FREQ *out2 )
But it's up to you of course.
|That would give this scenario for anyone starting to use their new
|TV-card:
|
| 1. chose the frequency-name -> frequency mapping table
| 2. chose the station-name -> frequency-name mapping table
|
|..and that the second mapping table is useless without the first (if a
|basic frequency is what you are after).
The second mapping depends on the first, yes. As I see it, users could use
either the frequency name (channel number) or the station name to tune in a
station. Initially, there'd be no station names so they could only use
frequency names (channel numbers) or frequencies. Then, if they wanted to,
they could configure frequency names.
I only suggest the second mapping being managed by libtv because it is
something that should be sharable across all TV/tuner/radio clients, or the
user ends up duplicating this info in multiple places.
Example: A new user sets frequency set (NABCST) and has only Table 1. to
play with:
1. ...
"7" -> 175.25 MHz
"8" -> 181.25 MHz
...
User can tune channels by frequency name (channel number). No station
names exist yet, because they haven't set them up. E.g. on channel "7",
"+" goes to channel "8".
User then can optionally define station names:
2. ...
"NBC" -> "7"
"UPN" -> "8"
...
Oh, one more thing that just occurred to me. Sometimes folks have this
problem where the default frequency-name-to-frequency mappings don't quite
work for them even with AFC on, and when defining their station names, they
need to hard-wire the station name to a specific frequency rather than a
frequency name. For example:
1. ...
"N1" -> 175.25 Mhz
"NBC" -> "7"
"UPN" -> "8"
...
So in that station-name mapping table, it would be useful to be able to map
to either frequencies or to frequency names.
Hope this helps.
Randall
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990626131127.A3726>