EDI to ETI conversion

383 views
Skip to first unread message

Gerard Lokhoff

unread,
Aug 2, 2020, 7:57:56 AM8/2/20
to mmbtools
Hi,

as you probably know since April local DAB transmissions have started in the Netherlands. Many of these use low cost transmitters based on the EasyDab board. Areas in which a single transmitter is sufficient to provide enough coverage can use recent versions of ODR-DabMux. However, areas in which SFN is required have to use version 2.3.1 or earlier, due to a change in TimeStamp information in the later versions.

I understand the wish to move to use an EDI output for DabMux, as this seems more future-proof. However, I would like to find a way to be able to use the EasyDab based transmitters with the more recent versions of ODR-DabMux. I wondered therefore, how hard it would be to create an EDI to ETI conversion program, which could act as a front-end to the transmitter ?

I'm still in an early phase, trying to understand what has actually changed, and trying to understand the EDI documentation. Perhaps we can start a little ODR project for this ?

Gerard

Rashid Mustapha

unread,
Aug 2, 2020, 9:00:32 AM8/2/20
to crc-mm...@googlegroups.com
Hi Gerard,

I think we met ages ago in London? You were with Klaas?

I'm a little bit interested in this, but I'm very 'time poor' of late. I've been partially through building up a couple of easydab 2-6 boards for some time...at least I now have a stencil and reflow the IC side!

The plan I have/had was to use openwrt on the CPE/firewall and run a tool on that which receives the EDI and provides a ETIoTCP socket for the easydab to connect on the LAN side. It's also a potentially good place to do a bit of extra buffering as easydab2 only has around a seconds worth of SRAM with 864CU filled.

I think I have identified a usefully plentiful target CPE which has dsl, ethernet and usb ports for failover to an LTE network...I will order a couple and add them to the pile of things to do. ;-)

Best regards,

Rash.

--
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/3f26a9ee-9513-456b-93f8-641c904f28c3o%40googlegroups.com.

Gerard Lokhoff

unread,
Aug 4, 2020, 3:06:20 AM8/4/20
to mmbtools
Hi Rash,

I have been to London many times. Unfortunately I don't remember whether or not we met. And who is 'Klaas' you are referring to ? Klaas Robers perhaps ? Please help me on this...

I discussed this issue also with Jan de Vries, as he is facing the same problem, and after an extended search he came up with the suggestion to look at eti-tools. I googled and found this interesting possibility:


The description even references EasyDab ;o)

I now plan to investigate whether or not this could do the trick, and will post results here.

Best regards,

Gerard

Op zondag 2 augustus 2020 15:00:32 UTC+2 schreef Rash:
Hi Gerard,

I think we met ages ago in London? You were with Klaas?

I'm a little bit interested in this, but I'm very 'time poor' of late. I've been partially through building up a couple of easydab 2-6 boards for some time...at least I now have a stencil and reflow the IC side!

The plan I have/had was to use openwrt on the CPE/firewall and run a tool on that which receives the EDI and provides a ETIoTCP socket for the easydab to connect on the LAN side. It's also a potentially good place to do a bit of extra buffering as easydab2 only has around a seconds worth of SRAM with 864CU filled.

I think I have identified a usefully plentiful target CPE which has dsl, ethernet and usb ports for failover to an LTE network...I will order a couple and add them to the pile of things to do. ;-)

Best regards,

Rash.

On Sun, 2 Aug 2020, 12:57 Gerard Lokhoff, <gerard...@gmail.com> wrote:
Hi,

as you probably know since April local DAB transmissions have started in the Netherlands. Many of these use low cost transmitters based on the EasyDab board. Areas in which a single transmitter is sufficient to provide enough coverage can use recent versions of ODR-DabMux. However, areas in which SFN is required have to use version 2.3.1 or earlier, due to a change in TimeStamp information in the later versions.

I understand the wish to move to use an EDI output for DabMux, as this seems more future-proof. However, I would like to find a way to be able to use the EasyDab based transmitters with the more recent versions of ODR-DabMux. I wondered therefore, how hard it would be to create an EDI to ETI conversion program, which could act as a front-end to the transmitter ?

I'm still in an early phase, trying to understand what has actually changed, and trying to understand the EDI documentation. Perhaps we can start a little ODR project for this ?

Gerard

--
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-mm...@googlegroups.com.

Gerard Lokhoff

unread,
Aug 4, 2020, 8:03:52 AM8/4/20
to mmbtools
A first update ;o)

This is what I have done:

1) added an EDI output to the .mux file. It now reads like (removed items that I don't think of importance for the remainder of this post):

general {
    dabmode 1
    nbframes 0
    tist true
}
ensemble {
    local-time-offset auto  ; automatically calculate from system local time
}
services {
}
subchannels {
}
components {
}
outputs {
    zmq  "zmq+tcp://*:59000"
    throttle "simul://"
    ;ADDED 2020-08-04 EDI OUTPUT FOR TEST
    edi {
        destinations {
            example_unicast {
                protocol udp
                destination "192.168.178.37"
                sourceport  13000
            }
        }
        port        12000
        enable_pft  true
        fec         0
        interleave 0
        dump        false
        verbose     false
    }
}


2) next I installed the eti-tools from https://github.com/piratfm/eti-tools . I enabled the ZMQ library as it is needed to connect to the EasyDab board. When compiling I did get a lot of warnings and even 2 Error messages. I did however - out of curiosity - install the software on the Raspberry Pi that I'm using to run ODR-DabMux on.

3) in a terminal window I ran edi2eti with the command

edi2eti -o "zmq+tcp://*:59001" 192.168.178.37:12000 -a

Creating a zmq eti output at port 59001

4) I then made the EasyDab board connect to the Raspberry Pi at 192.168.178.37:59001 in SFN mode. Contrary to earlier attempt, in which the EasyDab connected to a zmq output generated directly by the ODR-DabMux software, the EasyDab does not show the short 'off air' bursts anymore. However, the ETItoGPS buffer setting doesn't seem to make any difference anymore. It seems the ETI stream is broadcast directly, as the buffer filling stays at 2 - 7% regardless of the time delay setting, and on a receiver the audio is ahead in time compared to a transmitter using the zmq output of ODR-DabMux.

I assume the timestamp information is not included in the output of edi2eti... So there is no time information for the buffer delay setting on the EasyDab to refer to. But the EasyDab has been running now very stable for almost an hour, so this route seems to be a promising first step. Any suggestions how to get the timestamp information in the ETI stream is welcome (I'm not very familiar with C, but will attempt a review of the edi2eti code). It might well be that if we add the timestamp information we get the 'off-air' bursts again, but perhaps we could convert it to information that might be OK for the EasyDab to swallow.

Best regards,

Gerard


Op dinsdag 4 augustus 2020 09:06:20 UTC+2 schreef Gerard Lokhoff:

Gerard Lokhoff

unread,
Aug 4, 2020, 9:04:27 AM8/4/20
to mmbtools
Second update:

I now notice this may require some bug fixing as well. I'm noticing what seems like anoverflow of some sort:

 edi2eti -o "zmq+tcp://*:59001" 192.168.178.37:12000 -a
ZeroMQ:enabled, FEC:disabled
[08/04/20 12:42:55] receiving from: 192.168.178.37:12000...
[08/04/20 12:42:55] Initialise next pseq to 45941
[08/04/20 12:42:55] EDI-AF: Packet sequence error
[08/04/20 12:42:55] ZMQ: skip non-aligned frames: 00 != 01
[08/04/20 12:42:55] ZMQ: skip non-aligned frames: 00 != 02
[08/04/20 12:42:55] ZMQ: skip non-aligned frames: 00 != 03
[08/04/20 12:50:46] EDI-AF: Packet sequence error
[08/04/20 13:16:58] EDI-AF: Packet sequence error
[08/04/20 13:43:11] EDI-AF: Packet sequence error
\[08/04/20 14:09:24] EDI-AF: Packet sequence error
[08/04/20 14:35:37] EDI-AF: Packet sequence error

The EDI-AF; Packet sequence error occurs at regular intervals of 26 minutes 13 seconds, which corresponds with 65536 periods of 24 msec...
Not sure whether or this is an error in edi2eti or in ODR-DabMux itself (cannot imagine it is in the mux software, should have been discovered earlier, not ?)


Rashid Mustapha

unread,
Aug 4, 2020, 5:23:23 PM8/4/20
to crc-mm...@googlegroups.com
Hi Gerard,

I thought maybe you visited with a delegation from Agentschap Telecom...but perhaps not and no matter!

I totally forgot about Sergiy's ETI tools, which is incredible considering we tested them out at a RadioHack! I think the EDI bit was added later when newer satellite distribution feeds appeared (as being able to dump ETI feeds from satellites was the original idea) but I see no reason why that wouldn't work for the required purpose. I'll try this on a router (flashed with OpenWRT) and pipe the ETI to a netcat TCP listener for the board.

R.



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/90604d7c-1653-4b77-bc5e-5969957f0df6o%40googlegroups.com.

Gerard Lokhoff

unread,
Aug 5, 2020, 11:06:22 AM8/5/20
to mmbtools
Hi Rash,

no, I never worked for the Agentschap Telecom ;O) Just Philips...

The edi3eit tool seems to work, just doesn't include the time stamp information I think... Perhaps I can see with etisnoop whether or not I'm correct.

Gerard

Op dinsdag 4 augustus 2020 23:23:23 UTC+2 schreef Rash:
Hi Gerard,

Gerard Lokhoff

