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
>

Someone posted this back in March, but there were no replies on it. Thought I
would toss the line out again and see if anyone knew the answer. How many
vehicles on the road right now in the US are RDS-Ready?  The best I can tell was
a study back in 2006 that showed two out of five... but I'm not sure where the
estimate is today...

BR wrote

"- USB-interface is a must today, RS-ports are rare in PCs."

It depends on the intended audience, in the lab I work in all PCs and
laptops have real serial ports.
We find it easier to connect to equipment with this interface as no
drivers are required.
The interface is pretty much OS agnostic so we have flexibility there as
well.

If this is to be a consumer device then I supose the comment is correct,
but I wish it wasn't
USB has caused me nothing but headaches at work!

2-WCOM still have a serial port on their equpient

Derek


============================================
Derek Philip
Software Test engineer


Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Thanks for all the good info.  I'll take this into account!



--- In rdsforum@yahoogroups.com, Notareal <not_a_real@...> wrote:
>
>
> Hi !
>
> Because conrad rds manager is no longer manufactured,
>
> so I made PC-interface according to schematics "RDS Decoder by Puskas
Barnabas".
>
>
>
> Maybe you should ask also from forums that are dedicated to FM-DX and DXing.
>
> For example: http://www.hard-core-dx.com/
>
> Some notes
>
> - USB-interface is a must today, RS-ports are rare in PCs.
>
> - also easy software connection at least to excel, many DXer is using RDSDX or
Esslinger decoder-software
>
>
>
> See also:
>
> http://home.scarlet.be/~wijnherm/conrad.htm
>
>
>
> BR
>
>
>
>
>
> To: rdsforum@yahoogroups.com
> From: ray_h_dees@...
> Date: Wed, 30 Sep 2009 15:46:44 +0000
> Subject: [rdsforum] RDS Decoder
>
>
>
>
>
> Is there any interest in a commercially available RDS decoder? I currently
have a working prototype and am seeking information on how may people would be
interested in one.
>
> It can mimmick the Conrad RDS Manager or could have many more functions,
including a USB interface.
>
> Please let me know.
>
> Thanks
>
>
>
>
>
>
>
>
>
> _________________________________________________________________
> More than messages–check out the rest of the Windows Live™.
> http://www.microsoft.com/windows/windowslive/
>

I was sort of leaning towards USB so it could be powered also.  I've uploaded a
few pictures (not very good ones) of the display.  It's in the album - RDS
Decoder.



--- In rdsforum@yahoogroups.com, "Derek Philip" <derek.philip@...> wrote:
>
> Hi Ray
>
> Any details?
>
> A simple uart would be my prefrence, no drivers requuired.
>
>
> Derek
>
> ============================================
> Derek Philip
> Software Test engineer
>
>
>
> Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
>

Hi Ray

Any details?

A simple uart would be my prefrence, no drivers requuired.


Derek

============================================
Derek Philip
Software Test engineer



Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Is there any interest in a commercially available RDS decoder?  I currently have
a working prototype and am seeking information on how may people would be
interested in one.

It can mimmick the Conrad RDS Manager or could have many more functions,
including a USB interface.

Please let me know.

Thanks

I am playing with an RDS/RDBS decoder in the US and finding that PI
codes for some stations are not what the 1998 RDBS standard says they
should be. Many of them are off in a similar way, and I can think of
several possible reasons (in order of increasing likelihood):

1. The standard changed and I haven't found the info.
2. Some common broadcast hardware is either intentionally or erroneously
not following the standard.
3. The decoding hardware I am using has some problem (I am using SiLabs
SI4705 chips).
4. My software has some bug.

In order to narrow this down I am wondering if others in the US have
seen anything like what I describe below. Problem examples:

Example 1
-------------
KUBE in Seattle, WA

Following the RDBS standard, I calculate:
20*676 + 1*26 + 4 + 4096 = 17646
HEX: 44EE

What I actually decode is:
HEX: 14EE

Example 2
-------------
WKLS in  Atlanta, GA

Following RDBS standard, I calculate:
10*676 + 11*26 + 18 + 21672 = 28736
HEX: 7040
0 in 2nd nibble:  7040 =>  A740

What I actually decode is:
HEX: 1740

Example 3
-------------
KJR in Seattle, WA

RDBS table D.4 PI value:
HEX: 995A

What I actually decode:
HEX: 195A

