#541  
Old 29-01-2017, 10:38 PM
gehelem (Gilles)
Registered User

gehelem is offline
 
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
I asked Rome (aka Grim) before to publish anything :
He asked 2 things : code must remain free, and we must keep his name
That's why i published mine under gpl 2.1 (i think i have to because of libftdi)
I'll ask Rome if we can do the same with his firmware
Reply With Quote
  #542  
Old 29-01-2017, 11:11 PM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,136
Excellent idea Gilles.
Can you please ask him about the firmware, the Ascom driver and the viewer software... at least two people are involved in the software.
Reply With Quote
  #543  
Old 30-01-2017, 05:35 AM
gehelem (Gilles)
Registered User

gehelem is offline
 
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
Quote:
Originally Posted by luka View Post
Excellent idea Gilles.
Can you please ask him about the firmware, the Ascom driver and the viewer software... at least two people are involved in the software.
I've just asked on Ukrainian forum.
Rome is the only one : Sergiey Vakulenko told me he is "only" the author of Ascom driver. Nevertheless, he is already in the author file on my github.

Regarding your tests : did you flash your cam with new firmware ?
i've not ported everything ATM : i've just changed things I though the most important, especially the place of "Spi_comm(0xcb,0)//clear frame"
I must check everything else (role of CameraReadingTime for example)
There's also a rework around temperature reading, my version gives silly readings now...

BTW, I found a lost treasure : the box where I had stored my collection of Raspberry Pi
So now i can test B, B+, 2B, 3B
Wich one is yours ?
I'll test tonight on RP3

Gilles.

Last edited by gehelem; 30-01-2017 at 05:58 AM. Reason: correction of RPi references
Reply With Quote
  #544  
Old 30-01-2017, 06:25 AM
gehelem (Gilles)
Registered User

gehelem is offline
 
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
Raspberry pi 3 is giving good results.

But let me explain the way i play, as it might explain differences :
My RP3 (or Odroid xu4) is running headless.
I launch indiserver trough ssh.
Then, my kstars session runs either on big ubuntu PC (intel i5) or an old Windows Seven. I connect to distant RP3/Odroid indi server (especially this is awesome !)
Yes, there is a windows version of kstars, that suports distant connections.
This way, for 24h, I never get blocks neither lines.

I get blocks and lines when I open a full RDP session to RP3, and run kstars on it. (same on Odroid, but less often)
But we know that : CPU/ressources load is the issue, am I right ?

Gilles
Reply With Quote
  #545  
Old 30-01-2017, 01:48 PM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,136
Hi Gilles,

I did not flash the new firmware, I completely forgot about it. Well that is not quite right, I did some tests with it initially and then I flashed back version 1 and forgot about it.

A question, which firmware did you use? The latest firmware called cam86 prob3.hex did not work for me, its uncompressed size (18kB) is much smaller than the earlier firmwares which were about 75kB. I downloaded it several times and it was always the same.

My Beaglebone Black (BBB) setup is similar to yours, running headless. Kstars runs on my PC (debian). The lines that I was getting was all on my PC, I did not test the BBB recently but after you mentioned the firmware I will need to test with the new firmware.

