DabMod 30+ Channels

[William]

Hey everyone,

Forgive me as i'm fairly new to this haha. I am attempting to make a configuration file that has 30+ channels at 128 bits per sub channel. I know that will exceed the Capacity Units and I wont be able to do this under a single ensemble. I was wondering if anyone knows of a way to create multiple ensembles and send them to a single eti file. Or if there is a way to send multiple eti files at once, I am currently using a B200 USRP. 

[Frank Hennessy]

Hi 

the short answer is no you can't create more services than the carrier will handle I'm afraid 

Now let's think outside of the box for giggles and say you have a good understanding of the DAB transmission chain and a good RF background manipulating the MMb tools to do what you ask is possible if you write the multiplexer to accept more subcarriers that will widen the rf carrier from  1.536 MHz to possibly double that and let's say you overcame the previous challenges you would have to take up two or maybe more blocks and to add insult to injury you now would hit another big issue with the of side.  I may be wrong here but a carrier that wide would be tough to see an amplifier operated happily I would imagine 

the easiest solutions in my opinion  are as follows 

1. Put a mux side by side you can have  9 services at 128 per ensemble would require two B200 USRP or equivalent. (Two of everything really )

2. Broadcast DAB+ at 48-64k 32khz SR if properly fed would surprise you.

The MMB tools have come a long way since I began in 2019 with great individuals such as Matthias consistently gauging feedback and implementing changes.

the logical approach in my view from operating muxes (learning as I went) is if you intend to broadcast in DAB standard or DAB squishy became to call it requires 128 to get reasonable quality and eats CU capacity.

 DAB+ however  and the above bitrate  running services at that makes no sense to me because there is very little difference between let's say 64k and 128 provided your feeds are of good quality and the right codec and SR are used 

For example at 64k DAB+ with 32khz SR  using HE-AAC codec and feeding using a webstream with Gstremer using -G command at 320 AAC the quality is extremely good.

Below will also allow you to come close to your target without frying your brain by doing the following.

Maximum number of services in an ensemble using the following mode and minimum protection is recommended. 

 28 services with  protection rate EEP 3-A   @40kbs DAB+

 24 services with  protection rate EEP 3-A   @48kbs DAB+

 20 services with protection rate EEP 3-A  @56kbs DAB+

 18 services with  protection rate EEP 3-A   @64kbs DAB+

I hope this sheds some light on your query. 

Regards Frank.

[Peter Whisker]

Using EEP-B2 DAB+ saves some CUs (however you are limited to 32kbps encoder increments) but 64kbps at EEP-B2 is 42 CU which is the same as 56kbps at EEP-A3 (64k at A3 costs an extra 6 CU). 128kbps UEP-3 DAB eats more than twice as many CUs at 96.

I have tested EEP-B2 and subjectively find it no less resilient than EEP-A3.

I would certainly use HE-AACv1 SBR at 64k or even try HE-AACv2 SBR+PS. But it'll certainly sound better than 128k MP2.

Peter

--
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/5644b138-c073-4a99-9126-ce991b419c23n%40googlegroups.com.

[Matthias Brändli]

Hi William,

To complement the other answers, if you want to walk the "modulate
several ensembles with one B200" path: ODR-DabMod has a ZMQ output. You
can connect that to a ZMQ source in GNURadio.

So you could do a GNURadio flowgraph that takes two modulated ensembles
from two odr-dabmod instances, does interpolation, frequency
translation, addition, and transmits this with a single B200.

The sample rate required might be quite high, and you'll get into
difficulties once you want to amplify the resulting signal, but for
tinkering and learning, it's a fun exercise.

Cheers
mpb

> --
> 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

> <mailto:crc-mmbtools...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/crc-mmbtools/acad1dfe-202d-4ea4-8339-9f682ecd4c79n%40googlegroups.com <https://groups.google.com/d/msgid/crc-mmbtools/acad1dfe-202d-4ea4-8339-9f682ecd4c79n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[William]

This is perfect to go off of thank you both for the examples and information. I will attempt to give those ideas a go. I very much appreciate it! 

[pswiatki]

@Frank - you wrote:

