Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.



  • Content Count

  • Joined

  • Last visited

Community Reputation

127 Excellent

1 Follower

About Tonk

  • Rank
    Star Forming

Profile Information

  • Location
  1. read the README file that comes with the installation. There is a section for people who have not kept Windows7 up to date. We have put in a link to the specific MS update package you require. (If indeed its the Window10 backwards compatibility libraries that are missing.) Its also helpful to the devs to give specific details of the crash - what on screen messages or not were observed. As a consequence I've provided the most likely guess as to your problem and it may be wrong.
  2. ... and you cant elect to ignore the block? My virus checker lets me ignore a block - maybe yours does to
  3. What it means is by bad luck a sequence of bytes in the newer exe image happens to match one of the virus/adware/whatever signatures they have on file. Its a typical play safe quick check false positive.
  4. Try saving it explicitly from DSS as a 16 bit TIFF (Save Picture to File...). The Autosave files are 32 bit floating point TIFFs.
  5. We have now added ZIPed versions of the installers - use these if your web browser is set to block exe file downloads. You will of course have to unzip them first before installing - links added in first post
  6. If you have a stack that caused this in the past and it doesn't OOM with the new software - please let us know
  7. Hello all - Luc Coiffier (author of DeepSkyStacker) has asked me to post his message about new versions of DeepSkyStacker - specifically there is now a 64 bit version The installers can be found here: 64 bit version - https://github.com/L...64Installer.exe 32 bit version - https://github.com/L...erInstaller.exe 64 bit version as a ZIP file - https://github.com/LucCoiffier/DSS/releases/download/4.1.0/DeepSkyStacker64Installer.zip 32 bit version as a ZIP file - https://github.com/LucCoiffier/DSS/releases/download/4.1.0/DeepSkyStackerInstaller.zip (The ZIP versions are provided if your web browser blocks exe file downloads) I (Tonk) will pick up any issues reported here - but Luc would prefer (if possible) for bugs to be reported on the DeepSkyStacker yahoo group - or if not possible you can also use the GitHub issues page found here - https://github.com/L...fier/DSS/issues If you are not yet aware - DeepSkyStacker is now an open source project on GitHub - https://github.com/LucCoiffier/DSS Regards Tonk pp Luc Coiffier
  8. https://www.linkedin.com/company/farpoint-astronomical-research-a-division-of-optical-structures/
  9. I think the problem was that the instructions of camera manufacturers where misinterpreted as subtracting from the scope/reducer metal back distance when its actually "subtract from the camera back focus cost". Don Goldman (Astrodon) pointed this common trap out many years ago.
  10. "Do filters add to back focus?" They ADD to metal back distance (MBD) of your scope or reducer or they SUBTRACT from the camera back focus cost . You calculate the spacer requirements needed by either the following methods: (First calculate the filter offset via t * (n - 1) / n where t is filter thickness and n is filter substrate refractive index - note that most filters have n close to 1.5 so the equation can be treated as t / 3) 1. Adding the filter offset to the metal back distance of your scope or reducer and using this adjusted MBD as the base for subtracting the back focus costs used up by filter wheel and camera OR 2. Subtracting the filter offset from the camera back focus cost and using the original scope/reducer MDB as the base to subtract back focus cost due to filter wheel and due to the filter-adjusted camera back focus cost. (Some camera manufacturers instruct you to use this approach - particularly if the camera has an internal filter wheel where you add your own filters) The two methods are equivalent - one instructs you to add the filter offset to something - the other to subtract it from something else - somehow this subtle point has lead to 3 pages of tail chasing - lol The equivalent equations in words 1. Spacer length = metal back distance + filter offset - (filter wheel back focus cost + camera back focus cost) 2. Spacer length = metal back distance - (filter wheel back focus cost + (camera back focus cost - filter offset)) Camera back focus cost is measured from front flange to sensor surface
  11. The 511 and 514nm peaks in comet spectra are due to the fluorescense of neutral diatomic carbon molecules (first observed by Swan in the 19th century in Bunsen burner flames - now called Swan bands in spectra). The energy source for this is in comets UV light from the sun. CN radicals have a strong emission band right on the UV/violet border. The principle source of emission light from ion tails is from ionised carbon monoxide which is strongly blue. Dust tails just reflect sun light (so can be seen in any visible light filter though much dimmer than without a filter). The upshot of this is Comet aka Swan band filters are principally for increasing the contrast of the coma of non dusty comets. To enhance the blue ion tail they would have have rather broad pass band. This filter will NOT pass any light due to CN whose light is on the edge of visibility to human eyes (very deep violet). BTW "CN" is not cyanogen - cyanogen is a 4 atom molecule with the formula (CN)2 the dimer of CN. CN is the nitrile (aka cyano) radical. The is a huge amount of misinformation about the sources of light emitted by comets. You may have noticed that various Nasa related websites such as Spaceweather no longer trot out the myth that the green light of a comet coma is due to cyanogen. That myth goes back to the scaremongering that went on in 1910 when the Earth passed through Halleys comet tail and quacks sold "comet pills" to save you from gas poisoning (!). Somehow during the early days of the internet the cyanogen myth got ingrained into explaining comet coma colours. Tony (PhD chemistry :)) PS this lengthy thread over on Cloudynights has the uncovering of the source cyanogen error in the primary astronomy literature (late Victorian era) - you need a bit of stamina to get to the big reveal - https://www.cloudynights.com/topic/406505-green-in-comets-is-not-cn-cyanogen/
  12. I measured the bodies with calipers: Outer Width: 136mm Outer height: 136mm Depth without handles: 67mm (to front optical port flange) Depth with handles: 107mm The optical port is not centred - being offset by 10mm in the height dimension I measured the camera to see if it would fit my dual scope rig.
  13. I've gone the "LED detection" route and now have the USB monitor circuit working to allow the UPS to know if the 10Micron box is off or on. I'm using a SFH-300 phototransistor which has a peak spectral sensitivity @ 850nm (near IR region) but still has 80% sensitivity in the red LED region (@ ~700nm) - ideal for red LED detection. Sensitivity with this transistor is low for green and near 5% in the blue region. The circuit is pretty simple. I've using a 5v 5A Buck convertor (Pololu) as the 5v source for both the photodetector and to feed the USB 5v line to the UPS monitor input via a relay switch. The photo switch is made from a 10K resistor connected between 5V and the phototransistor collector. The phototransistor emitter is connected to ground. The phototransistor collector is also connected to the relay module on/off pin (the other relay module pins are 5V and ground plus the on/off pin is high for relay on). When the relay is off then 5V is present on the USB monitor cable connected to the UPS box. I've arranged it so that when the 10Micron control box LED is on, then the photo switch drives the relay off by taking the relay control pin low. This just saves a little on the consumed power as the relay coil itself consumes 75mA when on whereas the photo switch circuit only consumes 0.48mA to drive the relay off. Given that most of the time that the telescope rig power is on, so will be the mount controller, then it is useful to have the relay switched off and use the NC relay contacts to route the 5V to the USB monitor cable. The mechanics are: 8mm diameter x 10mm aluminium tubing tapped with 2 grub screws to clamp onto the protruding plastic facia LED holder on the 10Micron control box. The phototransistor is held inside a smaller diameter aluminium tube section that slips inside the larger one. I tapped an inside thread onto the inner aluminium tube to have it in turn cut a thread into the phototransistor plastic edge to make the whole lot secure. The 10K resistor is also soldered to the collector wire inside this tube holder, all potted, and a 3 lead cable provides 5v, ground and relay control line back to the UPS. 5V Buck (step down) converter - http://www.hobbytronics.co.uk/batteries/d24v50f5-5v-step-down-regulator Relay - http://www.hobbytronics.co.uk/electronic-components/switches-relays/5v-relay-module Phototransistor - http://www.maplin.co.uk/p/850nm-phototransistor-np64u - spec sheet - http://www.osram-os.com/Graphics/XPic2/00101785_0.pdf
  14. "How are you actually connecting to the mount ?" Ah - right - for the UPS control this is via the "ext switch" jack. This is the 10Micron designed means to remotely turn on/off the mount. They expect you to have a computer controlled relay to operate this. In my case the "ext switch" line is controlled by 1) The NUC (Windows) computer via a KMTronic USB controlled relay (so me in the UK can turn on off mount) and 2) The OpenUPS2 board via its relay control (this turns the mount on when solar source mains power turns on - and turns the mount off (if not already off) if the mains power fails or is scheduled to be off (obsv policy will be off during most of daylight hours for solar battery recharging). So both these relays are wired in parallel across the "ext. switch" plug pins. "So you plan to enclose the LED in some way and then sense whether it's on or off. " At this stage of thinking = yes The only other source of on/off state would be to intercept/tap/sense power to the hand pad. That to is turned on/off in synch with the front panel LED. If I can work out which pins (there are lots) are ground and +vcc then I could create an adapter plug. The adapter plugs into the mount box and the hand pad plug into the adapter. In the adapter I could tap the ground and +vcc pins to sense the on/off state. So the problem to overcome here is a safe discovery of the right pins ....
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.