Hi,
 
>The whole problem with this is if any receiver complies strictly to >RDS/RBDS
then they would in fact read group C of B packets and use the PI >code because
the spec says so!

Yes Tom, but what does the specification really?
Is this must or want or can? Is it a safety redundancy or what?
(For 2B says simply : if you use this for RT, you have only 32 characters. No
one word about PI.)
It must be identical with block 1? What if they are different for whatever
reason? No "emergency exit" defined in the standard.

I think it is not absolutely clear why the second PI is placed here.
Therefore we will never see who or what it uses and why.
EON also does not use it. The EON functions have no relation to the 2nd PI.

After 25 years of non-use we should be so brave and delete it.

>Ok.. so lets go with the assumption  that everyone, especially the RDS >Forum,
is on board with redefining Group B packets (with the exception of >EON), then
what? We're not really freeing up bandwidth because all we're >doing is opening
more ODA channels. I doubt any given station around the >world is utilizing
every available ODA group so getting another 12 more >won't get us anywhere.

However, we can simply say that the added PI was well intentioned, but not used,
and we simplify the matter.
The RBDS colleagues have done with their 15A.
The wise use of the freed groups coming automatically.

> I've noticed the iPod Nano does not show ........

Apple - oohh US system guys... a "gated community" - the next RDS implementation
for IPods & IPhone will be better ... guaranted :-)) (and coming from Europe)
But it is not a question of compatibility.

>Also, a change of this magnitude will mostly impact manufactures of
>encoders and decoders and products that utilize RDS, with a much lesser
>impact on the broadcaster and the consumer. Is anyone on this yahoogroup >
>a manufacturer?

We've just noticed that defacto nobody uses B groups.
So the effect is correspondingly small.
Special applications should be insert the PI itself for compatibility, if
necessary, or left the Field simply "blank".
New applications will take advantage of the larger B-groups, but this is the
future


Regards
Attila Ladanyi


--- On Mon, 12/7/09, Tom Pittenger <tpittenger@...> wrote:


From: Tom Pittenger <tpittenger@...>
Subject: Re: [rdsforum] Re: simple question
To: rdsforum@yahoogroups.com
Date: Monday, December 7, 2009, 1:53 PM

>> Okay, I agree, if changing the structure of B blocks does not affect
>> any existing receiver, then no problem to do it. I guess this would
>> have to be explicitly confirmed by extensive tests, though

The whole problem with this is if any receiver complies strictly to RDS/RBDS
then they would in fact read group C of B packets and use the PI code because
the spec says so! I doubt any products do this, just like everyone else on this
forum, but if we move forward with this then what we will be testing for is if
products do not comply strictly with the current standard. For the most part no
one will care but lets not forget that if they don't comply with this minor
detail then what other minor details are being overlooked in any given RDS/RBDS
product?

Ok.. so lets go with the assumption  that everyone, especially the RDS Forum,
is on board with redefining Group B packets (with the exception of EON), then
what? We're not really freeing up bandwidth because all we're doing is opening
more ODA channels. I doubt any given station around the world is utilizing every
available ODA group so getting another 12 more won't get us anywhere. 


