RX888 MkI Recorded Frequency Discrepancies
Posted: Sun Sep 04, 2022 9:21 pm
Hi Simon,
RX888 support appears to have migrated to the groups.io forum of late, but I'll be a good boy and post this here
I have both a MkI and a MkII RX888, and the latest SDRC releases have been superb for them both, but a few days ago I came across a problem with recordings made on the MkI, in that frequencies shown for signals are inceasingly inaccurate the further you go from the recording's centre frequency. Over a 2MHz wide recording, for instance, the error grows from zero at the centre to about 65Hz at 900kHz either side of the centre, the indicated frequencies being high at the lower end of the recording and low at the upper end. The screenshots in the attached zip file were taken during a test in which I sent a pair of signals at 9.1MHz and 10.9MHz from a GPS-locked signal generator and made a short 2MHz wide recording centred on 10MHz, showing the displayed frequencies live and from the recording. The RX888 was using 128Msps (new dll) and 4MHz B/W, but I first noticed the problem last week when I was comparing simultaneous recordings made on the MkI, MkII and Perseus to evaluate their NDB catching powers, and noticed that things were not as they should have been on the MkI recording. Three or four recordings made with the MkI since have all shown the same problem. The recordings were only 350kHz wide, and the errors were only up to 12Hz at the edges, but when you are used to working to 1Hz accuracy they tend to stand out quite easily!
Back in Apr 2019 I'd noticed a similar problem with the Perseus, which you sorted out after I'd made a load of sample rate data logs for you: if you need the same data this time just let me know and I'll start churning them out.
Edit: having looked at the log file I can see that this won't be possible, as the sample rate data isn't available.
As for the new dll you issued, it's working beautifully on my PC (Ryzen9 3900X CPU and GeForce 2700 GPU): last night I had both the MkI and MkII running simultaneously at 128Mbps, 16MHz B/W, and both waterfalls were silky smooth, with the CPU at <4% and the GPU at 63%. Increasing the MkI B/W to 32MHz, its waterfall was choppy for a few seconds and remained slightly stuttery afterwards, but the audio was still perfect. However, the CPU was then nearing 12% and the GPU was at 90%, so I thought better of pushing things any further! Thanks indeed for the work you've put in to get these radios working so well!!
Regards,
Dave
PS - the radio enumeration is also working very well, although I've found that the MkII always needs to be started first for some reason: if I start the MkI first, starting the MkII causes the MkI waterfall to slow down by half, then both radios crash when you try to change anysetting and need to be power cycled to get them recognised by the PC again (not a problem once you are aware of it). Edit: the crashes appear to have gone away in the latest software update, and both radios now start ok in any order.
RX888 support appears to have migrated to the groups.io forum of late, but I'll be a good boy and post this here
I have both a MkI and a MkII RX888, and the latest SDRC releases have been superb for them both, but a few days ago I came across a problem with recordings made on the MkI, in that frequencies shown for signals are inceasingly inaccurate the further you go from the recording's centre frequency. Over a 2MHz wide recording, for instance, the error grows from zero at the centre to about 65Hz at 900kHz either side of the centre, the indicated frequencies being high at the lower end of the recording and low at the upper end. The screenshots in the attached zip file were taken during a test in which I sent a pair of signals at 9.1MHz and 10.9MHz from a GPS-locked signal generator and made a short 2MHz wide recording centred on 10MHz, showing the displayed frequencies live and from the recording. The RX888 was using 128Msps (new dll) and 4MHz B/W, but I first noticed the problem last week when I was comparing simultaneous recordings made on the MkI, MkII and Perseus to evaluate their NDB catching powers, and noticed that things were not as they should have been on the MkI recording. Three or four recordings made with the MkI since have all shown the same problem. The recordings were only 350kHz wide, and the errors were only up to 12Hz at the edges, but when you are used to working to 1Hz accuracy they tend to stand out quite easily!
Back in Apr 2019 I'd noticed a similar problem with the Perseus, which you sorted out after I'd made a load of sample rate data logs for you: if you need the same data this time just let me know and I'll start churning them out.
Edit: having looked at the log file I can see that this won't be possible, as the sample rate data isn't available.
As for the new dll you issued, it's working beautifully on my PC (Ryzen9 3900X CPU and GeForce 2700 GPU): last night I had both the MkI and MkII running simultaneously at 128Mbps, 16MHz B/W, and both waterfalls were silky smooth, with the CPU at <4% and the GPU at 63%. Increasing the MkI B/W to 32MHz, its waterfall was choppy for a few seconds and remained slightly stuttery afterwards, but the audio was still perfect. However, the CPU was then nearing 12% and the GPU was at 90%, so I thought better of pushing things any further! Thanks indeed for the work you've put in to get these radios working so well!!
Regards,
Dave
PS - the radio enumeration is also working very well, although I've found that the MkII always needs to be started first for some reason: if I start the MkI first, starting the MkII causes the MkI waterfall to slow down by half, then both radios crash when you try to change anysetting and need to be power cycled to get them recognised by the PC again (not a problem once you are aware of it). Edit: the crashes appear to have gone away in the latest software update, and both radios now start ok in any order.