On 5 Sep 2013, at 01:23, Vincent Chen
<[email protected]<mailto:[email protected]>> wrote:
- The encoding uses an array, for example (thanks for the catch, Dan!):
[
{ "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },
{ "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },
{ "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },
{ "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
{ "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },
{ "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },
{ "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 },
{ "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 }
]
- Even for regulatory domains that do not compute a level for all channels,
there are still generalized (absolute) limits on unintended EM emissions, so
there should be no need to use special values, such as -inf, null, etc. for
indicating the "unavailable" ranges.
Should we adopt this more general encoding over the "channelized" encoding in
Draft 06?
I don't like it at all.
The questions I raised about the "Bw" part of "maxPsdDbmPerBw" and the exact
mechanism of how to encode multiple bandwidth PSDs are still unanswered.
It *appears* that "Bw" is supposed to be the delta between the current entry
and the previous entry? Not only does this result in a potential
division-by-zero that has to be detected, it would seem that to encode the
OFCOM/ETSI rules that require a PSD over 100 kHz would require an entry (or in
fact a pair of entries) for *every single 100 kHz subchannel* within the band.
Also, I'm pretty certain that the OFCOM/ETSI model will actually result in
channels that simply cannot be used. We haven't seen the DTT sample data yet
but previous conversations have strongly suggested that in certain squares they
will not permit any transmissions in certain channels. This simple contiguous
set of power vs frequency points cannot encode that.
Ray
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
