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.

stargazine_ep29_banner.thumb.jpg.da7f3b163f7bd35187cb558b0346baf6.jpg

gdheib0430

Xbox Livecam Mod (Cliff)

Recommended Posts

No fundamental reason why it shouldn't, though it's possible you may not get enough inwards travel with the focuser to bring the camera to focus. If that happens then adding a barlow may well help.

James

Share this post


Link to post
Share on other sites
Just finished my mod. Took apart a rubbish eyepiece and glued it on. Tape's a bit shabby but you can't have it all :)

Just need a cloud filter now :confused:

AqtFbMcCIAEDtIv.jpg

Thats good idea use tube from old eye piece.

you will have to add some images.

Share this post


Link to post
Share on other sites

Also can i ask if you need an IR filter can you not just leave the original one in place - sorry I just got mine and want to do it but dont have the first clue as to how.

Any advice greatly appreciated.

Jay.

Share this post


Link to post
Share on other sites

By all means leave the existing one in place if you wish. However, a "proper" IR filter will be much higher quality and do a better job. There may also be times when you actually want to do some imaging without any filtering.

James

Share this post


Link to post
Share on other sites

Ah okay. So its a matter of quality. I wondered if the little IR original was not right or in the wrong place, but i caqn use it until i get a better one? Which is best for lunar type images IR or no IR?

Thanks jamesf.

Great thread by the way, just got my livecam today. Looking to mod it over the next day or so, first time so bit apprehensive. But cheers for your help.

JAY

Share this post


Link to post
Share on other sites

I'd say you definitely want an IR filter in place for lunar imaging.

James

Share this post


Link to post
Share on other sites

cheers, if i keep the IR filter will i still need to cut the white nosepiece-tubing at the front to fit a spc900nc adapter or can i fit the 1.25 eyepiece direct (centrally) over the open hole as is?

sorry, i missed out the middle of the thread and lost my place, many of my ideas will seem uninformed :)

But thank you..

Share this post


Link to post
Share on other sites

Thanks cliff, I want to do astro imaging hopefully moon and planets. My question was whether i really need the spc900nc adapter (10quid) to attach to a scope or just a 1.25 eyepiece tube placed direct onto the front. I guess the adapter is used for the thread that fits the cam which then goes into focuser?

I have been reading some of the other posts on here and you really do have a great thread here, great ideas.

Cheers bud,

J

Share this post


Link to post
Share on other sites

James does that software your working on does that keep highest exposure

example like my image below

I wish exposure wud stay this level example from flicking through 0 and -1 once it gets very long exposure for second so but some how doesnt stay ? goes back to normal exposure still picks stars up like from normal -1 exposure.

stargazing_cliff-albums-cam-modifications-picture17030-test-image.jpg

that what i get when i flick from 0 to -1 quickly using windows

i wish that highest exposure wud stay :) i managed to take quick screen capture of it.

Old skool with my classic windows look.

i wud like to use some software that use it's full maximum exposure.

Edited by Stargazing_Cliff

Share this post


Link to post
Share on other sites
Thanks cliff, I want to do astro imaging hopefully moon and planets. My question was whether i really need the spc900nc adapter (10quid) to attach to a scope or just a 1.25 eyepiece tube placed direct onto the front. I guess the adapter is used for the thread that fits the cam which then goes into focuser?

The SPC900 adapter screws into the lens mount inside the camera and fits into the focuser on the telescope. There's no need to use it if you can bodge something together onto the front of the camera housing that will fit nicely into the focuser tube and keep the sensor centered and square in the focuser (both of these are important, otherwise you may never get an image on the sensor, or you might be able to get one side of the image in focus but not the other). The adapter just makes that easy.

As to whether you'd need to cut down the nosepiece if you didn't have the adapter, I'm really not sure. You might find that if you don't you get some vignetting on the images (increasing darkening of the image away from the centre), though I'm not totally convinced that you will because the light cone is so narrow at that point.

However, you really do need to take off the front of the camera, firstly to be able to remove the lens and secondly to kill the LEDs which definitely bleed into the image. Having taken it off, it's no more than five minutes work with a junior hacksaw and a bit of sandpaper to shorten the original lens housing to half its length, though it does help if you have the intended nosepiece handy to make sure it will fit through the hole :)

If you're not using the SPC900 nosepiece then I'd paint the inside of the lens housing matt black to help eliminate internal reflections.

James

Share this post


Link to post
Share on other sites
James does that software your working on does that keep highest exposure

example like my image below

I wish exposure wud stay this level example from flicking through 0 and -1 once it gets very long exposure for second so but some how doesnt stay ? goes back to normal exposure still picks stars up like from normal -1 exposure.

I assume that's Venus bang in the middle of the image there? I think all the other bright spots are hot pixels?

The whole exposure setup with the Xbox camera is somewhat strange. I don't understand what all the negative numbers are about when your capture program (or SharpCap -- it does the same) display the exposure range. I assume that's some sort of mapping the windows driver does internally. When the Linux driver requests the camera configuration data on initialisation, the camera reports that it accepts exposure settings from 0 to 4294967295 (0xffffffff hex) in steps of 1. Unfortunately the driver only can only store a range of -2147483648 to 2147483647. That leads to a few problems and is one of the reasons I had to hack the driver code to get the camera to work.

Anyhow, once modified to bring the exposure settings into a usable range, I discovered that exposures seem to work in overlapping ranges of 32. So, up to 31, the exposure gets longer, but 32 is shorter than 31 and 33 through 63 give progressively longer exposures, but 64 is a bit shorter than 63 and so on. 0 seems to be a special case which is brighter than 1. The camera doesn't seem to care what value I set, but but the time I get to about 65535 in daylight the image is near fully overexposed (ie. almost all pixel values are full on). I need to do some experimentation to find out what the realistic maximum is in dark conditions.

Anyhow, the code I've written allows you to set the exposure to any valid value and it should stay there for the duration of the capture session. What might still affect the image is that there seems to be some noise relating to the camera getting warm. For example if I take a sequence of 30 images ten seconds apart, each one has more noise than the previous one. In darkness, the average pixel value of the last image may be as much as three times that of the first image. I'll see if I can grab some frames for comparison this evening.

I have thought about adding a feature to allow the capture program to attempt to "normalise" the image by stepping down the exposure if the average pixel value is over a given threshold, but that's for another time...

James

Share this post


Link to post
Share on other sites

I've done a bit more experimentation this lunchtime. I've provided the driver with two buffers to fill with image data from the camera. The documentation suggests that if my code waits until the driver tells me a buffer is full and let's me reads, each time I'll get whichever buffer has the next frame. Assuming this is true I've started timing how long it takes for a buffer to become ready to read. It would appear that the exposure value actually works out as (relatively near to) the exposure time in units of 100usec. That is, if I set the exposure setting to 5000, I get a 500,000usec or half-second exposure. If I set it to 20000 then I get a two second exposure, though the timing appears to be getting a bit vague after that. I can get a steady response time of 2.5 seconds with a setting of 25000, but 25001 jumps to 3.3sec and by the time I've got to 35000 we're at a five second exposure. Beyond that it doesn't seem to matter what I do, I still get a maximum exposure of five seconds.

I can't really tell much during the day because at those kind of exposure periods the resulting image is completely white, but it looks potentially promising from the point of view of picking up star images. As soon as there's something in the sky to look at besides rain, I'll give it a whirl.

James

Share this post


Link to post
Share on other sites

That is some serious programming there for the webcam settings, dont really follow it all but enough to be quite impressed! Eventually you'll end up with a five buck webcam taking astro-pics worthy of a quality bit of kit! and thanks for the advice on the nose-piece, i will be aiming for a better built webcam, its partly impatience to get it in the scope and try it and partly wanting to understand how/why those bits are used together.

As i said, very impressive (this whole thread) keep up the good work dudes.

Jay

:)

Edited by Aenima

Share this post


Link to post
Share on other sites

Posted by mistake

Edited by Gina

Share this post


Link to post
Share on other sites

James I know what you mean about weather same here supposed to get thunder ahh try take some thunder lightening images i will try on night time cloud scanning

