These are chat archives for Opendigitalradio/mmbTools

23rd
Mar 2016
Gabriel
@vvombat
Mar 23 2016 09:00

A few updates regarding my request: Seems like ODR-DabMux misses a few FIG types / FIG extensions:

  • FIGtype0_21 & FIGtype0_22 [ETSI EN 300 401 - 8.1.8 and following]
  • FIGtype0_24 - FIGtype0_28
  • FIGtype0_31
  • FIGtype5_0 [ETSI EN 300 401 - 8.2 FIDC]

@mpbraendli I didn't know if I missed them (with github search) or if these really don't exist in ODR-DabMux. Thought it was worth mentioning because my initial question was linked to the FIDC / FIG type 5.

Matthias P. Braendli
@mpbraendli
Mar 23 2016 09:20
@vvombat indeed, there is no support yet for these FIGs.
Gabriel
@vvombat
Mar 23 2016 09:52

@mpbraendli Thanks for the answer! Looks like the answer to my question than. One (smaller) part of my Bachelor thesis deals with the question how easy it is to replace an existing ensemble with your own. E.g. rebuild an ensemble and overlaying the signal in your area.

Have nice easter holidays everybody!

Matthias P. Braendli
@mpbraendli
Mar 23 2016 09:57
Interesting challenge!
Matthias P. Braendli
@mpbraendli
Mar 23 2016 20:47
I don't understand how the command line allowed to define more than one service per component. The dabComponent struct never supported pointing to more than one service ID... @nickpiggott you say that it was possible to specify this before, but the command line parser allowed you to declare a service followed by several components. i.e. several components per service, not several services per component. This is reflected in FIG0/2 too.
And I absolutely don't get FIG0/8
According to TR 101 496-2 it has something to do with following, but I still don't see the reason why it's needed.
Ok, TR 101 496-2 Clause 3.3.3.4.2 explains it a bit.
Still, back to the original question: I don't see how to represent several services per component, regardless of the ODR-DabMux implementation, only according to the spec.