Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

sgl_imaging_challenge_banner_comet_46p.thumb.jpg.9baae12eeb853c863abc6d2cf3df5968.jpg

IanL

Improved Spectrum Lab Conditional Actions for Meteor Observing

Recommended Posts

Hopefully some of you will find this useful.  As you may know, Paul Hyde wrote the original Sky at Night articles that got so many of us interested in Radio Meteor Observing. Whilst the article and BAA web site provide some useful starter configuration files for Spectrum Lab, they have quite a few deficiencies.

Most importantly, Paul Hyde delivered a presentation (I know not where or when), which is available here: http://www.radio-space.co.uk/files/links/HYDE_Observing_with_SpectrumLab.pdf

On pages 25 to 28 he notes that using the cyclic actions in Spectrum Lab, the data captured about frequency, signal and noise for meteor events is likely to be erroneous, as by the time the script is triggered, multiple new FFTs will have been processed and the data read by the script will be wrong. He provides a pencil sketch of how to address this problem by changing the conditional actions settings to run each time a new FFT is processed, and triggering them using the 'new_spectrum' condition.

The example is far from comprehensive and I haven't found anywhere one can download a set of actions configured to work this way. So I've spent a few months writing and testing my own, which I have made available here: https://www.blackwaterskies.co.uk/2019/01/radio-meteor-scatter-improved-spectrum-lab-conditional-actions/

The files provided include both the conditional actions (if that is all you want) or a complete Spectrum Lab config file if you prefer. Both will capture screenshots (using queued events to avoid missing the second or third meteor in a quick sequence, and also capturing multiple shots for long trails that span more than the waterfall width). They also create a comprehensive event log file, hourly and daily meteor count logs and two types of RMOB log file suitable for upload to rmob.org. You can also capture sounds as .wav files if you like.