Maybe these new B packets can be protocol specific? I've seen several stations
using protocols like RT+ and TMC on similar groups. That is, on a given station
TMC/RT+ is on group 8A/10A and on another station broadcasting only RT+ on group
8A. With "new" group B packets, maybe all new "official" ODA packets be group B
to help organize the traffic? (On a related note, I've noticed the iPod Nano
does not show RT+ data if it's on group 8 & 9, Zune is ok).


Also, a change of this magnitude will mostly impact manufactures of
encoders and decoders and products that utilize RDS, with a much lesser
impact on the broadcaster and the consumer. Is anyone on this yahoogroup >
a manufacturer?


-Tom



On Mon, Dec 7, 2009 at 10:06 AM, Christophe Jacquet <jacquetc.listes@ free.fr>
wrote:


 



Hi,

Okay, I agree, if changing the structure of B blocks does not affect
any existing receiver, then no problem to do it. I guess this would
have to be explicitly confirmed by extensive tests, though.

Regards.

Christophe.




On Mon, Dec 7, 2009 at 10:25, Attila Ladanyi <attila.ladanyi@ yahoo.com> wrote:
>
>
>
> Hi,
>
> > I have no idea how existing receivers behave. So according to you they
> > ignore the groups they have not been designed to handle? If this is
> > right, then there is indeed no problem to change the meaning of group
> > 3 in B groups.
>
> I never saw a radio, the has used any B-group, except for EON and there is
primarily for European chains. Hardly to be found in the world.
> EON is specified in the RDS-standard an can be used without modification.
>
> > What worries me however, is that the RDS standard hints that PI codes,
> > either in A or B groups, may be decoded regardless of the group:
>
> No problem. The first Group is PI.
>
> > " The PI, PTY and TP codes can be decoded without reference to any
> > block outside the one that contains the
> > information. This is essential to minimize acquisition time for these
> > kinds of message [...]
>
> No problem. These flags are only in the second group. No difference between A
and B groups.
>
> > The occurrence of offset C' in block 3 of any
> > group can then be used to indicate directly that block 3 is a PI code,
> > without any reference to the value of B0 in block 2. " (1999 standard,
> > p. 16)
>
> This is a wasted opportunity. We can withdraw it without replacement.
>
> >So if someone broadcasts, say, a 13B group with various data in block
> >3, maybe some standard-compliant receivers would believe it is a PI
> >code, even though they were not specifically designed to decode 13B
> >groups. This is what I called the "backward compatibility" issue.
>
> This someone has the PI code several times.
> 13B is not defined as a core function and not reserved for ODA.
> It could also have been a bit error. What then?
> Why should he look for something that is extremely rare, and has never  been
used?
> He has 50% - 100% of cases the groups 0A and 2A in the multiplex.
>
> >Do you confirm that receivers that have been available on the market
> >actually discard any group that they do not specifically know?
>
> Since 1995 I had never a radio, who has implemented all the possible features.
> The only use of B-group is defined in the standard. This can be left so, and
we can free the field for the second PI.
>
> From the developer point of view today:
> PI is already in the 1st Group, we forget the code for
> the query of the 3rd Group.
> We save space and processing power.
>
> Why waste the transport capacity?
>
> Regards.
> Attila Ladanyi





--
-Tom Pittenger
tpittenger@ieee. org

Hi,
 
D'accord,  we all could check it first in our environment.

I ask the IRT for the D,A,CH Market and check the car radios from
Daimler, Audi and VW.
I have a lot of car radios near my desk. Does anyone know a useful application
with B groups?
Currently I can only send a lot of useless B-groups.
these are rejected by all of the the tuners.

Regards
Attila Ladanyi



--- On Mon, 12/7/09, Christophe Jacquet <jacquetc.listes@...> wrote:


From: Christophe Jacquet <jacquetc.listes@...>
Subject: Re: [rdsforum] Re: simple question
To: rdsforum@yahoogroups.com
Date: Monday, December 7, 2009, 1:06 PM


 



Hi,

Okay, I agree, if changing the structure of B blocks does not affect
any existing receiver, then no problem to do it. I guess this would
have to be explicitly confirmed by extensive tests, though.

Regards.

Christophe.

