hacktv
hacktv copied to clipboard
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
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: