Resolved STF-8300M / 2.57 firmware shows extremely high offset/bias levels

Discussion in 'STF Series CCD Cameras' started by funkmeisterfred, Feb 24, 2017.

  1. funkmeisterfred

    funkmeisterfred Standard User

    Joined:
    Aug 12, 2015
    Messages:
    38
    Location:
    St. Louis, MO
    Hello all -

    I recently updated to 2.57 on my STF-8300M during a stretch of poor weather. I was one of those affected by the drifting offset level with ambient temperature in my remote field setup, so was eager to test this update's resolution to the problem and report the results.

    Well... my initial results are not good. In pulling down calibration frames, I've discovered that the data returned from the camera is unusable -- The bias (0.1s) frames have an ADU over 17000! Longer dark cal frames climb from here. This makes long light frame exposures totally impractical as so much of the available range is consumed by this offset.

    I have tested and verified this issue on 3 different computers (one of which is the one I've used in the field all along). All are running the latest drivers per the current driver checker release. The camera was cooled to -15C during these tests.

    EDIT: I will add that I tested acquisition with both CCDOps and Sequence Generator Pro. Results are indifferent.

    Have I missed a driver configuration option somewhere? Misunderstood something? Any other thoughts?

    I finally have some clear skies forecast soon, so I'm hoping this is something easy that I've missed :)

    Best,
    -Rick
     
    Last edited: Feb 24, 2017
  2. Tim

    Tim Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    1,743
    Can you send us a sample bias FITS image to examine?
     
  3. funkmeisterfred

    funkmeisterfred Standard User

    Joined:
    Aug 12, 2015
    Messages:
    38
    Location:
    St. Louis, MO
    Of course - attached.
     

    Attached Files:

  4. Colin Haig

    Colin Haig Staff Member

    Joined:
    Oct 27, 2014
    Messages:
    4,590
    Location:
    Earth
    Rick, just because I'm a curious fellow customer, I had a quick look and see that image came from SGP. SGP had a whole bunch of fixes to it since your version. The latest was posted a couple days ago, version 2.6.0.14, and it might be worth updating to the latest.
    It looks a lot like a bias frame, but instead of being 0.0 seconds, its a really short exposure, with a 17400+ offset ;-) That should still look a lot more like a bias frame as you point out.
    Do you have a bias done with CCDOps or MaxIm as an alternative?
     
  5. funkmeisterfred

    funkmeisterfred Standard User

    Joined:
    Aug 12, 2015
    Messages:
    38
    Location:
    St. Louis, MO
    Hi Colin - Thank you for your message and suggestion!

    I did try CCDOps before posting, and unfortunately had received the same results. As you see, I am using SGP 2.5.1.17, which worked fine before updating the camera firmware and drivers. (I appreciate the notice that 2.6 is now a stable release! I will certainly update since it's now out of beta.)

    The bias frame exposure time is 0.1s because this is the shortest exposure time available on the STF-8300M. (CCDOps and SGP both claim to be able to do 0.09s with it, though the technical datasheet shows 0.1s.) This offset was also present on all dark frames I took, which included 1 minute through 30 minutes with some intervals in between.

    I have tried frames both with and without "Auto Bias Level Correction" enabled in the driver. No difference here.

    As further troubleshooting, I have enabled the overscan regions (200 vertical, 200 horizontal) and am attaching a 0.09s frame result from CCDOps here. (Note that the sensor is at ambient here.) The overscan regions also exhibit the ~17400 shift. The relative differentiation in these regions to the main sensor area is similar to what I have seen prior to the updates, possibly indicating a frame-wide offset may be present.
     

    Attached Files:

  6. funkmeisterfred

    funkmeisterfred Standard User

    Joined:
    Aug 12, 2015
    Messages:
    38
    Location:
    St. Louis, MO
    Hello all -

    I'm curious if this is being actively investigated, if there is something else I can try to resolve this issue, or some other action I should take?

    I tried a variety of different USB cables over the weekend with no discernible differences. I think I'm clean out of ideas at this point.

    Thanks very much for your attention on it. I'm flummoxed.

    Best,
    -Rick
     
  7. Tim

    Tim Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    1,743
    Please try the following:

    1.) Open CCDOps
    2.) Click the "Edit" menu, and select "Preferences...".
    3.) On the "CCDOps Preferences". click the tiny blank button in the top right corner. (Image attached Below)
    4.) Check the "Show Advanced Menu" checkbox, and click "OK".
    5.) In the Main CCDOps menu, there now should be an "Advanced" menu. Plug the camera in and under the "Advanced" menu, select "Set USB Offset".
    6.) Completely cover the camera, and ensure it is dark.
    7.) On the "USB Offset" window, click "Start". When the process successfully completes, click "Write to EEPROM". Then "Done".
    8.) Power cycle the camera to ensure new settings take affect.

    Untitled.jpg
     
  8. funkmeisterfred

    funkmeisterfred Standard User

    Joined:
    Aug 12, 2015
    Messages:
    38
    Location:
    St. Louis, MO
    Thanks Tim! I wondered about the need to re-evaluate the USB offset. I will give this a shot in a few hours and give the results when I have them.

    Do I need to actively cool the sensor when I run this?
     
  9. Tim

    Tim Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    1,743
    You can cool the sensor to -10 if you wish, which is our standard during programming/testing, but I have found it does not make much difference.
     
  10. funkmeisterfred

    funkmeisterfred Standard User

    Joined:
    Aug 12, 2015
    Messages:
    38
    Location:
    St. Louis, MO
    I've performed the USB Offset analysis at -10C and have written EEPROM.

    The results are as follows:

    Img. CCD Offset = 130 in EE for 996 ADU

    I have taken a -10C 0.09s bias with SGP and have attached it here. I'm quite relieved to say things look much more normal now. It appears the ADU is now around 1040 or so -- falling near the range I have seen in the past. I appreciate any review to see that this file looks as expected.

    Before reprogramming the EEPROM with the new offset, I read the current value from CCDOps -- it reported "131". I'm struggling to see how a single incremental change in this offset setting accounts for such a wild change in the offset level... but maybe there's more going on behind the scenes here than I understand.

    For my peace of mind, can anyone comment on why this error may have occurred? To recap, things were fine until I updated the firmware to 2.57 and updated the drivers to the latest. I will note that the firmware update failed, and Bill in repairs restored the unit for me.

    I will be generating some masters tonight, and will report back one more time to confirm things are truly as they seem -- fixed!

    Thanks for the guidance on this issue.
    -Rick
     

    Attached Files:

  11. funkmeisterfred

    funkmeisterfred Standard User

    Joined:
    Aug 12, 2015
    Messages:
    38
    Location:
    St. Louis, MO
    Well, I declared victory too early unfortunately. But I have more information.

    The "Set USB Offset" function clearly worked with my last post. However, when I got everything set up again to run my dark libraries tonight, I have found that the 17400 offset has returned!

    I re-ran the "Set USB Offset" function, and as before, the issue was corrected. On a hunch, I powered down the camera, powered it back up and hooked it up. The 17400 offset returned.

    It does not appear the USB offset is being properly initialized or used at power-up.

    I've checked the Offset value in EEPROM through the advanced configuration menu before re-running the "Set USB Offset" function, and it is 130 as expected and as saved earlier. The EEPROM values look to be correct.

    So, I'm back to unstable camera functionality. Any thoughts?
     
  12. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    7,904
    The symptoms don't make a lot of sense. It may be that there's a hardware problem on the main board. Unless someone else on the team has a brilliant idea, we may have to replace the board.

    Bill Lynch is unfortunately out for a couple of days, but please drop him a line. Contact info: http://diffractionlimited.com/support/technical-support/
     
  13. funkmeisterfred

    funkmeisterfred Standard User

    Joined:
    Aug 12, 2015
    Messages:
    38
    Location:
    St. Louis, MO
    Hi Doug - thank you for your reply!

    I suspected the board as well, until I saw that the EEPROM setting is retained through power up. Everything is operating normally except for this offset. I'm personally suspicious of the new firmware on here, as the changelog specifically notes a change to management of the offset to handle drift -- which is why I updated to begin with :)

    Would it make sense to attempt a downgrade? I will do this with instructions you can provide, if this seems reasonable.

    (You might recall that I'm the one that's had trouble bricking my camera with the firmware process on 2 occasions, but I have a different machine that is ready to use. If we're talking about sending it to Bill anyway, what's the harm in trying I guess?)

    I will add that how this would be processed regarding warranty service is extremely important to me. This will be the third time in just over a year that I'm shipping the camera in -- and the second in a month. I'm sure you can understand my frustration. Is this something I discuss with Bill? I'm happy to discuss with anyone else offline as well.

    Thanks again for your message!

    Best,
    -Rick
     
  14. funkmeisterfred

    funkmeisterfred Standard User

    Joined:
    Aug 12, 2015
    Messages:
    38
    Location:
    St. Louis, MO
    Hello again -

    I've thought about this further this morning. Hopefully you don't mind fielding my troubleshooting thoughts.

    Is it not curious that the difference in expected ADU (17400 ADU with error, to about 1040 ADU without error) is possibly an exact error of 16384... or 0x3FFF hex? The proximity doesn't seem coincidental.

    Thoughts?

    (Also, still curious what anyone thinks on downgrading the firmware.)

    Best,
    -Rick
     
  15. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    7,904
    I'm sorry you've been having trouble; this is very unusual. I don't think this is firmware. We've not made any changes that would cause this behavior, and everyone else's cameras aren't doing this.

    My best guess is a bad solder joint on the A/D converter channel. The FPGA is x-ray inspected so that's unlikely to be at fault. If there is a bad joint, it would be on U34, RA12 or RA13. I'd bet on RA13, because those little resistor packs are more difficult to solder. A visual inspection with a magnifier would confirm. If that's the cause then Bill can easily fix it, once he's back (unfortunately he's off for a few days).
     
  16. funkmeisterfred

    funkmeisterfred Standard User

    Joined:
    Aug 12, 2015
    Messages:
    38
    Location:
    St. Louis, MO
    Thank you again for your message, Doug! I appreciate you sticking with this.

    At the suggestion of another SBIG user, I tried running CCDOps in "admin" mode and resetting the USB offset. Now, I've been able to power cycle several times and get expected bias ADU levels of around 1040 when running my acquisition programs normally.

    I don't know if it's coincidence or not, as your suggestion of a bad solder joint could exhibit randomized behavior. I will give it several field runs and see if the problem ever resurfaces, and will report back here and contact Bill if it does.

    However, I'm hopeful again that we've solved this. What a puzzling situation... but I'm glad I can get back to imaging :)

    Best,
    -Rick
     
  17. funkmeisterfred

    funkmeisterfred Standard User

    Joined:
    Aug 12, 2015
    Messages:
    38
    Location:
    St. Louis, MO
    Hello all -

    Thank you again for everyone's suggestions here.

    After 2 consecutive nights in the field, I'm happy to report that the error appears to be permanently fixed. As a recap, the "Set USB Offset" function needed to be performed in CCDOps to eliminate the high bias ADU, and CCDOps had to be executed in Windows admin mode, as doing so in standard user mode resulted in a state where the camera did not use the calculated offset between power cycles.

    As further background, this is a Windows 10 laptop.

    Happy to be up and running again, and am very happy it wasn't the board.

    Many thanks!
    -Rick
     
  18. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    7,904
    Okay that's great news!
     

Share This Page