symmetal

Glad it's back working. With the weather you couldn't have used it anyway so not much lost. Alan

No, the laptop charger and the Nevada PSU are the only items running off the mains. Laptop PSU (19V @ 3.34A) is 63W. At 90% efficiency this will draw 0.3A from the mains. The Nevada supplying 13.8V @ 8A delivers 110W. At 60% efficiency this will draw 0.76A from the mains. Total mains current 1.06A. This is the maximum current, and in in normal use you will never use this amount. 0.5A mains current is a realistic average value so you're perfectly OK with the reel wound in. Personally I would only be concerned about unwinding the reel fully if your drawing 5A or more mains current. That's assuming your reel is rated at 13A which it looks like it is from the cable size in your pics. Alan

Neat solution. Good advice if the the extension is being used near its maximum capacity of 13A, but at the load used here (less than 1A) the reel won't heat up if it's left wound in. You'll probably need ventilation due to the heat produced by the linear power supply and laptop though, if the lid is left fitted in use. Alan

I thought that would be the result unfortunately, but at least you can swap it with a short road trip. Meanwhile enjoy playing with the fluffy model clouds. Alan

Ah, didn't know you're an electronics engineer too Shelster. Well, I'm a retired one now. Was going to say the two 3 terminal packages (SOT-223) with the heat sink tabs above the power connectors are the 5V and 3.3V regulators. You can measure the voltages on the tabs. (For future reference) Alan

Looks like the same board as on the AZ-EQ6. As you say nothing looks out of the ordinary. Did you re-seat the connectors to the power input and switch? The only real way is to measure the voltages around the board but that means having it powered with the board hanging out which risks causing shorts. As it's under guarantee probably best avoided if you're not too confident doing this. As you've tried several different power supplies and 2 different power leads I'd be surprised that a new power supply will fix it, but you never know. Good luck anyway. Alan

It looks like a high resistance connection inside the mount. With the power disconnected remove the side panel with the connectors on (the 4 outermost screws I expect) and look at the wire connections from the power connector and power switch to the PCB. Maybe one of the wires is only held by a few strands. or there's a bad solder joint. You could also remove the power connector on the PCB itself and check for any heat damage (dis-colouration) on the connector pins which indicates a poor connection. If there's nothing obvious and you have a multimeter power it up with the side panel hanging off (ensure nothing is shorted to the mount) and measure the 12V on the PCB each side of the power switch while your slewing to see where the 12V drops. If it's still looking OK then there may be a component failure which is a bit more complicated to find if your're not electronically minded. Alan

I use Rosco filters on my Huion LED flats panel just like Oddsocks though I use 1 or 2 sheets of 0.9 ND (3 stops) depending on the scope. Alan

Very neat job Jammy Alan

I set my studs into the concrete after the concrete had set. I had an Astro Engineering pier top kit from years ago. There were three 300mm M20 rods to fit the pier top plate. Like you there were nuts to fit above and below the pier top so there was no great rotational force on the studs themselves. I drilled 25 mm holes about 200mm deep in the set concrete and used Anchorset two part styrene based resin to glue the studs in place. I cut the bottom of the studs at a 45 degree angle to give some rotational resistance and they've been rock solid to date. Alan

This should read 'The offset cannot be set via SGP using the Ascom driver' as per my first post above. The relevant words are 'within SGP' When you click on the driver settings using the wrench icon you are effectively leaving SGP and manipulating the driver yourself. It's a subtle difference but may make the above statements clearer. ? Alan

Sorry blinky, just seen your reply and I have to apologise to you. It seems SGP now supports the ZWO cameras using the native ZWO drivers. It looks like it was included in SGP V3. ? In the past SGP devs said they don't want to use native drivers as it means possibly having to update SGP each time the manufacturer updates their drivers. Looks like too many people clamoured for offset control and they had to give in. The 'ZWO Camera' is the native driver while 'ASI Camera (1)' or (2) are the Ascom drivers So to answer your original question, yes, with the 'Zwo Camera' driver, setting the gain and offset settings per event are available where you've shown. Setting Priority Level 1 The gain and offset can be set using the wrench icon next to the camera driver selector. Setting Priority Level 2 The gain can be set for different binning settings in the 'Control Panel/Camera' tab. Setting Priority Level 3 The gain and offset can be set using the 'Sequencer/Event/Options' as in your screen shot above. Level 3 has the highest priority so will over ride any lower level settings. If set to 'Not Set' the settings from the level below will be used. Hope that helps blinky. ? Alan