will look forward to trying out your software sometime :)

Share this post


Link to post
Share on other sites

Well, I just saw a gap between the clouds and went for it. Before they closed in again I managed to get a sequence of thirty five-second exposures with one camera that had the IR filter removed, and the same again with an IR-filtered camera. Both had the standard lens fitted. Here are the first and last images from the IR-sensitive camera:

ircam-1.jpgircam-2.jpg

Part of Ursa Major is clearly visible there, but unfortunately also clear is the increase in noise over three minutes worth of captures.

Here's the first image from the non-IR camera:

stdcam-1.jpg

There are still some stars there, but you need a big histogram stretch to find them easily.

I used the same capture settings for all the images: five-second exposure, zero gain, minimum gamma. I forgot to set the white balance, which is irritating.

I had the front cover off the second camera and it showed nowhere near as much noise build-up over the same period of time as the first. More experimentation is clearly required there, but it does rather look like the camera may benefit from some cooling.

Unfortunately by the time I'd got the wide-angle lens into the IR camera the cloud had piled in again and the moment was lost...

James

Share this post


Link to post
Share on other sites
I assume that's Venus bang in the middle of the image there? I think all the other bright spots are hot pixels?

The whole exposure setup with the Xbox camera is somewhat strange. I don't understand what all the negative numbers are about when your capture program (or SharpCap -- it does the same) display the exposure range. I assume that's some sort of mapping the windows driver does internally. When the Linux driver requests the camera configuration data on initialisation, the camera reports that it accepts exposure settings from 0 to 4294967295 (0xffffffff hex) in steps of 1. Unfortunately the driver only can only store a range of -2147483648 to 2147483647. That leads to a few problems and is one of the reasons I had to hack the driver code to get the camera to work.

Anyhow, once modified to bring the exposure settings into a usable range, I discovered that exposures seem to work in overlapping ranges of 32. So, up to 31, the exposure gets longer, but 32 is shorter than 31 and 33 through 63 give progressively longer exposures, but 64 is a bit shorter than 63 and so on. 0 seems to be a special case which is brighter than 1. The camera doesn't seem to care what value I set, but but the time I get to about 65535 in daylight the image is near fully overexposed (ie. almost all pixel values are full on). I need to do some experimentation to find out what the realistic maximum is in dark conditions.

Anyhow, the code I've written allows you to set the exposure to any valid value and it should stay there for the duration of the capture session. What might still affect the image is that there seems to be some noise relating to the camera getting warm. For example if I take a sequence of 30 images ten seconds apart, each one has more noise than the previous one. In darkness, the average pixel value of the last image may be as much as three times that of the first image. I'll see if I can grab some frames for comparison this evening.

I have thought about adding a feature to allow the capture program to attempt to "normalise" the image by stepping down the exposure if the average pixel value is over a given threshold, but that's for another time...

James

Looks to me like the camera is reporting values as unsigned int & the driver is using signed int, so should just be a matter of adjusting output values in your code? exposure values -> bit flipping?

mind you, it must be 20 years since I coded for money so I could be talkiing out of my a*se :)

Share this post


Link to post
Share on other sites
Looks to me like the camera is reporting values as unsigned int & the driver is using signed int, so should just be a matter of adjusting output values in your code? exposure values -> bit flipping?

mind you, it must be 20 years since I coded for money so I could be talkiing out of my a*se :)

The definition of that data structure is generic and applies to every single video device supported on Linux however, so I can't really go fiddling with it without the potential for breaking something else. As most of the range offered by the Xbox cam is useless I just trimmed it down inside the driver using a method intended for handling camera "quirks". It was the simplest way to "fix" things by some margin.

James

Share this post


Link to post
Share on other sites

Finally finished my mod, took a bit longer than I'd hoped because of work and waiting for shipping.

sent from Gherkin Muncher mk .III (commonly known as a Galaxy S2)

Share this post


Link to post
Share on other sites

Argh! Didn't upload the pictures will have to do it later from the laptop. :)

sent from Gherkin Muncher mk .III (commonly known as a Galaxy S2)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

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