Dynamic Label extensions to RadioVIS TEXT

[Robin Cooksey]

Hi All,

 

There has been a suggestion that the text functionality of RadioVIS could be extended to add RT+ like functionality.

 

I’d suggest that it might be best to base any such extensions on the Dynamic Label Plus (DL Plus) specification – ETSI TS 102 980 v1.1.1, so that RadioVIS continues to mirror equivalent native DAB broadcast functionality.  It would also bring this capability to other broadcast mediums (e.g. FM), and the DL Plus specification has some extended capability over RT+.

 

From a technical perspective, I think that this could be implemented by extending the existing TEXT command to carry information equivalent to the DL Plus tags command in the DL Plus specification – primarily the Item Toggle and Item Running bits, and a list of tags (essentially a tuple of content type, start position and length referring to the TEXT message).  I guess this could be added as a header or headers.

 

Does anyone have any interest in this – either from a broadcaster or a device specification?

I’d like to find how much interest there is in taking this idea further.

 

Best regards,

Robin

 

Robin Cooksey
Principal Software Engineer
Frontier Silicon Ltd.

D +44 1223 497784

www.frontier-silicon.com
Dales Manor Business Park, Babraham Road, Sawston, Cambridge, CB22 3LJ, UK

Frontier Silicon Ltd is a Toumaz Group company (the Group also includes Toumaz Healthcare and Toumaz Microsystems), registered in England and Wales - company no. 4213838. Registered address: 137 Euston Road, London, NW1 2AA

[정훈섭]

Hi Robin.

Im very interested this functionality.

I think it is very useful function.

 

cant wait to add.

thanks.

2013년 7월 18일 목요일 오후 5시 56분 23초 UTC+9, Robin Cooksey 님의 말:

[Paolo]

Hi Robin,
very good, it would be a very useful functionality, mirroring existing (or coming soon) DAB DL+ services.
AFAIK it would be completely backwards compatible, like DL+.

Kind regards
Paolo Casagranda

--
You received this message because you are subscribed to the Google Groups "RadioVIS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radiovis-develo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Paolo @ RadioDNS]