Oops! you're right there Oddsocks. I was initially thinking of focused spot readings when I wrote it but added the infinity focus as a normal flat procedure. Of course this will integrate the whole exposed area which isn't much use. It was 3 am when I wrote it which is my excuse. ? How about fitting an aperture mask for the front of the scope with a small offset hole which could then cover the box corners without spilling over the edge. Or, you could set the light box at the end of the garden and focus on the box corners in turn. Or, you could follow Oddsocks detailed and elegant solution. ? Your capture software normally allows you to move the mouse over the image and give a readout of the ADU value under the mouse. Or looking at the histogram display will give a good indication of the ADU value spread. The histogram reads from 0 to 65535 from left to right (for a 16 bit display, as most are). Also the image statistics display will give you max, min and average ADU values of the whole image. Alan

Hi Jamie, With the scope still focused at infinity as normal and using your usual capture software, point the scope at the centre of the light box and take an image at whatever exposure gives you a reading of around 30000 ADU at the centre of the image. Ignore any readings away from the centre. An average of a block of pixels would be more useful, some software gives values of a 21 x 21 block or similar under the mouse cursor when moved over the image. Then keeping the exposure the same, take an image with the scope pointing at a corner of the light box and see if you again get the same reading at the image centre. Repeat for the other corners. If the readings are all the same then the light box is evenly illuminated. The flat frames you've seen with numbers and contours superimposed are from software like CCD Inspector which show the light fall-off characteristics of the imaging train. However to get these you need a flat frame from a source which you know is evenly illuminated. In your case, at the moment, you don't, so you wouldn't know if the fall-off characteristics were from just the scope, or a combination of the scope and flats box. Alan

As I mentioned in your previous post the Offset cannot be set outside the Ascom driver. As soon as you select any camera from the drop down menu the SGP Offset setting will be greyed out reading 'NA'. You can set the gain there if you wish but as it is of limited usefulness and is easily overlooked and is not immediately viewable on the event. You should be able to add the gain into the file name using the file name pattern options, but I never got that to work when I tested it. Just use the Ascom driver itself to set the gain and offset, and put the settings into the 'suffix' field as a reminder to what the settings were for the event. As han59 said it is much easier to leave it at unity gain/offset for everything especially when you are starting out. Vlaiv convinced me that was best anyway, and any 'benefits' of changing the gain have to be weighed against the downsides. If your alignment/guiding is not too good and you get sausage stars after a couple of minutes then there is a case for using higher gain at a shorter exposure but if you can guide well then stay at unity gain is my advice. ? At unity gain you have a full well capacity of just over 4000 electrons which matches pretty well with the 12 bit range of 4096 levels, 1 electron = 1 ADU. At gain 300 your full well capacity is down to about 650 electrons, with 1 electron = 5 ADU. This equates to effectively just over 9 bit resolution. When stretched this will give significant posterization in the image unless you take hundreds of subs to compensate. Alan

I imagine it's sticking a bit in RA, maybe needing a re-greasing. To check switch your multimeter to amps (assuming you have one ) and measure the current taken from the power supply while you drive the mount around in RA at a low speed. A sticking point should show up as an increase in current taken. At night as everything cools the grease will be thicker so would show problems more than when everything is warm indoors. Also thermal contraction at night could make sticky points more noticeable. Alan

Good work Lishan. The original C55 is a 10uF, 16V 10% tolerance tantalum capacitor, (markings 106 16K 537). The 106E you have used is a 10uF, 25V tantalum which is why it's bigger. Similar style markings for the 16V one would be 106C I never liked using tantalum capacitors in the past (the bead variety) as they had a nasty habit of going dead short with little or no provocation. This meant the capacitor looked perfectly undamaged while components around it often went up in smoke. At least the surface mount ones while still prone to failing it seems, show themselves as being the culprits and and seem less likely to take other components out. Alan