On Mon, Dec 7, 2009 at 10:25, Attila Ladanyi <attila.ladanyi@ yahoo.com> wrote:
>
>
>
> Hi,
>
> > I have no idea how existing receivers behave. So according to you they
> > ignore the groups they have not been designed to handle? If this is
> > right, then there is indeed no problem to change the meaning of group
> > 3 in B groups.
>
> I never saw a radio, the has used any B-group, except for EON and there is
primarily for European chains. Hardly to be found in the world.
> EON is specified in the RDS-standard an can be used without modification.
>
> > What worries me however, is that the RDS standard hints that PI codes,
> > either in A or B groups, may be decoded regardless of the group:
>
> No problem. The first Group is PI.
>
> > " The PI, PTY and TP codes can be decoded without reference to any
> > block outside the one that contains the
> > information. This is essential to minimize acquisition time for these
> > kinds of message [...]
>
> No problem. These flags are only in the second group. No difference between A
and B groups.
>
> > The occurrence of offset C' in block 3 of any
> > group can then be used to indicate directly that block 3 is a PI code,
> > without any reference to the value of B0 in block 2. " (1999 standard,
> > p. 16)
>
> This is a wasted opportunity. We can withdraw it without replacement.
>
> >So if someone broadcasts, say, a 13B group with various data in block
> >3, maybe some standard-compliant receivers would believe it is a PI
> >code, even though they were not specifically designed to decode 13B
> >groups. This is what I called the "backward compatibility" issue.
>
> This someone has the PI code several times.
> 13B is not defined as a core function and not reserved for ODA.
> It could also have been a bit error. What then?
> Why should he look for something that is extremely rare, and has never  been
used?
> He has 50% - 100% of cases the groups 0A and 2A in the multiplex.
>
> >Do you confirm that receivers that have been available on the market
> >actually discard any group that they do not specifically know?
>
> Since 1995 I had never a radio, who has implemented all the possible features.
> The only use of B-group is defined in the standard. This can be left so, and
we can free the field for the second PI.
>
> From the developer point of view today:
> PI is already in the 1st Group, we forget the code for
> the query of the 3rd Group.
> We save space and processing power.
>
> Why waste the transport capacity?
>
> Regards.
> Attila Ladanyi

Hi,

Okay, I agree, if changing the structure of B blocks does not affect
any existing receiver, then no problem to do it. I guess this would
have to be explicitly confirmed by extensive tests, though.

Regards.

Christophe.


On Mon, Dec 7, 2009 at 10:25, Attila Ladanyi <attila.ladanyi@...> wrote:
>
>
>
> Hi,
>
> > I have no idea how existing receivers behave. So according to you they
> > ignore the groups they have not been designed to handle? If this is
> > right, then there is indeed no problem to change the meaning of group
> > 3 in B groups.
>
> I never saw a radio, the has used any B-group, except for EON and there is
primarily for European chains. Hardly to be found in the world.
> EON is specified in the RDS-standard an can be used without modification.
>
> > What worries me however, is that the RDS standard hints that PI codes,
> > either in A or B groups, may be decoded regardless of the group:
>
> No problem. The first Group is PI.
>
> > " The PI, PTY and TP codes can be decoded without reference to any
> > block outside the one that contains the
> > information. This is essential to minimize acquisition time for these
> > kinds of message [...]
>
> No problem. These flags are only in the second group. No difference between A
and B groups.
>
> > The occurrence of offset C' in block 3 of any
> > group can then be used to indicate directly that block 3 is a PI code,
> > without any reference to the value of B0 in block 2. " (1999 standard,
> > p. 16)
>
> This is a wasted opportunity. We can withdraw it without replacement.
>
> >So if someone broadcasts, say, a 13B group with various data in block
> >3, maybe some standard-compliant receivers would believe it is a PI
> >code, even though they were not specifically designed to decode 13B
> >groups. This is what I called the "backward compatibility" issue.
>
> This someone has the PI code several times.
> 13B is not defined as a core function and not reserved for ODA.
> It could also have been a bit error. What then?
> Why should he look for something that is extremely rare, and has never  been
used?
> He has 50% - 100% of cases the groups 0A and 2A in the multiplex.
>
> >Do you confirm that receivers that have been available on the market
> >actually discard any group that they do not specifically know?
>
> Since 1995 I had never a radio, who has implemented all the possible features.
> The only use of B-group is defined in the standard. This can be left so, and
we can free the field for the second PI.
>
> From the developer point of view today:
> PI is already in the 1st Group, we forget the code for
> the query of the 3rd Group.
> We save space and processing power.
>
> Why waste the transport capacity?
>
> Regards.
> Attila Ladanyi

