Anyway, apart from the too large footprint that MOSFET only works with 5V logic and we are using 3.3V. RDS climbs very steeply with VGS under 6V. From the datasheet I would guess it is 6mΩ for 5V.
OK. Thanks. 3.3V - just curious and must have misread Brendan's post on this - thinking 10V, which didn't add up anyway. Can you point me to the data sheet for the device and a brief description of how the gate is being driven and the method of temperature control, if it's not too much trouble.
EDIT: Found it. Just finished reading the entire thread.
Rowland, I have attached the PDF of the design. Look at VT1 and DD5 in the middle of the PDF. Nothing very exciting to see, the ATMega328 is PWM-ing the MOSFET and hence controlling the TEC. The TEC cannot be controlled during the sensor frame read (which takes about 2 seconds) so the TEC can be left on or off during the read. This will affect the sensor temperature a bit.
Gilles, great work on the indi drivers
I will have to try them out when ready.
Patrice, when you were getting horizontal stripes, did they look like in the attached image?
The simple things we learn the hard way...
I was playing with the new Cam86. APT was set to use 2x2 binning with the sensor that still has the Bayer matrix and I kept wondering why I could not get any colour... D'oh
(Image attached, ambient was about 22 degrees C, not cooled Cam86, 112x 60s lights, 5 darks, 20 flats)
The simple things we learn the hard way...
I was playing with the new Cam86. APT was set to use 2x2 binning with the sensor that still has the Bayer matrix and I kept wondering why I could not get any colour... D'oh
(Image attached, ambient was about 22 degrees C, not cooled Cam86, 112x 60s lights, 5 darks, 20 flats)
Thank you. I still want to try debayering the corners of the sensor but just don't feel brave enough to do it
For 2x2 binning the sensor adds the 4 adjacent pixels together into a super-pixel. This means that the RGGB pixels defined by the Bayer matrix get added together and hence the colour information gets lost in the process. Basically I got 1/4 intensity and 1/4 resolution
At least the read noise was 1/4 compared to unbinned image
Excellent point and you are absolutely right. Actually we are probably both right, it all depends what it is being compared. I should have expressed myself better.
On one hand binning reduces the resolution but we get 4x the intensity for each super-pixel as 4 individual pixel get added together, just as you said. The well depth is increased 4x as well and the read noise is 1/4 (am I right about the read noise?).
On the other hand the CFA of the Bayer matrix reduces the intensity of light each pixel sees whencompared to a mono sensor. Red pixel will only see the red light, the blue pixel will only see the blue light and the two green pixels will only see the green light. Note that this is simplification, each "colour" lets a "band" of wavelengths through, see the chart for example here.
Anyway, the point is that each pixel behind CFA will see less light than its equivalent mono pixel. And I had a mono sensor next to me and could have easily swapped to it
How much less light? That depends on a particular CFA for a particular sensor but I guessed that 1/4 of the intensity will go through (compared to a mono sensor without the CFA). We are not doing the usual Bayer interpolation to extract the colour as we are binning the pixels on the sensor.
Ah, I am even managing to confuse myself now... do you see what I mean? Of course I could be wrong with what I said. Especially the factor of 1/4 between the mono and colour sensor is a guess anyway.
Excellent point and you are absolutely right. Actually we are probably both right, it all depends what it is being compared. I should have expressed myself better.(...) Ah, I am even managing to confuse myself now... do you see what I mean? Of course I could be wrong with what I said. Especially the factor of 1/4 between the mono and colour sensor is a guess anyway.
This is exactly where i think all of this is really interesting : This way whe think, we understand, we learn.
None of this happens when you buy a 1000€ camera
I've noticed that these bands appears when there is a problem with usb bandwidth or something like that :
with my driver, i can adjust timings and baudrates, and with "some" parameters they appear, with "others" they disappear.
Just my 2 cents...
I did some more investigation of the horizontal lines and really could not figure out what is causing it. My guess is that the FTDI chip is not buffering the frame data but passing it straight to the PC and the data gets lost in this transfer.
My results:
Laptop 1 (win7) consistently shows them (one in 10-20 images).
Laptop 2 (win10) never does. This one has USB3 but the cam86 is USB2 so it should not make a difference, unless the problem is caused by the chipset/drivers itself.
The CPU load does not seem to affect anything.
Gilles, which operating system are you using with your Indi drivers? I didn't get a chance to try them out on my main PC (linux) yet, have to figure out how to use Indi first
Pat, which operating system were you using with your old computer (that was showing lines) and which one are you using now (computer not showing lines).
I(...)
My results:
Laptop 1 (win7) consistently shows them (one in 10-20 images).
Laptop 2 (win10) never does. This one has USB3 but the cam86 is USB2 so it should not make a difference, unless the problem is caused by the chipset/drivers itself.
The CPU load does not seem to affect anything.
Gilles, which operating system are you using with your Indi drivers? I didn't get a chance to try them out on my main PC (linux) yet, have to figure out how to use Indi first
Pat, which operating system were you using with your old computer (that was showing lines) and which one are you using now (computer not showing lines).
May i suggest you to check if your laptops ar using different versions of D2XX libraries ?
For sure, FT2232 doesn't buffer anything, it sends data with the rythm given by the atmega. It's the driver's job to catch data.
My driver is running on Odroid XU4 for the server side, and kstars runs as a client either on windows 7 PC ( YES : kstars/ekos for windows !!!), or 2 or 3 classical Ubuntu distros (better with lastest 16.10 as indi is moving very fast).
Will soon try on Raspbery pi 3 as server, freshly arrived under christmas tree.
I added yesterday to my driver the ability to play with different baudrates for the 2 channels of FT2232, just to see...
If you need help to try, do not hesitate !
Gilles, I tried compiling the driver without much luck. cmake complains about missing libftdi1 config files:
Quote:
Could not find a package configuration file provided by "LibFTDI1" with any
of the following names:
LibFTDI1Config.cmake
libftdi1-config.cmake
Add the installation prefix of "LibFTDI1" to CMAKE_PREFIX_PATH or set "LibFTDI1_DIR" to a directory containing one of the above files. If "LibFTDI1" provides a separate development package or SDK, be sure it has been installed.
Any hints? Using debian stable. I have all the ftdi packages installed (libftdi-dev, libftd1, libftdipp-dev, libftdipp1) that I think are of relevance. I have also updated those packages from the latest debian unstable without any success.
I have noticed that LibFTDI1Config.cmake is not in the folder cmake_modules. Should it be there? I tried downloading LibFTDI1Config.cmake from the libftdi source and the error message was identical.
Gilles, I tried compiling the driver without much luck. cmake complains about missing libftdi1 config files:
Any hints? Using debian stable. I have all the ftdi packages installed (libftdi-dev, libftd1, libftdipp-dev, libftdipp1) that I think are of relevance. I have also updated those packages from the latest debian unstable without any success.
I have noticed that LibFTDI1Config.cmake is not in the folder cmake_modules. Should it be there? I tried downloading LibFTDI1Config.cmake from the libftdi source and the error message was identical.
Thanks
Luka
Did you try to build and install libftdi directly from Intra2net ?
(i don't remember, but i think it's the way i've done) http://developer.intra2net.com/git/?p=libftdi;a=summary
This way i think necessary .cmake files should be installed properly on your system...
Installed cmake from Intra2Net and got cmake to work. Thanks for the tip. Interesting how the packaged libraries do not work.
However, now I get compilation errors which I traced to the old version of indi that comes with Debian stable. And installing indi packages from unstable will break half of the system. I think I will need to compile indi... probably tomorrow, it is time for now.
Installed cmake from Intra2Net and got cmake to work. Thanks for the tip. Interesting how the packaged libraries do not work.
However, now I get compilation errors which I traced to the old version of indi that comes with Debian stable. And installing indi packages from unstable will break half of the system. I think I will need to compile indi... probably tomorrow, it is time for now.
Thanks for your help.
Have a good night
Another idea : if your purpose is to play with baudrates, you can try to build the library your self, with delphi, and tweak with baudrates.
i'm about to do it, just to understand ...well .. how it works !