IanL

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"

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.

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.

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?

Yes but typically each filter would start from a known position where it is near focus. Over time that position would be invalidated. Whether you can use only full steps depends on: With regard to whether to use full steps or not: Critical Focus Zone in microns = focal ratio x focal ratio x 2.2 So my scope is 6.38, making a CFZ of 89.41 microns (i.e. the range of focuser travel within which the image is in good focus). Distance moved per motor step in microns = Distance moved per focus shaft turn in mm x 1,000 / steps per motor turn x motor gear teeth / focus shaft teeth So my motor has a step angle of 1.8 degrees, making 200 steps per turn, I have an 18 tooth pulley on the motor and a 36 tooth pulley on the focuser shaft and the distance moved for one turn of the focuser shaft is 1.43mm. Thus I get a distance per step of 3.575 microns, and 89.41 / 3.575 equates to 25 steps in the CFZ. The distance moved per step needs to be a reasonable fraction of the scope's critical focus zone (say 10-20 steps), so mine is a bit too high but not unacceptable. If there were too few steps, then one would try half, quarter or eighth microstepping to increase the number of steps by 2, 4 or 8 respectively. If too big then there are a number of strategies - change the motor, change the gearing or just increase the number of motor steps per reported step number in the Arduino firmware.

I did some more testing after the above post and I found: - AAF2 was reporting the 'correct' position. whereas SGPro continued to report a completely different position every time I disconnected one and connected the other. - When I created a new equipment profile and re-added the focuser I then got matching positions between AAF2 and SGPro. So somehow with the original profile SGPro (or far less likely the ASCOM driver) is 'remembering' a different position. I couldn't figure out why. - I did some further testing and maths and determined that the physical size of each 1/8th microstep was way too small with this motor, gearing and the fine focus reduction. So really I need to use full steps not 1/8th microsteps. This may explain the autofocus failures as perhaps the focuser was not moving sufficiently at each focus point and SGPro was measuring small differences due to seeing rather than focus moves. The weather hasn't allowed me to do any further testing yet but I'm pretty sure that is one of the issues. - I couldn't figure out the cause of the ASCOM isMoving errors or whether they were important, but it was a bit worrying. I decided to try a different project's Arduino firmware and drivers to see if the problem occurred there and it did not so at the moment I can only conclude the problem lies somewhere between SGPro and this particular ASCOM driver. - As an aside I ran in to a whole bunch of other issues due to a small difference in the serial comms with Pro Micro boards vs. the Nano boards supported by the other project. The project's author worked with me to resolve the problems and I think I'll be sticking with that project going forwards (e.g. a lot more of the settings can be managed via the driver rather than by changing the sketch). - One important point that I picked up along the way is that you should only be disabling the FETs on the EasyDriver board if you are using full steps. If you use any form of microstepping and disable the FETs between moves then the stepper is going to jump to the nearest full step position, which will then cause the motor/focuser position to drift relative to the reported step position over time. - By extension, if you want a reliable starting position per filter (as supported by SGPro for example), you either need to have a method to repeatably position the focuser at startup relative to a known step number, OR you need to park the focuser at a full step position at the end of a session before powering off. If not you are again likely to experience drift over a a number of sessions due to powering off the motor whilst it is in a microstep position and having it jump uncommanded to the nearest full step. Hope this helps!

