Wish list: An example to convert MP4 to layer a / b / c for TX

[miaoski]

Hi.

Sorry to abuse the issue system. It's actually a wish. If I have an MP4, how to convert it to MPEG2-TS that ISDB-T uses, and how to decide the parameters to split the stream into layer a / b / c?

For example, Clayton has documented how to convert a webcam input to TS. By replacing /dev/video0 with a mp4, you get the MPEG2-TS to broadcast in DVB-T.

Thank you!

[git-artes]

Great question! We're working on it. Expect news on the next weeks. best

[miaoski]

I have tried to replay layer_a.ts / layer_b.ts and the recorded signal 569MHz_recording.tar.gz (I use a BladeRF x115 and used Osmocom Sink). However, the "ABS-CBN TV plus" did not decode it, and frequency scanning resulted in nothing.

I am flying over to the Philippines in the next week, and will record the signal. Is there anything I should pay special attention to? Otherwise, I guess a 10MHz b/w centered at 473.142875 MHz should be good (there is a DC spike in Osmocom, so expect the 1seg to be distorted.)

I will be there for 4 days and will share the capture.

[git-artes]

Hi, Are you using the latest version of tx_demo.grc? The "Skip Head" should be between the blocks "Pilot Signals" and "Frequency Interleaver" (and include a little comment justifying it).

Regarding hardware, we have used a B100 and a B200, and the difference is huge. Please see my post on the list: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-August/060447.html. I'm afraid we have no experience with the BladeRF. In any case, you may want to check the constellation you are getting by using an SDR as a receiver, to check if the TX hardware is correctly configured. Things to check are particularly gain (too high may generate distortions) and the TX antenna (although simple dipoles should be enough).

Regarding recording the signal, you should be fine with a 10MSps recording, but should again check the constellation you are getting just in case (again, gain is an important parameter).

best

[git-artes]

Hi, Regarding how to generate a transport stream that works with the transmitter, you may check the following message in the list: https://lists.gnu.org/archive/html/discuss-gnuradio/2019-10/msg00019.html. We'll post more detailed instructions on the repo soon. best

[miaoski]

Hi Federico, Yes, I'm using the latest version of tx_demo. The note reads "See sec. 3.9.2 of the standard." I'm checking the constellation with a HackRF as RX (USRP is too expensive for my hobby) and a BladeRF x115 as TX. Will keep you posted. Thanks!

[miaoski]

Hi. I managed to obtain some parameters in the Philippines, as well as recordings (recorded in BladeRF's sc16q11 format, converted into GNURadio complex format) for your reference. I need your kind help to fix some parameters, as the constellation looks chaotic (not only rotating) and I'm not sure where to tweak with.

The signal strength is fairly good.

• parameters.txt

The curve doesn't not look that in your 569MHz_recording.dat (two fixed peaks). The peaks were moving left. I guess that's caused by clock or phase shifting?

[miaoski]

BTW, the signal is strong, but I can only roughly see the 16QAM.

[git-artes]

Hi, Did you put "yes" in the print params of the TMCC decoder? It should print all the necessary parameters. However, with such a noisy constellation you won't decode much. Reasons for this behavior may lie in the bladeRF and how it's configured (as I mentioned before, we have no experience with that hardware) or in the acquired signal, which although strong, seem effectively very noisy. It should be roughly constant over the signal's bandwidth. Please, if the issue regards decoding a particular signal, open another issue. This one is related to generating a transport stream to be used in the transmitter. best