IanL

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.

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.

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.

"HK$10M of Astrological Equipment"

Never seen such a pretty set of stacking artefacts before. They appear to be hot pixels so darks or a bad pixel map should help in eliminating them. That said I'd have thought the stacking process would reject them anyway, but if you are using a simple average with no outlier rejection then perhaps not. I don't know what options the stacking process has, but even using a median rather than mean would work. Basically as the hot pixel 'moves across the sky' , a much higher value than normal gets included in the stack of pixels for the sky position it is at frame to frame. So if a point in the sky is producing (say) around 20 ADU per frame plus or minus a bit of noise, you're going to get a stack of 18, 19, 20, 21, 22, 200 (the latter being the frame with hot pixel in that sky location). A straight average will produce a final value of 60, whereas a median will get you 21. Clearly the latter us nearer the truth. There are usually more sophisticated statistical options available. The pattern effectively shows the pointing of the scope as it deviates from the apparent rotation of the sky and demonstrates three things: Firstly I think you must be using an equatorial mount of some sort, or perhaps a star-adventurer or similar star tracker? Secondly field rotation, the overall curved sweep of the trails show that your polar alignment is off by a wide margin. Thirdly you have a repeating sinusoidal motion. Given the round stars you must be using short exposures, so it's too rapid to be periodic error of the main RA worm gear, so thinking it might be periodicity of a smaller intermediate gear? Neither is a problem as such given you are doing such short exposures, but if you start to increase exposure lengths you will start to see star trailing.

Have taken a look at the RMOB data, it is clear there was a period of about 36 hours where GRAVES was off or doing something different. Multiple observers show zero detections during the period with detections before and after. Normal service resumed about 18:00 yesterday (21st March).

Like to be able to tell you but my data drive filled up two days ago and only just started getting logs and images this afternoon after clearing it up!

Just go to the "downloads" section of this page. Instructions and downloads are all there. The installation guide is also there: https://www.nooelec.com/store/sdr/sdr-receivers/nesdr/nesdr-smart-sdr.html Basically plug in the dongle and let windows install the default driver. Then run the Zadig installer to replace the default driver with the modified one. Your SDR dongle is now ready to work with SDR#, HSDR, etc. To get it working with Spectrum Lab first install Spectrum Lab, then copy the ExtIO....dll file from the HSDR installer zip to the Spectrum Lab folder. In SL you select the ExtIO...dll file as the audio input device. Tuning is just a matter of typing the desired frequency in the VFO box on the main SL screen and hitting enter.

You don't need SDR# at all. It's good for testing as easier to set up than Spectrum Lab but not needed to make the latter work. You just need to ensure that your chosen SDR dongle comes with an ExtIO.dll driver to interface with Spectrum Lab. I use the NooElec NedSDR which works fine.

We use one at our society observatory, concreted in to the ground rather than bolted but don't see why bolting would make any difference. It's relatively tall and not that chunky, no particular issues with vibration or deflection but it isn't that heavily loaded usually. If you're using it solely for imaging you can keep it fairly short to minimise such issues, but obviously for visual it would need to be taller.

You've already answered your own question. No magic solutions here, you need some disk recovery software as something will be screwed up in the disk partition table.

Just realised that you are using 5 second time intervals and I am using 1 second so your waterfall plots may be differently scaled. Would have to rescale one set of images so that it has the same number of pixels per second (H) and pixels per Hz (V) to compare visually.

These are FFT waterfall plots of radar reflections off the International Space Station from the GRAVES satellite tracking radar located in France. Graves transmits on 143.05 MHz, and on my plots (first post) the vertical axis is 2 kHz wide centred on that frequency. Horizontal axis is 1 second intervals, most recent at the right. Richard's plots are 2.2 kHz wide and five second intervals. Doppler shift is easily understood for an object approaching directly towards you or moving directly away. Less obvious is the case where the object is moving at 90 degrees to that direct path, i.e. across your line of sight. In such a case one might naïvely assume there is no Doppler shift, but that isn't the case. The only way an object could have no Doppler shift is if it follows a circular path with you at the centre. In that case it is neither approaching nor receding. For any other path (straight or curved) and/or observer location, the object is either receding or approaching, except for the instant of closest approach. Thus it exhibits a Doppler shift that is a function of its absolute velocity (in some frame of reference, e.g. orbital velocity for the ISS) and location on its path relative to the observer, i.e. its "Radial Velocity". For these forward scatter radar reflections one has to consider radial velocity relative to the transmitter, as the incoming radar signal will appear Doppler shifted as it arrives, plus the radial velocity relative to the receiver which creates a second shift from the receiver's perspective. Read some of the posts in this forum, as there are links to maths, etc. which may be of interest. Also, note that the Radar scans in Azimuth so the reflections are dashed lines as the radar scans on and off the ISS.

In a truly dark room, or at night in situ if you have no nearby light sources and little light pollution to leak in, fit the box to the scope focused to infinity. Take a flat, rotate the box 90 degrees, take a flat, and rotate/expose twice more. Calibrate the first flat with the second (put the first flat in your software as if it was a light frame and calibrate with the second) Then stretch the result as much as possible. If the flat box is evenly illuminated, being the only variable, you should see no gradients or vignetting as the second flat will have corrected just the uneven illumination from the optical train and uneven pixel response. Then flatten the original (unflattened) first with the third and review, etc. You may also want to take median ADUs of 25x25 pixel areas on the unstretched flattened flats. Any gradients mean the box is not evenly illuminated. Using the median measurements you can calculate the percentage difference across the field and decide if it is acceptable.

Take a look at the original article, first link on this page: https://www.britastro.org/radio/downloads.html It has a pretty wide angle in azimuth, probably 130 to 140 degrees of reasonable gain. In elevation there are significant lobes and nulls, but that seems fairly common with Yagis and is more a function of height above ground that anything else. The design is a simple half wave dipole with a single reflector and single director. It is optimised for the GRAVES radar transmitter on 143.05 MHz so depending on what you're using as your radio source you may need something different. No idea how you'd combine multiple antennae to improve coverage; most of the stuff I've read by Radio Hams is aimed at the opposite, i.e. making the antenna more directional not less.