Wolf's SpectrumLab was used to track 2400 Hz carrier frequency using its maximum 524288-point FFT.
#Wxtoimg error waveinopen failed windows 7#
Sampling was done by WINDOWS 7 16-bit soundcard at 11025 samples-per-second. To provide you a benchmark, an old xxx.wav file was pulled for examination. It might be worthwhile to examine a xxx.wav file and take a close look at carrier frequency. If it's frequency is any other than 2400.00 Hz, then either samples have been dropped, or sampling rate is inaccurate. NOAA's APT signal provides a convenient and very, very accurate frequency calibration reference: 2400 Hz audio carrier. It might be worthwhile to do a frequency calibration run to see if there's a problem there. One common thread in all those dis-similar softwares is ADC sampling rate. GQRX's frequency correction seems to ruin decoding. I've investigated the problem even further and this is not a bug with a VOLK. Seems like there are some serious bugs with VOLK's DSP, will recheck soon.Īlso both dongles - cheap "blue Chinese" and RTL SDR v3 works just fine! So there is definitely no problem with crystals inside them. I've found the cause of the problem - it's VOLK who ruined decoding. The problem is still here! I observe the same symptoms as with RTL SDR blog v3 dongle. Yesterday I got another dongle (simple blue from AliExpress). Also there is a quite significant drift from 2400 Hz. There is no multiple of 4.8 KHz, main peak is very broad. I can see main 2.4 kHz peak, 4.8 kHz multiple and minor peaks. I've analyzed audio spectra for two files: good recording from last year and a bad one from past week. I suppose it's all related to the dongle - APT, LRPT, DRM fails while simple audio works fine. At the same time feeding sample audio from other users works just fine. Only sometimes it's able to say me station name and show list of channels. Moreover, I've found that its is impossible to decode DRM HF stations with DReaM decoder in realtime at all - it fails to get all three CRCs good. WXtoIMG works fine - when I feed old recording to it then it gives me nice images. I've tried with using LTS 5.4.32 kernel on Arch Linux, compiling glrpt with GCC 8.4.0, clang but still getting the same issue. May be someone has already faced such a problem and could give me some advice? Or how can I test my hypothesis on 3rd-party test? It has protection diode on the input and I handle it with care so it shouldn't be ESD-smashed (I suppose it will not work at all after discharge). I suppose my dongle become damaged somehow but don't know exactly how. I don't know what can cause such issues as non-lockable PLL and troubles with NOAA reception (I think they are related to each other). Previous summer I was able to start decoding from 2-4 degrees above the horizon.Īt the same time I use GQRX quite well and can clearly hear FM broadcasting, NFM chatting and even AM broadcasting with the use of SpyVerter upconverter. Signal level is awesome, AGC works fine, but PLL never locks even if satellite is flying right above my head. In glrpt I observe issue with PLL locking. This is strange because I constantly get about 40 dB SNR in GQRX for most prominent APT peaks. I've tried to record about a dozen of NOAA passes but with no luck - my images are slanted and WXtoIMG can't do anything with that (see picture below).Īlso it says that it can't find telemetry data or complains about poor SNR ratio. I use (GQRX + Audacity)/(Arch Linux 64bit) + (WXtoIMG)/(Windows 10 64bit) combination to receive and decode NOAA images and (glrpt)/(Arch Linux 64bit) to receive and decode images from Meteor-M sats. I've successfully used it for decoding weather satellites past year. I own an RTL-SDR v3 USB dongle (official version from ).
0 kommentar(er)
