FEC not working for Gates transmiter.

[salvaaod]

Tried to use FEC with Gates transmitter and it is self generating 10% of errors with direct EDI ethernet connection, disabling FEC all works ok. On certain mux configurations regarding services, FEC works, not sure what combination of services makes fec work with Gates.

The dataflow is DABMUX-----> EDI2EDI ------> Gates

Not sure where the issue is coming from but seems that Gates is working with many other multiplexers with no issues.

output in dabmux is simple tcp:
outputs {
throttle "simul://"
edi {
destinations {
tcp {
protocol tcp
listenport [port]
}
}
}
edi2edi is adding fec
odr-edi2edi -c [IP:PORT] -w -400 -x -d [IP] -p [PORT] -f 2

Any suggestion on further tests to understand where the issue is coming from ?

[mpbraendli]

packet spreading might help (this was called interleaving until some odr-dabmux version)

Search packet_spread in doc/advanced.mux

[salvaaod]

Yes I tried, actually the test I an doing is all in the same network so it is actually not a real udp loss but something weird with FEC, I tried several settings of spread from 0 to the default 95% and I get the same results, around 4% packet corrected. As mentioned, depending of the mux content with same output configuration.
I have an example in particular, a mux with 23 services with FEC enabled, it has 0 fec recovered packets,, same configuration with just removing one service I have 4% packets recovered, even changing the bitrate of one service it goes from 0 packets recovered to 4%, makes no sense whatsoever but I can reproduce it anytime..

Will it help if I copy the EDI output of both situations, FEC errors and no FEC erros ?

[salvaaod]

Following my previous comment, the following sample minimal configuration sends FEC frames with no error, at 16 or 224Kbps the number of corrected FEC packets is 0, any other bitrate will give 4% of recovered FEC packets.

general {
dabmode 1
nbframes 0
}
remotecontrol {
telnetport 0
}
ensemble {
id 0xFFFF
ecc 0xFF
local-time-offset auto
international-table 1
label "TEST"
shortlabel "TEST"
}
services {
srv-p1 {
label "TEST"
shortlabel "TEST"
id 0xFFFF
pty 0
pty-sd static
language 0x00
}
}
subchannels {
sub-p1 {
type dabplus
bitrate 224
id 1
protection 3
inputproto edi
inputuri "tcp://*:1234"
buffer-management prebuffering
buffer 40
prebuffering 20
}
}
components {
comp-p1 {
service srv-p1
subchannel sub-p1
}
}
outputs {
throttle "simul://"
edi {
destinations {
example_udp {
protocol udp
sourceport xxxxx
destination "x.x.x.x"
port xxxxx
}
}
enable_pft true
fec 2
}
}

[mpbraendli]

Can you try setting tagpacket alignment to 16?

If that still doesn't work, please ask Gatesair. We're using ODR-DabMux in production with GatesAir transmitters, but maybe it depends on the model and/or firmware version.

[salvaaod]

Thanks, from a situation where is no FEC recovered changing the tagpacket alignment to 16 from the default 8 will create the issue, so, this seems not to help. It is strange because Gates told me the same thing, they have their transmitters with many other multiplexers with no FEC issues, anyhow, I will come back to them.

Just in case I have added two eti files to check, one with OK fec and the other with 4% fec error, the only thing changed between those to files is the audio bitrate.

dab_fec.zip

[salvaaod]

I Just realized that the ETI (NI) files makes no much sense since they do not have the underline EDI FEC as defined in TS102821, will try to dump a EDI file.

[mpbraendli]

Try to dissect the EDI stream with wireshark too. Maybe it can show protocol errors too.

[mpbraendli]

Any progress on this topic, or shall I close it?

[salvaaod]

I tried with 4.5.0 and issue is still there, I have two different type of Gates devices, single carrier and multicarrier and both show the same issue, Gates told me that they are using their TX with different muxers with no issues and they blame on us .. any other suggestion to try ?

[mpbraendli]

You can try using odr-edi2edi of the https://github.com/digris/digris-edi-zmq-bridge instead of the EDI/UDP output of ODR-DabMux.