Signalling Multiple MOT Applications (Slideshow, SPI/EPG) in X-PAD

[Nick Piggott]

We're discussing adding to odr-padenc the capability to encode and transmit both MOT Slideshow and MOT DAB SPI (EPG) on X-PAD. There are some stations where the regulatory environment does not allow them to transmit their SPI in a shared packet-data channel.

odr-dabmux allows specification of a figtype in the component definition, so logically you would do this:

figtype 0x07 : MOT DAB SPI (EPG)

figtype 0x02 ; MOT Slideshow

However looking at ConfigParser line 830:

component->audio.uaType = figType;

suggests that an audio component can currently only have one figType value attached to it, and therefore it can only signal EITHER MOT Slideshow OR MOT DAB SPI.

If I try this configuration, I find that whichever figType value is specified first is applied to the audio component.

--- Components list --- 

Componentcomp-fu

 service id: 0x4daa (19882) 

 subchannel id:0xa (10) 

 label: 

 short label: 

 (0xff00) 

 FIG2 label:

 service component type: 0x0 (0)

 (audio) app type: EPG

How hard is going to be to change that audio.uaType attribute to hold multiple values of figType and get it to generate multiple instances of FIG0/13?

[Matthias Brändli]

Hi Nick

On 08/06/2020 12:49, Nick Piggott wrote:
> How hard is going to be to change that audio.uaType attribute to hold
> multiple values of figType and get it to generate multiple instances of
> FIG0/13?

I had a quick glance at the spec, and I think it's not multiple
instances of FIG0/13. But it's not clear to me yet how to encode it,
because FI0/13 contains a list of user application types *and* a
separate X-PAD field.

To answer your question: not too hard.

- Understand and describe how we're supposed to signal this in FIG0/13
- Understand what we want to make configurable, and how to represent it
in the configuration file
- Propose a backward-compatible configuration entry
- Adapt configuration parsing, structures and FIG generation
- Update example configs and guide to reflect new configuration

I'd be happy to review proposals and help with implementing the code
changes.

mpb

[Lindsay Cornell]

For this example there are two user applications in the same PAD, so the FIG 0/13 references the audio service component, has No. User Applications = 2 and then has two user Application fields, one for each application.  Each has the UATy and and X-PAD field because the X-PAD AppTy value connects the right data to the right application.

Lindsay

--
You received this message because you are subscribed to the Google Groups "mmbtools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/crc-mmbtools/e00202ab-16f2-3761-eb0f-33eb0b8967fd%40mpb.li.

[Nick Piggott]

I was being inaccurate when I said "two FIG0/13". Lindsay's explanation is far more precise!

In the code, I think that would mean:

• Adapting the parser to find multiple instances of figType in a component definition. (Can the parser do that, or do we need to consider unique parameter names?)
  
• Storing an array of 0-n values in the audio.uaType
• Iterating through those in values in FIG0_13.cpp (loop around lines 96 - 141?)

The X-PAD encoder then has to put signalling bytes in the X-PAD to differentiate between MOT Slideshow and MOT DAB SPI.

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

[Nick Piggott]

Following up on this, I did a more comprehensive write up of what's needed to encode both Slideshow and EPG (or any other multiple of MOT Applications) in X-PAD.

X-PAD uses a concept of Data Group Start and Data Group Continuation indicators as it segments Data Groups across consecutive X-PAD frames.

The "default" is to use values of X-PAD AppTy 12 and 13 to indicate the Start and Continuation of Data Groups carrying MOT. These were "hard-coded" to Slideshow for first generation receivers (and probably, frankly, a whole bunch of lazy receivers since then).

When you want to transport more than one MOT application, you have to explicitly define which App Ty values you're using for each MOT Application. So in FIG 0/13 you need

- Number of User Applications : 2

- User Application 1: User App Type = 0x02 (Slideshow), X-PAD AppTy = X* (MOT), DSCTy = 60 (MOT)

- User Application 2: User App Type = 0x07 (EPG), X-PAD AppTy = Y* (MOT), DSCTy = 60 (MOT)

X would normally default to 12, and Y needs to be some other even number between 16 and 30.

Similarly, the X-PAD encoder has to use those values of X and Y in the Contents Indicator at the start of each X-PAD Frame, so that you can differentiate between Slideshow Data Groups and SPI Data Groups.

So my suggestion is (and I'll put this on an issue at the Github)

* Allow multiple instances of figtype in the component configuration section

* Define fixed User App Type numbers - Slideshow (0x02) -> 12, SPI (0x07) -> 16

* Compile FIG0/13 accordingly.

And then to set the same details in odr-padenc so it matches up.

Nick