Improved Spectrum Lab Conditional Actions for Meteor Observing

[IanL]

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.

[BiggarDigger]

Good piece of work Ian!

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

Richard

[BiggarDigger]

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

[BiggarDigger]

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:

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

[BiggarDigger]

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:

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 January 19, 2019 by BiggarDigger
one letter makes all the difference: "now" versus "not"

[Gasman]

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

[Stub Mandrel]

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

[IanL]

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:

 

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 January 20, 2019 by IanL

[IanL]

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.

[BiggarDigger]

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

[Gasman]

On 20/01/2019 at 12:34, IanL said:

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.

Thanks for that Ian, I had to reinstall SpectrumLab as it froze when I installed the MetScat_Comprehensive_v7.USR file? I had to ctrl alt delete to stop it. Not sure what's going on with Spectrumlab yet but I'll keep at it?

Regards 

Steve

[Geminids]

Hallo group and in particular Richard.  I have been programming SpectrumLab CA scripts and configurations unsuccessfully to extract the  frequency slope of the head echo.  I have tried detecting when a head echo has occurred and capturing a screen shot to measure. I have also tried using a CA  script to write a log file for the progressing frequency slope.   I fortuitously captured one spectrogram image that I could measure but to me the time resolution appears to be am issue.  I have logged a hand full of head echoes to text files but not succeeded in getting the full stroke, I assume because of the resolution ?  I am very keen on extracting this data and would welcome a chat, perhaps by email.

[The Admiral]

Welcome to the forum Geminids.

A couple of years ago Steve Nickolls and myself wanted to get more information on the head echos. We were using a script which I had written for logging meteors, not the same as the referenced Brit Astro ones, and although I forget the details now, I had sort of concluded that a faster FFT was likely needed. IIRC the FFT cycles every 33ms, which is a bit slow for head echoes I think. Mind you, I know little about FFTs, and there may well be a cunning plan to extract more information!

Ian

[BiggarDigger]

Yes, a warm welcome Geminids!

I'd second what Ian says, a higher rate sampling is needed to accurately record the transient head echoes.  That implied a shorter FFT window and more experimentation with Spectrum Lab.  Unfortunately, lack of time over the last couple of months meant I didn't progress the idea.  There may be issues with aliasing at high sample rates and fast transients: Could be interesting nonetheless.

Here's a couple of incoming strikes with clear head echoes that recorded as I type:

The problem here is noise. Taking the first return (on the left of the image), at what point does an algorithm detect the start of the head echo...

1, 2, 3 or 4?

Point 4 looks like noise, but is on a possible extended line from point 3.  There is "something" at points 3 and 2, but are they signal or noise?  Point 1 is clearly in the head echo on this return, but the signal is now strong enough to blur into adjacent pixels (time), reducing the accuracy of any measurement.

Much higher resolution is required, but, as noted, that may make the FFT sensitive to the discontinuities in the GRAVES Radar signal.  I suspect a quantitative rather than qualitative approach is needed to save being bogged down in noise and spikes.

Richard

[johnb]

Hi

I have spent the morning with this script and it does an excellent job - Despite being able to change the config for some elements Im struggling with the placement of the on screen labels position

What I would like to do if possible is

Move the Label down to the bottom of the screen and reduce the black space before the text ?

Regards

John B

 

[johnb]

Hi

 

So I answered my own question by reading the script properly (lesson learned) I do however have a question around the recording

The wav files are produced and the date \ timestamp corresponds with the log files and the screen captures but they are all empty as in they do not capture the sound - do I simply need to increae the buffer from 5 secs to 10 or 20 ? - does anyone else have the same issue ?

Regards

John B

[Geminids]

I have been thinking about  what to expect for a head echo and what measurement requirements one might need.  Very much rule of thumb so comments very welcome.  Kaufmann has written a paper in IMO's WGN 46:6 (2018) where he shows what he calls the "frequency slope"  by which I think he is referring to the rate of change of Doppler frequency with time - dF/dT.  His figures vary from around 250 Hz/s to 10kHz/s.  Meteoroids may have velocities of say 60km/s to say 20km/s and 40km of atmosphere (110 to 70km) to pass through (this is a gross approximation as meteoroid direction and locations come  into the calculation but we don't know these).  The duration of the head echo, if it is strong enough scatter, will be 0.75 to 2 seconds.  In this time the frequency recorded could have shifted by a few thousand Hz.  To resolve this we would need to get from our Spectrogram / FFT to provide frequency, say, every 100 Hz .  This would correspond to 2000 / 100 or 20 frequency samples.  To do this in our one or two second time frame means readings every 50ms to 100ms.

