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 opened this issue · 4 comments
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:
You can try to change in the bios (or windows) some power saving options, in order to ensure that CPU frequency will run at "performance mode" and will not lower its frequency, it may improve the results and reduce the latency of the laptop.
https://softwareg.com.au/blogs/computer-hardware/cpu-power-saving-mode-bios
I turned OFF BIOS setting "CPU Power Management" - the issue still persists ((
Also I tried to change Windows 10 power mode from "Better Performance" to "Best Performance" with no effect.
Next logical step is to set HackTV on some live Linux and try to boot a laptop...
Try also to increase process priority for hacktv in task manager :
https://www.wikihow.com/Change-Process-Priorities-in-Windows-Task-Manager