IanL

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.

That sounds right. When I have time I'm going to work through the maths. Given we know the distance to the ISS from both transmitter and receiver and we know the absolute velocity of the ISS it should be possible to determine the rate of change of the frequency.

Checking my meteor data for a presentation, and found this nice example of radial velocity vs. Doppler shift using two ISS passes about a day apart. You can see the ground track on the map is at a different angle relative to the GRAVES transmitter (centre of circle) and receiver (here in Essex) and so the frequency of the radar trace changes correspondingly as the ISS motion across our line of sight is slower on the 12th leading to a slower rate of frequency change. (The dates/times between the trace and map are different due to time zones and also my PC clock being 8 minutes slow for some reason).

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.

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. 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.

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.

I concur. Filters edges are also a consideration - have been instances of unmounted filters creating reflections if the edges aren't darkened, not sure if it is possible for mounted filters, suppose it depends on the mounting material.

MaskedStretch is useful to retain colour in stars as a single global stretch tends to oveestretch them to the point where the cores are (nearly) white and no amount of further processing will get the colour back. One downside is that the rest of the image lacks contrast so you have to do more work to boost contrast, etc. You can try masked stretch and a normal stretch on clones of the image and then use a star mask to blend the two, but it can be tricky to get a mask sized appropriately for large, medium, small and tiny stars. It might work better to do a masked stretch and then use a star mask to selectively apply further stretches or curves just to the background. The unwanted colour tints seem to be a byproduct of the fact that the stars are different diameters in each of the RGB channels, especially in DSLR/OSC images where you can't adjust the exposure time per filter to balance the sizes (if you don't you can also get colour casts when combining your LRGB image when using mono and filters). When the masking process is operating each channel gets a series of stretches that accentuate the problem as each channel ends up with different star profiles, leading to the magenta cast. Usually it is the medium stars that suffer most in my experience. It's pretty hard to avoid and harder to get rid of once created. I've tried things like extracting the colour channels, applying different star masks and using morphological transformation to shrink the stars so they match sizes across channels, but it is not ideal as clearly tge star has a Gaussian or similar profile. You can also try selective curves and a mask to desaturate the magenta, but this risks unnatural star colours. There is no magic bullet as the best approach seems to vary from image to image.

Agree with the above posters, second hand might be good or a disaster depending on your luck. EQ mounts are definitely not a good idea for a 7yo. I think you need to be realistic about how much she will be able to do without the help of parents, but observing the sky together is a great activity and if you get a reasonable scope she will grow in to it. Take a look at this for one guide to possibilities: https://www.firstlightoptics.com/beginner-telescopes.html Also the first item on this page offers a bit more information and a wider selection (disclaimer, I wrote it, up to date as it was revised this month): https://www.northessexastro.co.uk/free-astronomy-resources/

Thanks, will do, but the Baader is definitely larger than 6mm. I'll measure it again and drop them a line.

Thinking about what to do here myself. I've got a Baader Diamond Steeltrack (refractor), but likewise frustrated by the disappearance of the steeldrive and seems to be no urgency to replace it. I "successfully" built a DIY setup using a stepper, easydriver and pro-micro (arduino clone). It was all working earlier in the year, except I had problems with the belt drive. The Steeltrack has a HTD pulley machined in to the fine focus knob, and is designed to be driven by the steeldrive (contrary to a lot of advice not to drive the fine focus, the Baader is engineered for it). I couldn't find a matching flanged HTD pulley, and having tried a wider pulley the belt wanders and causes the focus to slip. So recently I got a pair of pulleys and switched to driving the coarse focus shaft on the other side, plus an improved bracket and spacer to mount it all. Should be OK with 1/8th stepping and the 2:1 gear reduction through my belt drive. Having done all that, the stepper won't budge (even off load and with max current set in easydriver), have had it all apart, resoldered everything, etc. and no joy. I'm sure it's either a dodgy connection, the easydriver has been fried or the stepper coil burned out. Fixing it would be a few quid to replace the suspect parts but I'm at my wit's end with the whole thing. Last decent imaging run was January this year and don't want a whole year to slip by without getting some use out of my kit. So regardless of it only being a few quid to build your own, looking at a commercial setup. The Senso doesn't appeal as the attachment mechanism seems entirely likely to be the weak point with tiny Allen head grub screws and stripped threads (why not just machine some decent sized holes and screws is beyond me). It's also pricey, as is the Lakeside. I'm looking at the Pegasus focuscube. It's c. £100 less than all the other options, and I don't need a manual focus control since it's for a permanent imaging setup. I can't see much written about it anywhere so not sure about hardware and software quality. The main issue is what it the maximum size of focuser shaft the flexible coupler will accept? Can't find that information anywhere and the Baader's is pretty chunky (about 7-8mm dia. I seem to recall but haven't checked). Of course it would be relatively simple to get a larger bore coupler if needed, but just dread getting in the pulley situation where I can't find the right combination of focuser and stepper shaft diameters. Anyone know?