As I said , very much rule of thumb and could be completely wrong.  What do you think?

Mike

[IanL]

4 hours ago, johnb said:

The wav files are produced and the date \ timestamp corresponds with the log files and the screen captures but they are all empty as in they do not capture the sound - do I simply need to increae the buffer from 5 secs to 10 or 20 ? - does anyone else have the same issue ?

Not had that issue as far as I can recall. One thing to try is to save your configuration, exit SL and restart it. I have found that if you make changes to the sound recording settings, they can get in to a state where they appear to be working but are not! A restart will get SL's internals back in to a sane state.

The options are all on the Options - > Wave file settings section. The script uses the "Triggered" option, so when you set "rec.trigger" to any non-zero value in the script, recording starts, and stops again when it is set to zero. If you're getting files then that part is working, so your issue is likely to be in the sound output settings.

Take a look at the Source value on the Options-> Wave file settings tab. In my setup it is set to L5=Left Output, 2400kS/s. If you look at the Components window, you should see that the audio input passes from L0 through to L5 and thus at L5 it is captured in to the sound files.

Between L3 and L4 is the bandpass filter (should be green), which I guess could be limiting the captured frequencies incorrectly but I don't think so as that would also affect meteor detection, logging, screeenshots, etc. If you double click it you should get the filter control window and that should show a centre cutoff of about 1858Hz with a bandwidth of 965Hz, i.e. only passes frequencies within about +-500Hz of the GRAVES frequency.

At L6 you have the DAC which should be putting the audio out through your default sound output device. It should be green if working, though it might not be if the output rate is too high (will appear red). Click it and then choose Configure DA converter. You will get the Spectrum(1) settings tab come up. Check the 'use different sample rate for output' option and set nominal: to (say) 9375 S/s to reduce the DAC output to something that the sound card can handle.  Apply the change then back in the Components window click the DAC box, uncheck enabled and then recheck it to restart the DAC and clear out the buffer. Hopefully all being well the DAC will now show in green.

Now Immediately before L5 there should be a light blue triangle pointing right to L5. Click that and you can change the gain using the slider on the right side of the window. Slide that up until you hear the background noise coming out of your speakers, then slide it down to the point where the noise is barely audible. Wait for a meteor and you should then hear a distinct audio chirp. As I said before you may need to save and restart for the sound capture to work, but if you can hear it yourself the capture file should also grab the sound.

 

[IanL]

2 hours ago, Geminids said:

I have been thinking about  what to expect for a head echo and what measurement requirements one might need.  Very much rule of thumb so comments very welcome.  Kaufmann has written a paper in IMO's WGN 46:6 (2018) where he shows what he calls the "frequency slope"  by which I think he is referring to the rate of change of Doppler frequency with time - dF/dT.  His figures vary from around 250 Hz/s to 10kHz/s.  Meteoroids may have velocities of say 60km/s to say 20km/s and 40km of atmosphere (110 to 70km) to pass through (this is a gross approximation as meteoroid direction and locations come  into the calculation but we don't know these).  The duration of the head echo, if it is strong enough scatter, will be 0.75 to 2 seconds.  In this time the frequency recorded could have shifted by a few thousand Hz.  To resolve this we would need to get from our Spectrogram / FFT to provide frequency, say, every 100 Hz .  This would correspond to 2000 / 100 or 20 frequency samples.  To do this in our one or two second time frame means readings every 50ms to 100ms.

As I said , very much rule of thumb and could be completely wrong.  What do you think?

Mike

Mike, whilst I agree that the head echo may have a total duration of a couple of seconds, you will never detect the full length of it using this kind of forward scatter setup.