Glad to help Ady. Have you actually checked you haven't downloaded it twice before? . Here's another link to the manual from skywatcherUSA if you haven't yet got it. Here's the bit you want from the manual Alan

On page 8 of the AZ-GTI manual it gives the pinout of the RJ12 connector which you can match to the known RJ45 pinout. It uses 3.3V logic. As noted on the EQDIRECT page the AZ-EQ6 and EQ8 have 3.3V logic but will happily work with 5V TTL FTDI adapters. Whether the AZ-GTI will also cope with 5V logic I don't know so it might be worth getting the 3.3V FTDI adapter to be sure it'll work. If anyone knows whether it will work using 5V logic it would be useful to know. Alan

If it was 15 degrees off in RA I would suspect a 1 hour error in the time setting somewhere. Daylight saving time ending perhaps. Alan

@AngryDonkey, Mike. I installed AllSkeye on the mini PC in the shed with the Oculus connected and I get this message when I run it. I've been using AstroArt to aquire the images which has worked well and was keen to try your software. SxUsb.dll is there in your folder. I reinstalled the latest drivers from Starlight Xpress, no change, and did the .net framework check which said it was already installed. The mini PC is running Win 10 home 64 bit. Edit. Working now. Didn't install the C++ redistributable package. . Looking good so far. Alan

I wondered how it coped with two cameras needing the same driver. Maybe not too well. I use ethernet connection to my rig as using WiFi was fine until you started transferring files when the Teamviewer or TightVNC connection became very sluggish. With ethernet it still worked fine. Having two computers would then mean running out two cat5 or installing a network switch on the scope. Thanks kens, that's interesting. My assumption that indi-web server used a FIFO was right. ? You should certainly submit the fix as it should fix the dual imaging problem using one remote computer for those not into sending scripts/commands over terminals to achieve the same result. Yes that's true, indi-web just makes it easier for those not used to scripting and using terminals. I was thinking of ways to automate sending commands via Putty or similar to achieve what indi-web does as you suggest. If kens indi-web fix gets implemented that should help the less linux savvy people. Alan

I've been having a play and you can have two indiservers running at the same time on one machine, each connected to different equipment (using different ports for the two servers) and have two sessions of Kstars/Ekos running on the Windows PC each one connected to a different indiserver. Woohoo!! However, you can't use indi-web to start the servers. Only one instance of indi-web server seems to be allowed to be run. If you start another with different ports it attempts to kill the first one, fails, and doesn't start. So using indi-web only one indiserver can be remotely controlled from Ekos. Starting the two indiservers directly on the remote machine using ssh from Windows, with the drivers required listed as arguments to the launch command (and a different port number) you can then connect and disconnect from Ekos (with indi-web un-ticked). Also if the hardware isn't connected when the server is started will probably lead to problems. Changing the equipment used on the fly is a bit more difficult though. A crude way is to kill the indiserver process and restart with new arguments. The more elegant way is setting up a FIFO and pass the location of the FIFO list to the indiserver on startup and send text commands to the FIFO to add or remove specific INDI drivers as required. Scripts could be set up to do this. I imagine this is what indi-web does for you. There are probably easier ways but this was my first attempt. ? Or,....... use a second RPi. ? I'll keep playing, but my current setup of everything running on the remote Windows PC seems much simpler. Being able to change connected equipment at will is very handy. INDI isn't very plug-and-play. Alan

Thanks for all your suggestions. As you say it's best to ask on the INDI forum. ? Alan

Thanks Wim, your method would certainly work. Mine aren't the same scopes and cameras. One's widefield with an ASI1600 while the other is narrower with an Atik One. The ASI needs the USB3 which the Pi doesn't have hence the mini PC. I thought it could be possible either to have both Ekos clients use the same INDI server, or to run two INDI servers on the same PC to save the extra RPi. Dithering is a bit messy. I just set the Atik sequence to dither and accept that the ASI with shorter exposures will have to scrap 25% of the images unless I'm monitoring it and set the Atik to pause after each image and continue when the ASI has finished an image where I pause that until dithering is done. I'd have thought that synchronizing the dithering on dual rigs shouldn't be too difficult to achieve automatically but it seems to be. Alan