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