Jump to content

Banner.jpg.b89429c566825f6ab32bcafbada449c9.jpg

jiberjaber

Members
  • Posts

    541
  • Joined

  • Last visited

Everything posted by jiberjaber

  1. I'm going to add some internal holes in mine, there is something happening with condensation (I'm sure it's external) and there is no air movement possible between the dome screen and the base of the enclosure due to my printed part, so I will pop a few holes in that with the drill and see if that helps with both the morning misting and the CPU temperature.
  2. I had something on mine this morning, I think it was dew on outside and cleared off once the sun came up.
  3. The L value apparently, https://www.axis.com/files/whitepaper/wp_sharpdome_en_1503_lo.pdf (pg 3 & 4) I hadn't put any thought in to this when I knocked up the part, currently, it's about where the original camera was that was removed (perhaps a little lower). Given the wide angle of the (cheap) lens, it's hard to see how distorted the image is as a result of positioning at the moment.. I might experiment if I can see any distortion... but at the moment it seems OK (if out of focus slightly) but lack of stars isn't helping checking focus at the moment
  4. How you finding reflections in the image? I have modified mine now with a revised camera mount, in black, to reduce internal reflections in the dome and also to lift the camera up further in to the dome top. Happy side effect is the Pizero is also lifted up out of the metal base of the enclosure so wifi is back to normal levels for now I didn't want to sit around all day waiting for it to print so bumped the print speed up and lowered the layer resolution so it looks a bit rough - perhaps that might avoid further internal reflection lol The remaining white silicon on the lens edge is still reflecting off inside the some unfortunately, but overall it's better now than with the white mount. Hard to tell at night with the rain on the dome - will have to check tomorrow should we get any sunshine! Looking forward to seeing how the new camera turns out, I see they are back in stock now!
  5. Dome camera arrived today, guts removed and adaptor printed based on the coke bottle camera, probably needs revisiting to give the Pi a bit more room under plus it's in white at the moment, so suspect daylight reflections will be an issue! Lens has dried out now, so all in and fitted. Rough focus on the ceiling of the study seems OK o far. Metal enclosure seems to have a small effect on wifi range. There were some slight scratches on the dome cover, might be an issue with direct sunlight. Camera angle cut off is a couple of cm above the lens.
  6. I finished with capturing data about a week ago and since then I have started and scrapped numerous attempts to the point of giving up almost - I'm close but still not 100% happy. The main problem I had was the resultant NB image was far far too busy with stars etc and I couldn't decide on a colour scheme! This is my first NB image after getting a mono camera, it's been a bit of a mission! Captured over 5 nights ZWO B 31mm: 8x120" (gain: 139.00) -15C bin 1x1 ZWO G 31mm: 10x120" (gain: 139.00) -15C bin 1x1 ZWO Ha 31mm 7nm: 22x600" (gain: 139.00) -15C bin 1x1 ZWO L 31mm: 8x120" bin 1x1 ZWO OIII 31 mm 7 nm: 21x600" (gain: 139.00) -15C bin 1x1 ZWO R 31mm: 4x120" (gain: 139.00) -15C bin 1x1 ZWO R 31mm: 6x120" (gain: 139.00) -15C ZWO SII 31mm 7nm: 40x600" (gain: 139.00) -15C bin 1x1 So about 15 hours combined NB & WB. After pre-processing (all aligned to a master Ha sub) I ran mure denoise on the separate integrated filters, DBE and linear fit. I then combined the NB channels and did a stretch. R = 0.5*HA + 0.5*SII G = OIII B = 0.85*OIII + 0.15*HA For the WB I followed much the same process with a photometric colour calibration but the stretch was simple to give more stars than nebula. I ran the NB image through Starnet++ in PI with a stride of 32. This gave a very starlessimage! I used the blend script and the RGB image to bring a few stars back to the picture. I wanted to mask and play with the colours in the nebula plus try some HDR so see if I could pull out the detail visible in the Ha subs, making a mask proved problematic but I eventually used a luminance mask and some eraser action in photoshop to get some sort of mask to allow only the nebula to be altered. So this is the current revision of the image. I was hoping for something crisp but colourful like the OIII sub - I wonder if it was my selection of combination of the NB subs that has left me feeling this way but I really don't have the enthusiasm at the moment to reprocess to see if that was the case! LOL The OIII sub...
  7. So the pi zero W was itself dry inside the bottle camera but the water seems to have got between the outer glass and inner glass of the lens and fogged up, unable to clear it with any tissue etc so I've put the whole lot in a small tub of rice and dessicant to see if it clears though I suspect a new lens is required...
  8. Mine looks like a very foggy day! I can just tell that there is sun in the sky but the roof is no longer visible - suspect I'll have to take it down and open it up to dry out... !
  9. Yep - will await what it looks like in the morning, might have to remove and dry it out, shame as I was happy about where I had got it working... must get round to consolidating all the bits I've done somewhere!
  10. I suspect the amature waterproofing of my allskycamera coke bottle version hasn't past the test of truth! LOL Suspect I'll have to get a proper dome cover for it now...
  11. How much did they charge to knock that up ?
  12. Wow - this has been a busy day on this. I thought a bit more about the use of the banner text version and decided it was better to not have the execution of the php in cron but to just execute it before the picture is copied, so to this end I removed the cron entry part listed above and modified the copypic.sh script. There is now a true/false option so if you want to use the banner version of the image in the movies you can, if not, then it is ignored, if you want to give this a go, replace copypic.sh with the following:
  13. Aha - so I suspected the fix might only work for locations with no astrodark and I think I was correct, testing with my lat/long and Pete's location details (Pete has astrodark at the moment, I don't) revealed that the solution is to resolve teh issue at source where the sunwait data is generated in the webcam script. This I've tested and seems to work. So need to revert the webcam.php and suntime.php back to the original version and add the following in to the webcam script. It basically checks for the presence of "--:--" which is associated with the 'Midnight Sun' text which screws up the formatting of all the rest of the code tht relies on the sunwait generated data. From line 165, add the if...fi statement blocks to look like the following:
  14. I see "Ralph" has fixed the issue with the suntimes text on the associated webpage - he's put a fix up in the issues section of github but I am unsure if it only fixes it for when we have no astrodark or not? Might need some code elsewhere to ensure the format is correct for both cases? Also needs an edit to the webcam.php file to ensure correct text for sunset time. changing line 64 to Before: After: I've also figured out how to get the banner text updated when no views have occured on the live video page, it's a bit of a brute force approach, I added a line to the crontab through the webcam script to execute webcam.php every 2 mins using wget.
  15. OK - so a while ago I adjusted my version of the code to use the buffer image rather than the plain webcam image for constructing the day/night videos. The reason for this is I wanted the timestamp and data in the video. This worked great - or so I thought... Of late I have been having a problem where the video would be just made up of 1 frame repeated and I was struggling to understand why. Today it dawned on me, the 'buffer.jpg' is only generated when the live view web page is being viewed - if you go days without viewing the live view, the buffer.jpg is not updated, it doesn't need to in it's original use case as it was only for the web page display. As a result, my modification was correctly grabbing the buffer picture but the picture never changed as the live view wasn't being executed (no views) . I need to work out how to run the php code to get the same effect of banner creation but on a regular schedule rather than on demand when teh live view web page is viewed.
  16. I'm currently looking at a disc for a HEQ5 and have found this with all the dimensions in for car models. Now to find that elusive free delivery sub £10 disc of the right size! LOL http://www.national-auto.co.uk/assets/content/documents/brake_disc_cat_-_nov_2014.pdf
  17. Yes - moving larger sounds easier though I do have a load of M3 washers here but it would involve more removal than the larger gear, however the larger gear is quite a tight fit, so washers I think... cheers for the info.
  18. Yes - I tried using the full res of the V2 camera and reverted to the lower res, plus the lower res supports 2x2 binning (not sure if it's automatic) To debug the picture thing, try running the scripts manually, you might be suffering from what I had which is a low size image which still contained the correct image but Pete's code deletes any images below a certain size (110kb) to solve an issue he was experiencing, I commented out the deletion and mine has been fine since (well expect the current issue of the video not being created.) If the image is not being deleted, there should be a copy of the picture in the /home/allsky/pics/night/ directory with a timestamp in the filename. If you run the copypic.sh is should copy a picture from the /run/shm directory and rename it with a timestamp. If this isn't happening, edit the file and comment out the line "/usr/bin/find . -name "webcam-*.jpg" -type 'f' -size -110k -delete" and re-run to test. If you then get a file, check it is actually and OK image, if so, leave the comment in. The same command is in a couple of the scripts, so you'll need to comment it out in all of them if the test solves your issue. so concatday.sh concatnight.sh newdaymovie.sh and newnightmovie.sh I think thats all but worth looking through just in case
  19. Hi all - I am considering making a 'Todmorden' block pier, the initial ones I have seen are circa 2 blocks high but I'd like to get to something closer to the original tripod height of circa 1.2m plus the patio height it is on, so 3 or 4 blocks given my choice of build location. Has anyone used more than 2 blocks successfully? Plus any long term issues to be aware of? Thanks in advance...
  20. My DEC belt is a fraction of a mm proud to the top at the moment so might look in to that, I assume if the belt is riding up, then the large gear needs moving up?
  21. Good question - I'm considering this too.. also, where did you get the pier top from ?
  22. Hi Peter, thanks for that I've updated my version of the webcam script to cover the revised twiSetVid value but I don't think this is where the problem is at. There is still something wrong however.... It seems to effect the movie making for both day and night movies, no longer are the a combination of timed exposures, but seem to be stuck at a particular time. The movie is about the right length, so the concatmovie script is being run and adding a frame each time, the problem is it keeps adding the same frame each time - I can see this as I have the timestamp on the frames! Why this is occuring I am not sure, if I manually run copypic and concatmovie, it works. So my suspicion is still around the other thing thats changes which is the times used as a result of no astro-dark. At present this is corrupting the webpages as the file it is stored in is now in a different format as posted above, I think the " --:-- (Midnight sun) -00:10" stuff is breaking the scripting somewhere (perhaps in the webcam script or the web pages)
  23. Hi Pete, I think it's because at my location we now have no astro dark so when the script runs the Astro rise is "--:--" and this breaks the script (I've not looked in detail as I have some image processing to catch up on so this is just a theory ) Here's the output from webcam: pi@raspberrypi:/home/allsky $ sudo ./webcam raspistill not running N /usr/bin/raspistill -q 100 -ISO auto -co 70 -awb greyworld -n -ex night -ag 9.0 -dg 2.0 -ss 6000000 -w 800 -h 600 -o /run/shm/webcam.jpg E V E N T HH:MM OFFSET --------------------------------------------- ----- ------ Astronomical Rise (18 degrees below horizon): --:-- (Midnight sun) -00:10 Astronomical Rise (Real) : --:-- (Midnight sun) Nautical Rise (12 degrees below horizon) : 02:46 -00:10 Nautical Rise (Real) : 02:56 Civil Rise (6 degrees below horizon) : 03:52 -00:10 Civil Rise (Real) : 04:02 CAMERA switches from Night to Day : 03:54 -00:08 VIDEO switches from Night to Day : 03:59 -00:03 Sunrise (0 degrees below horizon) : 04:45 00:00 Sunrise (Real) : 04:45 Sunset (0 degrees below horizon) : 21:05 00:00 Sunset (Real) : 21:05 Civil Set (6 degrees below horizon) : 21:48 -00:00 Civil Set (Real) : 21:48 CAMERA switches from Day to Night : 21:57 -00:09 VIDEO switches from Day to Night : 22:00 -00:12 Nautical Set (12 degrees below horizon) : 22:54 -00:00 Nautical Set (Real) : 22:54 Astronomical Set (18 degrees below horizon) : --:-- (Midnight sun) -00:00 Astronomical Set (Real) : --:-- (Midnight sun) Sat 30 May 01:51:55 BST 2020 pi@raspberrypi:/home/allsky $ webcam
  24. Thanks - I guess I was expecting less as I think I had less with the DSLR and going for the larger filters, from what I read, would have no effect on the vignetting.
  25. Hi Simon, I asked the supplier, FLO and the advice was "The tension should be 1 to 2mm of movement. When tensioned correctly the drive should be smooth, if you hear any kicky noises it is ether to tight or to loose" I guess it's quite hard to describe what good looks like because that movement depends on how much pressure is applied to the belt to get the deflection. My replacement was a new one from FLO which I paid for - I am not aware of an alternative supplier and I am hoping that this isn't a frequent consumable part once the tension is right Both axis have a very slight wobble on the spindle I hadn't considered swapping them because they came in separate marked bags of components for each axis, so assumed they might be different, I do have an issue still on teh RA axis so might try swapping over to see if the issue changes - I've done what I can in terms of grease and worm mesh on the RA so that might be an avenue to explore.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.