Feature Request: Enable multiple MOT Applications in X-PAD

[nickpiggott]

In order to allow transmission of both Slideshow and SPI information in the X-PAD of an audio service, odr-dabmux needs to be able to send two User Application definitions in FIG0/13 for that audio service.

My suggestion is:

• Enable multiple instances of figtype to be specified in a component configuration
• figtype = 0x02 (Slideshow) is statically configured to use X-PAD AppTy = 12 (MOT)
• figtype = 0x07 (EPG) is statically configured to use X-PAD AppTy = 16 (User Defined Application)

This should be compiled into the FIG0/13 for the relevant service, plus the relevant Profile information as extension bytes (hard coded to 0x0100 - Basic) probably around lines 126-128 of FIG0_13.cpp (the Basic profile is already inserted into a packet mode service definition by line 179).

Fixing the X-PAD AppTy for SPI to 16 means it can also be set in odr-padenc to the same value.

Outstanding Issue Currently, all FIG0/13 entries are hard coded to AppTy = 12

What value should be used for figtype values not Slideshow or SPI? AppTy = 18? Maintain an incrementing count?

[mpbraendli]

Have a look at latest "next". The advanced.mux explains the new configuration entries. I didn't test this yet except looking at the ETI with etisnoop. Looking forward to reading your feedback!

Also, please test SPI inside a packet data service too, I didn't test that at all since these changes!

[nickpiggott]

That looks great. I'll grab and test it over the next day or so.

Nick

On Mon, 13 Jul 2020 at 13:06, Matthias P. Braendli notifications@github.com wrote:

Have a look at latest "next". The advanced.mux explains the new configuration entries. I didn't test this yet except looking at the ETI with etisnoop. Looking forward to reading your feedback!

Also, please test SPI inside a packet data service too, I didn't test that at all since these changes!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Opendigitalradio/ODR-DabMux/issues/47#issuecomment-657521498, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYF3WWLPIIDL2KDLNM2OZDR3L2FHANCNFSM4OXO34CQ .

-- Nick

[nickpiggott]

The good news is that the FIG0/13 signalling for X-PAD looks correct.

The bad news is that signalling for a MSC Packet Data channel is broken. You can see it doesn't appear in the FIG0/13 list at all.

I have the SPI service configured as:

spi{
label"EPGLogos"
shortlabel"EPG and Logos"
id0xe1c000d4
}

and component

spi {
type 60
service spi
subchannel spi
user-applications {
userapp "spi"
}
address 0x1
datagroup true ; true means using MSC Datagroups 
} 

If I revert to using figtype 0x07 in the configuration (rather than the user-applications / userapp), then it does generate a FIG0/13, but doesn't contain the User Application type information (07 for EPG).

[mpbraendli]

Things you don't test are never correct. Should be fixed in "next".

[nickpiggott]

Looks like the problem still remains. It's spotting that the "epg" channel is configured for SPI/EPG:

Component epg
 service id: 0xe1c000d4 (3787456724) 
 subchannel id: 0xe (14) 
 label:
 short label:
 (0xff00) 
 FIG2 label: 
 service component type: 0x3c (60)
 (packet) id:0x0 (0)  
 (packet) address: 1  
 (packet) datagroup:  1  
 (packet) app type:SPI/EPG

but the output of the analyser doesn't show a FIG0/13 for that service (the last one) being generated. It is showing for the services where SPI/EPG is defined in X-PAD

(the version reported by odr-dabmux is v3.1.1-6-g40883fa-dirty)

[mpbraendli]

Hi, latest next contains a fix for this. Let me know!