Hi John.
Proposed camera type is also important. Like does it have a remote shutter release, and what is it, mechanical, switch closure or something else. This will determine how you drive it.
That video in Michael’s previous post suggests some sort of standard as that gizmo just seems to plug into an existing socket and just appears to be a tip and sleeve plug. have a look at that link and the included video, very interesting.
Cheers Bob
1 Like
Robert, that device looks pretty good but I wasn’t thinking of using DSLRs. I wanted to use a camera module connected to microprocessor board such as an Arduino or RPi. It might be similar to a trail camera.
I’ll refine the spec so we can get down to selecting hardware.
– two identical devices
– no comms b/w the two devices
– commanded by radio from some command device to take a single shot each
– the two shots to be taken within 100ms of each other
– lag b/w command and shots not important
– each device has a GPS module
– image taken at first PPS pulse from the GPS after receiving command
– images not transmitted but saved to SD card
Anything else?
1 Like
Hi John
Arduino is a microCONTROLLER, RPi is a microPROCESSOR (I think). There is a difference.
There have been several discussions on trail cameras and I think some have had good success with this use. A search and a read would probably be enlightening.
Cheers Bob
Deviating a bit and thinking about the time lapse technique used in an easier link. Have you tried taking a shot with a fairly long shutter time. I have not tried this but I thought the resulting “motion blur” might provide the illusion of movement. Experiment with actual shutter speeds would of course be required.
2 Likes
Both the Arduino and RPi could do the job. I see the RPi as a computer – it has the Linux operating system and I use one as my desktop PC. The RPi has plenty of IO pins.
I bought from Core a RPi Zero W(wireless) and camera module back in lockdown but have never used them. This might be the time to put them to use.
Blurred motion of birds can be great with close up shots. I’ll try it on a flock (probably cockies or galahs).
2 Likes
re gps trigger. This one may or may not be needed.
In theory your radio would be a broadcast, control device to BOTH trigger devices via the one packet/transmission.
If both trigger devises are 100% the same, eg. same radio module same control processor/controller running the same code, then both should be ready to take the photo/trigger at the same time (with in requiements).
That said, if there is a high risk of something else delaying the critical code path (e.g. other OS interrupts, different processors, radio modules) then yes you would need to align somehow.
e.g. I would expect an ATMega (if using a crystal) just waiting for UART input and run the trigger function would be the same each end. An ESP32 can run much faster but RTOS will have overhead, but you could run the critical code on the 2nd CPU. And should still be fairly close.
So alignment is just down to the drift in the end devices and clock accuracy/tolerances; which if the same, should be low.
Keep in mind, you may use the GPS to get a date/time to time stamp the files (if you wanted); at the expense of GPS uart coms and radio comms.
The following is a very quick single trigger test.
There was a 3rd radio that sent the packet, both RX units in the image plots are the same device with the same settings. We can see their IS a small difference of about 0.4 - 0.5 ms between the two sending the command out the serial port (after all radio and decoding). This is well within the 100ms requirement.
2 Likes
The problem with a Pi is timing repeatability. Since it runs an operating system, many processes are running and there is no guarantee of response time. A microprocessor would take a definite (and repeatable) time to process the ‘trigger message’ and operate an output.
Dave
2 Likes
This would certainly be a good project to get that Pi Zero and Camera to use on.
Glad to see this one is becoming more than a thought experiment.
Please share these ones too.
2 Likes
Answering the question about accuracy of 1PPS from GPS modules. Without surveying every module on the market, I’d say all will produce a 1PPS within one microsecond of each other.
If modules are getting good quality GPS signals, then the difference will usually be less than 100ns (nanoseconds). There is a measure called DOP (dilution of precision) that GPS modules report. A higher DOP means less accuracy. If the DOP indicates good accuracy, there is 1PPS jitter to take into account. This is due to the 1PPS being produced by the GPS hardware which has its own internal oscillator, which may not be synchronised to anything. This results in the 1PPS wandering (in low end u-blox modules this is > 20ns). There are GPS modules specifically designed for timing purposes e.g u-blox M8T, which provide more accurate results when in a fixed place. Although the M8T has the jitter problem, it has messages that say what correction to apply to the recieved 1PPS (a few nanoseconds) to get a notionally accurate arrival time. Pay big money for a high end module such as the ZED-F9P (about $200 I believe), it can deliver 1PPS to within 5ns of the correct time.
In the context of the application, pictures taken timed to 1PPS are practically simultaneous, and all the above bumph can be ignored.
3 Likes
Hi All
Something puzzles me.
If John goes down the path of synchronising using the GPS one second pulse he still has to instruct the cameras to “take a frame at the next pulse”. Just how is he going to do this and could not that instruction just be “take a frame”. Saves all the complication of playing around with the GPS.
Also if he were really unlucky the delay could be up to 1 second in which time the bird display could be gone or drastically altered. These birds are quite quick.
Just trying th think in a practical manner here.
Cheers Bob
1 Like
That ignores the possibility that the instruction might reach the two cameras at different times, which is the point of the problem.
There is no reason for the instruction to specify “at the next pulse”. The MCU is quite capable of keeping accurate time within a second, so the instruction can specify a time delay from the previous pulse. The required delay between issuing the instruction and the time at which it is to be executed depends on the maximum difference between setups in time taken to send and receive the instruction, and could well be less than a second.
1 Like
Hi Jeff
Michael’s experiment above showed a possible 0.4 or 0.5mSec
So the smart bits at the camera have to monitor and track every GPS pulse in case they get a signal to take a shot.
Then the birds have to be told to hang around a bit and wait for the cameras to catch up. The bird display can change quite a bit in less than a second.
I would have thought that the idea would be to cut any processing to a minimum and get the fastest possible response. Like send a simple radio signal t the cameras (which has to happen anyway) to trigger whatever it takes to take the shot without undue processing time.
Cheers Bob
A radio setup like that is one solution to the problem. But the problem may need a different solution for a different setup. Other options should be part of the discussion.
Fastest possible response wasn’t the question. The question was about the camera and “…how to trigger them simultaneously?”.
Hi Jeff
John’s original post said he wanted to photograph Starlings during their shows with 2 cameras.
To me that and “fastest possible response” seem to be related. The birds will not wait around.
Cheers Bob
Robert, in a sense the birds do hang around in that they are flying around some central point in space. So they’re not flying across the cameras’ field of view but, with some luck, staying in the field of view. But there’s bound to be unforeseen difficulties. A one second lag between command and shots would be fine.
Hi John
That is OK. What I am getting at is if you are using the GPS 1 sec pulse you have to communicate with the cameras to instruct them to take a shot at the next pulse or whatever. So why not simplify everything and use this signal to actually take the shot. The GPS seems to be an add on complication to my simple mind.
I am a real believer in the KISS principle. Will say no more.
Cheers Bob
At the moment I like Bob’s idea if not adding the complexity of the GPS, the key clause here is if you have one transmitter and two receivers and everything it either the same or could be calibrated to remove any time differences. With two identical cameras and identical receivers connected to identical control units, then things should all be within the 100 ms limit.
That said, the pps does not mean you need to wait for it (that was more just to make it simpler coding) but you can use the PPS to get a more Intune clock on each unit; keeping in mind that it will need some more coding.
A high level PPS sync would be something like this.
-
On PPS low to high trigger a pin with an IRQ (we want to know as soon as we can).
In the IRQ function, PPT_ticks = clock_ticks (what ever units its in) -
Post decode of the GPS time packet, adjust to account for the delay beteen PPS and packet RX and time stamp extraction.
NewTime = gps extrated time + (clock_ticks - PPT_ticks);
where clock_ticks - ppt_ticks is ina support unit = milli seconds. -
Set time to NewTime
i.e. we have used the clock ticks to add in the time between PPS and time decode.
While this still will have some overhead, some can be removed with some calibration based on that controller device.
At this point the clock should be accurate to 1 ms (or very close to it)
So now the transmitter can do something like this.
On button press send “Take picture at now() in ms + radio transmission overhead” to all units.
The rx units can then setup a countdown time.
countdown start = TakePicNow - now() in adjusted to the timer units.
At timer expire, operate shutter.
So if you think about the two options.
-
Send take pic now; if the over head is the same to both units and in both units, it will just take the picture when it gets the command.
-
GPS PPS, more complex, but you can schedule images at the expense of a min delay for the packet to get there, extracted and still be before the scheduled time.
Of course, there would be nothing stopping doing both; its just a matter of defining the commands.
01 - Take image asap (now)
02 - Take image at time-stamp
03 xx yy - Take image every XX seconds for YY images
etc.
Michael, thanks for doing that radio test with the scope. Really helpful.
I liked the idea of using GPS cos I think it would be an interesting programming exercise.
I have a pair of GME radios. Model TX675, 2 watts. Do you think there’d be a simple way to control a device using these?
A bit of a long post, but I wanted to go over some ideas rather then just say yes/no.
Short answer would be their should be a way, but not sure if it would be the best way.
In theory you could automat the PTT (push to talk) and send tones down it, then at the remote end RX that tone. You would be adding some needs to digital to analogue to feed into the “mic”, then at the other end to sample the “speaker” and see what tone it is; most of those sorts of radios have headset ports that could be used. To work out what tone is sent could be more work eg some sort of FTT from the ADC input.
Of course for just a trigger you could just monitor the squelch break open on the DAC pin of the controller; at the risk of someone else doing that as a false trigger; of course using CTCSS/DCS could help reduce that.
There may be some middle bits of ready made hardware to do that for you, or other peoples home made projects you could review; I am sure the Amature radio people will have done that sort of thing.
That said, there are radios already out there designed for digital to digital comms, lora comes to mind here. LoRa is “Long Range” low power for short messages. Most modules have a fairly simply interface SPI/UART. (Note If you are looking at lora, you want the base lora and not loraWAN). That does not mean some loraWAN modules could not be setup to meet your needs, e.g. “Makerverse LoRa-E5 Breakout” is really for loraWAN, but via the AT commands you can set it up for point to point “test mode” that would work. I have tested these with fair line of site to about 3km (and they should go more), and non-line of site i got about 600m.
Key Note: In Aus, I believe lora is restricted to 915Mhz band.
Note: with any radio different things can reduce the real world range.
If your going to use GPS to control the actual trigger, then 2 radios should work, i.e. Master and Slave. But if you want to stand between the two cameras then you will need a trigger and 1 receiver for each camera.
I don’t want to recommended any actual hardware unless I have read enough or have tested myself. I have seen some nice lora + ESP32 premade modules that look like a good option (not tested) So you have the radio and controller in the one premade board, so just need to add the power and Trigger hardware.
If you find some radio hardware that you think looks good, let us know and we can have a deeper look at it. One of my side projects will be to test some ESP32 Lora Modules, so I don’t mind getting some test modules to play with.
This is just some food for thought so have a think about what you want to do, If you want to use your UHF handhelds, first step would be to check out how to trigger a PTT (and tone if not automatic); then run some tests to see if you can do it and get the results your after.
For any project, I would work out the bits you really would like to use (if you have a preference) as that will help short list the other bits you need.
edit/update
I called one of my friends who plays with radios, he is going to send my some similar models and external mics to play with; so I will see what I can find then they get here. Normally PTT is just a switch so that bit sounds easy once we pin out what pin does what.
Just to support @Alan73922 comment, i setup a test to see how far apart the pps was on 2 of the same GPS modules.
UPS Modules : U-blox NEO-6M GPS Module | Core Electronics Australia
the PPS is not on a pin on this unit, rather driving an LED.
While this is just a one off test with these units I saw a PPS difference of 200ns which is even more then Alan was expecting.
So I let the units run for a bit longer and the difference dropped down to 30ns; then later again 4ns. This again shows and supports Alan that there are factors affecting it has he outlined and it can drift/change while in use.
Keep in mind, that for the use in this project that is not going to make much of a difference. (200nS) 0.0002 ms out of 100 ms. I just found it very interesting and wanted to see the difference in these cheap gps modules. So thanks Alan for prompting me to look deeper.
Hi Michael
Yes @Alan73922 comes up with some good solutions and inspirations. Some time ago I was playing with a pulse generator and trying to figure out how to overcome the processing time.
@Alan73922 pointed me in the direction of writing directly to the PWM registers which after some research I managed to do with success. I Intend to post the results soon, not as a project as never got to construct it (I already have a function generator) but just as a subject of interest.
Cheers and thanks @Alan73922 Bob