Firstly, the Doppler shift of the head echo is due to radial velocity, which is a product of the meteor's intrinsic motion (i.e. actual velocity though the air) and its motion towards or away from us as it moves across our line of sight. As you can see below, even if the meteor is travelling perpendicular to our line of sight at point of closest approach, it first gets nearer and then moves away, creating a Doppler shift.

We can calculate the radial velocity at any given point along the head echo quite simply, as shown below:

The radial velocity is delta f (the amount of shift in Hz), divided by twice the transmitter frequency, then multiplied by the speed of light in km/s. So at the marked point there is a shift of +300Hz, so the radial velocity is 0.3144 km/s. Note that it is always easier to measure if you have a static trail associated with the head echo. Trails will usually have fairly negligible velocities, maybe 20 km/h at most, so by assuming the centre line of the trail is the transmitter frequency we can measure the delta for the head more easily (I find that trying to calibrate these cheap dongles accurately is not possible and the reported frequencies can be off by several hundred Hz and doing this sidesteps the need for calibration).

Bear in mind that this is only the radial velocity. To calculate the meteor's true velocity we would need to know the direction of travel relative to transmitter and receiver, which is not really possible using a single forward scatter detector (though I think it is with multiple receiver sites, e.g. BRAMS). If you make assumptions about the meteor's true velocity, you can calculate the distance to the meteor from the radial velocity. This is possible in meteor showers if you use the published average velocities of that shower's meteors as your assumption.

As you note, the frequency shift is going to be very wide which would make it challenging to capture a sufficiently wide range of frequencies coupled with sufficient time resolution to measure the slope. I haven't done the maths in detail, but realistically I think you're going to be limited to perhaps a bandwidth of 6kHz with these cheap dongles and Spectrum Lab processing, which is nowhere near wide enough to cover the entire range of a typical head echo across it's entire flight.

More importantly, the geometry between transmitter, meteor and receiver is extremely important in forward scatter detection. Forward scatter is a form of specular reflection, i.e. the same as light reflecting off a mirror:

So the strongest signal will be received when the head is at the point where the angle of incidence equals the angle of reflection around the normal with respect to the reflecting surface. For a flat mirror, the normal is just the line perpendicular to the mirror's surface. For a ball of plasma reflecting radio waves, the concept of a 'surface' is a bit more nebulous (pun intended), but from my reading you can roughly approximate it as a flat mirror somewhere inside the plasma ball.

The upshot is that firstly you're only going to detect head echoes where the geometry is favourable, typically moving across the line of sight, not where the meteor is heading directly towards or away from transmitter or receiver. We definitely see overdense plasma tails with no associated head echo visible, and I am assuming these are cases where the head's geometry was not favourable for detection of specular reflection.

Secondly the transmitter beam is wide but still fairly directional. Again, reading suggests that typically you will only detect the specular reflection within +/- 3km of the point of closest approach.  So in the diagram above you could slide the yellow normal line left or right 3km and receive the signal. Beyond that, the green reflected beam is going to miss the receiver. As I understand it, that's the fundamental limit on how much of the head echo you can detect with a forward scatter receiver.

Its worth bearing in mind that a lot of the academic papers deal with back scatter setups, where the radar transmitter and receiver and co-located and thus many of the variables affecting forward scatter don't apply or are well constrained and known. Plus modulation and timing of the radar pulses allows accurate determination of the distance to the meteor head over time.

[johnb]

The more I tinker with the script the more I like it, really looking forward to the TODO list

Sound issues resolved, using the info above followed by a number of restarts

So a question

Would it be possible to add a variable called eventduration and then only trigger log entry, screen capture and audio if the eventduration is exceeded for instance set eventduration=5, so it will only log, capture and record events that are equal to or longer than 5 seconds ?

Regards
John B

[IanL]

45 minutes ago, johnb said:

The more I tinker with the script the more I like it, really looking forward to the TODO list

Sound issues resolved, using the info above followed by a number of restarts

So a question

Would it be possible to add a variable called eventduration and then only trigger log entry, screen capture and audio if the eventduration is exceeded for instance set eventduration=5, so it will only log, capture and record events that are equal to or longer than 5 seconds ?

Regards
John B