unread,
Aug 6, 2020, 9:54:12 AM8/6/20
to mmbtools
I don't seem to be able to get etisnoop to work. It fails when I want to 'make' it, indicating it cannot find libfaad, although the latest version is installed.
I also don't understand Mathias comment in the etisnoop readme about downloading faad2.-27 and put it in a folder, but where should this folder reside ? Inside the folder in which etisnoop is cloned ? For someone not familiar with C compilation it is a bit confusing... sorry about that.

Op woensdag 5 augustus 2020 17:06:22 UTC+2 schreef Gerard Lokhoff:

Gerard Lokhoff

unread,
Aug 11, 2020, 5:56:45 AM8/11/20
to mmbtools
I'm still trying to understand what is happening such that edi2eti doesn't generate a timestamp information that an EasyDab board an recognize... So I have taken a look at the specification of the EDI format, and found the following in Annex A.2:

"The TIST field of the ETI(LI) Frame may be recovered from the TSTA field of the ATST, and the RFUD field. The
least significant 24 bits of the TIST shall be the 24bits of the TSTA field. If the TSTA field is not present then these bits
shall take the NULL Timestamp value FFFFFF16. The most significant 8 bits of the TIST field shall be recovered from
the RFUD field. If the RFUD if not present then these bits shall have the value FF16."

Perhaps this is not happening correctly ?
I will try to install etisnoop on a new linux machine later today or tomorrow, to investigate the output of edi2eti...

Gerard


Matthias Brändli

unread,
Aug 11, 2020, 6:03:10 AM8/11/20
to crc-mm...@googlegroups.com
Hello Gerard,

FYI, EDI contains the ETI TIST you mention, and also the EDI timestamp
at second-level that is not included in ETI.

I have no idea how edi2eti handles that, nor do I know what the EasyDAB
really expects. But if you ignore that you can accidentally transmit in
the wrong second.

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/eb1655a2-6ed5-4b26-a603-c9b911a094b9o%40googlegroups.com
> <https://groups.google.com/d/msgid/crc-mmbtools/eb1655a2-6ed5-4b26-a603-c9b911a094b9o%40googlegroups.com?utm_medium=email&utm_source=footer>.

Matthias Brändli

unread,
Aug 11, 2020, 6:05:14 AM8/11/20
to crc-mm...@googlegroups.com
On 06/08/2020 15:54, Gerard Lokhoff wrote:
> I also don't understand Mathias comment in the etisnoop readme about
> downloading faad2.-27 and put it in a folder, but where should this
> folder reside ?

Don't do that unless you actually want to use a custom faad library to
do some debugging.

For the etisnoop compilation you're probably just missing the
libfaad-dev package.

mpb

Gerard Lokhoff

unread,
Aug 11, 2020, 12:13:44 PM8/11/20
to mmbtools
Hi Mathias !

Thanks for these confirmations. Hope to get etisnoop to work on a fresh linux debian installation.

As to what EasyDab expects: the problem started with the change in timestamps from DabMux 2.3.1 to 2.4.0 . I did have a look at https://github.com/Opendigitalradio/ODR-DabMux/blob/master/doc/TIMESTAMPS.rst and see you introduced the offset. But this shouldn't make a difference in Tframe when the offset is set to 0. Unfortunately I don't understand enough C to have a look at the source code so I would understand the difference between 2.3.1. and 2.4.0. Perhaps you can give a short explanation ? If I get this to work correctly I plan to write an explanation for the wiki so others here in the Netherlands and elsewhere can use it as well with the EasyDab transmitters.

Gerard

Op dinsdag 11 augustus 2020 12:03:10 UTC+2 schreef Matthias Brändli:

Matthias Brändli

unread,
Aug 12, 2020, 2:18:50 AM8/12/20
to crc-mm...@googlegroups.com
Hello Gerard,

it's been a while already, I don't remember the details about the
change. Introducing the offset wasn't the only modification, I also
changed the way the timestamp is initialised.

But all this brings us back to the question "what does the easydab
expect?" and without looking into its timestamp decoder it will be
difficult to find out.

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/a276fe6e-54d0-41d5-bc4e-63022adce0a2o%40googlegroups.com
> <https://groups.google.com/d/msgid/crc-mmbtools/a276fe6e-54d0-41d5-bc4e-63022adce0a2o%40googlegroups.com?utm_medium=email&utm_source=footer>.

Gerard Lokhoff

unread,
Aug 12, 2020, 4:38:06 AM8/12/20
to mmbtools
Hi Matthias,

yes, you're right, and that's why I intend to check the difference between the ETI output of version 2.3.1 and the later ones.with etisnoop.

Will post my findings.

Gerard

Op woensdag 12 augustus 2020 08:18:50 UTC+2 schreef Matthias Brändli:
Reply all
Reply to author
Forward
0 new messages