Hi,

> I have no idea how existing receivers behave. So according to you they
> ignore the groups they have not been designed to handle? If this is
> right, then there is indeed no problem to change the meaning of group
> 3 in B groups.
 
I never saw a radio, the has used any B-group, except for EON and there is
primarily for European chains. Hardly to be found in the world.
EON is specified in the RDS-standard an can be used without modification.

> What worries me however, is that the RDS standard hints that PI codes,
> either in A or B groups, may be decoded regardless of the group:
 
No problem. The first Group is PI.

> " The PI, PTY and TP codes can be decoded without reference to any
> block outside the one that contains the
> information. This is essential to minimize acquisition time for these
> kinds of message [...]
 
No problem. These flags are only in the second group. No difference between A
and B groups.
 
> The occurrence of offset C' in block 3 of any
> group can then be used to indicate directly that block 3 is a PI code,
> without any reference to the value of B0 in block 2. " (1999 standard,
> p. 16)

This is a wasted opportunity. We can withdraw it without replacement.

>So if someone broadcasts, say, a 13B group with various data in block
>3, maybe some standard-compliant receivers would believe it is a PI
>code, even though they were not specifically designed to decode 13B
>groups. This is what I called the "backward compatibility" issue.
 
This someone has the PI code several times.
13B is not defined as a core function and not reserved for ODA.
It could also have been a bit error. What then?
Why should he look for something that is extremely rare, and has never  been
used?
He has 50% - 100% of cases the groups 0A and 2A in the multiplex.

>Do you confirm that receivers that have been available on the market
>actually discard any group that they do not specifically know?

Since 1995 I had never a radio, who has implemented all the possible features.
The only use of B-group is defined in the standard. This can be left so, and we
can free the field for the second PI.

From the developer point of view today:
PI is already in the 1st Group, we forget the code for
the query of the 3rd Group.
We save space and processing power.

Why waste the transport capacity?


Regards.
Attila Ladanyi
 
 


--- On Thu, 12/3/09, Christophe Jacquet <jacquetc.listes@...> wrote:


From: Christophe Jacquet <jacquetc.listes@...>
Subject: Re: [rdsforum] Re: simple question
To: rdsforum@yahoogroups.com
Date: Thursday, December 3, 2009, 4:17 PM


 



Hi,

I have no idea how existing receivers behave. So according to you they
ignore the groups they have not been designed to handle? If this is
right, then there is indeed no problem to change the meaning of group
3 in B groups.

What worries me however, is that the RDS standard hints that PI codes,
either in A or B groups, may be decoded regardless of the group:

" The PI, PTY and TP codes can be decoded without reference to any
block outside the one that contains the
information. This is essential to minimize acquisition time for these
kinds of message [...] The occurrence of offset C' in block 3 of any
group can then be used to indicate directly that block 3 is a PI code,
without any reference to the value of B0 in block 2. " (1999 standard,
p. 16)

So if someone broadcasts, say, a 13B group with various data in block
3, maybe some standard-compliant receivers would believe it is a PI
code, even though they were not specifically designed to decode 13B
groups. This is what I called the "backward compatibility" issue.

Do you confirm that receivers that have been available on the market
actually discard any group that they do not specifically know?

Regards.

Christophe. — http://rds-surveyor .sourceforge. net/

On Thu, Dec 3, 2009 at 14:53, Attila Ladanyi <attila.ladanyi@ yahoo.com> wrote:
>
>
>
> Hi All, hi Christophe,
>
> You wrote:
> > However, it is well possible that some existing radio sets out there
> > actually use/interpret the second PI code when receiving B groups.
>
> Chips and Chipsets are definitely transparent. These must be even transparent!
> Applications are the equivalent of the transmitted data. These can remains use
it, just
> need to fill in themselves. (UECP-question, dot a decoder question)
> No application will use untested foreign data. If they do, it is a bug.
> What you fill in the encoder is what you get from decoder.
>
> > In these conditions, transmitting "new B groups" with arbitrary data
> > instead of the second PI code would definitely confuse these
> > receivers. So for backward compatibility reasons, it may not be
> > possible to change the standard regarding B groups.
>
> There is no compulsion for backwards compatibility. B-groups are not
systemically important. The B-group - C-block is only prefilled, without ever
tested somewhere.
> The transfer is transparent and the recipients must know what they get.
> By the way: what functions should be irritated, when we after 25 years no one
knows?
>
> Yes, it may be that the additional group names are not currently needed.
> Their blockade is also not necessary. I think the run on ODA still coming
soon.
>
> > I'm not sure what you mean by " if you can't read the "A" Block the
additional PI is also useless..... .......
>
> I mean, usually when the PI code is unreadable or wrong, normally you discard
the entire block before you realise, that this had coincidentally a second PI.
> It may be wrong, but hardly anyone expects B-groups in the stream, exept
special case like EON. And this is part of the core, not of the additional data
services. The compatibility problem can be solved in the UECP and encoder part.
>
> Regards
> Attila Ladanyi

Hi,

I have no idea how existing receivers behave. So according to you they
ignore the groups they have not been designed to handle? If this is
right, then there is indeed no problem to change the meaning of group
3 in B groups.

What worries me however, is that the RDS standard hints that PI codes,
either in A or B groups, may be decoded regardless of the group:

" The PI, PTY and TP codes can be decoded without reference to any
block outside the one that contains the
information.  This is essential to minimize acquisition time for these
kinds of message [...] The occurrence of offset C' in block 3 of any
group can then be used to indicate directly that block 3 is a PI code,
without any reference to the value of B0 in block 2. " (1999 standard,
p. 16)

So if someone broadcasts, say, a 13B group with various data in block
3, maybe some standard-compliant receivers would believe it is a PI
code, even though they were not specifically designed to decode 13B
groups. This is what I called the "backward compatibility" issue.

Do you confirm that receivers that have been available on the market
actually discard any group that they do not specifically know?

Regards.

Christophe. — http://rds-surveyor.sourceforge.net/


On Thu, Dec 3, 2009 at 14:53, Attila Ladanyi <attila.ladanyi@...> wrote:
>
>
>
> Hi All, hi Christophe,
>
> You wrote:
> > However, it is well possible that some existing radio sets out there
> > actually use/interpret the second PI code when receiving B groups.
>
> Chips and Chipsets are definitely transparent. These must be even transparent!
> Applications are the equivalent of the transmitted data. These can remains use
it, just
> need to fill in themselves. (UECP-question, dot a decoder question)
> No application will use untested foreign data. If they do, it is a bug.
> What you fill in the encoder is what you get from decoder.
>
> > In these conditions, transmitting "new B groups" with arbitrary data
> > instead of the second PI code would definitely confuse these
> > receivers. So for backward compatibility reasons, it may not be
> > possible to change the standard regarding B groups.
>
> There is no compulsion for backwards compatibility. B-groups are not
systemically important. The B-group - C-block is only prefilled, without ever
tested somewhere.
> The transfer is transparent and the recipients must know what they get.
> By the way: what functions should be irritated, when we after 25 years no one
knows?
>
> Yes, it may be that the additional group names are not currently needed.
> Their blockade is also not necessary. I think the run on ODA still coming
soon.
>
> > I'm not sure what you mean by " if you can't read the "A" Block the
additional PI is also useless............
>
> I mean, usually when the PI code is unreadable or wrong, normally you discard
the entire block before you realise, that this had coincidentally a second PI.
> It may be wrong, but hardly anyone expects B-groups in the stream, exept
special case like EON. And this is part of the core, not of the additional data
services. The compatibility problem can be solved in the UECP and encoder part.
>
> Regards
> Attila Ladanyi

Hi All, hi Christophe,

You wrote:
> However, it is well possible that some existing radio sets out there
> actually use/interpret the second PI code when receiving B groups.

Chips and Chipsets are definitely transparent. These must be even transparent!
Applications are the equivalent of the transmitted data. These can remains use
it, just
need to fill in themselves. (UECP-question, dot a decoder question)
No application will use untested foreign data. If they do, it is a bug.
What you fill in the encoder is what you get from decoder.

> In these conditions, transmitting "new B groups" with arbitrary data
> instead of the second PI code would definitely confuse these
> receivers. So for backward compatibility reasons, it may not be
> possible to change the standard regarding B groups.

There is no compulsion for backwards compatibility. B-groups are not
systemically important.  The B-group - C-block is only prefilled, without ever
tested somewhere.
The transfer is transparent and the recipients must know what they get.
By the way: what functions should be irritated, when we after 25 years no one
knows?

Yes, it may be that the additional group names are not currently needed.
Their blockade is also not necessary. I think the run on ODA still coming soon.

> I'm not sure what you mean by " if you can't read the "A" Block the additional
PI is also useless............

I mean, usually when the PI code is unreadable or wrong, normally you discard
the entire block before you realise, that this had coincidentally a second PI.
It may be wrong, but hardly anyone expects B-groups in the stream, exept special
case like EON. And this is part of the core, not of the additional data
services. The compatibility problem can be solved in the UECP and encoder part.

Regards
Attila Ladanyi







--- On Thu, 12/3/09, Christophe Jacquet <jacquetc.listes@...> wrote:


From: Christophe Jacquet <jacquetc.listes@...>
Subject: Re: [rdsforum] Re: simple question
To: rdsforum@yahoogroups.com
Date: Thursday, December 3, 2009, 6:51 AM


Correction: please replace "B block" with "B group" in the above
message, just as below:

