search

AlbrechtL / welle.io

A DAB/DAB+ Software Defined Radio (SDR)
https://www.welle.io
Other
625 stars 117 forks source link

Add ETI bitstream input #199

Closed lars18th closed 6 years ago

lars18th commented 6 years ago

Hi,

Now some tools for extracting the ETI bitstream from the RF signal exists. For example, the tool “dab2eti” from the dabtools package: http://github.com/Opendigitalradio/dabtools

And some tools, like the “DABlin” player, has support for reading from the ETI bitstream: http://github.com/Opendigitalradio/dablin

So, as the Welle.io it’s one of the most user friendly and multiplatform DAB player, I suggest to add to it the option for use an ETI bitstream as input (from pipe, file and/or socket).

If you need it, you can see the code from the DABlin project for the ETI-NI input: http://github.com/Opendigitalradio/dablin/blob/master/src/eti_source.h http://github.com/Opendigitalradio/dablin/blob/master/src/eti_source.cpp

I hope you can consider this enhancement. Thank you!

andimik commented 6 years ago

Please use ODR-DABMod in such a situation. Since a few commits it also will generate u8 rawfile. You need not write a file, just use stdout

lars18th commented 6 years ago

Please use ODR-DABMod in such a situation

Great! Thank you for pointing it. :smile: It will be useful for teting.

However, why I need to modulate the IQ values of the RF signal with this tool, and demodulate them after with Welle.io?

My objective it's: get the ETI Stream from IP sources (SAT, dab2eti, etc.) and play all of them with Welle.io (I prefer it over other players).

I feel isn't complex to add this function, right?

andimik commented 6 years ago

I remember I had a discussion with Albrecht some months ago.

If you are using eti then you might be a broadcaster or at least an advanced user who really knows how to generate a modulated signal.

mpbraendli commented 6 years ago

Hi, if your ETI files are error-less, using ODR-DabMod will work fine. If your ETI is received in a way that can create errors, ODR-DabMod could crash. I don't guarantee it will handle faulty ETI.

I feel isn't complex to add this function, right?

Sure. But it's also not a simple trivial thing to do :-)

lars18th commented 6 years ago

If you are using eti then you might be a broadcaster or at least an advanced user who really knows how to generate a modulated signal.

No, no! I only like to push in the direction of "remote DAB tuner", that outputs ETI bitstream instead of IQ bitstream. See the issue #91.

If your ETI is received in a way that can create errors, ODR-DabMod could crash. I don't guarantee it will handle faulty ETI.

Thank you for pointing this, as my objective it's: Broadcasted RF signal (with errors) --> SDR tuner --> dab2eti --> Welle.io.

But it's also not a simple trivial thing to do.

I suspect. However, internally that it's doing Welle.io (and any other DAB player) it's reconstructing the ETI bitstream from the RF signal and "decode" this bitstream. So, if the demulation of the IQ it's done by another tool that generates the ETI bitstream, then you can use the ETI bitstream as a direct input. Right?

mpbraendli commented 6 years ago

it's reconstructing the ETI bitstream from the RF signal

Not exactly. ETI was intended and designed to be the protocol to carry a multiplex between a multiplexer and a modulator. On receive side, there was another protocol called RDI, which isn't used (to my knowledge) nowadays.

It's true that the RF signal gets decoded into bits, and into FIC and MSC streams, but there is no need to reassemble these into ETI. That's why your request is not trivial to implement.

andimik commented 6 years ago

Broadcasted RF signal (with errors) --> SDR tuner --> dab2eti --> Welle.io.

Are you sure?

lars18th commented 6 years ago

ETI was intended and designed to be the protocol to carry a multiplex between a multiplexer and a modulator. On receive side, there was another protocol called RDI.

Oh, yes! RDI it's the decoder bitstream of the DAB signal. I see that the XPADexpert tool can use it: https://www.basicmaster.de/xpadxpert/ Thank you for the info.

It's true that the RF signal gets decoded into bits...

And in fact decoded as RDI. So, my request should change to RDI input.

Broadcasted RF signal (with errors) --> SDR tuner --> dab2eti --> Welle.io.

Are you sure?

After read this, the objective will be: RF signal --> SDR tuner --> dab2rdi --> Welle.io

What I really like to do it's transport the bitstream demodulated over the network, instead of the IQ data, and decode it in a remote location. Any idea?

lars18th commented 6 years ago

Hi,

Regarding the RDI Protocol:

EN 62105 [i.5] describes an interface between the DAB receiver and data decoders. The maximum DAB data rate of 1,8432 Mbit/s as well as data for receiver control and information on the received transmitters of the SFN can be carried via the RDI. The source for the data to be carried on the Receiver Data Interface is the output bit stream of the channel decoder of a DAB receiver. Dedicated decoders for data applications, computers, etc., but also devices for audio post processing and recording can be connected to the DAB receiver through this interface.

The RDI specification is independent of any physical interfaces and interfaces commonly used in consumer electronics are supported. The use of RDI allows connection of several decoders to a single receiver and it is possible to implement a return channel for receiver control from an application terminal.

andimik commented 6 years ago

Broadcasted RF signal (with errors) --> Welle.io

Why not this?

lars18th commented 6 years ago

Broadcasted RF signal (with errors) --> Welle.io Why not this?

Well, I explain my personal opinion:

For DAB reception I use a RTL-SDR dongle. This dongle can't be connected at the same time to all of my devices (PC, smartphone, tablet, Pi, etc.). So I like to use a client-server model.

As you know the "rtl-tcp" protocol can target this model. However, it's focused on Software Defined Radio. And then it sends the data of the IQ samples. This it's a lot of data... and if you like to use a wireless device, then you will consume a lot of battery.

Then, my objective it's receive from a central location the DAB bitstream, that is the demodulated data previous to decode the DAB data. This has a bandwith of less than 2Mbps, and it's very reasonable. Futhermore, you can ask why not decode the DAB data in the central node, and receive the "audio" bitstream... because you then loss the DAB metadata, and you receive only a simple audio streaming.

So, the idea is replace the IQ data stream with a RDI bitstream. I know that this objective can be at time far for the Welle.io project. But I suggest to consider it. Or at minium encapsulate the data for the IQ demodulator to the DAB decoder. This will enable the option for record/play the bitstream (even if it ins't conformant to the RDI specification).

I hope this explains more clear my point of view. :smile:

andimik commented 6 years ago

Sure, but this is NOT an issue. Please program it and send @AlbrechtL a pull request

But why on earth you want to have it in parallel on all your devices? And why don't you invest 5-20 Euro and buy additional low cost 2nd hand sticks? They are so cheap that even writing your posts might cost more.

basicmaster commented 6 years ago

See my comment on RDI here: https://github.com/Opendigitalradio/dabtools/issues/16#issuecomment-365869733

mpbraendli commented 6 years ago

I should not have mentioned RDI, it just confuses the discussion. We have tools to work with ETI, even IQ-to-ETI tools, but we have nothing for RDI. Forget about it. Regardless of ETI or RDI, I understand the request, because it would enable welle.io to play ETI streams from different sources, for example those that are carried in DVB-S. Or maybe ETI generated by ODR-DabMux for monitoring purposes. If @AlbrechtL wants to support such use cases or not is his decision, but I suspect it would be quite low on his priority list.

lars18th commented 6 years ago

If @AlbrechtL wants to support such use cases or not is his decision

I agree! I'm only suggesting some alternative input as bitstream different than IQ samples. I hope @AlbrechtL will consider it when he likes it. :smile:

Thank you all for your comments.

lars18th commented 6 years ago

Hi @AlbrechtL ,

After found the project "eti-stuff" https://github.com/JvanKatwijk/eti-stuff . And see that the Dablin project is incorporating this tool (replace "dab2eti" [aka "iq2eti"] with "eti-cmdline", then I suggest you to add support for reading "*.eti" files (similar to raw-file you actually do) and enhance this with live ETI input (as now does Dablin with the command line, exemple dablin -d ~/bin/dab2eti -c 11D -s 0xd911).

What I hope to see? I like to run Welle.io in my Android device receiving the data over wifi from a Pi with a RTL-SDR connected. I know that I can do this with RTP_TCP, however 33Mbps are a lot of data. And 2Mbps of ETI-NI it's great. The drawback is that I lost the option of receive multiple frequencies (just only one, no change of frequency), but I have some ideas to resolve this.

You agree to incorporate this?

AlbrechtL commented 6 years ago

@lars18th I know that you opened a lot of issues and I appreciate your ideas. Please keep in mind that welle.io is developed by hobbyists just for fun. It is not our aim to fulfill all requirements that somebody is requesting. Especially features that only a few people would use are not really interesting. This feature is one of those. Your can use dablin for it. I also don't see which receiver (besides eti-stuff) creates an ETI stream.

If your are a developer and you are implementing and maintaining it then we can discuss this feature.