Also I did more work on the synchronous/streaming data transfer and gave up on it. It will never work with our current hardware. The high speed transfer is clocked at 60MHz which our ATMega cannot do. Also the wiring for the control of synchronous transfer is not connected (pin27 TXE#) so we are out of luck. It is a dead end unless we change the hardware.

Great find of your RPi collection . I have quite a few as well, 2x RPi B (unused), 2x 2B and 2x 3B but the last 4 are all used. I can always take one down for testing but I thought I will try with a BBB first as it was unused and faster than the original RPi B.

Luka
Reply With Quote
  #546  
Old 30-01-2017, 02:23 PM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,136
Tried firmware "cam86 prob2" on my main PC, I still get occasional line but no blocks any more. This is a relatively fast machine with i5-4590 CPU.
Reply With Quote
  #547  
Old 30-01-2017, 11:38 PM
N_DD
Registered User

N_DD is offline
 
Join Date: Oct 2016
Posts: 33
Hi!
first post here: I was following the cam84 thread on cloudynights and on the Ukrainian forum and eventually built a cam84 and a cam86 (and already have a chip for building a cam90 once it will be published! ).
Now I somehow got lost with the firmware versions (I am still using the original one for my cam86) but with it my camera is exposing even when it should not: I am getting around this by acquiring and discarding a short exposure before starting a long sub, but I think this could be addressed at the firmware level (or has it already?!). Which firmware is the most up to date/best?!

Thanks for keeping this project alive and CS,

Nico
Reply With Quote
  #548  
Old 31-01-2017, 12:51 AM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,136
Hi Nico,

There were several versions of Cam86 firmware.
1. Initial release (cooler off during frame reading)

2. The same as 1 but with cooler on during frame reading

3. cam86_firmware_prob2
"Add at the end of each line read adjustable delay. Delay increases the reading time frame for 2 seconds later."
This version came with a new cam86_view software that has a slider for adjustable delay.

4. cam86_firmware_prob3:
"The delay in each pixel. Casting Time of 3.8 seconds."

Firmwares 3 and 4 have been released as some people had horizontal and vertical lines in their images. The adjustable delays fixed problems for some.

I was unable to use the firmware 4. The downloaded firmware file was much smaller than the other firmwares and did not work at all after flashing.

Regarding camera capturing light when not exposing, this is something all? sensors do. If I remember correctly what Grim explained once, the charge accumulates in the sensor at all times. The firmware does some cleaning before exposure but this does not work completely. The only way to fully clean the sensor is to do a short bias exposure before a real frame, just like you are doing.
Another example of this is that we can see light signal in 0ms exposures.

This can be best fixed in the ASCOM driver and not in the firmware. There was some talk about this being done but I have not seen any ASCOM driver releases since the initial one.

I will have a look at the ASCOM driver...

Luka
Reply With Quote
  #549  
Old 31-01-2017, 01:20 AM
N_DD
Registered User

N_DD is offline
 
Join Date: Oct 2016
Posts: 33
Thanks Luka!

I am not getting any broken images, and the cooling off during download is also ok for now, so I think I will stick to my firmware. It would be great to have a modified ASCOM driver to address the charge accumulation: how do the commercial cameras deal with this problem?

Nico
Reply With Quote
  #550  
Old 31-01-2017, 02:27 AM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,136
Hi Nico,
I don't know how the commercial cameras deal with the charge accumulation as I never had a commercial camera before (just DSLRs). Anyone else?

Modification of the ASCOM code seems simple enough, just not sure what is the best way to do it. See the quoted Grim's post below, he suggests to do a bias before shooting if there is more than 30 seconds between the shots. Would this be OK? I can probably add an adjustable gap instead of fixed 30 seconds between images to trigger the bias-before-imaging.

Note that doing a bias shot before exposure would add 2 seconds reading time to each shoot (probably shorter if 2x2 binning is used for the bias?).

I am curious, which imaging software are you using now? How do you do a short exposure before a real one?

Here are translations of Grim's old posts from the Ukrainian forums describing what is happening:
Post 2030:
Quote:
This occurs for the following reason. When any simple charge accumulates in the sensor.
The firmware provides cleansing it in the formation of the frame pulse SUB. The method works, but not completely. We need to do a single frame preview frame "empty" before shooting. then it is becoming normal. This also applies to other versions of the cameras.
It seems that along with vakula be able to solve the problem.
Post 2064:
Quote:
This trouble can be overcome in a soft-ASCOM driver, ie, in the case of chamber idle (say more than 30 seconds) to automatically take Bias before exposure. But it is already in the track. version.
Luka
Reply With Quote
  #551  
Old 31-01-2017, 02:47 AM
gehelem (Gilles)
Registered User

gehelem is offline
 
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
I think commercial cameras use hidden pixels on each row to evaluate the charge...
Reply With Quote
  #552  
Old 31-01-2017, 03:00 AM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,136
Now that is very interesting information Gilles. Our sensor is 3008 2000 pixels and we are using "only" 3000 x 2000 pixels so there would be 8 unused pixels in each row. This could potentially be used to evaluate the accumulated charge but would require modifications to firmware and drivers.

But is this approach really useful for astro-imaging considering that our image consists of areas of extreme contrast (stars vs background). For example, if there are no stars in the hidden pixels the evaluated accumulated charge would be zero there... but there may be very bright areas in the rest of the images from star light.
Reply With Quote
  #553  
Old 31-01-2017, 07:24 AM
N_DD
Registered User

N_DD is offline
 
Join Date: Oct 2016
Posts: 33
Hi Luka,

Quote:
Originally Posted by luka View Post
I am curious, which imaging software are you using now? How do you do a short exposure before a real one?
I am using APT (www.ideiki.com) and setting up an imaging plan with a short (0.1 s) exposure followed by the actual long exposure. I am dithering every 2 frames, so that the long exposure starts immediately after the short one.
Thirty seconds sounds ok: exposing this value in the ASCOM driver would also be great! Another approach would be to acquire a bias if the requested exposure is longer than say 10 s: in this way, longer sub will be "clean", while shorter ones (presumably acquired either for "live view" or for focussing) will still download faster.
I was wondering wether it is really necessary to download the bias frame: would it be possible to simply apply the vertical clock to the sensor and dump the result? Kind of a 2000x bin! Or what am I saying makes no sense?!

Nico
Reply With Quote
  #554  
Old 31-01-2017, 09:33 PM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,136
Working on the ASCOM driver now, may even have something later tonight.

Nico, I am not sure how the sensor works and what can be done. We will probably have to experiment to get things working as good as possible.

Gilles, did you manage to use the firmware cam86_firmware_prob3 or did it fail to flash for you as well?
Reply With Quote
  #555  
Old 31-01-2017, 09:44 PM
gehelem (Gilles)
Registered User

gehelem is offline
 
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
Quote:
Originally Posted by luka View Post

Gilles, did you manage to use the firmware cam86_firmware_prob3 or did it fail to flash for you as well?
No I had the same problem (suspect file size)
I didn't went further
Reply With Quote
  #556  
Old 01-02-2017, 02:25 AM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,136
Did lots of changes to the ASCOM driver but it is not finished yet and there are still few bugs to sort out. Debugging dlls running from dlls running from ASCOM is a pain.

I have started adding options to:
1. adjust reading time like in the latest cam86_viewer (done)
2. adjust time for taking bias before exposure to clear accumulated charge (done but untested)
3. have option to chose between TEC on or TEC off during reading
4. option to switch between mono/colour sensor (not sure if any software uses this information).
5. store options between sessions (it seems to be in the code but it is not working)

Nico, when I tried to test the new driver I could not get the cam86 to show effects of charge accumulation while not exposing. I could not see it either with the original driver/firmware. Can you describe how to replicate the issue?
Reply With Quote
  #557  
Old 01-02-2017, 02:26 AM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,136
Gilles, which OS are you running on your RasPi3? I want to replicate your setup and try it out.
Reply With Quote
  #558  
Old 01-02-2017, 02:31 AM
gehelem (Gilles)
Registered User

gehelem is offline
 
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
Quote:
Originally Posted by luka View Post
Gilles, which OS are you running on your RasPi3? I want to replicate your setup and try it out.
Ubuntu Mate 16.04
Reply With Quote
  #559  
Old 01-02-2017, 03:42 AM
pat30 (Patrice)
Registered User

pat30 is offline
 
Join Date: Oct 2016
Location: France
Posts: 119
Super luka for the modifications of the ascom driver especially the 1.
If you want to try the firmware Prob3 here is the link of my drive or you can download it, this firmware does not work with APT just with Camview-prob
Reply With Quote
  #560  
Old 01-02-2017, 06:44 AM
N_DD
Registered User

N_DD is offline
 
Join Date: Oct 2016
Posts: 33
Luka, that's great, thanks a lot!

Quote:
Originally Posted by luka View Post
Nico, when I tried to test the new driver I could not get the cam86 to show effects of charge accumulation while not exposing. I could not see it either with the original driver/firmware. Can you describe how to replicate the issue?
In my case it is pretty obvious: I leave the camera illuminated without exposing, then I take two consecutive exposures of same duration. The first one has much more signal than the second.
Tomorrow I will check the SUB signal of my board, just to be sure that I don't have any hardware problem.

Nico
Reply With Quote
Reply

Bookmarks

Thread Tools
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +10. The time is now 10:52 AM.

Powered by vBulletin Version 3.8.7 | Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Advertisement
Astromechanics
Advertisement
Bintel
Advertisement
Lunatico Astronomical
Advertisement
Testar
Advertisement
Astronomy and Electronics Centre
Advertisement