It already exists for logging and screen capture, just change the value of Log_Threshold to whatever you want the minimum duration to be, default is set to 0.05 seconds. Some scripts have separate durations for logging and screen capture, but mine doesn't as it was complex enough to get the conditions working right already.

Sound capture is more problematic, since you have to capture the event whilst it is in progress, so if you wait until you are sure it is long enough, you might miss the boat. Thus it is either on or off and anything that exceeds the SNR threshold will start a capture. You could increase the pre-buffer length I suppose and provided the pre-buffer was always longer than the minimum duration you'd get the sound, but again I avoided that for simplicity.

[johnb]

thanks for that, very  handy

 

Regards

John

[Geminids]

Thanks IanL for the reply and your useful notes on Head Echoes.  Interestingly another way of looking at the Doppler shift is using the Wikipedia definition for bistatic Doppler which gives DeltaF = (1/lambda) . d(RG + RM)/dt where DeltaF is the frequency shift, lambda is wavelength,  RG and RM are the ranges of moving body from GRAVES and the monitor station respectively. Thus d(RG + RM) / dt is rate of change of the sum (RG + RM).  Although I haven't done the algebra I am sure they are different formualtions of the same physics.  

Quote

So the strongest signal will be received when the head is at the point where the angle of incidence equals the angle of reflection around the normal with respect to the reflecting surface.

Wikipedia notes also notes under bistatic Doppler "... that objects moving along the line connecting the transmitter and receiver will always have 0 Hz Doppler shift ..." By this I infer that DeltaF will be zero when crossing over the Great Circle between  GRAVES and Monitor station. This could at least give a line over which the meteoroid has passed

Quote

... typically you will only detect the specular reflection within +/- 3km of the point of closest approach.

So, choosing a nice round figure for the actual velocity of the meteoroid of say 24 km/s the detected signal would last about a quarter of a second.

I too, very many versions away, started my Conditional Action scripts on those of Paul Hyde.  For Head echoes I have modified my most recent incarnation to capture a screen shot whenever the rate of change of the frequency (DeltaF/dT) is above a given amount.  Measuring this frequency slope has been identified in recent IMO journal articles: "Forward Scattering : an interesting formula to calculate the velocity of a meteoroid that generates a head echo"; Pierre Ernotte; WGN, the Journal of the IMO 46:6 (2018)  pp 198 and the subsequent paper " Visualizing sporadic meteor radiants and their dynamics by radio forward scattering";  Wolfgang Kaufmann; WGN, the Journal of the IMO 46:6 (2018) pp 201.

I needed to modify the size of the FFT to increase the  Spectrogram scroll rate and improve time resolution (at the expense of frequency resolution)  I am still playing with this so won't give any details at the moment, but here is a typical screenshot.

I have been able to extract the frequency and time data from pixel data of images using software and have sensible figures for the frequency slope albeit with wide uncertainties.  The software gives me 20 ms per pixel on the time axis and just over 2 Hz per pixel on the frrequency axis.   My spectrogram indicates 2000 Hz corresponding to zero Doppler and the GPSDO on the RSPDuo ensures confidence in the absolute frequency.

 In a roughly 24 hour period I captured some 1000 screen shots of which 50 were of the kind of quality that would allow slope extraction, and so it can be seen that I need to improve matters quite a bit to get the right ones 😞  The software will probably allow me to automatically extract the details but not sure yet.  I also am working on getting a log of the frequency and time down the slope.

Edited May 12, 2019 by Geminids
none

[Al.Grant]

Following this thread with interest ....

I ran a meteor detector a little while ago but after the laptop died I didn't have a spare one I could use.  That has recently changed and I just need to find a bit of free time over the next week or two and get things up and running.

I've got a Funcube Pro+ dongle and found my old scripts for SpectrumLabs - however this script looks like a great place to get it back up and running again.

My old script kept growing and whilst it did everything I needed when it worked ..... when something went wrong it caused me more than a few headaches!

[johnb]

Hi

I used this script and unfortunatly the laptop died, now on a new laptop and it all seems to be working, however when I looked at the Conditional Actions there is a lot of Red

Mostly to do with Time 

So it  says: Test Line 10: Current Time is Unknown in condition [68], near Current_ti

I have not changed the script, pointers really appreciated

Regards