New utility ETI ZMQ -> FarSync card

[Matthias Brändli]

Hi all,

The ODR-DabMux repository includes a new utility called odr-zmq2farsync
which can read a ZMQ ETI stream from ODR-DabMux and play it to a FarSync
card. I wasn't able to test with a modulator attached, but the Farsync
card seems to accept the data :-)

Cheers
mpb

[Francesco Antoniella]

I've got a Farsync card and a modulator so I will be glad to make the test for you.
I tryed to use it with odr-datbmux I have the card recognised, the modulator reads the input as in progess but not lock
into the E1 stream
Maybe I wrong in some aspect but I cannot find in which,
I need a special otput config into mux file other than set raw://sync0 as output?
Thanks.

[Matthias Brändli]

Stan, would you have some advice for Francesco ? You're the last person
I know to have tested the Farsync.

Otherwise we could also get in touch with FarSite.

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>.
> For more options, visit https://groups.google.com/d/optout.

[Francesco Antoniella]

Solved, only a misunderstanding with 1pps enable/disable and quite criptic interface.

I'm about to start trials on sfn.

Cheers, Francesco

You received this message because you are subscribed to a topic in the Google Groups "mmbtools" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/crc-mmbtools/me8pNB68s6I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to crc-mmbtools...@googlegroups.com.

[Federico Allegretti]

sorry for resuming this old thread, but there are any news about ETI ZMQ?

Thanks :D

Il giorno martedì 4 agosto 2015 20:45:56 UTC+2, Matthias Brändli ha scritto:

[Matthias Brändli]

Hi Frederico,

no problem about resumung this thread, but what is the question?

:-)

Are you using the new utility?

mpb

[Federico Allegretti]

not a real question.
Just wish to know if Farsite cards are now, known to work well with ODR tools.

We are going to acquire a card to begin tests, also trusting that Francesco (in his last post) said to have solved the unlock of the modulator with that type of card :D

But the card is quite expensive and wanna minimize risks of having an unworking board on the desk ;-)

Thanks.

Il giorno martedì 4 agosto 2015 20:45:56 UTC+2, Matthias Brändli ha scritto:

[Matthias Brändli]

We have been using these cards in production setups in a few projects,
and did not have trouble in operation. Setup is maybe a bit of work, but
it is very stable in operation.

I hope this reassures you a bit :-)

mpb

[Federico Allegretti]

exactly what i need, thanks.

I'll make a tread with progresses of this project.

Cheers

Il giorno martedì 4 agosto 2015 20:45:56 UTC+2, Matthias Brändli ha scritto:

[Yoann QUERET]

To reassure you, i use FarSite card in paris (9A) on two server without
any issue from more than 1 years.

Yoann

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

> For more options, visit https://groups.google.com/d/optout.

--
Yoann QUERET
yo...@queret.net - 06.62.61.99.40

[cl...@radioalfa.dk]

Would it be possible to include EDI as an output option as well? - to have a sort of ZMQ -> EDI converter to be placed at the transmitter site.
It may seem odd not to use EDI the whole way - but EDI is actually not working very well on the internet and does not handle packet loss very well. Therefore dedicated IP networks is needed.

There are several products available that can be used for handling EDI over the internet, for instance the APT Surestreamer from Worldcast Systems. I know of other multiplex providers who convert the EDI to rtp for
internet transportation and then back to EDI at the transmitters.

--
Claus Juul Nielsen
Denmark

[Federico Allegretti]

Claus post was real interesting.

Packet loss is very common on public networks (internet), and if ETI do not handle that we can have problems in a "out of the lab" enviroment.

In our mind the idea was to have one radio of the mux to act like HUB of the multiple incoming radio streams (from their own studios).
In DAB+ format using a ZMQ stream or getting the "normal" stream and recoding it .....

Here the streams had to be muxed and the ETI out sent to the montains (icecast2 ?) using hyperlan or fiber (fiber internet access on the montain).

On the TX site we plan to get the EDI stream and inject it (trough G703 connector) to the rest of the tx chain.

Is that setup relyable or not? Solution?

[Rashid Mustapha]

Hello,

On 27 May 2016 at 12:14, Federico Allegretti <alle...@gmail.com> wrote:

Claus post was real interesting.

Packet loss is very common on public networks (internet), and if ETI do not handle that we can have problems in a "out of the lab" enviroment.

ETI encapsulated in ZMQ seems to work well over the public Internet providing you choose the connectivity carefully. It works perfectly for the studio to multiplexer contribution links too.

 

In our mind the idea was to have one radio of the mux to act like HUB of the multiple incoming radio streams (from their own studios).
In DAB+ format using a ZMQ stream or getting the "normal" stream and recoding it .....

Direct ZMQ streams are preferable as transcoding or concatenation of coders will result in sub-optimal sound quality. Sound is the 'product', so that is an important consideration. 

  

Here the streams had to be muxed and the ETI out sent to the montains (icecast2 ?) using hyperlan or fiber (fiber internet access on the montain).

I do not understand how Icecast2 fits in here. The zmq output of odr-dabmux can support multiple clients.

 

On the TX site we plan to get the EDI stream and inject it (trough G703 connector) to the rest of the tx chain.

I presume you mean ETI? EDI is (as far as I know) not available via G.703/4. I would avoid using SDH these days, but if your modulators only have ETI on G.703 inputs then you will need to buy some (very expensive!) converters, or make some with the odr-zmq2farsync tool.

 

Is that setup relyable or not? Solution?

On Tuesday, 4 August 2015 20:45:56 UTC+2, Matthias Brändli wrote:

Hi all,

The ODR-DabMux repository includes a new utility called odr-zmq2farsync
which can read a ZMQ ETI stream from ODR-DabMux and play it to a FarSync
card. I wasn't able to test with a modulator attached, but the Farsync
card seems to accept the data :-)

Cheers
mpb

--

[Federico Allegretti]

yes ETI not EDI ...

I suppose dab-enc would do the encode and pass the "mount" to some kind of media-server .... like darkice.

I recently discovered that the dabplus-enc will "send" the encoded packets to the odr-mux listening socket using a simple switch in the bash command.

But if i have this situation:

Radio Source1 -> dabplus-enc -j dab -l -b 64 --sbr --ps -f raw -o tcp://odr-mux_public_address:port1
...
Radio SourceN -> dabplus-enc -j dab -l -b 64 --sbr --ps -f raw -o tcp://odr-mux_public_address:portN

where i have a single ODR_mux machine, How i can feed a SFN network?

At page 20 of odr software (http://www.opendigitalradio.org/releases/mmbtools.pdf) seems ODR-DabMux will dialog with ODR-DabMod.
But i will use a Farsync T1 card to feed a third party modulator ....

Shall i do some kind of multicast?

On Tuesday, 4 August 2015 20:45:56 UTC+2, Matthias Brändli wrote:

[Federico Allegretti]

yes i found that in odr-mux there is a odr-zmq2farsync folder .... but after compiling the FULL package (debian script) no odr-zmq2farsync nor zmq* command was installed.

Shall i pass some kind to option to the building script?

Thanks for the kind answers :D

On Tuesday, 4 August 2015 20:45:56 UTC+2, Matthias Brändli wrote:

[Matthias Brändli]

Hi Federico

On 01/06/16 19:54, Federico Allegretti wrote:
> yes i found that in odr-mux there is a odr-zmq2farsync folder .... but
> after compiling the FULL package (debian script) no odr-zmq2farsync nor
> zmq* command was installed.
>
> Shall i pass some kind to option to the building script?

The debian install script does not enable output-raw which is needed for
the farsync card. You need to compile it yourself and add the
--enable-output-raw option.

You also need to install the farsync driver!

Cheers
mpb

[Federico Allegretti]

OK, successfully build farsite oem drivers

succesfully enabled raw output on odr-dabmux with:
./bootstrap.sh
./configure --enable-input-zeromq --enable-output-zeromq --enable-output-raw
make
sudo make install

***********************************************

Inputs:
  Enabled:  fifo file zeromq
  Disabled:  prbs test slip udp

Formats:
  Enabled:  raw mpeg packet dabplus dmb epm
  Disabled:  bridge

Outputs:
  Enabled:  file fifo udp tcp raw simul zeromq edi
  Disabled:

***********************************************

On Tuesday, 4 August 2015 20:45:56 UTC+2, Matthias Brändli wrote:

[Matthias Brändli]

Excellent! glad you were able to sort it 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>.

[Christian Milling]

I also just installed the zmq2farsync. My multiplexer is on a virtual server in a datacenter, and zmq2farsync runs on a local pc, connected over the internet. I experience that after a time no ETI frames are transmitter anymore, but netstat -t shows that the TCP connection is still established. Do you have any idea why this happens?

Best regards,

Christian

[Federico Allegretti]

try to get some farsinch tools to check if data get OUT from the board.
maybe you receive them but there is a bug on send ....

ideally a second eti card to GET packets from first farsite card could help the debug

[Matthias Brändli]

We sometimes observed something similar between ODR-DabMux and
ODR-DabMod, but only when there was a problem with the network
connectivity. For some reason zeromq seems to forget to setup the
connection again.

I don't know more in detail. Please share your observations if you find
out more.

Maybe we need to add write a new tool called tcp2farsync that connects
to the TCP output.

mpb