I guess the first question is how many discrete commands you want to give? Shoot, zoom in, zoom out, shutdown ?
Let us know if you need a custom build to try this out.
If this gets implemented, the message to the camera would become very small, and it would get buried in a lot of noise... So in order for this to work there should be a way for the camera to disregard the noise (baseline 800us pulses), and only report the signal (1500us and 2200us pulses). I don't know how easy or hard this might be. Do LUA scripts get compiled and then run using native camera code or are they interpreted every time? The answer to that question might determine if the code that detects the signal vs the noise should be implemented in firmware code (fast?) or LUA code (slow if interpreted?), as this code would be executed a lot.
For how long should the pixhawk hardware send the 1500us and 2200us pulses? I believe this will depend on how long it takes the camera to run one loop of the script... If the pixhawk sends the pulse for a very short time and the timing is such that the camera misses reading it, the signal might get lost... On the other hand, if the signal is sent for too long, the camera might take the same action twice...
Has anybody timed the shortest & longest time to run a complete loop? The longest time will probably vary if for example the camera has to write the log to disk, or perform other actions...
Finally, the signal will probably be repeated a few times, I wonder how the camera reads that. If for example it constantly reads for a signal and buffers, and then sends whatever it buffered when the LUA script asks, this whole thing might be difficult to implement... I don't know if I can get the pixhawk hardware send only one 1500us pulse and then revert to 800us.
This can be fairly easily handled in the Lua code. But rather than continue worrying about the various "armchair theories" it would be better to just hook up the camera to a RC receiver and try it. be fairly easily handled in the Lua code.
I'm itching to try this out, unfortunately I won't be able to for at least a month
The high precision pulse counting / measurement code runs in a interrupt service routing written in C. There is a Lua call to allow it to read buffered data from that routine.
Quote from: waterwingz on 20 / April / 2015, 16:00:15The high precision pulse counting / measurement code runs in a interrupt service routing written in C. There is a Lua call to allow it to read buffered data from that routine.Did someone actually test the code with sub-millisecond repetition rate?
As far as I remember, timers are not very accurate when called that often. Also, Naccio mentioned an SD1100, which is a DIGIC III model. The ARM core in DIGIC II and III runs at 36 MHz (DIGIC 4 and 5 is clocked higher, at least 72 MHz). edit: not to mention that CPU load is much higher in shooting mode.
I couldn't find the post but I believe from memory that thing got really shakey down below 500 uSec timer rate.
I already have CHDK installed on my Canon S110, how do I go about adding this script into it and is there a link anywhere on how to do it?
Started by Jim
Completed and Working Scripts
Started by nadavofi
« 1 2 »
Started by Benny_H88
« 1 2 3 »
Started by davefolts
Creative Uses of CHDK
Started by GlobalSurvey
General Help and Assistance on using CHDK stable releases