some unsorted tricks and hints about the Perseus software defined receiver.
Antenna setup comparison
- the ALA1530S 7m above ground and 15m from the house
- the ALA1530LNP 3.5m above ground on a field 70m from the house
28 MHz:noise level is the same (8dbµV). The ALA 1530S shows better results probably because of its height. (SNR 3 dB against 1.5 dB receiving the local beacon DM0AAB, 70 km from here)
MWremarkably low noise level on the of antenna on the field (9 dB vs 21 dB), also less signal (23 dB vs 31dB) on 1602 KHz (Radio Seagull, 1kW, 300km). But the improved SNR by 4 dB already makes a significant difference. On 603 KHz noise and signal levels of both antennas are almost equal to each other.
It's a strange thing: the Microtelecom Perseus software (V4 and 5) runs well on both USB hubs of my PC (front and back side). But external software like Spectrum Lab or SDR Console only accepts the front ports. On the rear ports, no data will flow (Acquisition 0%, attenuators still click on change) or perseususb.dll won't be loaded. It's not a USB 2.0/3.0 issue. Both ports have the same controller type (Intel 8 series/C220). I spent a few hours analyzing this without a final result. But here are some conclusions that might for other purposes:
It did not help to update the Perseus driver.
- I used WinUSB before, a version from probably 2014. In the device manager, the Perseus appeared under Microtelecom devices in the tree.
- I completely uninstalled it
- After installing
PerseusDriverUpdate 2016a1 (perseusx64.cat version from 01/04/2016), the Perseus was initially listed as the only device under USB devices (not USB controller)
- now it's back under Microtelecom devices again
Spectrum Lab Perseus files
- Spectrum Lab V2.92b02 works fine after I copied all
*.sbs files from the Perseus directory into the Spectrum directory
perseususb.dll must be in the Spectrum directory, too. It only works with the dll from 2009 or 2010. The dll from 2013 (supplied with newer versions) fails.
- if you have things set up like this, the FPGA path in the Perseus control panel can be ignored. It can be anything - still working.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_04B4&PID_325C\ is the path to the USB ports on which the Perseus has ever been connected. For each connection there is a subdirectory.
- the well working front port entry has a subdirectory:
Device Parameters/WUDF/ with an key DriverList as REG_MULTI_SZ with a value
- the faulty rear port has a subdirectory named
Control instead. It contains the key
ActiveService with value
- copying the values to the other port did not help
FM+ RDS decoder vs RDS Spy
The FM+ software already offers excellent RDS decoding for weak DX signals. But is it possible to get a little further? I've tested some recordings with both variants. The result: RDS Spy is a little ahead. Don't expect miracles. Nevertheless, both SDR solutions are a great leap forward compared to RDS decoding by my old-but-excellent Onkyo T4970 tuner. RDS decoding of weak signals starts at about 90 KHz bandwidth, best bandwiths are 125-140 KHz.
advantages Perseus FM+ software
- much faster PI guessings (but many wrong). Unfortunately there is no statistic about which PIs are being shown repeatedly.
- RDS-SNR helps to adjust bandwidth and identify sections of a recording which are worth looping
- looping of sections is possible
- live performance
advantages SDR# RDS Spy
- slightly better PI decoding under critical DX situations
- it takes a little while, but then the shown PI is more reliant (though not always correct)
- faster PS with defined letter position
- loads of additional information: AF, radiotext and much more (only with stable signals)
Setting up RDS Spy with SDR sharp software (SDR#)
In SDR# you can play any WAV recorded by Perseus or FM+ software. It's recommended to use the File Player plugin. It adds a waterfall timeline to the recording and the ability to skip / rewind / forward and loop (no loops between selected parts unfortunately, only full length). The MPX output requires a virtual audio cable with 192 KHz capability (a real 192 KHz sound card is not neccessary). I did not manage to do it with VAC. But VB-Audio is an alternative.
Live performance is not possible. I've tried routing the Perseus output to the virtual VB-Audio. But the audio spectrum is completely cut above 15 KHz. Not even the 19 KHz MPX is visible, let alone the RDS carrier at 57 KHz. Nico, if you read this, is there any trick to change this?
- install the VB audio HiFi(!) cable
- install the MPX output plugin for SDR# and activate MPX with VB audio (MME or DirectSound work both)
- in RDS Spy select VB-Audio as input source
- in the Mixer settings for recording and playback select properties and then the same 192 KHz mode
- for DX purposes check the Super PI decoder option in RDS Spy settings
- play a recording: RDS data should appear
just found out that there must be a spectrum compression in the waterfall in the Perseus software. This is important to know when you interpret signal levels. I've listened to KVRI on the Masset recording (3-Jan-2009, 17 UTC) on 1600 KHz. Until 16:59:56 there is Asian music which suddenly stops. After that a station ID is spoken, followed by 2 seconds of silence. Finally, music starts again.
Watching the waterfall, I first wondered why the carrier signal seems stronger during the station ID and the silence part. Simultaneously, the weaker 1602 KHz carrier becomes visible strongly. When the music starts again, it disappears completely. If the waterfall was linear, it should remain. But actually it's always there. It's just masked by the modulated signal. And the waterfall follows to the overall level. I guess Spectrum Lab wouldn't do that.
Exact frequency measurement
Theoretically it is possible to measure frquencies by 0.03 Hz. This is the highest resulution possible.
How to get there: use 0.8kHz
for the secondary spectrum, use Zoom. Now you see a highres spectrum in the first window. It only refreshes about every 30 seconds.
The calculation overlaps. So if you've justed tuned to one frequency it will take two or three refreshings.
The span is indicated on the left: 24Hz. So the
vertical lines are 2 Hz apart in the highest resolution. The AMLIST
used by FMSCAN now lists more than 1000 exact MW frequencies (use the "exact frequency" option in the experts
This is a spectrum of 1602 KHz in North Germany (calibrated). The labels of the x-scale are misleading. The center is 1602.000 KHz, the vertical lines would be 1602.002, 1602.004 and so on. You can estimate the carrier frequencies by 0.1 Hz here. There are 9 carriers between 1601.990 and 1602.007 KHz. Most of the MW carriers are relatively stable over a few weeks here in Europe. From February 2009 to September 2009 I've observed that many carriers have drifted about 1 Hz. So does it make sense measuring 1/10 Hz? Well it does if you compare recordings from different parts of the world from a limited time span. Then you can identify weak MW signals even beyond 10.000 km of distance.
But when you work as exact as this, calibration becomes extremely important. The manual describes calibration with the secondary spectrum. But there's an easier way.
- tune to the time signals on 10 MHz
- click on CalClr.
- turn "Labels" on
- turn "Zoom" on
- select a resolution of 0.48 Hz in the Span/RBW window.
- detertmine the peak and then tune to that frequency by using the scroll mouse on the frequency counter.
- Click on "Cal"
Beware of doppler effects. The smaller peaks on the right side could be reflected signals from airplanes. Sometimes they're as strong as the main signal.
Unfortunately it is impossible to calibrate the scale as exact as it could be possible theoretically. The minimum VFO step is 1 Hz while you could determine the peak by 0.03 Hz.
The shift is proportional to the frequency: If 10 MHz has 0.5 Hz, then 20 MHz would have 1 Hz, 1 MHz would have 0.05 Hz. There is no other way than calculating.
Check the reference frequency (usually 10 MHz) every once in a while: when the Perseus is turned on, it will take one hour until the calibration is relatively stable. During the first 10 minutes the peak of my receiver drifts by about 30 Hz (from 9999.945 to 9999.975 with CalClr for example).
Recordings are affected by calibration but not exactly the way they should be. If the receiver is calibrated correctly, the center frequency
of the recording will also be. But the border frequencies will be detuned.
Example: peak found on 9999.980 KHz, calibrated, then started recording with center frequency 1000 KHz.
This means the calibration factor is 20 Hz per 10 MHz, thus 1 Hz per 500 KHz.
If you tune to 1500 KHz in the playback (500 KHz off the center), the peak of an exact signal will be found on 1499.999 KHz (1 Hz less).
The good thing: when you deal with recordings with unknown calibration status, you will only need two refence offsets. The rest
Example: The playback contains France Inter on 162 KHz with a peak found on 162.0017 and DLF on 549 KHz with
peak found on 549.0030 (both really transmit on exact reference frequency).
The offset in Hz for any frequency in KHz will be (frq-162)/(549-162)*(3-1.7)+1.7
I've compiled a list of the detuning on the recordings distributed by the former Five Below Blog. It wasn't always easy to find reference frequencies but I think the result is quite good.
PRS - the Perseus record scheduler
First of all you need to install com0com to make it work (see release notes). But I still had errors saying "one device is not working" ("ein
angeschlossenes Gerät funktioniert nicht" in German). The cause: COM10 and COM11 were already used by the virtual Bluetooth Serial Port. In fact
Bluetooth uses all the COM-Ports from 3 to 13 - I don't know why so many. In such a case you need to
- rename the com0com-Ports to an unused number (see Perseus release notes), example: A0 to 14, B0 to 15
- change the registry VCom-Entry from 10 to the 14
- modify PRS_alternate_COM_Port.bat to 15
- start PRS with PRS_alternate_COM_Port.bat
Here are a few bugs of the current Perseus software. is it possible to navigate around them? Please help.
- if you listen to recordings and use high resolutions (1.6 KHz span and lower), the "center"
option and the CF step are disabled.
2000 KHz recordings
Recordings always have the same span as according to the sample rate. It's not only 1600 KHz but even 2000 KHz if you tune via the secondary window (drag and drop) or enter the frequency manually. But keep in mind: Beyond the span the recorded range is mirrored to phantom frequencies.
Handewitt Perseus site
Questions? Corrections? Ideas? Comments?
This site is based at: