HackRF is able to produce stable picture / color / sound only at 9.7-9.8Msps and fails at 10Msps or greater for 2 digital LG TV sets from Windows

[gavenkoa]

Official recommendation is to use 16Msps for TV stream:

16MHz works well with PAL modes, and 13.5MHz for NTSC modes.

I built latest HackTV on Windows (packaging by pacman for MSYS2 / Mingw64 project, see https://github.com/gavenkoa/tv-result/blob/master/hacktv-mingw64-pacman/README.md - an adaptation of HackTv build script ) & also used WSL 2 + usbip-win (at 0+git20230104+ds-2 from Debian Bookworm).

The video output via HackRF is stable only for low sample rate 9.7-9.8Msps (together with color & sound!). At 10Msps the picture is unstable and at 12-16Msps is very unstable - visible only for the fraction of the second, constantly fluctuating.

I tried different modes (PAL/SECAM), supported by 2 digital LG TVs:

TV mode	HackTv mode
L	l
BG	b or g
DK	d or k or pal-d or pal-k
I	i or secam-i or ntsc-i

and channel E29 & E36 (535.25MHz & 591.25) + tried to offset frequency a bit from CLI & in GNU Radio:

hacktv.exe -f 535250000 -g 30 -s 9800000 -r test -m pal-k
wsl hacktv -f 591250000 -g 30 -s 9718750 -r test -m i
wsl hacktv -f 591260000 -g 30 -s 9718750 -r test -m l
wsl hacktv -f 535250000 -g 30 -s 16000000 -r test -m ntsc-i

I tried 2 different USB 3 ports. HackRF reports only 4 U: UUUU at the beginning, no problems with USB transfer rates...

The same CLI works fine at 10-17.4Msps sample rate from RaspberryPi 4 USB 3 port for the same HackRF board & USB cable & same digital LG TVs. With 18Msps the signal is not detected by TV & no USB buffer overflow is reported by HackRF in console...

So the problem lies in Windows driver stack or my laptop USB hub hardware. I doubt to blame libusb because seems usbip-win is not using libusb underneath.

IDK if I could get any suggestions, just sharing my experience.

PS I surprised to see TV picture at 9.7Msps - I looked at spectrogram of:

hacktv -m pal-k -s 9700000 10s.mp4 -t float -o file:10s-9.7mhz.cf32
inspectrum 10s-9.7mhz.cf32

and color & audio FM streams are at wrong offsets, I was able to recover & decode audio FM in GNU Radio by multiplying IQ file stream by +3.2MHz sine (so FM carriar is at -3.2MHz offset, not +6.5MHz) & low pass filter 180kHz + WDFM demodulator.

Stable color + audio streams location is when sample rate is at least 14Msps, I checked with inspectrum every:

for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do   hacktv -m pal-k -s ${i}000000 1s.mp4 -t float -o file:1s-${i}mhz.cf32; done

Here the color is behind audio and I am able to reproduce the picture on the screen from IQ file in GNU Radio to HackRF transmission: