search

smallscaledab / small-scale-dab

Code and Issues for Small Scale DAB
1 stars 0 forks source link

mot-encoder should send DLS Clear Command when text updates #2

Closed nickpiggottwork closed 9 years ago

nickpiggottwork commented 9 years ago

Many DAB radios scroll DLS text slowly across the screen, and will not show a new message until the current message has finished scrolling. This can create quite a big delay (>20") between a new DLS being transmitted (e.g. at the beginning of a new song) and it being shown on the receiver.

Newer DAB radio support the DLS Clear Command (EN 300 401 s.7.4.5.2), which removes the message immediately and replaces it with the new message.

mot-encoder should compare the next-to-be-transmitted DLS string with the currently-transmitted DLS string, and if they differ, should insert the DLS Clear Command prior to transmitting the next-to-be-transmitted DLS string.

mpbraendli commented 9 years ago

@basicmaster can you please have a look at this, and align with @nickpiggottwork ? Maybe you can include this into the refactoring you're already working on.

basicmaster commented 9 years ago

ATM I am working on a new packetizer which allows better utilization of the available PAD size. As adding the DLS Clear command to the PAD generation will be much easier when the packetizer is finished, I therefore postpone the command's implementation (which then will be in form of a cmdline option).

nickpiggottwork commented 9 years ago

Agreed. There's an obvious place in the code to drop the Clear Command in (around line 1073), which could be enabled by a new command line parameter as you suggest.

basicmaster commented 9 years ago

Assuming that you refer to the "master" branch, I rather thought of inserting it between lines 1003f (nearby the DLS text comparison you mentioned, which is already present). This way DLS Clear is sent only once on every DLS text change. Otherwise it would be sent on every retransmission of a label, as thereby the whole PAD array prepared by create_dls_pads() is resent.

nickpiggottwork commented 9 years ago

Agreed, that was roughly where I was looking. Do you want me to move this to an issue in the ODR Github?

basicmaster commented 9 years ago

IMO it is enough to leave this ticket here open. In addition I added the request to our internal development Trello board.

basicmaster commented 9 years ago

Nick, I just added the mentioned option. Please try the next branch of my personal fdk-aac-dabplus fork.

I myself can confirm that it works with:

My Sangean DPR-17 in contrast (painly slow scrolling longer texts) ignores the cmd.

nickpiggottwork commented 9 years ago

That's excellent news. I think it makes a big difference to the value of DLS.

I suspect the Frontier Silicon modules support it, but other suppliers don't. The UK Minimum Specification for Domestic and Automotive receivers makes support mandatory.

Will give it a go with the latest branch.

Thank you very much.

mpbraendli commented 9 years ago

@basicmaster Stefan, do you want me to pull this into the ODR repository, or is it now yet complete ?

basicmaster commented 9 years ago

Matthias, the code itself is complete. I just wanted to first await Nick's confirmation, as he certainly has additional vendor's chipsets to test with. On the other hand, as the two mentioned devices (both indeed having Frontier Silicon chipsets; the DPR-17 has a GyroSignal BTW) work, this should be enough and I'll be glad if you'll pull the regarding commit.

nickpiggottwork commented 9 years ago

I'd go ahead with the pull. It may expose some strange behaviour in non-compliant chipsets, but I suspect they'll ignore it. Putting it out in the wild will get it tested on more receivers than I can pull together. So it seems fine on Frontier, but I suspect it'll be ignored on PURE devices. (I'll go check).

mpbraendli commented 9 years ago

Does it work ? Can we close this issue ?

nickpiggottwork commented 9 years ago

I think it's working fine, but I haven't got a modulator at home I can use to try it with PURE devices.

Let's close it, because it's such a relatively simple thing, it'll either work or not-work, and if it doesn't work, it's probably a bad implementation by PURE rather than an incorrect implementation on the mux.