Device behaviour: PI code switching and DAB service following

[Andy Buckingham (RadioDNS)]

Recently a discussion has begun regarding the preferred device
behaviour for the following situation:

1. Whilst receiving an FM service, the PI code changes

The specification already states that the radio must perform a full
RadioDNS lookup again, resubscribing to a new topic that matches the
new PI code. But the question raised was what the device should do
with the currently displayed slide from the previous PI code until a
new one is received (if it is received at all?)

In case you are not aware, there is a common technique amongst
networked radio stations with multiple transmitters that, at certain
times, share the same programming and at other times, for example
during advert breaks, split their content so each transmitter has
unique audio. The use of a "switched PI" is to improve the user
experience, particular on in-car FM RDS receivers, which often use a
technique on dual tuner devices to scan the FM band for other
transmitters with the same PI code and a stronger signal than the one
currently being consumed. When a suitable candidate is found, the main
tuner is switched thus appearing to offer improved reception without
an interruption to the audio. As you can expect, this is a great user
experience and seamless if the audio is identical. However, in our
example of advert breaks that differ between transmitters, if the PI
codes are still identical this causes a jarring audio switch - and it
could happen many times per minute in patch coverage areas. Therefore,
the broadcaster switches the PI code on some of the transmitters in
the group so radios don't consider them suitable candidates for
switching to.

When we explored this situation further, we found a couple of similar
situations:

2. Whilst receiving a DAB service, a service following behaviour
causes the radio to move to an alternative service

3. IP bearers may implement in-band signalling technologies to force
the radio to move to an alternate service (I'm aware the Shoutcast 2.0
spec contains techniques for doing this)

One possible option is to identify any situation where the client,
without user interaction, changes differently to a specific user
interaction (picking a new service from a service list). Where no
interaction occurs, it is reasonable to assume that this is a service
provider instruction. Therefore, we could state than when the user
initiates a change, the screen must be cleared, and when a service
provider initiates a change, the last slide should persist until a new
slide is received OR it is determined that RadioVIS is unavailable on
the "new" service.

A situation where this logic falters would be if the user is between 2
transmitters for entirely unrelated services, which both happen to be
on the same frequency. This situation could be more prevalent in lift
conditions. When this occurred it would appear to the client as a PI
code change without user interaction. If one of the service providers
was incorrectly signalling VIS support when they didn't or was using a
slow rotation with no retroactive, the client may incorrectly persist
the wrong visualised content for a long period of time. I would argue
that the incorrect signalling of a VIS service is a more serious issue
which we shouldn't necessarily deal with in this instance. Would it be
reasonable to assume that a service provider would always use either a
reasonable rotation speed and/or use retroactive (as without the user
experience for a typical turn on/subscribe/view scenario is poor) thus
making this an unlikely issue?

It would be good to gather other peoples thoughts on device behaviour
and whether this should be put in to a specification or just issued as
advice for best practise?

Thanks,


Andy.

[Robin Cooksey]

Hi Andy,

Thank you raising this question, and describing the cases so clearly.

So, I think the possible option that you're suggesting is essentially that if service details change without user interaction (either because the broadcaster changed them, or the receiver performed some service following), then the last slide should not be cleared until it's replaced by a new slide received from RadioVIS for the new service details, or it's determined that RadioVIS is not available for the new service.

I guess the user experience that this will give is that if the user has not interacted with their radio, and the radio is simply trying to keep the same audio service available, then there will be no apparent interruption to RadioVIS - assuming that RadioVIS is available, and quickly shows a slide on the new service.

I wonder whether this behaviour should apply only when the receiver is service following to a service that it believes is identical to the original one, rather than one which might just be related? E.g. falling back from a secondary to primary service, or a soft link.

Also, to clarify, does "it is determined that RadioVIS is unavailable on the "new" service", include the case that RadioVIS support was signalled (via an SRV record), but the Stomp server (or HTTP server for the HTTP transport) does not support that topic?

For the situation where two different FM services on the same frequency, but with different PI codes are seen; I think it's an acceptable risk. As you say, the case where one has working RadioVIS, and the other has signalled RadioVIS, but never actually publishes a slide, is probably unlikely, and is most likely to be indicative of a problem with the RadioVIS service that needs to be fixed anyway.

Finally, I think that this kind of behaviour probably should be specified in a specification - unless anyone can think of a reason not to. It's behaviour that receiver implementers will have to think through, and it's relatively central to the user experience around RadioVIS.

Best regards,
Robin