Dear RadioDNS colleagues,
some time ago Andy and I contacted the Mozilla FirefoxOS project, to
understand if a standard API for FM/RDS could be implemented for that
mobile OS ( ref. https://bugzilla.mozilla.org/show_bug.cgi?id=864327)
We've proposed a first API draft (ref.
https://bug864327.bugzilla.mozilla.org/attachment.cgi?id=741322) and now
the draft should be revised by the WebAPI team, as a second step towards
inclusion in the OS.

Before the revision, it could be a great opportunity for us to improve
the first proposal, e.g. including also digital radio support, or at
least changing it so that it supports extensions to other formats.

In a few days we've to submit the new proposal and the revision process
will take place.

Please, if you have some improvement suggestion, send it to the list!

If there'll be no comment in the next few days, we'll confirm to Mozilla
WebAPI team to review this proposal.

Kind regards
Paolo

PS: as a first try, just to kickoff discussion, the FM part could be
modified in this way, adding basic DAB support:

// NEW: DAB API extension BEGIN

readonly attribute long sid; // DAB Service ID, similar to RDS PI Code
readonly attribute long eid; // DAB Ensemble ID
readonly attribute long scids; // DAB Service Component Identifier within the Service
readonly attribute DOMString serviceLabel; // service label
readonly attribute DOMString dls; // Dynamic Label Segment string, when available

attribute Function onsidcodechange; // SId Code becomes available or changes (REQUIRED)
attribute Function oneidcodechange; // EId Code becomes available or changes
attribute Function onpscodechange; // PS name becomes available or changes
attribute Function ondlschange; // new DLS becomes available

// DAB API extension BEGIN


// FM RDS API proposal BEGIN

readonly attribute long piCode; // PI Code: the Program Identification (REQUIRED)
readonly attribute long eccCode; // ECC Code: the Extended Country Code
readonly attribute DOMString psCode; // PS name: Program Service name

attribute Function onpicodechange; // PI Code becomes available or changes (REQUIRED)
attribute Function onecccodechange; // ECC Code becomes available or changes
attribute Function onpscodechange; // PS name becomes available or changes

// FM RDS API proposal END

[Paolo Casagranda]

Hi Christian,

thank you for your timely feedback. Would you describe a simple concrete use case where signalStrength would significantly improve the app behavior? Maybe useful for an app able to switch from FM/DAB+ to IP if signalStrength is too low?

By the way, note that the original draft API (FM only, no DAB or RDS) is at https://developer.mozilla.org/en-US/docs/Web/API/FMRadio 

Kind regards

Paolo

On Monday, October 21, 2013 1:15:30 PM UTC+2, Christian Winter wrote:

Hi,

what about a signalStrength Attribute? Even if conditions can change quickly in FM I think this is needed for hybrid radio, because how would your app react when onpicodechange, onecccodechange onpscodechange isn't called anymore?

kind regards,

Christian

[Robin Cooksey]

Hi Paolo,

 

This looks interesting – I had a few comments:

 

readonly attribute DOMString psCode; // PS name: Program Service name

 

Would it make more sense to call this “psName”, rather than “psCode”?

Is there anything else from RDS/RBDS that it would be useful to include?  E.g. Programme type, RadioText?

 

 

For a DAB API, I notice that this only provides information about the current station – not any control of the DAB tuner, whereas the original FM WebAPI also included control.

 

Obviously there’s lots more information associated with a DAB station that potentially could be useful; but I think at least the ECC would be needed for DAB to allow for RadioDNS lookup.

 

Best regards,

Robin

 

 

[Paolo Casagranda]

Hi Robin,
thank you for the comment. RadioText would be definitely useful, and maybe it could be implemented with a little extra effort. Radio controls were not included because they are common to FM and DAB (and probably to all radio standards). So here is another proposal clarifying some points, merging your suggestions and Andy's, and using class inheritance to point out the similarities. My view is that separating, e.g., RadioText and DLS, would increase readability for developers. The alternative is to define a new name to include them ( RT/DLS, PS/SL, PI/SID etc.). Does it make sense?

Suggestion: FMRadio and DABRadio should inherit from RadioInterface interface, an interface (in OOP sense) which includes all common attributes and methods.

interface RadioInterface : EventTarget { //inherits from RadioInterface
   readonly attribute boolean enabled;
   readonly attribute boolean antennaAvailable;
   readonly attribute double frequency;
   readonly attribute double frequencyUpperBound;
   readonly attribute double frequencyLowerBound;
   readonly attribute double channelWidth;

   attribute Function onantennaavailablechange;
   attribute Function onfrequencychange;
   attribute Function onenabled;
   attribute Function ondisabled;

   DOMRequest enable(double frequency);
   DOMRequest disable();
   DOMRequest setFrequency(double frequency);
   DOMRequest seekUp();
   DOMRequest seekDown();
   DOMRequest cancelSeek();

//  NEW BEGIN
    readonly attribute long signalStrength; // the signal strength, a measure of signal quality
//  NEW END
  
   }

interface FMRadio : EventTarget { //inherits from RadioInterface
   readonly attribute boolean enabled;
   readonly attribute boolean antennaAvailable;
   readonly attribute double frequency;
   readonly attribute double frequencyUpperBound;
   readonly attribute double frequencyLowerBound;
   readonly attribute double channelWidth;

   attribute Function onantennaavailablechange;
   attribute Function onfrequencychange;
   attribute Function onenabled;
   attribute Function ondisabled;

   DOMRequest enable(double frequency);
   DOMRequest disable();
   DOMRequest setFrequency(double frequency);
   DOMRequest seekUp();
   DOMRequest seekDown();
   DOMRequest cancelSeek();

//  NEW BEGIN
    readonly attribute long signalStrength; // the signal strength, a measure of signal quality
//  NEW END

    // FM RDS API proposal BEGIN   

    readonly attribute long pi; // PI Code: the Program Identification (REQUIRED)
    readonly attribute long ecc; // ECC: the Extended Country Code
    readonly attribute DOMString ps; // PS name: Program Service name

    attribute Function onpichange; // PI Code becomes available or changes (REQUIRED)
    attribute Function oneccchange; // ECC Code becomes available or changes
    attribute Function onpschange; // PS name becomes available or changes

// FM RDS API proposal END
  
   }
  

interface DABRadio : EventTarget {
   readonly attribute boolean enabled;
   readonly attribute boolean antennaAvailable;
   readonly attribute double frequency;
   readonly attribute double frequencyUpperBound;
   readonly attribute double frequencyLowerBound;
   readonly attribute double channelWidth;

   attribute Function onantennaavailablechange;
   attribute Function onfrequencychange;
   attribute Function onenabled;
   attribute Function ondisabled;

   DOMRequest enable(double frequency);
   DOMRequest disable();
   DOMRequest setFrequency(double frequency);
   DOMRequest seekUp();
   DOMRequest seekDown();
   DOMRequest cancelSeek();

   //  NEW BEGIN
    readonly attribute long signalStrength; // the signal strength, a measure of signal quality
    //  NEW END

  
   // NEW: DAB API extension BEGIN
    readonly attribute long sid; // DAB Service ID, similar to RDS PI Code
    readonly attribute long eid; // DAB Ensemble ID
    readonly attribute long scids; // DAB Service Component Identifier within the Service
    readonly attribute DOMString serviceLabel; // service label
    readonly attribute DOMString dls; // Dynamic Label Segment string, when available

    attribute Function onsidchange; // SId Code becomes available or changes (REQUIRED)
    attribute Function oneidchange; // EId Code becomes available or changes
    attribute Function onpschange; // PS name becomes available or changes

    attribute Function ondlschange; // new DLS becomes available
// DAB API extension BEGIN
  
   }
  

Best regards
Paolo

To unsubscribe from this group and stop receiving emails from it, send an email to radiovis-developers+unsub...@googlegroups.com.

[Paolo Casagranda]

Dear colleagues,
if there's no objection, I'll send the new draft to the FirefoxOS Bugzilla forum, for a review. Of course you can also comment on the forum.

Best regards
Paolo

PS: as Robin suggests I'll add the ecc part to the DAB too (necessary after the FM/DAB interfaces separation)

[Paolo Casagranda]

Dear all,
I send again the last draft proposal (apparently gone with an update of Google Groups app).
The updates are (see the code below):
- ECC and RadioText and associated callbacks added
- signalStrength callback added
- some minor improvements

Please send feedbacks/improvements. Otherwise we'll send the draft to the Mozilla FirefoxOS forum this afternoon.

Best Regards
Paolo

Suggestion: FMRadio and DABRadio should inherit from RadioInterface interface, an abstract class which includes all common attributes and methods.

interface RadioInterface : EventTarget { //inherits from RadioInterface
   readonly attribute boolean enabled;
   readonly attribute boolean antennaAvailable;
   readonly attribute double frequency;
   readonly attribute double frequencyUpperBound;
   readonly attribute double frequencyLowerBound;
   readonly attribute double channelWidth;

   attribute Function onantennaavailablechange;
   attribute Function onfrequencychange;
   attribute Function onenabled;
   attribute Function ondisabled;

   DOMRequest enable(double frequency);
   DOMRequest disable();
   DOMRequest setFrequency(double frequency);
   DOMRequest seekUp();
   DOMRequest seekDown();
   DOMRequest cancelSeek();

//  NEW BEGIN
    readonly attribute long signalStrength; // the signal strength, a measure of signal quality

    attribute Function onsignalstrengthchange; // signalStrength changes

//  NEW END
  
   }

interface FMRadio : EventTarget { //inherits from RadioInterface
   readonly attribute boolean enabled;
   readonly attribute boolean antennaAvailable;
   readonly attribute double frequency;
   readonly attribute double frequencyUpperBound;
   readonly attribute double frequencyLowerBound;
   readonly attribute double channelWidth;

   attribute Function onantennaavailablechange;
   attribute Function onfrequencychange;
   attribute Function onenabled;
   attribute Function ondisabled;

   DOMRequest enable(double frequency);
   DOMRequest disable();
   DOMRequest setFrequency(double frequency);
   DOMRequest seekUp();
   DOMRequest seekDown();
   DOMRequest cancelSeek();

//  NEW BEGIN
    readonly attribute long signalStrength; // the signal strength, a measure of signal quality
   

    attribute Function onsignalstrengthchange; // signalStrength changes

//  NEW END

    // FM RDS API proposal BEGIN   
    readonly attribute long pi; // PI Code: the Program Identification (REQUIRED)
    readonly attribute long ecc; // ECC: the Extended Country Code
    readonly attribute DOMString ps; // PS name: Program Service name

    readonly attribute DOMString radioText; // RadioText, a 64 bytes string

    attribute Function onpichange; // PI Code becomes available or changes (REQUIRED)
    attribute Function oneccchange; // ECC Code becomes available or changes
    attribute Function onpschange; // PS name becomes available or changes

    attribute Function onradiotextchange; // RadioText becomes available or changes

// FM RDS API proposal END
  
   }
  
interface DABRadio : EventTarget {
   readonly attribute boolean enabled;
   readonly attribute boolean antennaAvailable;
   readonly attribute double frequency;
   readonly attribute double frequencyUpperBound;
   readonly attribute double frequencyLowerBound;
   readonly attribute double channelWidth;

   attribute Function onantennaavailablechange;
   attribute Function onfrequencychange;
   attribute Function onenabled;
   attribute Function ondisabled;

   DOMRequest enable(double frequency);
   DOMRequest disable();
   DOMRequest setFrequency(double frequency);
   DOMRequest seekUp();
   DOMRequest seekDown();
   DOMRequest cancelSeek();

   //  NEW BEGIN
    readonly attribute long signalStrength; // the signal strength, a measure of signal quality

    attribute Function onsignalstrengthchange; // signalStrength changes

    //  NEW END
  
   // NEW: DAB API extension BEGIN

    readonly attribute long sid; // DAB Service ID, similar to RDS PI Code (REQUIRED)
    readonly attribute long eid; // DAB Ensemble ID (REQUIRED)
    readonly attribute long scids; // DAB Service Component Identifier within the Service (REQUIRED)
    readonly attribute long ecc; // DAB ECC: the Extended Country Code (REQUIRED)
    readonly attribute DOMString serviceLabel; // DAB service label
    readonly attribute DOMString dls; // Dynamic Label Segment string, when available, 128 bytes string

    attribute Function onsidchange; // SId Code becomes available or changes (REQUIRED)

    attribute Function oneidchange; // EId Code becomes available or changes (REQUIRED)
    attribute Function onscidschange; // SCIDS becomes available or changes (REQUIRED)
    attribute Function oneccchange; // ECC Code becomes available or changes (REQUIRED)
    attribute Function onservicelabelchange; // PS name becomes available or changes

[Paolo Casagranda]

Dear colleagues,
just a feedback. They ask if
- the signal strength measure could be in dBm (instead of a dimensionless 0-5)
- the API for FM/RDS and DAB/DAB+/DMB can be split (to split development effort too)

If there's no objection, I'll confirm dBm for signal strength and the separation of FM/RDS and DAB, taking care that in the future also other standards could be supported, so a unique Radio interface superclass could be useful.

Kind regards
Paolo

[Alexander Erk]

Hello Paolo, dear RadioDNS developers,

the change to dBm for measuring the signal strength seems fine for me. But allow me to try to initiate a more general discussion on this API/functionality:

1 I would like to see this API designed with a common functionality capsulated in a base Class/Interface. The reason is, for application developers 90% of the common tasks in a HTML application could be held generic, no matter if there’s a FM or DAB tuner technically build into the device. This is even more the truth, if we include IP based delivery of radio services. If we look into the RadioEPG XSI documents, there are FM, DAB and IP services grouped together, allowing the implementation for service following and other fancy stuff.

2 Searching/setFrequency:
If there’s a cancelSeek(); method there must be a way for the application to determine that a channel search is in progress. I would suggest:

readonly attribute boolean searching; // returns true if the tuner currently i in scanning mode. False otherwise


3 Service lists/tuning: An API for obtaining the service list is missing. Applications normally don’t want to scann over the whole bands to find what channels are available. First it takes a long time and secondly we’ll assume that some kind of scann already happened. In DAB the situation is a bit more complicated. Even if an application knows the frequency of an ensemble, one ensemble usually contains more than one service. So my assumption would be, that an application calls a method getServiceList(); and an List/Array of Services is returned. The Service objects have then properties:

for FM:

> readonly attribute long pi; // PI Code: the Program Identification (REQUIRED)
> readonly attribute long ecc; // ECC: the Extended Country Code
> readonly attribute DOMString ps; // PS name: Program Service name

or for DAB/DAB+:

> readonly attribute long sid; // DAB Service ID, similar to RDS PI Code (REQUIRED)
> readonly attribute long eid; // DAB Ensemble ID (REQUIRED)
> readonly attribute long scids; // DAB Service Component Identifier within the Service (REQUIRED)
> readonly attribute long ecc; // DAB ECC: the Extended Country Code (REQUIRED)
> readonly attribute DOMString serviceLabel; // DAB service label

As consequence, the RadioInterface much more needs a method like :

DOMRequest setService(Service newService); // Sets the new service

for the application developer to tune the device to the desired service. Following this a property:

readonly attribute Service actualService; // Returns the actual tuned service

and

attribute Function onServiceChange; //Allows to register a listener for service changes

makes sense to get the currently tuned service object.


If the initial call to getServices() doesn’t return a list of services or the desired service is not in the list, the application still can either initiate (with user feedback) a full scan or the input of a frequency by the end user.


4 Dataservices:

As already mentioned in 1: I would like to see a generic common API for Radio (no matter if FM or DAB). This includes APIs in the Service object for:

getServiceLabel();
getTextMessage();
getVisual();
getEPG();


and the usual methods to observe this data like:

attribute Function onSlideChange;
attribute Function onRadioTextChange;
attribute Function onEPGChange;


On FM devices this high level access is mapped the RDS (Service Label and RadioText) and to RadioDNS (RadioVIS, RadioEPG). While on DAB devices this is mapped to DAB data services SLS, DL/DL+ and DAB EPG. This abstraction would have the benefit, that developers don’t have to care about technologies (FM/RadioDNS/DAB) until the use-case makes this necessary.


Best regards


Alexander Erk

> --
> You received this message because you are subscribed to the Google Groups "RadioVIS developers" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to radiovis-develo...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.

-------------------------------------------------------------------------------------------------------------------
Dipl.Inf (FH) Alexander Erk
Informationsdienste

Institut für Rundfunktechnik GmbH
Phone: +49 (0)89 / 323 99 - 282
Fax: +49 (0)89 / 323 99 - 200
Internet: www.irt.de

Forschungs- und Entwicklungsinstitut von ARD, ZDF, DRadio, ORF und SRG/SSR GmbH
Geschäftsführer: Dr. Klaus Illgner-Fehns
Registergericht München HRB 5191

Research and Development Institute of ARD, ZDF, DRadio, ORF and SRG/SSR GmbH
Managing Director: Dr. Klaus Illgner-Fehns
Registration court Munich Commercial Register No. B 5191

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und löschen Sie diese E-Mail. Das unerlaubte Kopieren
sowie die unbefugte Weitergabe dieser E-Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and delete this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.

[Paolo Casagranda]

Dear all,
thank you for the useful comments. All points raised by Alexander and Christian seem very good ones.

As a consequence, at this point it's not clear for me how to proceed. In the following days there'll be also a discussion at EBU and I hope some useful direction will emerge. Meanwhile, I see the following questions:
1. Are we trying to design a minimum or a complete interface? I'd be inclined for the first choice, the minimum to implement RadioDNS use cases. Any other opinion?
2. Are we OK splitting the interface in FM/RDS and DAB, as requested by the Mozilla team? For sure their request is well motivated (by the limited resources for this topic)
3. The DAB part is more complicated indeed (see Alexander's comments for example). Do we need a better analysis of the interface?

Techincally, I'd add another point, taking inspiration from a previous proposal of FM API for Android (Ericsson, 2010 https://groups.google.com/forum/#!topic/android-platform/eFhxfsxqIMc ). We can define multiple states:  disabled, starting, enabled, seeking, paused. Paused would be useful if we want to temporarily take anothe action on the phone and then play the radio again (it needs a setPause method and another callback of course).

Looking forward for your feedback
Kind regards
Paolo


On Tuesday, October 29, 2013 7:11:42 PM UTC+1, Christian Winter wrote:

Hi Paolo, Dear RadioDNS DevTeam,

it's great to see so many of your opinions. There is a lack of a good FM/DAB API in the Android, WP,iOS world so I'm glad that the Firefox OS devs want to face up with it.

SignalStrength in dBm would be fine for me, too.

I like the suggestion Alex made to create a more generic Radio API in respect that RadioDNS would work with all broadcast systems.

Kind regards,

Christian

Am Montag, 21. Oktober 2013 08:58:20 UTC+2 schrieb Paolo Casagranda:

[Andy Buckingham (RadioDNS)]

Hopefully some of you on the group are aware of the efforts of the
Smartphone Radio API project, which involves a number of broadcasters
and related organisations collaborating to define a "generic" Radio
API. The main of this is to abstract as many of the complexities of
handling radio hardware for developers as possible, to encourage the
development of innovative applications. Furthermore it is proposed
this API to then be adopted across manufacturers and platforms
providing a common way to use radio hardware in smartphone devices.

Personally, I would value a low level API that lets me access the
hardware itself. This would need to be split in to FM and DAB APIs and
is very much the sort of think you've already captured in previous
posts. On top of this, though, I like the idea of the abstract
simplified API. This would allow FM and DAB to integrated and make it
easier for developers to use. To this extent, it makes sense to me to
adopt the existing work of the Smartphone Radio project and encourage
Mozilla to adopt this as the higher level "superclass" methodology.
This layer would also have built in RadioDNS functionality within the
API itself.

Essentially I propose we have 2 levels of API access:

* Hardware level (FM API, DAB API etc.)
* Abstracted "Radio" level API (getServices, tune, notifications etc.)

[Mike Reid]

Where can I find info on "Smartphone Radio API project" ?

Thanks !

[Paolo Casagranda]

Hi Andy,
fortunately you could give us information about the existence of this project. There's no info on the internet, and some broadcasters and interested people were not involved, it's a pity. However I think in the next days more information will come.

So we can still work on the "low level" API. Before sending the proposal to the Mozilla FirefoxOS team, we have to know some detail about the Smartphone Radio API project, to be sure their API can be built upon ours, at least.

Technically, I would add to the disabled and enabled states, also the starting (the receiver is not yet enabled), seeking (or searching) and paused (the receiver is temporarily paused or muted, but not disabled, allowing for fast music recovery).

By the way, Mike Reid was also asking more information, apparently his mail is still waiting a moderator approval.

Best regards,
Paolo

[Alexander Erk]

Dear all,

the question if we should develop a low level or a high level abstraction for the usage of tuner hardware is a very hard one.

In my point of view the question should be: What do we want to achieve, or whom we want to attract? I think we want to see cool radio applications for the mobile devices. From the application developers point of view, a general high level API is more attractive, just because the majority of applications will ever perform the same tasks, regardless of FM or DAB. Having only a low level API would lead to a bunch of applications doing the same tasks slightly different. This in turn, is also not satisfying for device manufacturers as well as for application developers. A high level API would give the device manufacturers the possibility to implement theAPI in a best possible way.

So I would prefer a application developers optimized high level API with a very well defined feature set. Having furthermore the possibility to detect the underlying transmission technology and (if the application requires this level) hand over to a low level API however could be very useful.

Alex

> --
> --
> You received this message because you are subscribed to the RadioDNS developers group. RadioDNS is at http://radiodns.org/
> To post to this group, send email to
> radiodns-...@googlegroups.com
> To unsubscribe from this group, send email to
> radiodns-develo...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/radiodns-developers?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-develo...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.

[Paolo Casagranda]

Hi Alexander,
the first goal of the involvement in the FirefoxOS project was to provide a minimum set of API providing horizontal access to the FM Tuner and enabling the RadioDNS use cases. Of course this target should change, if useful.

The idea of a unifying Smartphone Radio API is great, but the level is much higher and maybe it will take some time before it's fine tuned and accepted by all the players. Waiting for some detailed info about that project, here we're trying to make a much smaller step. We're taking an opportunity, proposing a basic, low level API to a young (and very collaborative, at the moment) mobile OS. If I correctly understand what Andy said, we can go forward and then map these API on any kind of high level API.

Once we have a set of primitive functions, we can create much more advanced functionalities using them.

I propose the following state diagram to better undestand how the receiver will work: https://drive.google.com/file/d/0Bwmhj0kP0mn-SXM4Z010M1VZTGM/edit?usp=sharing
The antennaavailable state is not mentioned to simplify the diagram (as it's a pre-requisite). Below there's a listing of the FM/RDS part (split, as suggested). Please feel free to correct/change/comment.

Best regards
Paolo

interface FMRadio : EventTarget {
   readonly attribute boolean disabled; // NEW: when the interface is created, is in the "disabled" state

   readonly attribute boolean enabled;
   readonly attribute boolean antennaAvailable;
   readonly attribute double frequency;
   readonly attribute double frequencyUpperBound;
   readonly attribute double frequencyLowerBound;
   readonly attribute double channelWidth;

   readonly attribute long signalStrength; // NEW: the signal strength, a measure of signal quality
   readonly attribute boolean searching;   // NEW: "searching" state
   readonly attribute boolean paused;      // NEW: "paused" state
   readonly attribute boolean starting;    // NEW: "starting" state

   attribute Function onantennaavailablechange;
   attribute Function onfrequencychange;
   attribute Function onenabled;
   attribute Function ondisabled;

   attribute Function onsignalstrengthchange; // NEW: signalStrength changes
   attribute Function onpause;   // NEW: signalStrength changes
   attribute Function onresume;  // NEW: signalStrength changes
   attribute Function onstartingcomplete;  // NEW: signalStrength changes
   attribute Function onsearching;  // NEW: signalStrength changes
   attribute Function onsearchingcomplete;  // NEW: signalStrength changes

   DOMRequest enable(double frequency);
   DOMRequest disable();
   DOMRequest setFrequency(double frequency);
   DOMRequest seekUp();
   DOMRequest seekDown();
   DOMRequest cancelSeek();

   DOMRequest pause(); // NEW: transition from "enabled" to "paused"
   DOMRequest resume(); // NEW: transition from "paused" to "enabled"
   
   readonly attribute long pi; // NEW: PI Code: the Program Identification
   readonly attribute long ecc; // NEW: ECC: the Extended Country Code
   readonly attribute DOMString ps; // NEW: PS name: Program Service name (OPTIONAL)
   readonly attribute DOMString radioText; // NEW: RadioText, a 64 bytes string (OPTIONAL)

   attribute Function onpichange;  // NEW: PI Code becomes available or changes
   attribute Function oneccchange; // NEW: ECC Code becomes available or changes
   attribute Function onpschange;  // NEW: PS name becomes available or changes (OPTIONAL)
   attribute Function onradiotextchange; // NEW: RadioText becomes available or changes (OPTIONAL)

> radiodns-developers+unsub...@googlegroups.com

> For more options, visit this group at
> http://groups.google.com/group/radiodns-developers?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-developers+unsub...@googlegroups.com.

[Nick Piggott (RadioDNS)]

Hello,

Andy's referred to the Universal Smartphone Radio Project, and the intention to create some high level APIs for radio functionality that are globally consistent across FM, HD, DAB and DAB+.

It's taken a while to organise the project partners, but we are working out a way to share the API document and take into account comments from developers.

The API is high level and abstract from the specifics of silicon. That means there is still value in defining low level, radio system and OS specific APIs for developers who want specific control.

As Alex has said, one of the benefits of a consistent high level API set is that very specific broadcast behaviours (like Service Following) can be correctly implemented by developers who have no interest/understanding of the detail required to implement them correctly. This will make the user experience more consistent.

I'll communicate what's happening onto this list as I'm able to.

Nick

--
--

You received this message because you are subscribed to the RadioDNS developers group. RadioDNS is at http://radiodns.org/
To post to this group, send email to
radiodns-...@googlegroups.com
To unsubscribe from this group, send email to

radiodns-develo...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
---

You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-develo...@googlegroups.com.

[Paolo Casagranda]

Thank you for the update.

I'm going to send the link to this public discussions to the Mozilla forum, as we've asked to.

Best regards
Paolo



On Tuesday, November 5, 2013 3:15:52 PM UTC+1, Mike Reid wrote:

I look forward to more information about the "Universal Smartphone Radio Project"

I see the WorldDMB General Assembly Wednesday 15:20 slot describes: http://www.worlddab.org/public_document/file/411/GA-final.pdf?1383049678

"Hear about plans for DAB in cars... Delegates will hear also about the Universal Smartphone Radio Project led by the BBC and Global Radio in the UK

and others around the world including Clearchannel and EBU. Mark Friend,..."

I think there is good value in both low level and higher level radio APIs. In fact 3 or more levels can have merit too, but I've been very hesitant to add more APIs

to the current mix.

The old ST-Ericsson proposed Android FM API, still used by Sony, supported by my Spirit FM apps, and a basis for my new "Spirit2" app, provides both:

- The low level API is Android NDK C language based, for low level FM chip/API "plugins". The plugins adapt the ST-Ericsson software "stack" above it

to a particular chip or low level API. The plugin can deal with V4L or other device drivers. This API isn't documented, except by examining source.

- The high level API is Android Java based and is built on an Android specific layer that allows the plugins to be accessed with a pretty rich API across processes

and even by multiple processes simultaneously. This API is meant for Android Java "apps", by which I mean at least one Android Service, and at least one Android Activity

for the GUI.

I've been designing and building my new Android specific Spirit2 app with an intention to enable 3rd party "apps" with alternative & better GUIs than I've been

doing so far. I'm using the ST-Ericsson code and have created some FM plugins and it works well, for low level APIs at least.

But I've concluded that the "high level" of the ST-Ericsson code is still too complicated for many people to deal with. I put a thin layer on top of it, but

even that isn't easy enough IMO. The result is that I've created a higher level Android Intent based API that speaks with my Android Service.

In this way, a 3rd party app or widget is much simplified. All the "hard" background stuff is done by my Radio Service. The 3rd party app or widget only has

to send simple commands to the Service (1 line of code) and receive simple status updates.

The background "hard stuff" includes notification shade updates & controls, same for "remote controls" including BT AVCRP and lockscreen display/control,

media button controls, sleep/alarm functions, digital audio processing, recording, and some support for equalization & visualizations.

I've also added some support for Android App Inventor apps, intended for non-programmers and hobbyists. It's technically another layer, but uses the same Intent API.

I should note that audio related functionality should not be overlooked. A "tuner API" is fine, but a fuller "radio API" needs to deal with audio issues.

My Spirit FM app supports 6 different highish level Android Java APIs (in addition to 4 low level). Four of those were reverse engineered in early 2012,

and my work has been somewhat ongoing with those, as they change over time. But at least half my work this past year has been with solving audio problems.

Don't underestimate the importance of audio.

Regards,

Mike.

radiodns-developers+unsub...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
---
You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-developers+unsub...@googlegroups.com.

[Mike Reid]

I hate to be "dense", but... how do I properly join the group ?

Thanks,
Mike.

--
You received this message because you are subscribed to the Google Groups "RadioVIS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radiovis-develo...@googlegroups.com.

[Paolo Casagranda]

Hi Mike,
welcome! If you already joined the radiovis-developers (or radiodns-developers) groups, I think the moderators already included your requests, in any case they can give you a feedback.

Personally I suggest you have a look at the RadioDNS documentation (http://radiodns.org/documentation/ ) and, specially, at the IPR Policy if you contribute http://radiodns.org/wp-content/uploads/2009/03/ipr_policy_v1.pdf

Best regards
Paolo

[Paolo Casagranda]

Dear RadioDNS colleagues,
as there's no objection, I'm going to send the new low-level FM/RDS API proposal to the Mozilla team (you can read it below). Feedbacks and corrections are welcome as always.

Best regards
Paolo


Proposed FM/RDS low level Radio API, r04

interface FMRadio : EventTarget {
   readonly attribute boolean disabled; // NEW: when the interface is created, is in the "disabled" state
   readonly attribute boolean enabled;
   readonly attribute boolean antennaAvailable;
   readonly attribute double frequency;
   readonly attribute double frequencyUpperBound;
   readonly attribute double frequencyLowerBound;
   readonly attribute double channelWidth;

   readonly attribute long signalStrength; // NEW: the signal strength in dBm, a measure of signal quality

 Overview
 This FM/RDS API includes suggestions from the discussions on the FirefoxOS WebAPI Google Group, the Mozilla FirefoxOS Bugzilla server and RadioDNS Developers Google Groups.
 The API extends the previous FirefoxOS API, adding some attributes and functions, useful to enable the RadioDNS Hybrid Radio use cases and to enrich the Radio user experience.
 
 Refer to the attached diagram for an overview of this low level API states. At the moment, the "searching" state only refers to setFrequency(), seekUp() and seekDown()
 Some API (readonly attribute double frequencyUpperBound; readonly attribute double frequencyLowerBound;) were left for backwards compatibility, it's not clear their usage.
 signalStrength, while not strictly necessary, is very useful to track reception quality. It should be represented in dBm (see Pin Zhang, Justin Lebar).
 pause() should be used to allow a quick audio mute and resume, without the latency involved e.g. in enable() and setFrequency() methods. It's not strictly related to the hybrid radio use cases, but it can greatly improve user experience (e.g. temporary activity on smartphone while listening radio).
 The ps and radioText attributes (and associated functions) can be considered Optional, as they are not strictly necessary for the hybrid radio use cases. However, they improve the user experience in a broadcast only scenario.
 
 
 
 
 

[Paolo Casagranda]

Dear colleagues,
a manufacturer's suggestion is needed for the signalStrength parameter. Our proposal was to use "dBm" units, however there could be no consistency between the FM chip outputs of different manufacturers. And it’s not clear which maximum and minimum values we should set.

One of the original proposals (FirefoxOS bugzilla) was to use a [0,1] interval for signalStrength, mapping raw values to this interval (check https://bugzilla.mozilla.org/show_bug.cgi?id=864327#c23 and the past discussions at https://bugzilla.mozilla.org/show_bug.cgi?id=779500#c128 ). This would be a relative measure of course. However, is there a strong need for an absolute power measure?

Any comment? Robin Cooksey specially, what do you think about that?

Best regards
Paolo