Use BigInteger for frequency instead of long

[AlexandreRouma]

Hi, there is a pretty big problem with the current versions,
It's impossible to chose a frequency above 2.17GHz

Since a lot of SDRs are capable of going higher than that (Eg: hackrf, limesdr, adalm pluto), it would be great if using a higher frequency was possible.

I ran into this issue when trying to receive 2.4GHz CCTV cameras.

Cheers, alex.

[eried]

This is not supposed to capture the transmission itself, but the noise of the circuitry controlling the display. Depending on the refresh rate and other things, this can be around 120 mhz or 300 mhz or so...

[mgkuhn]

Pull requests to make the limits of the center-frequency setting better match the capabilities of the hardware tuner used, where the driver does provide that information, would be welcome. If the SDR driver used does not provide that information, adding a command-line option to provide it manually might also be justified.

But, as @eried said, while TempestSDR should be capable to rasterize any AM modulated analog b/w video transmission, it is in particular intended for accidental raster emissions, i.e. those that do not come with any standardized sync-pulse signals. TempestSDR can also be useful to understand the undocumented analog transmission format of a CCTV camera, but to actually use it routinely, you are probably better off with other TV-receiver software that includes logic to detect and follow horizontal and vertical sync pulses. TempestSDR contains only a heuristic to detect and follow blanking intervals (essentially looking for a dark cross in the frame), which may or may not work for your particular CCTV transmission format. And as the result of that heuristic is applied instantly, and not first fed into a filtered PLL, if I recall correctly, the resulting frame alignment might jump around quite a bit compared to what you get with a regular TV receiver software.

[eried]

For the CCTV camera signal, SDRSharp with TV plugin works perfectly