OK now I'm in need of some help to get this working working with Sequence Generator Pro: - I can successfully connect to the AAF2 in SGPro and get it to drive the focuser in and out using both the focus control docking module and the auto focus routines that run as part of a sequence. Note that I need to tick 'Reverse Focuser Direction' in the SGPro control panel to get the motor going in the correct direction for IN and OUT. One issues I am having is that the position reported by SGPro in the focus docking module does not match with the position set by the AAF2 driver. So for example, if I force the initial position to be 1000 in the ASCOM chooser thus: - The driver is correctly reporting a position of 1000, I can see this in AAF2 trace file, e.g. if I use the focus control docking module to move the focus control 'IN' 50 steps, it needs to move to position 1050 (as the direction is reversed per the settings): 14:55:38.670 Move 1050 I have confirmed this more thoroughly by connecting to the focuser using the ASCOM Pipe device and the POTH device and can see the AAF2 ASCOM driver and the Arduino sketch seem to be in agreement about the 1000 -> 1050 move. SGPro reports the initial position as being 9000 though: After pressing 'IN' it reports 8950. So the relative number of steps seems OK 50 steps in the opposite direction to what the driver reports per the reverse setting above, but the absolute values are out of whack for some reason 8950 vs 1050. Any idea why SGPro is reporting a different value to the driver? (I know this might be one to take to the SGPro forum, but see below as there are other issues which may be related). Secondly, when digging in to the SGPro Logs whilst connected directly to the AAF2 driver I am seeing regular errors as follows: [12/11/17 14:55:55.683][DEBUG] [Focuser Thread] ASCOM Focuser: Error in IsMoving wrapper. : Exception has been thrown by the target of an invocation. (System.Runtime.InteropServices.COMException (0x80040402): Timed out waiting for received data at ASCOM.Utilities.Serial.ReceiveTerminated(String Terminator) in C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\Serial.vb:line 1204 at ASCOM.AAF2.AAF2.CommandString(String command, Boolean raw) at ASCOM.AAF2.AAF2.isMoving() at ASCOM.AAF2.Focuser.get_IsMoving()) at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams) at rb.ml() at q5.br(Boolean A_0) I'm not sure why these are triggering, they seem to happen sometimes by themselves and other times immediately after connecting to the focuser driver or after doing a move. I do not see these errors in the SGPro log when connecting via POTH. My suspicion is that the POTH is still seeing these timeout problems from the AAF2 driver, but is not passing them up the line to SGPro but I can't see any way to diagnose if that is the case? I think this lack of ability to determine 'IsMoving' is a cause of erratic behaviour in SGPro. When I try the auto focus routine it generally fails to work unless I try it a lot of times - the focus position seems to jump around erratically - maybe because SGPro is trying to do further moves before the last one is complete? I see a nice downward line starting to form after maybe three autofocus steps and then suddenly it will jump up again, causing SGPro to try to restart the autofocus with a bigger intial rack-out. (I admit it might just be backlash or not having configured things properly, but trying to nail down one issue before the next so I can be sure what is going on). Any thoughts - there definitely seems to be a driver issue somewhere - I don't think it is a sketch or comms problem at the Arduino end as everything else seems to work as expected?

I was in the process of building an Easy Driver based version of this when Jameson kindly supplied the modified sketch above to support it, thus saving me a fair bit of time. I've taken things a bit further and so find attached below a new version (2.5.0C) which is compatible with the current ASCOM driver. The changes I have made are as follows: 1. I have re-unified the standard (unipolar driver board, sketch V2.5.0) and Easy Driver (bipolar driver board, sketch V2.5.0B) variants in to a single sketch to make future additions and updates easier rather than having to maintain two forks. - To select which board, just uncomment #define EASYDRIVER at the top of the config section to use the Easy Driver board, or leave it commented out (default) to use the normal unipolar functionality. - You'll then need to define the pins for whichever board you are using in the section immediately below. 2. I have refactored the code to achieve the following: - Separated mandatory and optional user-configurable settings in to two sections. - Moved everything which is not actually a user configurable setting out of the configuration section to avoid mistakes. - Added a bunch more #ifdef clauses to eliminate redundant code (mostly to choose between driver boards, but also to get rid of temperature sensor library and code if definitely not using one). This helps to keep memory usage down on small devices (e.g. Pro Micro) so that extra functionality could be added later (e.g. OLED display, control buttons, etc.) 3. Added a couple more configuration options: - #define DALLAS_TEMP which enables the temperature sensor functionality (on by default). As before this will check if there is a sensor or not so can be left on safely, but if you now comment out this line then the Dallas and OneWire libraries are no longer required and the checking code is excluded to reduce memory consumption. - #define FORCE_SERIALEVENT which forces checking of the USB serial input (off by default). On my pro micro clone board, serialEvent() is never called, as for some reason serialEventRun() is not defined by the Arduino IDE (this seems to be an issue for certain board variants that others have reported). serialEventRun() is called automatically every loop and calls serialEvent() if there is data to process, but it can't be called if it isn't defined! If you get time-out errors trying to connect to the focuser through FocusAAF2 or another application using the ASCOM driver, you may need to try uncomment this line to fix the issue. There are other reasons why you may not be able to communicate, but you can attempt diagnose it by connecting to the board using the Arduino IDE serial monitor (9600 baud, no line endings). Try sending a # or V# command through the serial input. If there is no response then you've likely got this issue. (Much head scratching and tactical use of LED blinking to figure out what was broken!!) IMPORTANT NOTES: I have tested the sketch with an Easy Driver, but I have not been able to test the temperature sensor, Bluetooth or unipolar driver functionality as I have none of these available to me. Hopefully I have re-incorporated everything correctly - sketch certainly compiles with these options on. Please feed back any issues after verifying your hardware works with either the 2.5.0 or 2.5.0B sketches as appropriate. AAF2_Combined.ino

Their Twitter says they were having for about 9 hours yesterday: https://twitter.com/sfnet_ops/status/913183031111929857 https://twitter.com/sfnet_ops/status/913044025791467520 Currently the whole of SourceForge is giving a 500 for me (internal server error) so clearly they are having technical problems again today!