Unfortunately, despite my best efforts of having an application with multiple threads and a pulseall to signal those threads to send the putm capture, we're still getting too much delay.
This was the main problem, it was pretty ungraceful. Once I ensured the long running script was shut down after the actual capture, all the crashes and memory problems went away.
That builds and returns a A\DCIM\IMG02___05\IMG000023.jpg path by using os.listdir and the last item in the arrays for the DCIM and the IMG?? folders.Yes it's horrible.I might be able to use the sequencing number get_exp_count and simplify this down, but figuring out what the IMG? bit is will be tricky without a statement like above.
To summarise, I now have 4xA495 and they're all being controlled by a bit of C# software. We're doing our final testing before purchasing the entire batch of 40.
I'm personally quite happy but as the A495 has no manual mode, there's no easy way to set the TV and AV. I tried using proptable and set_prop but I either used the wrong magic numbers (for the values) or it's not implemented in the a495 alpha chdkde firmware i'm using.Most of the time I got an error from the camera.
Quote from: agrath on 04 / May / 2011, 18:36:57Unfortunately, despite my best efforts of having an application with multiple threads and a pulseall to signal those threads to send the putm capture, we're still getting too much delay. A possible problem with using threads is that you have no control over when each thread will actually resume after the "pulseall". Add to that the extra layers of passing a message to ptpcam and then to a script on the camera.Also, unless you have 40 processors that are ready to kick in for each thread, I doubt it's faster than just having a loop messaging each camera sequentially. (Even with 40 processors I wouldn't be sure of it.)Perhaps it is possible to start a script, disconnect and then use the "old" USB trigger. I'm not sure you can programmatically turn power to a USB device on/off, but shouldn't it be possible to supply the power from an external source (though still controlled by the computer)? The camera doesn't need the power supplied via USB, so if USB and the camera allow it, you might even be able to have a PTP session open while switching the power on/off.B.t.w.: as you seem to be using C#, you might be interested to know that I put a (not 100% percent complete) .NET/C# library for CHDK PTP online today. At the moment it expects a special CHDK version, but it is easy to change that to the current "official" version; just don't use the GetLive* functions. You can find it here (should be downloadable without git).
An possible alternate approach to synchronization using PTP:All the cameras have a 10ms ish accuracy tick counter (get_tick_count())You should be able to calibrate these relative to the PC system clock, then set up your scripts to shoot on each camera at a particular tick count that corresponds to the same real time. I'm not sure what sort of accuracy you could get, you'd definitely want to calibrate each camera in turn without a lot of other traffic on the USB.There are a number of sources of uncertainty in the calibration: your program <-> ptpcam, ptp transport, scheduling variations in the PTP and script tasks, scheduling within the final script that takes the shot. Some of these could be reduced if you are willing to hack the CHDK code a bit, but you'd want to characterize them before expending any effort on that.What sort of synchronization accuracy do you require ? Is shot latency critical (e.g someone presses a button and all the cameras fire at that instant, or could you schedule the shot 1 second in advance, as long as all the cameras shoot together)Another option might be CHDK motion detection. You could set the threshold really high so the cameras all go off when they see a flash.Of course long exposure + flash would be the obvious brute force way to do this.
The problem with the usb remote trigger and the eyefi cards to get the photos off are that they don't transfer until the script quits.. and if it does that, I have no way of starting it again without being physically in front of the cameras or a messy usb switching system.Any idea why the photos wouldn't upload until the script quits? the eyefi firmware won't be using the camera CPU so it must be something filesystem/sd card related.
Quote from: agrath on 06 / May / 2011, 22:26:33The problem with the usb remote trigger and the eyefi cards to get the photos off are that they don't transfer until the script quits.. and if it does that, I have no way of starting it again without being physically in front of the cameras or a messy usb switching system.Any idea why the photos wouldn't upload until the script quits? the eyefi firmware won't be using the camera CPU so it must be something filesystem/sd card related. No, I have no idea. That is *very* strange, I'm having difficulty imagining how that would even be possible. CHDK doesn't interact with the canon firmware jpeg writing at all, and a script "running" really shouldn't mean anything to the rest of the firmware. A lua script sitting in a tight loop can hog CPU, which might delay a Canon task I guess. Putting a long sleep() in somewhere would prevent that.It occurs to me eyefi might some heuristic based on how recently the card was accessed, but a running script really shouldn't access the card repeatedly, unless you are using the file io or console log functions. If you are doing something like that, try not doing it
The script doesnt do any IO either, it just waits for a trigger, takes the photo then refocuses (half shutter) until the next shoot perhaps that's it?
Started by pcdude2143 Feature Requests
Started by fvdk « 1 2 ... 34 35 » DryOS Development
Started by ramboestrada Hello, I'm a NEWBIE - HELP!! (Newbies assistance, User Guides and thank you notes)
Started by wa0tjt General Discussion and Assistance
