IanL

I built a DIY pipe pier for my NEQ6. The whole observatory build process is documented in detail here (parts 2 and 3 cover the pier): https://www.blackwaterskies.co.uk/series/a-small-imaging-observatory/ Bear in mind this was for imaging, so I only built the pier using a 1 metre length of 6 inch steel pipe delivered from eBay (as was the rebar), filled with bags of ready-mix concrete. You'd probably want a longer pier (and thus more diameter) for visual. A plastic pipe would certainly work if you can find an appropriate length and diameter. Sourcing long, large diameter metal pipes from eBay is a challenge since they're hard to deliver and so tend not to go much over 1 meter in length. One option I've found is mild steel flue pipe. It is in no way strong enough to act as a pier on its own, but would be ideal if painted and filled with concrete and rebar. You can buy it in 1 metre lengths which are formed to slot together to make whatever length you need, and being thin mild steel wouldn't be too hard to cut one pipe down to make the exact length you want: https://www.ebay.co.uk/itm/STEEL-FLUE-PIPES-ELBOWS-COWLS-FROM-4-INCH-UP-TO-8-INCH/172496012877?var=471340394224&hash=item282990464d:m:mOsMuGoz-8fF5kPxl3LXjrw You'd probably want 2 x 180mm or 200mm, 1 metre lengths. For the pier head adaptor, I went with an off-the-shelf NEQ6 extension tube: https://www.firstlightoptics.com/sky-watcher-mount-accessories/skywatcher-eq6-extension-tube.html This is designed to fit the NEQ6 mount head perfectly, and my blog posts describe how to drill out the bottom plate of the extension tube and fix it in to the concrete pier using stainless steel studding (again bought from eBay). Hope this gives you some ideas.

You can: - Disable all driver updates in the system settings, just Google for it, but it's a very blunt instrument and you probably don't want to go there as new devices and software will often work better if you are using latest drivers. - If you're using Win 10 Pro then you can use the group policy editor to disable driver updates for specific device IDs, but not possible in home editions. - You can go in to device manager and select the properties of the device, then choose 'roll back driver' after it has auto updated. This may prevent it re-updating for a while, but I never had much luck and would regularly have to roll back or reinstall the working Prolific driver. In the end, you don't want to be wasting limited clear skies chasing these gremlins and personally I just bit the bullet and bought an FDTI cable which works flawlessly. The Lynx ones also look more professional and better made, I was always worried with the hi-tec ones that one accidental yank and the cable would part company with the plastic box housing the board.

See this: http://www.prolific.com.tw/us/newsdetail.aspx?news_id=35 I don't know what version of Windows you are using, but if Windows 10 that chipset doesn't have a supported driver and Windows 10 will update (break!) drivers automatically. Is it the Hitec Astro EQDirect cable by any chance? If so you're definitely going to have problems with Win 10 and possibly earlier versions of Windows. Prolific produced the original chipset but it was then ripped off by loads of far-east chipmakers who basically cloned the chip, sold it cheaper but used Prolific's drivers so both stealing their IP and the money they invested in writing, testing and updating drivers. In the end Prolific released an updated driver that tries to detect the clone chips and stops working. You used to be able to get around the problem by finding and installing the older driver version, but with Win 10 it would happily re-update to the later driver next reboot unless you went through a bunch of shenanigans to prevent it. The upshot is that you'll save yourself a lot of grief by moving to a new EQDirect cable with an FDTI chipset, e.g. the Lynx Astro models.

Might be worth having a look at this if you're using PI, or even if you're not, to understand the general principles of weighting. https://www.lightvortexastronomy.com/tutorial-pre-processing-calibrating-and-stacking-images-in-pixinsight.html#Section5 Bottom line is that if you combine two stacked masters containing 20 subs each, simplistically you'd weight them 50:50, but what if 10 of the subs in the first master are "poor" and only 2 of the subs in the second master are "poor"? Would you now think 50:50 is the correct weighting? The only practical way to ensure correct weighting is to stack everything in one go.

Regarding "Zooming in", up to a point it's purely a display issue (i.e. adjusting FC to show a smaller frequency range), but after that point zooming further just increases the height of each frequency bin without actually gaining resolution, same as for a digital image once the individual pixels become visible. To understand more I'd suggest you read this: https://www.qsl.net/dl4yhf/speclab/fftinfo.htm The basic idea is that at some point, you will have to start trading off resolution in frequency vs. resolution in time. To decrease the size of the frequency bins (i.e. the span of frequencies covered by one waterfall line) the FFT process needs to collect a larger block of samples, which takes a longer time, thus increasing the time span covered by each waterfall update. The point at which this becomes an issue is a function of the sampling rate of your dongle and the processing power of your PC, but once you reach it you have to make that trade off. The settings that control this are mostly here: https://www.qsl.net/dl4yhf/speclab/settings.htm#fft_settings Don't be afraid to play about with a copy of your working configuration - you might find it easier to tune in to the test beacon or an FM radio station to see the effects of each tweak rather than waiting for meteors.

The offset up and down buttons change the offset, the display up and down buttons change the frequency scale by nudging the VFO, so you can use both to get the right combination for your dongle. Once you are happy, right-click the Tune to Graves button to amend the VFO value it tunes to permanently and save your settings. If I recall the chosen offset will remain set in the config file until you change it. I'm away from my equipment so recollection may be faulty here!

It will be an issue with the specific version of SL. I previously posted in the SL group and the author confirmed that a particular internal variable disappeared in a later version due to a bug. Can't remember if it was this one or something else sorry. Try updating to the current version or regress to an earlier one, or ask for help in the SL group.

Can you share more details of your set-up, what software you are using, etc. How are you doing the filtering and plotting - software application, Excel, something else, e.g. interested in your Moon Bounce intelligent filter... Not that I see a lot of that here - a few tropos and maybe the odd bounce but on the whole they are much fewer and further apart - maybe 2 or 3 short events a month I'd guess.

Agreed it is problematic when the only trigger is exceeding a set SNR threshold for a set period. One will catch all sorts of spurious signals plus miss weaker ones. I haven't had time to look at or test other filtering mechanisms or triggers, though some others have produced scripts with such concepts but not seen any rigorous attempt to prove their accuracy. Bottom line is that manual review of screenshots or recordings is necessary to get a 100% accurate count, but even so might be quicker to start with a total and subtract obviously bad data points rather than count good ones. I also take the view that for longer term trends and amalgamation of data across multiple observers it will come out in the wash, i.e. if you're over recording it is likely to have some degree of consistency over time so trends, showers vs. sporadics, etc. would be identifiable. By way if illustration, earlier in the year there was an interestingly large spike in activity for a couple of hours that several UK RMOB contributers recorded. On examining the data it was just a tropo or similar atmospheric condition allowing detection of the CW transmitter. I didn't sweat for hours cleaning up data, rather waited for the data to suggest an investigation was needed.

You could certainly process the data in Excel by using a PivotTable. You'd need to import the data, make sure each column has text label in the first row. Now add a column on the left with a formula to extract just the hour part of the timestamp (look at the date and time functions). Then select all the data and insert a pivot table. You drag the hour column to the rows section and the meteor count to the values section. You'll need to change the values field settings to display 'max' rather than the default 'sum'. You should now have a table of hours and maximum meteor counts, no programming required. This is all standard Excel stuff so plenty of tutorials online on each step I've described above. Alternatively change your spectrum lab conditional actions to generate the hourly meteor count at the end of the hour rather than for each meteor event. Take a look at my post linked below for an idea of how to do this. https://www.blackwaterskies.co.uk/2019/01/radio-meteor-scatter-improved-spectrum-lab-conditional-actions/

The Spectrum Lab actions that I created (see other topic in this forum) will produce a live log file that can be used. You simply use the Live - Spectrum Lab option in Colorgramme and choose the log file. You can only pick a file with tge right naming convention for the current month so should be obvious which log to use. it also tries to produce a standard Colorgramme/RMOB file, not documented as far as I can see. Doesn't seem to work but due to lack of documentation hard to know why. Beware that Colorgramme is very flaky. I eventually got in working on my Windows 10 machine by tweaking compatibility settings but it regularly crashes the PC if left running.

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"