Now let's think outside of the box for giggles and say you have a good understanding of the DAB transmission chain od a good RF background manipulating the MMb tools to do what you ask is possible if you write the multiplexer to accept more subcarriers that will widen the rf carrier from  1.536 MHz to possibly double that and let's say you overcame the previous challenges you would have to take up two or maybe more blocks and to add insult to injury you now would hit another big issue with the of side.  I may be wrong here but a carrier that wide would be tough to see an amplifier operated happily

Do I understand correctly you meant the DAB modulator rather than the DAB multiplexer? As far as I know the multiplexer has no knowledge of the RF part of the DAB specification, correct?

As far as the bandwidth is concerned - I do not see a problem for the [hypothetical] doppel width DAB ensemble occupying 3+ and more MHz. After all DVB-T channels are up to 8 MHz and the amplifier is very happy with those.

[pswiatki]

The ETI frames are produced by the DAB multiplexer. That means those are for a single ensemble only as this is the output of a DAB multiplexer (i.e. DAB MUX == DAB ensemble).

[Matthias Brändli]

Hi,

On 29/04/2024 00:28, pswiatki wrote:
> @Matthias: do I understand correctly, that trying to execute the
> necessary operations on samples produced by two separate ODR-DabMod
> instances (especially frequency shift) may prove overwhelming for a
> general purpose CPU (or use a substantial amount of its computational
> resources)?
Depends on the frequency difference of the two ensembles, because that
dictates the necessary sample rate.


> By the way: I see a parallel activity here in this group as well as at
> `groups.io/odr-mmbtools`

Oh, indeed, I hadn't noticed.

@William, please subscribe to groups.io/odr-mmbtools, that's where most
of the discussion happens now.

Cheers
mpb

[pswiatki]

It is so strange here... I'd suggest making this Google group read-only.

@Matthias:

you responded to the message I sent and it shows as "message has been deleted for me". When I try to contact the admins, I get circled back to the group and it seems any support is non-existent.

So, perhaps it would be better to move to groups.io for good. 

[Matthias Brändli]

Agree. But I'm not admin of this group.
mpb

On 02/05/2024 00:42, pswiatki wrote:
> It is so strange here... I'd suggest making this Google group read-only.
> @Matthias:
> you responded to the message I sent and it shows as "message has been
> deleted for me". When I try to contact the admins, I get circled back to
> the group and it seems any support is non-existent.
> So, perhaps it would be better to move to groups.io for good.
>
>
>
> On Wednesday 1 May 2024 at 13:30:32 UTC+2 Matthias Brändli wrote:
>
> Hi,
>
> On 29/04/2024 00:28, pswiatki wrote:
> > @Matthias: do I understand correctly, that trying to execute the
> > necessary operations on samples produced by two separate ODR-DabMod
> > instances (especially frequency shift) may prove overwhelming for a
> > general purpose CPU (or use a substantial amount of its
> computational
> > resources)?
> Depends on the frequency difference of the two ensembles, because that
> dictates the necessary sample rate.
>
>
> > By the way: I see a parallel activity here in this group as well
> as at

> > `groups.io/odr-mmbtools` <http://groups.io/odr-mmbtools>

>
> Oh, indeed, I hadn't noticed.
>
> @William, please subscribe to groups.io/odr-mmbtools

> <http://groups.io/odr-mmbtools>, that's where most

> of the discussion happens now.
>
> Cheers
> mpb
>

> --
> 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
> <mailto:crc-mmbtools...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/crc-mmbtools/750d8475-65ac-478b-9553-5e0b9ba96d04n%40googlegroups.com <https://groups.google.com/d/msgid/crc-mmbtools/750d8475-65ac-478b-9553-5e0b9ba96d04n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[pswiatki]

That is very unfortunate, Matthias. I hope the admin can be found and will react. There are evident technical issues with this group here. Also, if the discussion is to be happening @groups.io - the existence of this group creates an unnecessary confusion. I will keep my fingers crossed for a resolution of this issue.

Thank you much,

Peter

[pe...@whisker.org.uk]

The group owner is  François Lefebvre according to the group info.

Peter

[pe...@whisker.org.uk]

PS: The new group is https://groups.io/g/odr-mmbtools

On Saturday, May 4, 2024 at 2:25:17 PM UTC+1 pswiatki wrote: