Pattern sequence questions (and bugs)

Hi Pete Thompson,

Thanks for your inputs.

Item #1 : This is a limitation of LCr. For extended patterns (number of bits > 96 or exposure > 20000ms) only multiples of 20000ms exposure is supported.

Item #2 and Item #3 are LCr Software bugs and will be addressed in the next release.

Item #4: As long as the write response packet is successful the pattern should work correctly. Let me know if you are receiving write response. You can also try "Display This" option to see if it is uploaded correctly.

Regards,

Suresh

Hi Suresh,

Thanks for the answers.  It's good to know that #2 and #3 will be addressed in the next release!  That does bring up a new question... is there a rough ETA of when that release will be?

Other followup questions:

Item #1:  Is there a lookup table of valid exposure values that I can use when designing our application UI that allows the user to choose an exposure value?  Not a huge deal -- I can create one through trial and error as long as I know this table is the same for all bit depths.

Item #4:  I saw a recent post by Divya saying that there's a known issue when uploading more than 4 images... I'm wondering if that's a related issue to this.

More information on #4:

The write response seems to have succeeded after every image sent.  That is, I am not getting any errors.  The source code is largely the same as the packetizer in the demo in the v1.1 package. 

However, despite getting no errors, there are still some images being overlooked when being uploaded.  As a test, I have two sets of patterns -- I uploaded the first set a couple of times and verified they're all intact.  Then I uploaded the second set -- received no errors -- then played through the sequence using Auto.  However, the previous set still shows through in positions 5,6,11,12. 

This has been reproduced using the LightCrafter GUI 3.8 -- it'd take a couple of "Upload All" before the entire set is fully there.  The status bar reads "Command SUCCESS" after both times.  I still had the wrong patterns in a few slots when playing through in Auto mode. 

What's even more curious is if I set the Exposure to 160000 (and trigger period goes up to 162640), then uploading patterns seem to work much better.  I haven't had an issue yet.  When I set the exposure and trigger period back down to 1600 and 1970 respectively, then it becomes more likely to skip some patterns when uploading. 

I should repeat that this is all observed using the GUI and not once did I ever get a "Command FAILED" popup.  It's always a success.

Hello Thompson,

Thank you for providing valuable inputs on the software behavior.

We will look into #4.

About your earlier clarification, it will take atleast until January 2013 to make it publicly available for use.

Regards,

Sanjeev

Thanks Sanjeev.

I just ran into another issue related to #4 that has me honestly confused, and I'm hoping you can help shed light on what's going on here.

Here's the setup:  A "blank" LightCrafter -- no saved solution etc.  Set it to pattern sequence mode, 4 bits, 16 patterns, Auto input trigger, Blue LED, Exposure time 1000000us (1 sec)  (This exposure time is the important part)

Upload 16 4bit patterns using "Upload All".  Make sure the last pattern is something distinctive and easy to identify.  Use "Display This" to confirm the last pattern is at number 15.  Also, start the sequence in Auto mode at 1sec exposure time to confirm that you properly cycle through all 16 patterns.

Stop the sequence.  Set exposure and trigger period to 0 (forcing them to become 1600 and 1970us respectively).

Now use "Display This" on number 15 again.  Nothing appears.  Now use "Display This" on number 11.  The last pattern appears now.  For some reason it's shifted from 15 to 11 because of the exposure time change.

Change exposure time back to 1sec again, and use "Display This" on 15 again.  Now it appears again. 

This has been reproduced on two Lightcrafters, one is a v1 model, the other is a v2 model.

This strongly implies that the exposure time has a major impact on the uploading behaviour.  As mentioned before, the reason why I increased the exposure time to 1sec before uploading was to ensure that all images get uploaded, but it appears that this actually created a worse problem (throwing the number of patterns out of whack). 

Right now, I am unable to find a reliable method of uploading 16 4bit patterns in our software.  I tried sleeping for 1 second in between each image but that still doesn't avoid the occasional empty/blank slots, and I'm still getting a "SUCCESS" return code even when it actually failed.

Ahhhh that explains a lot!  I had no idea that changing the exposure actually changed the pattern memory arrangement!  That answers so many questions.

That also explains the other issue I was having with the missing pattern issue -- I was uploading at 1600us, then playing back in Auto at 1sec to verify that they were all there.  Of course, since this also changed the pattern memory arrangement, it would look like some patterns were missing.

We were changing the exposure to match the camera's exposure so that they stay in sync while doing HDR captures and that's where we started running into trouble.

Hi Thompson,

I have one more detail that might help you that i have not explained in my previous post.

Changing the bit depth always changes the arrangement of patterns in the frame buffer but changing the exposure or pattern count does not always change the pattern arrangement.

Here is the reason :

The LCr uses different pattern arrangements for normal mode and extended pattern mode.

The extended pattern mode is used in cases that normal mode would not work.

Following are the conditions where extended pattern mode is used

    > 96 bits total

   > 20ms exposure

   Used pattern count is not listed in the drop-down menu of GUI

Assuming that pattern count and the bit depth are same the mode change happens only if the exposure changes from < 20ms to >20ms or vice-versa

So you should be able to change the exposure within 20ms or above 20ms without updating all the images (If bit depth and pattern count are same)

Just following up on issue #3... 

I've added a couple of workarounds, but it seems it's still possible for the wrong color to display when switching back to pattern sequence mode, even after stopping and running the sequence again.  So far the only real stable way to make sure "Blue" is actually "Blue" is by setting the solution to "Red", then back to "Blue".  This adds a bit of a delay in our UI which can get annoying after a while. 

Is there a patch coming out soon for this?