> Hi,
>
> I agree, as B groups are almost never used in practice, it was
> definitely not needed to have this repetition of the PI code. I guess
> the RDS designers were extra-cautious here, but in practice no one
> ever used the possibility to increase the repetition rate of PI
> codes...
>
> However, it is well possible that some existing radio sets out there
> actually use/interpret the second PI code when receiving B groups. In
> these conditions, transmitting "new B groups" with arbitrary data
> instead of the second PI code would definitely confuse these
> receivers. So for backward compatibility reasons, it may not be
> possible to change the standard regarding B groups.
>
> I'm not sure what you mean by " if you can't read the "A" Block the
> additional PI is also useless. ". Do you mean that if you can't read
> block 2 (which contains the group type code and A/B-version flag),
> then you can't read the PI code in block 3, in case of a B group,
> because you don't know it is a B group? This is not the case,
> actually, as B groups use an offset word for block 3 different from
> that used for A groups (the offset word is C' instead of C). So there
> is a low-level means of identifying B groups, even when all blocks but
> block 3 are missing. In this way, if in a B group you get only block 1
> you can extract the PI (present in all groups regardless of group
> type), and if you get only block 3 you can still extract the PI
> (because the special C' offset word of block 3 is sufficient to
> identify a B group). So yes, in poor conditions using B groups could
> truly speed up decoding of PI. But again, no one ever needed to do
> this in practice.
>
> As a side note, in the latest edition of the RDS standard, group 15A
> is no longer reserved for compatibility with older RBDS versions: now
> it can be used freely for ODA. So as of 2009, 5A, 6A, 7A, 8A, 9A, 11A,
> 12A, 13A, 15A groups may be used for ODA (and possibly paging, IH,
> TDC, EWS). 9 types of groups: I think it is quite a lot, so we don't
> desperately need new types of groups.
>
> Regards.
>
> Christophe. – http://rds-surveyor .sourceforge. net/

Correction: please replace "B block" with "B group" in the above
message, just as below:

> Hi,
>
> I agree, as B groups are almost never used in practice, it was
> definitely not needed to have this repetition of the PI code. I guess
> the RDS designers were extra-cautious here, but in practice no one
> ever used the possibility to increase the repetition rate of PI
> codes...
>
> However, it is well possible that some existing radio sets out there
> actually use/interpret the second PI code when receiving B groups. In
> these conditions, transmitting "new B groups" with arbitrary data
> instead of the second PI code would definitely confuse these
> receivers. So for backward compatibility reasons, it may not be
> possible to change the standard regarding B groups.
>
> I'm not sure what you mean by " if you can't read the "A" Block the
> additional PI is also useless. ". Do you mean that if you can't read
> block 2 (which contains the group type code and A/B-version flag),
> then you can't read the PI code in block 3, in case of a B group,
> because you don't know it is a B group? This is not the case,
> actually, as B groups use an offset word for block 3 different from
> that used for A groups (the offset word is C' instead of C). So there
> is a low-level means of identifying B groups, even when all blocks but
> block 3 are missing. In this way, if in a B group you get only block 1
> you can extract the PI (present in all groups regardless of group
> type), and if you get only block 3 you can still extract the PI
> (because the special C' offset word of block 3 is sufficient to
> identify a B group). So yes, in poor conditions using B groups could
> truly speed up decoding of PI. But again, no one ever needed to do
> this in practice.
>
> As a side note, in the latest edition of the RDS standard, group 15A
> is no longer reserved for compatibility with older RBDS versions: now
> it can be used freely for ODA. So as of 2009, 5A, 6A, 7A, 8A, 9A, 11A,
> 12A, 13A, 15A groups may be used for ODA (and possibly paging, IH,
> TDC, EWS). 9 types of groups: I think it is quite a lot, so we don't
> desperately need new types of groups.
>
> Regards.
>
> Christophe. – http://rds-surveyor.sourceforge.net/

Hi,

I agree, as B groups are almost never used in practice, it was
definitely not needed to have this repetition of the PI code. I guess
the RDS designers were extra-cautious here, but in practice no one
ever used the possibility to increase the repetition rate of PI
codes...

However, it is well possible that some existing radio sets out there
actually use/interpret the second PI code when receiving B groups. In
these conditions, transmitting "new B groups" with arbitrary data
instead of the second PI code would definitely confuse these
receivers. So for backward compatibility reasons, it may not be
possible to change the standard regarding B groups.

I'm not sure what you mean by " if you can't read the "A" Block the
additional PI is also useless. ". Do you mean that if you can't read
block 2 (which contains the group type code and A/B-version flag),
then you can't read the PI code in block 3, in case of a B block,
because you don't know it is a B block? This is not the case,
actually, as B blocks use an offset word for block 3 different from
that used for A groups (the offset word is C' instead of C). So there
is a low-level means of identifying B blocks, even when all blocks but
block 3 are missing. In this way, if in a B group you get only block 1
you can extract the PI (present in all groups regardless of group
type), and if you get only block 3 you can still extract the PI
(because the special C' offset word of block 3 is sufficient to
identify a B group). So yes, in poor conditions using B groups could
truly speed up decoding of PI. But again, no one ever needed to do
this in practice.

As a side note, in the latest edition of the RDS standard, group 15A
is no longer reserved for compatibility with older RBDS versions: now
it can be used freely for ODA. So as of 2009, 5A, 6A, 7A, 8A, 9A, 11A,
12A, 13A, 15A groups may be used for ODA (and possibly paging, IH,
TDC, EWS). 9 types of groups: I think it is quite a lot, so we don't
desperately need new types of groups.

Regards.

Christophe. – http://rds-surveyor.sourceforge.net/


On Wed, Dec 2, 2009 at 22:15, Attila Ladanyi <attila.ladanyi@...> wrote:
>
>
>
> Hi All!
>
> Yes Chris, it is true. I'm living in the SWR Area, I can see it.
>
> As I see, nobody uses the B groups for "ODA" in the world. Only in an
exceptional case like Group 15, because 15A is locked by RBDS. Also in case of
3.2.1.8.2, EON  - but 14B is not necessarily dependent on the second PI.
>
> We can't realy use a lot of groups for "ODA". Reason for this is the loss of
space because of the second PI code. This is never necessary, also not for EON.
The PI code will be received more than 11 times per second, if you can't read
the "A" Block the additional PI is also useless.
>
> I propose, that we pull out this second PI from RDS-standard. ( Sometime
during next opportunity.)
> Should still give applications who need it, you can freely insert.(maybe 14B)
> We obtain a number of other ODA groups with full efficiency.
> Similarly, the selections bit (5.) will no longer be just ballast in block
"B".
>
> Regards
>
> Attila

Hi everybody,

Actually, B-type groups are required for EON to work. Namely, to
command receivers to switch to a traffic message being broadcast on an
Other Network, you must send 14B groups (see the standard, 1999 ed.,
paragraph 3.2.1.8.2).

Also, I have noticed that some stations (namely SWR1 in Germany) send
bunches of 15B groups when switching TA on/off.

Apart from this, no ODA has been registered with B-type groups so far.

Regards.

Christophe Jacquet — http://rds-surveyor.sourceforge.net/


--- In rdsforum@yahoogroups.com, Bev MARKS <bevm@...> wrote:
>
> Attila
>
> Good to hear from you via this Group!
>
> I do not know of any use of Type B Groups.
>
> Indeed I suspect that the RDS Forum would take a very negative view to
> any suggestion to use Type B Groups, which have not seen favour over the
> last 20+ years of RDS developments.  Reading between the lines of your
> question, I suppose you are thinking about a new RDS feature or
> application - in which case just use an ODA and register with the RDS
> Forum - giving much implementation freedom.
>
> Bev
> --
> Mr Bev MARKS, Holly Blue Associates - consulting broadcast engineers
> Mobile: +44 7785 23 64 68
> E-mail: bevm@...
> Skype: bevm1066
> Twitter: bevm 1066
>

Hi everybody,

Actually, B-type groups are required for EON to work. Namely, to
command receivers to switch to a traffic message being broadcast on an
Other Network, you must send 14B groups (see the standard, 1999 ed.,
paragraph 3.2.1.8.2).

Also, I have noticed that some stations (namely SWR1 in Germany) send
bunches of 15B groups when switching TA on/off.

Apart from this, no ODA has been registered with B-type groups so far.

Regards.

Christophe Jacquet — http://rds-surveyor.sourceforge.net/


On Wed, Nov 25, 2009 at 15:02, Bev MARKS <bevm@...> wrote:
>
>
>
> Attila
>
> Good to hear from you via this Group!
>
> I do not know of any use of Type B Groups.
>
> Indeed I suspect that the RDS Forum would take a very negative view to any
suggestion to use Type B Groups, which have not seen favour over the last 20+
years of RDS developments.  Reading between the lines of your question, I
suppose you are thinking about a new RDS feature or application - in which case
just use an ODA and register with the RDS Forum - giving much implementation
freedom.

Hi All,

The B-type group contains an additional PI code.
Is this required for some application or is there only for historical reasons?
Requires someone the B-type groups?

regards
Attila Ladanyi

Very curious about this myself. Anyone have any idea?  Back in 2006 the estimate
was two out of every five vehicles.

--- In rdsforum@yahoogroups.com, "nso823" <novadia@...> wrote:
>
> I work for a broadcaster in the US and I'm trying to figure out how many cars
on the road right now in the US have RDS.
>
> Does anyone know how/where I can find this out?
>
> Thanks!
>
> -Nicole
>