RDS/RBDS support for FMRadio API

[Andy Buckingham (RadioDNS)]

I would like to propose the inclusion of basic RDS (RBDS in the US) support in the FM radio API. In particular the exposure of the RDS PI code and ECC value for the current radio station (when available).

For those that are not aware, RDS is a worldwide standard for the transmission of additional in-band meta. For example, most car stereos will show the 'PS' value on the display when you tune to a station - that's the short 8 character station name. The standard itself is quite extensive and includes various different data types such as clock time, name, text messages and more.

I am particularly interested in obtaining the PI (Programme Identifier) code which uniquely identifies the radio station being listened to. For example Capital FM in London broadcasts the code 'c479' on 95.8 FM. Combined with the open standard RadioDNS (http://radiodns.org), you can perform an authoritative lookup that allows the resolution of internet-based resources associated with the FM broadcast.

Built upon this standard are a number of open projects such as RadioVIS, which provide an HTTP long poll (Comet) slideshow of images and text to be displayed whilst listening. A growing number of broadcasters around the world are now adopting these standards and the inclusion of these rich visuals in the radio app, instead of the default "87.6 FM", would make Firefox OS stand out from the crowd.

There are several other apps including RadioEPG, which provides detailed service information and programme schedules, including station descriptions, logos, alternative IP stream URLs to switch to when FM reception dies and more. An upcoming standard RadioTAG also standardise way for all radio-capable devices to perform return path interaction, such as "tagging" a favourite song, ad or promo.

All that is needed to enable a wealth of possibilities for developers to build upon the FM radio support is the exposure of the PI value to perform lookups. Without having seeing the drivers myself, I strongly suspect support is already in there for RDS functions and it simply needs exposing via the JS API. For some inspiration, Qt recently added RDS support to their FM interface (https://bugreports.qt-project.org/browse/QTBUG-23762).

I really hope you'll give this some serious consideration and if I can assist with any further details or questions please do let me know.

Thanks.

--
Disclosure: I am a founding member of the RadioDNS project and I am the app team lead for the RadioTAG specification. I am employed by the UKs largest commercial radio group, Global Radio (http://www.thisisglobal.com/radio), who are strong supporters of the RadioDNS project and provide implementations of RadioVIS/EPG/TAG for all our FM, DAB and IP radio services.

[Paolo Casagranda]

Hi Andy and all,
the inclusion of PI code and ECC code extraction methods would be great. It would enable interesting use cases, allowing to uniquely identify a radio station and associate dynamic content to it (unfortunately the frequency is not enough).

I note here that, in my knowledge, Firefox OS would be the first mobile OS with a standard radio API (which already has) AND access to RDS parameters.
Hybrid radio is perhaps the most significant (but not the only) example of service enabled by this enhancement - look at the *open* and (AFAIK) *patent free* http://radiodns.org project. In Italy and several other countries there are live prototype and also public hybrid radio channels. At the moment the only mass market receivers are "kitchen radios"; if Firefox OS API had also RDS PI and ECC code extraction it would enable all these services for its customers.

If further documentation or possible use cases contribution is needed, count me in.

Thanks
Paolo

Disclosure: I work for the Italian public TV and radio broadcaster (Rai), following radio related research projects. I'm also supporter and contributor of the RadioDNS project.

[JOSE MANUEL CANTERA FONSECA]

Very interesting, I think the way to start moving this forward is to file
a bug in bugzilla for exposing the requested fields in the WebFM Radio
API.

El 26/02/13 16:03, "Andy Buckingham (RadioDNS)" <an...@radiodns.org>
escribió:

>_______________________________________________
>dev-webapi mailing list
>dev-w...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-webapi
>



________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Andy Buckingham (RadioDNS)]

Thanks for your response, but I did already comment on the original bug tracking the development of the FM API back in August:

https://bugzilla.mozilla.org/show_bug.cgi?id=749053#c2

This didn't lead very far. Is it worth opening a new bug for this work?

Thanks,


Andy.

[Andy Buckingham (RadioDNS)]

Thanks for your response, but I did already comment on the original bug tracking the development of the FM API back in August:

https://bugzilla.mozilla.org/show_bug.cgi?id=749053#c2

This didn't lead very far. Is it worth opening a new bug for this work?

Thanks,


Andy.

On Tuesday, 26 February 2013 16:05:46 UTC, JOSE MANUEL CANTERA FONSECA wrote:

[Mounir Lamouri]

Hi Andy,

Thank you for taking the time to give us your feedback.

On 26/02/13 15:03, Andy Buckingham (RadioDNS) wrote:
> I really hope you'll give this some serious consideration and if I can assist with any further details or questions please do let me know.

If you have a proposal regarding how we could change the API to make it
support those features, that would be great. Code contributions are also
very welcome :)

Thanks,
--
Mounir

[David Bruant]

Hi Andy,

I don't know much about radio, so I'll be asking some questions in order
to better understand how to expose the informations you suggest.
In case the questions I ask are very naive, feel free to direct me to
resources where I could find the answers. Please do it on the list so
that the discussion is archived.

Le 26/02/2013 16:03, Andy Buckingham (RadioDNS) a écrit :
> I would like to propose the inclusion of basic RDS (RBDS in the US)

Is it just a different name in the US or are US radios following a
completely different standard? More to our concern, is it really a
worldwide standard or are there some local specificities? The latter
case would complicate the API a bit (but not make it impossible)

> support in the FM radio API. In particular the exposure of the RDS PI code and ECC value for the current radio station (when available).

Under which conditions are these values not available? Is it only
related to how a station broadcasts or can there be hardware limitations?

> For those that are not aware, RDS is a worldwide standard for the transmission of additional in-band meta. For example, most car stereos will show the 'PS' value on the display when you tune to a station - that's the short 8 character station name. The standard itself is quite extensive and includes various different data types such as clock time, name, text messages and more.

Do you have a link to the standard? (and perhaps a comprensive version
of its content. As we know, standards may be hard to read sometimes)
Is the standard followed to the letter everywhere or are there local
specificities (like some regions having their own additions, etc.)?
Is the list of properties and there type finite and known in advance?

> I am particularly interested in obtaining the PI (Programme Identifier) code which uniquely identifies the radio station being listened to. For example Capital FM in London broadcasts the code 'c479' on 95.8 FM. Combined with the open standard RadioDNS (http://radiodns.org), you can perform an authoritative lookup that allows the resolution of internet-based resources associated with the FM broadcast.

Most likely irrelevant to draft an API, but who provides the Programme
Identifier code? Can anyone "emulate" it?

> Built upon this standard are a number of open projects such as RadioVIS, which provide an HTTP long poll (Comet) slideshow of images and text to be displayed whilst listening. A growing number of broadcasters around the world are now adopting these standards and the inclusion of these rich visuals in the radio app, instead of the default "87.6 FM", would make Firefox OS stand out from the crowd.

I've played a bit with the app and I was surprised indeed that a car is
capable to show the radio name in letter and FirefoxOS only shows the
frequency. That'd be an exciting change.

> There are several other apps including RadioEPG, which provides detailed service information and programme schedules, including station descriptions, logos, alternative IP stream URLs to switch to when FM reception dies and more. An upcoming standard RadioTAG also standardise way for all radio-capable devices to perform return path interaction, such as "tagging" a favourite song, ad or promo.

Just to clarify, do you which any of that to appear in the native API or
is it just ideas of things apps could use if they had access to the
information you're requesting?

> All that is needed to enable a wealth of possibilities for developers to build upon the FM radio support is the exposure of the PI value to perform lookups. Without having seeing the drivers myself, I strongly suspect support is already in there for RDS functions and it simply needs exposing via the JS API. For some inspiration, Qt recently added RDS support to their FM interface (https://bugreports.qt-project.org/browse/QTBUG-23762).

Unrelated to this specific API, but relevant in regards of some recent
discussions on the list, I like the first sentence of this bug report:
"It would be of great use to add the ability to synchronously and
asynchronously retrieve RDS data using the FM Radio APIs"

David

[David Bruant]

Purely based on Andy's previous message, it sounds like it's too early
to open bugs.
I suggest the following plan of action:
Let's further discuss and understand the need and constraints of the
informations that are wished to be exposed. Then let's draft an API,
then only let's open new bugs. From what I've read on this mailing-list
early days, that's how it worked pretty much.
Bugzilla isn't a very good tool to draft APIs.

David

Le 26/02/2013 18:17, Andy Buckingham (RadioDNS) a �crit :

> Thanks for your response, but I did already comment on the original bug tracking the development of the FM API back in August:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=749053#c2
>
> This didn't lead very far. Is it worth opening a new bug for this work?
>
> Thanks,
>
>
> Andy.
>
> On Tuesday, 26 February 2013 16:05:46 UTC, JOSE MANUEL CANTERA FONSECA wrote:
>> Very interesting, I think the way to start moving this forward is to file
>>
>> a bug in bugzilla for exposing the requested fields in the WebFM Radio
>>
>> API.
>>
>>
>>
>> El 26/02/13 16:03, "Andy Buckingham (RadioDNS)" <an...@radiodns.org>
>>

>> escribi�:

>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol�tica de env�o y recepci�n de correo electr�nico en el enlace situado m�s abajo.

>>
>> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
>>
>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Paolo Casagranda]

Hi David,
thank you for your feedback. I try to give a contribution for your questions.

1. RDBS is an extension of RDS. They have only slight differences. The HW implementing both in a mobile should be common (I'm waiting feedback from manufacturers to confirm). In any case, the FM drivers can cope with their slight differences (ref. http://www.nrscstandards.org/RBDS/rbdsrds.pdf ). An example: CRC from Canada has implemented an FM-RDS library working on a popular mobile phone, working both in Europe and USA (http://mmbtools.crc.ca/content/view/53/33/ it works well, but with only *1* Android model... because Android has no standard FM-RDS API!).

2. PI code is always present and uniquely identifies the radio station (fundamental, because frequency can be common to different stations in different areas). ECC is not always used, can be present or not. It doesn't depend on HW. It's only a choice of the broadcaster.

3. Refs to the standards: RDS: http://webstore.iec.ch/webstore/webstore.nsf/mysearchajax?Openform&key=62106 (unluckily and is not free - maybe you find something on the web searching rds1999.pdf another useful primer is http://en.wikipedia.org/wiki/Radio_Data_System ) RDBS:http://www.nrscstandards.org/SG/nrsc-4-B.pdf

4. Who provides the PI code? The PI code is provided by the broadcaster (think about it as a public IP address broadcasters use to identify the station). The PI code is assigned by a central authority or calculated using special algorithms (USA) to the broadcaster, however it's irrelevant from the API point of view. So, you can assume there's a PI code, and of course you can simulate it.

5. RDS capabilities for Firefox OS: I totally agree! Radio station identification would enable exciting new use cases, allowing broadcast to get relevant information from the internet.

6. +1 "It would be of great use to add the ability to synchronously and asynchronously retrieve RDS data using the FM Radio APIs"

Kind regards
Paolo

[Paolo Casagranda]

Hi David,
thank you for your feedback. I try to give a contribution for your questions.

1. RDBS is an extension of RDS. They have only slight differences. The HW implementing both in a mobile should be common (I'm waiting feedback from manufacturers to confirm). In any case, the FM drivers can cope with their slight differences (ref. http://www.nrscstandards.org/RBDS/rbdsrds.pdf ). An example: CRC from Canada has implemented an FM-RDS library working on a popular mobile phone, working both in Europe and USA (http://mmbtools.crc.ca/content/view/53/33/ it works well, but with only *1* Android model... because Android has no standard FM-RDS API!).

2. PI code is always present and uniquely identifies the radio station (fundamental, because frequency can be common to different stations in different areas). ECC is not always used, can be present or not. It doesn't depend on HW. It's only a choice of the broadcaster.

3. Refs to the standards: RDS: http://webstore.iec.ch/webstore/webstore.nsf/mysearchajax?Openform&key=62106 (unluckily and is not free - maybe you find something on the web searching rds1999.pdf another useful primer is http://en.wikipedia.org/wiki/Radio_Data_System ) RDBS:http://www.nrscstandards.org/SG/nrsc-4-B.pdf

4. Who provides the PI code? The PI code is provided by the broadcaster (think about it as a public IP address broadcasters use to identify the station). The PI code is assigned by a central authority or calculated using special algorithms (USA) to the broadcaster, however it's irrelevant from the API point of view. So, you can assume there's a PI code, and of course you can simulate it.

5. RDS capabilities for Firefox OS: I totally agree! Radio station identification would enable exciting new use cases, allowing broadcast to get relevant information from the internet.

6. +1 "It would be of great use to add the ability to synchronously and asynchronously retrieve RDS data using the FM Radio APIs"

Kind regards
Paolo



On Tuesday, February 26, 2013 9:59:41 PM UTC+1, David Bruant wrote:

[Paolo Casagranda]

Hi David and all,
I hope you had time to take a look to the RDS overview.
The proposal could be to add at least one method to get the PI (programme identification code - 16 bits number) code and, possibly, other two methods to get ECC (extended country code - 8 bits number) code and PS (programme service, 8 characters with the station name).
I ask you help to define the methods that should be added. Just as *an example* they could be:

DOMRequest getPI() [with onpiready() callback, returning an unsigned integer - 16 bits]
Optionally (but recommended):
DOMRequest getECC() [with oneccready callback, returning an unsigned integer - 8 bits]
DOMRequest getPS() [with onpsready callback, returning an 8 chars string]

Could someone define the API to get these data, according to your best practices?

Best regards
Paolo

[David Bruant]

Hi Paolo,

Sorry it took so long to answer. Answering both of you messages here.
Answers inline.

Le 01/03/2013 10:27, Paolo Casagranda a écrit :
> Hi David,
> thank you for your feedback. I try to give a contribution for your questions.
>
> 1. RDBS is an extension of RDS. They have only slight differences. The HW implementing both in a mobile should be common (I'm waiting feedback from manufacturers to confirm).

Have you heard back from manufacturers?
Is there a simple way to test if some piece of hardware implements it?

> In any case, the FM drivers can cope with their slight differences (ref. http://www.nrscstandards.org/RBDS/rbdsrds.pdf ). An example: CRC from Canada has implemented an FM-RDS library working on a popular mobile phone, working both in Europe and USA (http://mmbtools.crc.ca/content/view/53/33/ it works well, but with only *1* Android model... because Android has no standard FM-RDS API!).

From what I understand, the differences are mostly minor semantics
differences for some fields in the RDS standard.
Devs may suffer from that, but we can imagine that a good open source
library combining geolocalisation with the RDS/RDBS infos could help
infer the exact semantics of the fields when necessary.

> 2. PI code is always present and uniquely identifies the radio station (fundamental, because frequency can be common to different stations in different areas). ECC is not always used, can be present or no5. RDS capabilities for Firefox OS: I totally agree! Radio station identification would enable exciting new use cases, allowing broadcast to get relevant information from the internet.
I see a (minor?) privacy issue here since user localization can be
infered from its PI/ECC and/or cross-referenced with a radio FM
frequency database.
It might make necessary to expose this information only to privileged
apps (downloaded from some marketplace after security/privacy review)

> 3. Refs to the standards: RDS: http://webstore.iec.ch/webstore/webstore.nsf/mysearchajax?Openform&key=62106 (unluckily and is not free - maybe you find something on the web searching rds1999.pdf another useful primer is http://en.wikipedia.org/wiki/Radio_Data_System ) RDBS:http://www.nrscstandards.org/SG/nrsc-4-B.pdf

Why isn't the standard free? I see it's not free as in beer, but is it
also not free as in speech? In the latter case, there might be legal
complications to implement it. Do radios which implement it need to pay
something or declare something somewhere to be allowed to use these
data? That'd be weird as radio is so widespread, but in case.
I'll wait for your answer on this topic.
(Btw, I've found a copy [1] of the RDS standard)

> The proposal could be to add at least one method to get the PI (programme identification code - 16 bits number) code and, possibly, other two methods to get ECC (extended country code - 8 bits number) code and PS (programme service, 8 characters with the station name).

> I ask you help to define the methods that should be added. Just as*an example* they could be:

>
> DOMRequest getPI() [with onpiready() callback, returning an unsigned integer - 16 bits]
> Optionally (but recommended):
> DOMRequest getECC() [with oneccready callback, returning an unsigned integer - 8 bits]
> DOMRequest getPS() [with onpsready callback, returning an 8 chars string]
>
> Could someone define the API to get these data, according to your best practices?

From what I understand (tell me if I'm mistaken), all the properties
being currently discussed are radio signal-related informations unlike
all current properties of the FMRadio object [2] which are more hardware
related. It might be worth cleanly separating both types of information.
Here is an idea:

partial interface FM {
readonly attribute RadioStationInfos currentStation;
event<RadioStationChangeEvent> radiostationchange;
} // the event notation isn't proper WebIDL, just idiomatic

interface RadioStationInfos {
readonly attribute unsigned long PI;
readonly attribute unsigned long ECC;
readonly attribute unsigned long PS;
// add other broadcast signal infos here
}

interface RadioStationChangeEvent : Event{
readonly attribute RadioStationInfos newStation;
}

The radiostationchange event is triggered whenever the radio station
changes which can happen either when the frequency changes or when the
frequency doesn't change, but the user moves far/fast enough so that the
same frequency refers to a different station.
I think it can happen that even if the radio is on, the user moves and
the radio doesn't get a station any longer. This would trigger a
radiostationchange event with null as "station".

This design relies on the idea that all infos change at once.
Is it possible that one value changes but not the others for a given
station?
When some infos are sent by the station and not others, would a "null"
value be appropriate for the unsent values?

Obviously, that's a first-shot kind of idea. Everything (starting by
interface names) is open to being questioned.

David

[1] http://read.pudn.com/downloads121/doc/comm/513245/Rds1999.pdf
[2] https://developer.mozilla.org/en-US/docs/DOM/WebFM

[David Bruant]

Hi,

Sharing with the list things I'm finding out while reading some
Wikipedia pages on RDS [1][2]:
* TP (Traffic Program) flag. Tells whether the received station may emit
traffic alerts. Since some car-radio only seek through stations with TP,
most radio emit this flag even though they don't say anything about
traffic issues (sounds so much like a lot of features on the web)
* The TA (Traffic announcement) tells whether the station is currently
emitting information about the traffic.
There is probably some good use case for that in combinaison with
notifications (put your phone in "road mode")
* AF (Alternative Frequencies). Frequencies for the same station. Used
to travel from a place to another without having to manually change the
frequency. WE NEED THAT SO BAAAAD!!
* Japan uses a different frequency band (76-90 MHz)
How is doing the FirefoxOS Radio app in Japan? Has anyone tested it?
Are there special builds for Japan?

David

[1] fr.wikipedia.org/wiki/Radio_Data_System
[2] http://en.wikipedia.org/wiki/Radio_Data_System

[Paolo Casagranda]

Hi David and all,
I hope you had time to take a look to the RDS overview.

The proposal could be to add at least one method to get the PI (programme identification code - 16 bits number) code and, possibly, other two methods to get ECC (extended country code - 8 bits number) code and PS (programme service, 8 characters with the station name).

I ask you help to define the methods that should be added. Just as *an example* they could be:

DOMRequest getPI() [with onpiready() callback, returning an unsigned integer - 16 bits]
Optionally (but recommended):
DOMRequest getECC() [with oneccready callback, returning an unsigned integer - 8 bits]
DOMRequest getPS() [with onpsready callback, returning an 8 chars string]

Could someone define the API to get these data, according to your best practices?

Best regards
Paolo

[Paolo Casagranda]

Hi David,
I try to give you more details.

> Have you heard back from manufacturers?

I've asked information to the RDS Forum. I'll give some feedback as soon as they tell me something. A

> Is there a simple way to test if some piece of hardware implements it?

The HW manufacturers exposes all the specs, I'm not aware of any other mean to check.

> From what I understand, the differences are mostly minor semantics
> differences for some fields in the RDS standard.
> Devs may suffer from that, but we can imagine that a good open source
> library combining geolocalisation with the RDS/RDBS infos could help
> infer the exact semantics of the fields when necessary.

Yes I can confirm this, it's mostly minor semantics. It's publicly available information http://www.nrscstandards.org/RBDS/rbdsrds.pdf So, independently from the RDS flavor, PI will be a 16bits integer, ECC 8bits, PS an 8 char string...
In most cases the two parameters PI code + ECC code unambiguously identify the region of the transmission. At application level it could be useful if geolocalization or a user choice (select country...) sets a default country value.

> I see a (minor?) privacy issue here since user localization can be
> infered from its PI/ECC and/or cross-referenced with a radio FM
> frequency database.
> It might make necessary to expose this information only to privileged
> apps (downloaded from some marketplace after security/privacy review)

I don't know the level of privacy requested in Firefox OS but it shouldn't. Consider that localization infered from PI/ECC can be less precise that the info you can get from the user's IP address. They generally identify the country.

> Why isn't the standard free? I see it's not free as in beer, but is it
> also not free as in speech? In the latter case, there might be legal
> complications to implement it. Do radios which implement it need to pay
> something or declare something somewhere to be allowed to use these
> data? That'd be weird as radio is so widespread, but in case.
> I'll wait for your answer on this topic.
> (Btw, I've found a copy [1] of the RDS standard)

Yes, I understand. The RDS standard is an IEC standard, and like ISO standards you can buy it. It different from IETF and ETSI standards, available for free. As you know, even the C++ standard is open but not free (and you have to pay to get the original document :-|). On the other hand, this doesn't mean that you have to pay anything to implement it. You can implement it and you are allowed to used the data (of course, patents are a different story). And you also found a "free" copy :-)
Note that the RDBS standard doc and the RDBS-RDS differences doc (see previous references) ARE free, and can be used as official free documentation.

> From what I understand (tell me if I'm mistaken), all the properties
> being currently discussed are radio signal-related informations unlike
> all current properties of the FMRadio object [2] which are more hardware
> related. It might be worth cleanly separating both types of information.

> [...]

> This design relies on the idea that all infos change at once.

Good point! The info are carried in the data, so they will become available when the data has been correctly decoded. Be careful that PI, ECC (and PS eventually) are transmitted with other data (in "carousel" mode), and could be subject to interference and other problems. So there's no guarantee they are available instantly. Could they be associated to an asynchronous event (like onpiready)?

> Is it possible that one value changes but not the others for a given
> station?

A station PI and ECC codes are fixed, don't change. The PS (station name) is different, it can change. In USA it can change; Europe (RDS) it SHOULD NOT change (but almost stations let it change to display both the radio logo, phone numbers, etc.)

> When some infos are sent by the station and not others, would a "null"
> value be appropriate for the unsent values?

I think so. null could be a good default value. Andy, any ideas?

> Obviously, that's a first-shot kind of idea. Everything (starting by
> interface names) is open to being questioned.
> David
>

Good starting point!

Paolo

[Paolo Casagranda]

Hi David,
I try to give you more details.

> Have you heard back from manufacturers?

I've asked information to the RDS Forum. I'll give some feedback as soon as they tell me something. A

> Is there a simple way to test if some piece of hardware implements it?

The HW manufacturers exposes all the specs, I'm not aware of any other mean to check.

> From what I understand, the differences are mostly minor semantics
> differences for some fields in the RDS standard.
> Devs may suffer from that, but we can imagine that a good open source
> library combining geolocalisation with the RDS/RDBS infos could help
> infer the exact semantics of the fields when necessary.

Yes I can confirm this, it's mostly minor semantics. It's publicly available information http://www.nrscstandards.org/RBDS/rbdsrds.pdf So, independently from the RDS flavor, PI will be a 16bits integer, ECC 8bits, PS an 8 char string...
In most cases the two parameters PI code + ECC code unambiguously identify the region of the transmission. At application level it could be useful if geolocalization or a user choice (select country...) sets a default country value.

> I see a (minor?) privacy issue here since user localization can be
> infered from its PI/ECC and/or cross-referenced with a radio FM
> frequency database.
> It might make necessary to expose this information only to privileged
> apps (downloaded from some marketplace after security/privacy review)

I don't know the level of privacy requested in Firefox OS but it shouldn't. Consider that localization infered from PI/ECC can be less precise that the info you can get from the user's IP address. They generally identify the country.

> Why isn't the standard free? I see it's not free as in beer, but is it
> also not free as in speech? In the latter case, there might be legal
> complications to implement it. Do radios which implement it need to pay
> something or declare something somewhere to be allowed to use these
> data? That'd be weird as radio is so widespread, but in case.
> I'll wait for your answer on this topic.
> (Btw, I've found a copy [1] of the RDS standard)

Yes, I understand. The RDS standard is an IEC standard, and like ISO standards you can buy it. It different from IETF and ETSI standards, available for free. As you know, even the C++ standard is open but not free (and you have to pay to get the original document :-|). On the other hand, this doesn't mean that you have to pay anything to implement it. You can implement it and you are allowed to used the data (of course, patents are a different story). And you also found a "free" copy :-)
Note that the RDBS standard doc and the RDBS-RDS differences doc (see previous references) ARE free, and can be used as official free documentation.

> From what I understand (tell me if I'm mistaken), all the properties
> being currently discussed are radio signal-related informations unlike
> all current properties of the FMRadio object [2] which are more hardware
> related. It might be worth cleanly separating both types of information.

> [...]

> This design relies on the idea that all infos change at once.

Good point! The info are carried in the data, so they will become available when the data has been correctly decoded. Be careful that PI, ECC (and PS eventually) are transmitted with other data (in "carousel" mode), and could be subject to interference and other problems. So there's no guarantee they are available instantly. Could they be associated to an asynchronous event (like onpiready)?

> Is it possible that one value changes but not the others for a given
> station?

A station PI and ECC codes are fixed, don't change. The PS (station name) is different, it can change. In USA it can change; Europe (RDS) it SHOULD NOT change (but almost stations let it change to display both the radio logo, phone numbers, etc.)

> When some infos are sent by the station and not others, would a "null"
> value be appropriate for the unsent values?

I think so. null could be a good default value. Andy, any ideas?

> Obviously, that's a first-shot kind of idea. Everything (starting by
> interface names) is open to being questioned.
> David
>

Good starting point!

Paolo

[David Bruant]

Le 07/03/2013 11:06, Paolo Casagranda a écrit :
> Hi David,
> I try to give you more details.
>> Have you heard back from manufacturers?
> I've asked information to the RDS Forum. I'll give some feedback as soon as they tell me something. A

Were you starting a new sentence here?

>> From what I understand, the differences are mostly minor semantics
>> differences for some fields in the RDS standard.
>> Devs may suffer from that, but we can imagine that a good open source
>> library combining geolocalisation with the RDS/RDBS infos could help
>> infer the exact semantics of the fields when necessary.
> Yes I can confirm this, it's mostly minor semantics. It's publicly available information http://www.nrscstandards.org/RBDS/rbdsrds.pdf So, independently from the RDS flavor, PI will be a 16bits integer, ECC 8bits, PS an 8 char string...
> In most cases the two parameters PI code + ECC code unambiguously identify the region of the transmission. At application level it could be useful if geolocalization or a user choice (select country...) sets a default country value.

Indeed. We need to make this information available to the app. I know
the user currently chooses a default language, but I don't think it can
choose a country and I don't think there is a way for an app to have
access to this information directly.
I don't really know how we can make this work without using
geolocalisation which the user can choose not to opt-in to.
In the case the user doesn't accept geolocalization, the app can't know
if the fields are to be interpreted against the RDS or RDBS semantics.

>> I see a (minor?) privacy issue here since user localization can be
>> infered from its PI/ECC and/or cross-referenced with a radio FM
>> frequency database.
>> It might make necessary to expose this information only to privileged
>> apps (downloaded from some marketplace after security/privacy review)
> I don't know the level of privacy requested in Firefox OS but it shouldn't. Consider that localization infered from PI/ECC can be less precise that the info you can get from the user's IP address. They generally identify the country.

Even the country can be a serious leak if your country is very small
(Andorra, Vatican, etc.) for instance.
PI/ECC may reveal only the country, but consider the following case:
My favorite radio is Le Mouv' (which PI is F208 [1], public info). The
frequency in Bordeaux is 87.7 [2] (public info too).
If an app has access to both the PI (which we're debatting) and the
frequency (which is available to every app already), then the app can
infer that I'm in Bordeaux, right? The inference can be further improved
using ECC and other "weaker" fields like PS, etc.
If that's the case, it's a form of geolocalization (which is actually
very interesting) and that's a bit privacy-invasive.

Now that I think about it, using the seekup method, an app can
*currently* know all frequencies which emits something. Based on the set
of frequencies emitting something, is it possible to infer the region?
If so, the FMRadio API should probably be considered to be a bit higher
priviledged than it currently is ("priviliged" would be enough).

>> Why isn't the standard free? I see it's not free as in beer, but is it
>> also not free as in speech? In the latter case, there might be legal
>> complications to implement it. Do radios which implement it need to pay
>> something or declare something somewhere to be allowed to use these
>> data? That'd be weird as radio is so widespread, but in case.
>> I'll wait for your answer on this topic.
>> (Btw, I've found a copy [1] of the RDS standard)
> Yes, I understand. The RDS standard is an IEC standard, and like ISO standards you can buy it. It different from IETF and ETSI standards, available for free. As you know, even the C++ standard is open but not free (and you have to pay to get the original document :-|). On the other hand, this doesn't mean that you have to pay anything to implement it. You can implement it and you are allowed to used the data (of course, patents are a different story). And you also found a "free" copy :-)
> Note that the RDBS standard doc and the RDBS-RDS differences doc (see previous references) ARE free, and can be used as official free documentation.

Ok, sounds good.

>> From what I understand (tell me if I'm mistaken), all the properties
>> being currently discussed are radio signal-related informations unlike
>> all current properties of the FMRadio object [2] which are more hardware
>> related. It might be worth cleanly separating both types of information.
>> [...]
>> This design relies on the idea that all infos change at once.
> Good point! The info are carried in the data, so they will become available when the data has been correctly decoded. Be careful that PI, ECC (and PS eventually) are transmitted with other data (in "carousel" mode), and could be subject to interference and other problems. So there's no guarantee they are available instantly. Could they be associated to an asynchronous event (like onpiready)?

I'm wondering if we need an event for each value or if one event for a
"bundle" (which I called "RadioStationInfos") can be enough. Although
there might be interference issues, I assume a station resends regularly
(do you know how often in practice?) the RDS infos.
If there was some interference and the RDS infos couldn't be read, is it
ok to miss the info and wait for the next time?
Are there case where an app would want to be informed that the RDS infos
couldn't be read?

The idea of the radiostationchange event was to bundle the
onpiready/oneccready/onpschange/etc all at once. Basically, users play
with the frequency (or not) and whenever the radio station infos change,
you get a new event. It's less about PI/ECC being ready and more to tell
that the value has changed.

>> Is it possible that one value changes but not the others for a given
>> station?
> A station PI and ECC codes are fixed, don't change. The PS (station name) is different, it can change. In USA it can change; Europe (RDS) it SHOULD NOT change (but almost stations let it change to display both the radio logo, phone numbers, etc.)

I see, so we can consider it does change :-)
It's really interesting how standards ask to do things and people just
don't respect standards (like for the TP flag). Reminds me of the web.
The outcome on the web was that the standard body (mostly W3C) backed up
after the people who implement the standards (Opera and Mozilla
initially, later joined by Apple then Google) decides to do their own
thing with the WHATWG.
XHTML2 died, the W3C started to follow up on HTML5 (started by the WHATWG).
De-facto standards... Has the commitee that standardizes RDS considered
changing the standard to follow de-facto practices (namely that radios
do change the PS)?

Thanks for your answers,

David

[1] http://www.csa.fr/csaradio/radiords_tableau
[2] http://www.lemouv.fr/frequences

[Andy Buckingham]

Just a quick correction to Paolo's response...

On 7 March 2013 10:06, Paolo Casagranda <crit.r...@gmail.com> wrote:
>> Is it possible that one value changes but not the others for a given
>> station?
>
> A station PI and ECC codes are fixed, don't change. The PS (station name) is different, it can change. In USA it can change; Europe (RDS) it SHOULD NOT change (but almost stations let it change to display both the radio logo, phone numbers, etc.)

In the UK (and potentially other countries) PI values do sometimes
change on the same station, typically during ad breaks. I won't get in
to the particulars of why this happens (unless anyone is interested?!)
but it is not safe to assume they are always the same, they can
legitimately change.

ECC should never change.

PS should never change, but as Paolo says some broadcasters break the
spec and change it, so it's reasonable for an API to expect changes
and bubbles those through.


A

[Paolo Casagranda]

Hi David and all,

> Were you starting a new sentence here?

...a phone call probably, forget it.

> Indeed. We need to make this information available to the app. I know
> the user currently chooses a default language, but I don't think it can
> choose a country and I don't think there is a way for an app to have
> access to this information directly.
> I don't really know how we can make this work without using
> geolocalisation which the user can choose not to opt-in to.
> In the case the user doesn't accept geolocalization, the app can't know
> if the fields are to be interpreted against the RDS or RDBS semantics.

Yes, it's a problem. Maybe here we can use the additional data if they're available. The app, for example, could have the country already set as the phone localization settings (e.g. in Android you can get the system Language and Country, usually set during configuration), and user can modify that on the app. This should only happen seldom.

> Even the country can be a serious leak if your country is very small
> (Andorra, Vatican, etc.) for instance.
> PI/ECC may reveal only the country, but consider the following case:
> My favorite radio is Le Mouv' (which PI is F208 [1], public info). The
> frequency in Bordeaux is 87.7 [2] (public info too).
> If an app has access to both the PI (which we're debatting) and the
> frequency (which is available to every app already), then the app can
> infer that I'm in Bordeaux, right? The inference can be further improved
> using ECC and other "weaker" fields like PS, etc.
> If that's the case, it's a form of geolocalization (which is actually
> very interesting) and that's a bit privacy-invasive.

Yes you're right. It should be put in the right perspective, following the system privacy guidelines. By the way, interesting idea, alternative to wifi geoloc (like Android's)

> Now that I think about it, using the seekup method, an app can
> *currently* know all frequencies which emits something. Based on the set
> of frequencies emitting something, is it possible to infer the region?
> If so, the FMRadio API should probably be considered to be a bit higher
> priviledged than it currently is ("priviliged" would be enough).

Yes in some cases you could infer the region. Although I imagine it's not trivial.

> Ok, sounds good.

> I'm wondering if we need an event for each value or if one event for a
> "bundle" (which I called "RadioStationInfos") can be enough. Although
> there might be interference issues, I assume a station resends regularly
> (do you know how often in practice?) the RDS infos.
> If there was some interference and the RDS infos couldn't be read, is it
> ok to miss the info and wait for the next time?
> Are there case where an app would want to be informed that the RDS infos
> couldn't be read?

Yes, all the information is continuously sent. For PI and ECC it reception should be less then 0.1s (transmitted 11.4 times/s). Another example, the station name will take 1 or 2s (1 time/s), and considering typical reception conditions could be 4s. (->ftp://ftp.rds.org.uk/pub/acrobat/rbds1998.pdf page 18)

> The idea of the radiostationchange event was to bundle the
> onpiready/oneccready/onpschange/etc all at once. Basically, users play
> with the frequency (or not) and whenever the radio station infos change,
> you get a new event. It's less about PI/ECC being ready and more to tell
> that the value has changed.

Now it's clear. Then maybe another event could give added value, because of the timings I described before. A possible example to clarify timings:
0.00s the user starts the radio app
3.00s the FM turns on
3.10s the music start playng (and radiostationchange is called)
3.30s PI and ECC available (and onpichange is called) the radio app begins enhancing the radio UX with content from the internet
7:30s station name appears (PS available)

> XHTML2 died, the W3C started to follow up on HTML5 (started by the WHATWG).

Interesting. And very pragmatic. We can understand that, there is no single force making it evolve.

> De-facto standards... Has the commitee that standardizes RDS considered
> changing the standard to follow de-facto practices (namely that radios
> do change the PS)?

No AFAIK. I think we should accept (and smartly manage) diversity ;-)

Thank you
Paolo

[Paolo Casagranda]

Hi David and all,

> Were you starting a new sentence here?

...a phone call probably, forget it.

> Indeed. We need to make this information available to the app. I know
> the user currently chooses a default language, but I don't think it can
> choose a country and I don't think there is a way for an app to have
> access to this information directly.
> I don't really know how we can make this work without using
> geolocalisation which the user can choose not to opt-in to.
> In the case the user doesn't accept geolocalization, the app can't know
> if the fields are to be interpreted against the RDS or RDBS semantics.

Yes, it's a problem. Maybe here we can use the additional data if they're available. The app, for example, could have the country already set as the phone localization settings (e.g. in Android you can get the system Language and Country, usually set during configuration), and user can modify that on the app. This should only happen seldom.

> Even the country can be a serious leak if your country is very small
> (Andorra, Vatican, etc.) for instance.
> PI/ECC may reveal only the country, but consider the following case:
> My favorite radio is Le Mouv' (which PI is F208 [1], public info). The
> frequency in Bordeaux is 87.7 [2] (public info too).
> If an app has access to both the PI (which we're debatting) and the
> frequency (which is available to every app already), then the app can
> infer that I'm in Bordeaux, right? The inference can be further improved
> using ECC and other "weaker" fields like PS, etc.
> If that's the case, it's a form of geolocalization (which is actually
> very interesting) and that's a bit privacy-invasive.

Yes you're right. It should be put in the right perspective, following the system privacy guidelines. By the way, interesting idea, alternative to wifi geoloc (like Android's)

> Now that I think about it, using the seekup method, an app can
> *currently* know all frequencies which emits something. Based on the set
> of frequencies emitting something, is it possible to infer the region?
> If so, the FMRadio API should probably be considered to be a bit higher
> priviledged than it currently is ("priviliged" would be enough).

Yes in some cases you could infer the region. Although I imagine it's not trivial.

> Ok, sounds good.

> I'm wondering if we need an event for each value or if one event for a
> "bundle" (which I called "RadioStationInfos") can be enough. Although
> there might be interference issues, I assume a station resends regularly
> (do you know how often in practice?) the RDS infos.
> If there was some interference and the RDS infos couldn't be read, is it
> ok to miss the info and wait for the next time?
> Are there case where an app would want to be informed that the RDS infos
> couldn't be read?

Yes, all the information is continuously sent. For PI and ECC it reception should be less then 0.1s (transmitted 11.4 times/s). Another example, the station name will take 1 or 2s (1 time/s), and considering typical reception conditions could be 4s. (->ftp://ftp.rds.org.uk/pub/acrobat/rbds1998.pdf page 18)

> The idea of the radiostationchange event was to bundle the
> onpiready/oneccready/onpschange/etc all at once. Basically, users play
> with the frequency (or not) and whenever the radio station infos change,
> you get a new event. It's less about PI/ECC being ready and more to tell
> that the value has changed.

Now it's clear. Then maybe another event could give added value, because of the timings I described before. A possible example to clarify timings:
0.00s the user starts the radio app
3.00s the FM turns on
3.10s the music start playng (and radiostationchange is called)
3.30s PI and ECC available (and onpichange is called) the radio app begins enhancing the radio UX with content from the internet
7:30s station name appears (PS available)

> XHTML2 died, the W3C started to follow up on HTML5 (started by the WHATWG).

Interesting. And very pragmatic. We can understand that, there is no single force making it evolve.

> De-facto standards... Has the commitee that standardizes RDS considered
> changing the standard to follow de-facto practices (namely that radios
> do change the PS)?

[crit.r...@gmail.com]

> * AF (Alternative Frequencies). Frequencies for the same station. Used
> to travel from a place to another without having to manually change the
> frequency. WE NEED THAT SO BAAAAD!!

Unfortunately, this parameter and the others are used only by radio stations. You will find several stations not using them.
However, perhaps they are more useful on a home or car radio, and on a mobile, with radio station identification (PI & ECC) and internet connection

Best regards
Paolo

[crit.r...@gmail.com]

> * AF (Alternative Frequencies). Frequencies for the same station. Used
> to travel from a place to another without having to manually change the
> frequency. WE NEED THAT SO BAAAAD!!

Unfortunately, this parameter and the others are used only by *some* radio stations. You will find several stations not using them.

[crit.r...@gmail.com]

> * AF (Alternative Frequencies). Frequencies for the same station. Used
> to travel from a place to another without having to manually change the
> frequency. WE NEED THAT SO BAAAAD!!

[David Bruant]

Le 08/03/2013 12:19, crit.r...@gmail.com a écrit :
>> * AF (Alternative Frequencies). Frequencies for the same station. Used
>> to travel from a place to another without having to manually change the
>> frequency. WE NEED THAT SO BAAAAD!!
> Unfortunately, this parameter and the others are used only by *some* radio stations. You will find several stations not using them.

I don't think that's a problem. If they are available, they are exposed,
if they're not available, they're not exposed.
The RadioStationInfos interface can have all fields "optional" and
robust code would so something like:

if(stationInfos.AF !== undefined){
// do something with the AF
}

Which brings the question of the definitive list of infos. You've
expressed that you want PI, ECC and PS but what should the full list be?
I won't dive into the RDS standard to figure out what could be useful,
so I'll need from you a first list of properties that could be useful to
some use case. It could be all fields that are sent, but I imagine there
can be infos that are only "internal" and that no apps could make useful
use of.

David

[crit.r...@gmail.com]

> Which brings the question of the definitive list of infos. You've
> expressed that you want PI, ECC and PS but what should the full list be?
> I won't dive into the RDS standard to figure out what could be useful,
> so I'll need from you a first list of properties that could be useful to
> some use case. It could be all fields that are sent, but I imagine there
> can be infos that are only "internal" and that no apps could make useful
> use of.

Hi David,
thank you for your very active feedbacks.
Maybe selecting all possible RDS parameters and expose them in the API requires much time, and possible "quirks" could appear in how the HW exposes some other parameters (leading to even more problems). My feeling is that sticking to the basic parameters, at least initially, could be more effective.

Here are 3 of the most useful:
- PI Code: with ECC, it allows to identify the station, enabling the enrichment with content from internet (and hybrid radio)
- ECC Code
- PS name: displaying the station name, it improves the radio experience also if the station is not providing additional content.
Here is my proposal. A limited number of important parameters, to be quickly exposed. I would like to hear other opinions too.

To complete the list we could also include RadioText (and RadioText+). However this last data is seldom used [1] As an example, you can see that PS and RT+ implemented also e.g. in Apple iPod Nano.
All these parameters have been used in the CRC Android FM Library, well worth to be considered [2]

Other parameters are seldom implemented by broadcasters, or require a double FM tuner to be effective (and so are mainly used in car radios), and so on.

[1] http://www.rds.org.uk/2010/pdf/rdsForum_RTPlus%20progress_110120_10.pdf
[2] http://mmbtools.crc.ca/files/android/doc/ca/gc/crc/libfmrds/FMinterface.html

[crit.r...@gmail.com]

> Which brings the question of the definitive list of infos. You've
> expressed that you want PI, ECC and PS but what should the full list be?
> I won't dive into the RDS standard to figure out what could be useful,
> so I'll need from you a first list of properties that could be useful to
> some use case. It could be all fields that are sent, but I imagine there
> can be infos that are only "internal" and that no apps could make useful
> use of.

[David Bruant]

Le 08/03/2013 15:35, crit.r...@gmail.com a �crit :

>
>> Which brings the question of the definitive list of infos. You've
>> expressed that you want PI, ECC and PS but what should the full list be?
>> I won't dive into the RDS standard to figure out what could be useful,
>> so I'll need from you a first list of properties that could be useful to
>> some use case. It could be all fields that are sent, but I imagine there
>> can be infos that are only "internal" and that no apps could make useful
>> use of.
> Hi David,
> thank you for your very active feedbacks.
> Maybe selecting all possible RDS parameters and expose them in the API requires much time, and possible "quirks" could appear in how the HW exposes some other parameters (leading to even more problems). My feeling is that sticking to the basic parameters, at least initially, could be more effective.
>
> Here are 3 of the most useful:
> - PI Code: with ECC, it allows to identify the station, enabling the enrichment with content from internet (and hybrid radio)
> - ECC Code
> - PS name: displaying the station name, it improves the radio experience also if the station is not providing additional content.
> Here is my proposal. A limited number of important parameters, to be quickly exposed. I would like to hear other opinions too.

Ok, sounds good. If someone feels strongly about adding some other
properties, they can join the discussion.

Does the name "RadioStationInfos" sounds accurate for the interface that
will carry all these properties?
Is it the correct place to add future properties if someone wants to see
other properties exposed?

Thanks,

David

[David Bruant]

Le 07/03/2013 17:16, Paolo Casagranda a écrit :
>> Indeed. We need to make this information available to the app. I know
>> the user currently chooses a default language, but I don't think it can
>> choose a country and I don't think there is a way for an app to have
>> access to this information directly.
>> I don't really know how we can make this work without using
>> geolocalisation which the user can choose not to opt-in to.
>> In the case the user doesn't accept geolocalization, the app can't know
>> if the fields are to be interpreted against the RDS or RDBS semantics.
> Yes, it's a problem. Maybe here we can use the additional data if they're available. The app, for example, could have the country already set as the phone localization settings (e.g. in Android you can get the system Language and Country, usually set during configuration), and user can modify that on the app. This should only happen seldom.

Yeah worst case it can be an in-app thing. No need to worry too much
about that as a first approximation if the differences are minor.

>> Even the country can be a serious leak if your country is very small
>> (Andorra, Vatican, etc.) for instance.
>> PI/ECC may reveal only the country, but consider the following case:
>> My favorite radio is Le Mouv' (which PI is F208 [1], public info). The
>> frequency in Bordeaux is 87.7 [2] (public info too).
>> If an app has access to both the PI (which we're debatting) and the
>> frequency (which is available to every app already), then the app can
>> infer that I'm in Bordeaux, right? The inference can be further improved
>> using ECC and other "weaker" fields like PS, etc.
>> If that's the case, it's a form of geolocalization (which is actually
>> very interesting) and that's a bit privacy-invasive.
> Yes you're right. It should be put in the right perspective, following the system privacy guidelines. By the way, interesting idea, alternative to wifi geoloc (like Android's)
>
>> Now that I think about it, using the seekup method, an app can
>> *currently* know all frequencies which emits something. Based on the set
>> of frequencies emitting something, is it possible to infer the region?
>> If so, the FMRadio API should probably be considered to be a bit higher
>> priviledged than it currently is ("priviliged" would be enough).
> Yes in some cases you could infer the region. Although I imagine it's not trivial.

One person publishing the inference algorithm and open sourcing it can
be enough to turn something "not trivial" into "as trivial as importing
a script". Then *any* app can import this app to geoloc the user without
its consent since the radio API is currently available to any app.
Do you know where I can find a database of all frequencies/radio
stations/region?
I'll try to write a script to see how hard it is to infer where I am
from the frequencies. I'll report what I find and will probably take
action afterward.

>> Ok, sounds good.
>> I'm wondering if we need an event for each value or if one event for a
>> "bundle" (which I called "RadioStationInfos") can be enough. Although
>> there might be interference issues, I assume a station resends regularly
>> (do you know how often in practice?) the RDS infos.
>> If there was some interference and the RDS infos couldn't be read, is it
>> ok to miss the info and wait for the next time?
>> Are there case where an app would want to be informed that the RDS infos
>> couldn't be read?
> Yes, all the information is continuously sent. For PI and ECC it reception should be less then 0.1s (transmitted 11.4 times/s). Another example, the station name will take 1 or 2s (1 time/s), and considering typical reception conditions could be 4s. (->ftp://ftp.rds.org.uk/pub/acrobat/rbds1998.pdf page 18)
>
>> The idea of the radiostationchange event was to bundle the
>> onpiready/oneccready/onpschange/etc all at once. Basically, users play
>> with the frequency (or not) and whenever the radio station infos change,
>> you get a new event. It's less about PI/ECC being ready and more to tell
>> that the value has changed.
> Now it's clear. Then maybe another event could give added value, because of the timings I described before. A possible example to clarify timings:
> 0.00s the user starts the radio app
> 3.00s the FM turns on
> 3.10s the music start playng (and radiostationchange is called)
> 3.30s PI and ECC available (and onpichange is called) the radio app begins enhancing the radio UX with content from the internet
> 7:30s station name appears (PS available)

The way I was seeing things, the radiostationchange event only happens
when the PI/ECC values are avaiable or more accurately, when any value
RDS changes, so for me, the radiostationchange event happens at 3.30s
I'm still reluctant at the idea of one event per RDS info, because that
can become a lot.
What about an event anytime something changes and this event carries
only the "delta" between the last infos and the current infos? A bit
like "mutation summary" [1].
Asked differently, is an app more likely to want to be informed that a
particular value has changed or that some values have changed and deal
with it?

Hmm... especially given the frequencies you provided above, it seems
that one event with all changes may result in a lot of useless events if
the interesting values doesn't change very often (like PI and ECC), so I
guess that would weigh in favor of an event per value.

Sorry, I'm writing as I'm thinking. Tell me what you think.

Thanks,

David

[1] http://code.google.com/p/mutation-summary/

[Andy Buckingham]

On 8 March 2013 15:47, David Bruant <brua...@gmail.com> wrote:
> Does the name "RadioStationInfos" sounds accurate for the interface that
> will carry all these properties?
> Is it the correct place to add future properties if someone wants to see
> other properties exposed?

The only counter argument I could possibly add to that is that some
stations "resell" RDS spectrum for third party services, for example
in the UK RDS data of national broadcasters on FM carries traffic
information that sat nav systems use to update maps with problems and
disruptions. It has also been discussed using FM RDS to carry
information to domestic appliances to signal electricity day/night
rates for discounts, etc.

However, I cannot think of any common meta being transmitted
currently, that is not specifically related to the radio station, that
would be of interest currently. Furthermore I worry about the creep
this introduces in to the proposal.

I agree that "RadioStationInfos" sounds suitable.


On 8 March 2013 15:47, David Bruant <brua...@gmail.com> wrote:

> Le 08/03/2013 15:35, crit.r...@gmail.com a écrit :
>
>>
>>>
>>> Which brings the question of the definitive list of infos. You've
>>> expressed that you want PI, ECC and PS but what should the full list be?
>>> I won't dive into the RDS standard to figure out what could be useful,
>>> so I'll need from you a first list of properties that could be useful to
>>> some use case. It could be all fields that are sent, but I imagine there
>>> can be infos that are only "internal" and that no apps could make useful
>>> use of.
>>
>> Hi David,
>> thank you for your very active feedbacks.
>> Maybe selecting all possible RDS parameters and expose them in the API
>> requires much time, and possible "quirks" could appear in how the HW exposes
>> some other parameters (leading to even more problems). My feeling is that
>> sticking to the basic parameters, at least initially, could be more
>> effective.
>>
>> Here are 3 of the most useful:
>> - PI Code: with ECC, it allows to identify the station, enabling the
>> enrichment with content from internet (and hybrid radio)
>> - ECC Code
>> - PS name: displaying the station name, it improves the radio experience
>> also if the station is not providing additional content.
>> Here is my proposal. A limited number of important parameters, to be
>> quickly exposed. I would like to hear other opinions too.
>

[crit.r...@gmail.com]

Dear colleagues,
I've just added a ticket to ask FM RDS support in the webapi, as comprehensively discussed in this group. The ticket link is: https://bugzilla.mozilla.org/show_bug.cgi?id=864327

A descriptive information about the RM RDS API is also included, as asked by Anne van Kesteren (ref. https://bug864327.bugzilla.mozilla.org/attachment.cgi?id=740294 ).

Kind regards
Paolo


On Tuesday, February 26, 2013 4:03:37 PM UTC+1, Andy Buckingham (RadioDNS) wrote:
> I would like to propose the inclusion of basic RDS (RBDS in the US) support in the FM radio API. In particular the exposure of the RDS PI code and ECC value for the current radio station (when available).

>
>
>
> For those that are not aware, RDS is a worldwide standard for the transmission of additional in-band meta. For example, most car stereos will show the 'PS' value on the display when you tune to a station - that's the short 8 character station name. The standard itself is quite extensive and includes various different data types such as clock time, name, text messages and more.
>
>
>

> I am particularly interested in obtaining the PI (Programme Identifier) code which uniquely identifies the radio station being listened to. For example Capital FM in London broadcasts the code 'c479' on 95.8 FM. Combined with the open standard RadioDNS (http://radiodns.org), you can perform an authoritative lookup that allows the resolution of internet-based resources associated with the FM broadcast.
>
>
>

> Built upon this standard are a number of open projects such as RadioVIS, which provide an HTTP long poll (Comet) slideshow of images and text to be displayed whilst listening. A growing number of broadcasters around the world are now adopting these standards and the inclusion of these rich visuals in the radio app, instead of the default "87.6 FM", would make Firefox OS stand out from the crowd.
>
>
>

> There are several other apps including RadioEPG, which provides detailed service information and programme schedules, including station descriptions, logos, alternative IP stream URLs to switch to when FM reception dies and more. An upcoming standard RadioTAG also standardise way for all radio-capable devices to perform return path interaction, such as "tagging" a favourite song, ad or promo.
>
>
>

> All that is needed to enable a wealth of possibilities for developers to build upon the FM radio support is the exposure of the PI value to perform lookups. Without having seeing the drivers myself, I strongly suspect support is already in there for RDS functions and it simply needs exposing via the JS API. For some inspiration, Qt recently added RDS support to their FM interface (https://bugreports.qt-project.org/browse/QTBUG-23762).
>
>
>