The full config also has a sane set of programmable buttons configured that allow you to configure and manage meteor logging, including the ability to automatically retune your RTL-SDR dongle via an add-on .exe file (which isn't possible otherwise using Spectrum Lab buttons). I created this to simplify use of the system for others in my Astronomical Society.

Hopefully this will prove to be of some use.  Happy to receive feedback.

  • Like 5
  • Thanks 1

Share this post


Link to post
Share on other sites

Good piece of work Ian!

I'll need to make time to experiment with the new script.

Richard

Share this post


Link to post
Share on other sites

I had a little play with this just now and encountered the usual pernickity Spectrum Lab.

I've never been able to get SL to drive my RTL-SDR directly, and so it was today.  I use a virtual cable (from vb-audio.com) to connect the SDR output to SL and use SDR# to drive the rf functions of the SDR.

Nonetheless, I'm interested in the features in this script and tested it with a 1kHz local oscillator in SL to fine tune the conditional actions.

For now, I've reverted back to my original script as I don't have enough time to tweak much further tonight.  However, with a bit of luck I can find time in the week to merge the conditional actions text file into my hardware specific setup.

I'll report back in a few days.

Richard

Share this post


Link to post
Share on other sites

Ian, A brief update on some tests I ran with the script.

Since my RTL-SDR dongle appears not to like Spectrum Lab, or more specifically, I haven't been able to find a driver dll to interface the two and need to drive it from SDR#, I had to fall back to testing only the conditional actions in the text file.  These imported fine, but I couldn't get the script to trigger correctly.  I can see it reading the average SNR, but upon an incoming meteor, it steadfastly refuses to trigger any further.  I have adjusted the SNR trigger point down to a couple of dB, at which point it should be triggers almost continuously, but still nothing.

Oddly enough, when there is an incoming strike, I see the green icon on the main display briefly flash to yellow and then back to green, just as it does when executing my current script:

image.png.e8946c22314f50985cb676ff192fa96d.png

I need to spend more time reviewing the new script to see if there's a configuration in SL that I need to adjust to get the new script to recognise the peaks in the spectrum.  Given that I'm only using the conditional actions and not your full setup, is there something in the initial configuration of SL using your method that specifies the incoming frequency range over which the conditional action script should search for a peak?

Anyway, I'll try find some more time over the next week to run some more tests and checks.

Richard

Share this post


Link to post
Share on other sites

Progress!

Reviewing the .USR file, I can see there are a number of configuration variables which are passed to the conditional actions script.  Primary for my concern is the cfg.SpecFreqMax and cfg.SpecFreqMin.  These were set outside the tuning range of my dongle - remember I'm running the dongle driven by SDR# and not Spectrum Lab.  Adding those variables into the conditional actions text file plus tweaking some minor SNR and duration settings and I'm now recording meteors with this new script:

event20190119_191811_1.jpg.b9486396518f65238b7faa27fba8e8f1.jpg

I'll monitor the output for a few days and see what the script records, particularly in the small hours when background rates and duration tend to peak.

Richard

Edited by BiggarDigger
one letter makes all the difference: "now" versus "not"

Share this post


Link to post
Share on other sites

Hi Ian

I can`t seem to find the `Tune to Graves` or `Tune toTest Beacon` buttons as you suggest if changing the install directory which I did. I actually installed Spectrum Lab to my D drive.

I am getting a good signal using the default Sky at Night files and using a Funcube Dongle plus.

cheers

Steve

Share this post


Link to post
Share on other sites
On 13/01/2019 at 18:50, BiggarDigger said:

I had a little play with this just now and encountered the usual pernickity Spectrum Lab.

I've never been able to get SL to drive my RTL-SDR directly, and so it was today.  I use a virtual cable (from vb-audio.com) to connect the SDR output to SL and use SDR# to drive the rf functions of the SDR.

Nonetheless, I'm interested in the features in this script and tested it with a 1kHz local oscillator in SL to fine tune the conditional actions.

For now, I've reverted back to my original script as I don't have enough time to tweak much further tonight.  However, with a bit of luck I can find time in the week to merge the conditional actions text file into my hardware specific setup.

I'll report back in a few days.

Richard

I do the same - except I drive the dongle with HD-SDR

Share this post


Link to post
Share on other sites
On 17/01/2019 at 19:53, BiggarDigger said:

Oddly enough, when there is an incoming strike, I see the green icon on the main display briefly flash to yellow and then back to green, just as it does when executing my current script:

image.png.e8946c22314f50985cb676ff192fa96d.png

 

That icon is the .wav recorder trigger. If you're just using the conditional actions, I don't know how you've got it set to trigger if at all. In the full config file, if Sound_Capture is initialised to 1 it will trigger for each logged meteor and save a .wav file to the location specified in Sound_Path. As noted in the instructions, Sound_Path needs to exist, otherwise the capture process fails the first time it triggers and then won't work until you restart Spectrum Lab.

17 hours ago, BiggarDigger said:

Progress!

Reviewing the .USR file, I can see there are a number of configuration variables which are passed to the conditional actions script.  Primary for my concern is the cfg.SpecFreqMax and cfg.SpecFreqMin.  These were set outside the tuning range of my dongle - remember I'm running the dongle driven by SDR# and not Spectrum Lab.  Adding those variables into the conditional actions text file plus tweaking some minor SNR and duration settings and I'm now recording meteors with this new script:

cfg.SpecFreqMin and cfg.SpecFreqMax are Spectrum Lab configuration values that can be set/read by the interpreter:

https://www.qsl.net/dl4yhf/speclab/cfg_comp.htm

They correspond to the minimum and maximum frequency values displayed on the first (main) spectrum display. So basically any meteor that appears on the waterfall display with an SNR that exceeds the Log_Threshold value should trigger a capture event. I find some smaller events are missed even though visually they look like they are big enough to trigger, I assume because the SNR doesn't actually exceed the threshold for long enough so something that might be worth experimenting with is how to measure the signal and noise more accurately.

I don't know why your setup didn't have useful values for these configuration items, might be because you are using SDR# as your input source? If the meteor appears on the waterfall it should be within the range we are measuring so a bit of a puzzle there. In theory changing these values by assigning frequencies to them in the interpreter should actually change the displayed waterfall range; that's how the 'Display Up' / 'Display Down' buttons work in the full config.  Worst case, just manually replace cfg.SpecFreqMin and cfg.SpecFreqMax with hard-coded frequency values (in hZ**) or create some extra variables to hold them and substitute them them in the commands triggered by line 18 (new_spectrum) to measure across the appropriate range.

** Note that the frequency values are relative to the tuned frequency. In my config, vfo is tuned to 143.05 MHz and the min and max values are approximately +1300 Hz to +2300 Hz if I recall rightly (maybe a bit more than that), i.e. the waterfall display frequencies are differences relative to the tuned frequency, not absolute radio frequencies. Your mileage may vary for other data sources.

If you've got a working configuration already, you can find the correct values by going in to the Conditional Actions tab and typing cfg.SpecFreqMin in the 'Watch' box at the bottom and the current value should appear in the box to the right, then change to cfg.SpecFreqMax to see what that is. Alternatively, as I've done in the full config file, right click a spare programmable button and type "SF: " + cfg.SpecFreqMin + " - " + cfg.SpecFreqMax +" Hz" in the first input box to have both values on screen at all times.

Edited by IanL
  • Like 1

Share this post


Link to post
Share on other sites
15 hours ago, Gasman said:

Hi Ian

I can`t seem to find the `Tune to Graves` or `Tune toTest Beacon` buttons as you suggest if changing the install directory which I did. I actually installed Spectrum Lab to my D drive.

I am getting a good signal using the default Sky at Night files and using a Funcube Dongle plus.

cheers

Steve

Steve,

I assume you are loading the full MetScat_Comprehensive_v7.USR file using the main 'Load' command in Spectrum Lab. Also check that you are running the latest version of Spectrum Lab just in case there is some version incompatibility.

Beyond that it is a bit hard to say why you're not seeing the buttons. Do you see any of the custom buttons I have created (per the instructions at https://www.blackwaterskies.co.uk/2019/01/radio-meteor-scatter-improved-spectrum-lab-conditional-actions/ )?

You can edit the MetScat_Comprehensive_v7.USR file using any text editor, e.g. Notepad. The relevant section is here:

[MACRO_BUTTONS]
:
:
Exprs2="Tune to GRAVES"
Commands2=sdr.freq=143048017:cfg.SpecFreqMin=1357:cfg.SpecFreqMax=2357:exec("C:\\Spectrum\\Retune.exe"):Logging=LoggingState
Options2=2
Hotkey2=0
Exprs3="Tune to Test Beacon"
Commands3=LoggingState=Logging:Logging=0:sdr.freq=144428000:cfg.SpecFreqMin=1357:cfg.SpecFreqMax=2357:exec("C:\\Spectrum\\Retune.exe")
Options3=2
Hotkey3=0

Worst case, right click on an unused programmable button, type Tune to GRAVES in the first input box and sdr.freq=143048017:cfg.SpecFreqMin=1357:cfg.SpecFreqMax=2357:exec("C:\\Spectrum\\Retune.exe"):Logging=LoggingState  in the second input box then save the button. You'll need to amend C:\\Spectrum to whatever path you have installed Spectrum Lab (or wherever you have saved the Retune.exe file), remembering to use double backslashes.

Share this post


Link to post
Share on other sites

Thanks Ian,

Yes, now I've added a definition for the cfg.SpecFreqMax and cfg.SpecFreqMin constants in the conditional actions script, the logger isn't missing much.  In fact, arguably, for my site and system, it's too sensitive.  Generally speaking, I don't think I've got too much RF noise.  However, in addition to events of the order of a second or more, I recorded a fair number of extremely short duration and weak events overnight (<0.1s and ~15dB SNR), My original script didn't detect many of these.  Given my range to GRAVES, I have no reason to think these are not meteoric in nature, but I suspect they may be very low in mass, which almost instantaneously vaporise creating a very weak and short duration events.

I suppose that for a complete picture these should be included, but it would make post analysis of the events more difficult.  As a result, I've tweaked the SNR threshold and duration up to 16dB and 0.1s.  I'll see what effect that has on filtering out these extremely short duration events over the next day or so.

If I can find the time, I might also have a play with a second spectrum, with a narrow window, to record the head echoes and see if I can deduce information about incoming velocity.

Richard

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

By using this site, you agree to our Terms of Use.