The common pattern in the decoded PIs seems to be truncation after 13
bits with the highest bit set to 1. Is anyone in a position to check the
broadcast PI codes for any of those stations? Or does anyone know of a
different (and inexpensive) RDBS decoder that I could purchase to
cross-check these values?

-Brad

Hey guys! Thanks for the update on the situation in the US. I knew it from
Dallas, TX so far, but good to know that California and Tennessee also have such
stations.
From my point of view, this scrolling text is stupid. It prevents the spread of
real radiotext, as it limits the need to have receivers and transmitters to
support radiotext (why invest in that when we can just scroll the PS?).
BTW Tom: You could have a playstation display the scrolling messages to
exaggerate the distraction ;o)

Thanks again!

Cheers from Germany,
Markus

--- In rdsforum@yahoogroups.com, "Nathaniel N." <dalluvr001@...> wrote:
>
> I agree. I've only encountered a few channels that use "page" scrolling.vs
just scrolling across the screen. I'm near Nashville TN.
> 103 WKDF uses page scrolling. Where as station local to me uses just regular
scrolling. They both seem to work well. Just a preference I guess.
>
> --- On Mon, 5/18/09, Tom Pittenger <tpittenger@...> wrote:
>
> From: Tom Pittenger <tpittenger@...>
> Subject: Re: [rdsforum] Spread of non standard PS
> To: rdsforum@yahoogroups.com
> Date: Monday, May 18, 2009, 10:58 AM
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>       Markus,
> I live in California and at least half of the stations in my city have
scrolling PS. Here in the USA, the RBDS people (NRSC) have left this 'rule' a
bit more vague than the RDS people (CENLEC). They have unofficially said
something to the effect of: "although we'd rather you not scroll, there is no
punishment if you do scroll." In my opinion it's a waste of bandwidth to not
scroll it. Granted, if you do a 'RDS scan' of the area like what you're doing
you won't get any useful PS although their PI code should tell you something
about the station at least.
>
> This whole rule is kinda dumb anyway. The major argument is driver
distraction. ... but PlayStations and DVD players on LCD screens in the car is
ok? Ridiculous.
> Now that technology has caught up with the RDS on the cheap, RT and RT+ is the
way to go for song title and other text data.
>
>
> -Tom
>
> On Mon, May 18, 2009 at 7:49 AM, grospietschm <grospietschm@ yahoo.com> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>       Hi all!
>
>
>
> I'm working on products which also include a FM Radio receiver capable of
displaying RDS information (PS, AF...). The FM Radio software used also has the
option to save stations, along with their PS name, and display some stations in
a station list.
>
>
>
>
> We are currently thinking of some improvements for our software, like
automatically saving the PS name for a station when it was received and/or
saving it while autosearching for stations. Until now, we didn't include this
solution as we are aware of radio stations which violate the RDS specifications
and use a non-standard (changing/scrolling ) PS station name. To avoid our
customers having stupid names in their station list like "Burgers 99ct", we are
wondering how many stations in this world still violate the RDS specification.
>
>
>
>
> Here in Germany, i am currently not aware of a station in my region which does
this. The PS is always the same.
>
>
>
> - Can anyone here share some experience on the current situation?
>
> - Does anyone know how the situation is like in e.g. India, the USA, Taiwan,
China, rest of Europe?
>
> - I looked for such information in the net, but couldn't find something
useful. Does anyone know a good source of information on this topic?
>
>
>
> Thanks a lot in advance for any answers!
>
>
>
> Cheers,
>
> Markus
>

Hi Nicolas,

merci bien for the info! My french is not the best, but i could get most of the
text in the link you gave below. Babelfish was also a bit helpful :) Good to
know that France is experimenting  with an alternating PS.

Cheers,
Markus

--- In rdsforum@yahoogroups.com, "Nicolas Croiset (VDL)" <ncroiset@...> wrote:
>
> At 15:49 19/05/2009 +0000, you wrote:
> >Hi all!
> >
> >I'm working on products which also include a FM Radio receiver
> >capable of displaying RDS information (PS, AF...). The FM Radio
> >software used also has the option to save stations, along with their
> >PS name, and display some stations in a station list.
> >
> >We are currently thinking of some improvements for our software,
> >like automatically saving the PS name for a station when it was
> >received and/or saving it while autosearching for stations. Until
> >now, we didn't include this solution as we are aware of radio
> >stations which violate the RDS specifications and use a non-standard
> >(changing/scrolling) PS station name. To avoid our customers having
> >stupid names in their station list like "Burgers 99ct", we are
> >wondering how many stations in this world still violate the RDS
specification.
>
> Hello Markus,
>
>
> In France we are using alternate PS, The french radio authority
> launch an experimentation about that feature.
>
> cf : http://www.csa.fr/actualite/decisions/decisions_detail.php?id=128320
>
> Sorry it is in french.
>
> Bye.
>

At 15:49 19/05/2009 +0000, you wrote:
>Hi all!
>
>I'm working on products which also include a FM Radio receiver
>capable of displaying RDS information (PS, AF...). The FM Radio
>software used also has the option to save stations, along with their
>PS name, and display some stations in a station list.
>
>We are currently thinking of some improvements for our software,
>like automatically saving the PS name for a station when it was
>received and/or saving it while autosearching for stations. Until
>now, we didn't include this solution as we are aware of radio
>stations which violate the RDS specifications and use a non-standard
>(changing/scrolling) PS station name. To avoid our customers having
>stupid names in their station list like "Burgers 99ct", we are
>wondering how many stations in this world still violate the RDS specification.

Hello Markus,


In France we are using alternate PS, The french radio authority
launch an experimentation about that feature.

cf : http://www.csa.fr/actualite/decisions/decisions_detail.php?id=128320

Sorry it is in french.

Bye.

At 15:49 19/05/2009 +0000, you wrote:
>Hi all!
>
>I'm working on products which also include a FM Radio receiver
>capable of displaying RDS information (PS, AF...). The FM Radio
>software used also has the option to save stations, along with their
>PS name, and display some stations in a station list.
>
>We are currently thinking of some improvements for our software,
>like automatically saving the PS name for a station when it was
>received and/or saving it while autosearching for stations. Until
>now, we didn't include this solution as we are aware of radio
>stations which violate the RDS specifications and use a non-standard
>(changing/scrolling) PS station name. To avoid our customers having
>stupid names in their station list like "Burgers 99ct", we are
>wondering how many stations in this world still violate the RDS specification.

Hello Markus,


In France we are using alternate PS, The french radio authority
launch an experimentation about that feature.

cf : http://www.csa.fr/actualite/decisions/decisions_detail.php?id=128320

Sorry it is in french.

Bye.

At 15:49 19/05/2009 +0000, you wrote:
>Hi all!
>
>I'm working on products which also include a FM Radio receiver
>capable of displaying RDS information (PS, AF...). The FM Radio
>software used also has the option to save stations, along with their
>PS name, and display some stations in a station list.
>
>We are currently thinking of some improvements for our software,
>like automatically saving the PS name for a station when it was
>received and/or saving it while autosearching for stations. Until
>now, we didn't include this solution as we are aware of radio
>stations which violate the RDS specifications and use a non-standard
>(changing/scrolling) PS station name. To avoid our customers having
>stupid names in their station list like "Burgers 99ct", we are
>wondering how many stations in this world still violate the RDS specification.

Hello Markus,


In France we are using alternate PS, The french radio authority
launch an experimentation about that feature.

cf : http://www.csa.fr/actualite/decisions/decisions_detail.php?id=128320

Sorry it is in french.

Bye.

Hi all!

I'm working on products which also include a FM Radio receiver capable of
displaying RDS information (PS, AF...). The FM Radio software used also has the
option to save stations, along with their PS name, and display some stations in
a station list.

We are currently thinking of some improvements for our software, like
automatically saving the PS name for a station when it was received and/or
saving it while autosearching for stations. Until now, we didn't include this
solution as we are aware of radio stations which violate the RDS specifications
and use a non-standard (changing/scrolling) PS station name. To avoid our
customers having stupid names in their station list like "Burgers 99ct", we are
wondering how many stations in this world still violate the RDS specification.

Here in Germany, i am currently not aware of a station in my region which does
this. The PS is always the same.

- Can anyone here share some experience on the current situation?
- Does anyone know how the situation is like in e.g. India, the USA, Taiwan,
China, rest of Europe?
- I looked for such information in the net, but couldn't find something useful.
Does anyone know a good source of information on this topic?

Thanks a lot in advance for any answers!

Cheers,
Markus