What radio to use for a project

Status
Not open for further replies.
MichaelMeissner

MichaelMeissner

Senior Member+
Now, I have several projects in various states of assembly/disassembly, and I really don't need another one, but in perusing the digital camera groups, I came up with another project.

For digital photography, I use Olympus and Panasonic micro 4/3rds cameras. The micro 4/3rds cameras, while popular, don't have the market penetration that Nikon, Canon, and Sony have, so you don't get as many third party developers adding specific products for the market.

In particular, Olympus/Panasonic offer wireless flash systems that rely on light pulses from the master controller (typically the built-in or clip-on flash on the camera) to send control signals to the remote flashes (flashes can be in up to 4 groups, and from the camera, you can control each of the groups to adjust amount of light, etc.). It is a TTL (through the lens) system, where the camera first tells the flashes to do a pre-flash, it records the light, and then calculates the amount/duration of the flash for real when the picture is taken. There is no feedback from the flashes back to the camera, the communication is all one way.

While the system works, there are some drawbacks: 1) it doesn't work well outdoors since the sun overpowers the light from the camera, and the flashes can't determine that a flash pulse occurred; 2) the system only works if the flashes can see the pulses from the camera, so you need line of sight; 3) there are distance thresholds as well.

There was a third party vendor (aoktec.com) that offered a system where you had a transmitter clip on to the camera's flash, and it would convert the pulses to radio waves, and each of the receivers would position a LED over the flash sensor, and convert the radio waves back to visible light. However, the company has abruptly removed the products from being sold without an explanation. It could be the remote flashes just didn't sell well, or perhaps they didn't have the necessary permits for commercial operation, or perhaps they got threatened for patent infringement.

In any case, it seems like a simple project, put one Teensy LC (or other microprocessor) with a light sensor over the flash (and make a hood, so the sensor only sees the flash), and have it communicate to the remote microprocessors over radio waves, and have them convert the pulses back into visible light. You only need a byte of data (plus address bytes for packetized radio), but it needs to be fairly low latency to send the bytes in real time. And the radio system needs to be 1 to many.

I tend to think wifi is too much overhead for this system. Bluetooth classic is only 1-to-1 communication, and BLE tends to be expensive. It would go several meters, but it doesn't need extreme distances. It does need to be non-line of sight, but it doesn't need to go through thick walls. nRF24L01+ might be a possibility -- I bought several of these some time ago, but I haven't used them. I see Adafruit having RFM96W and LORA radios for their feather systems, and these might work as well if they can do the 1-to-many transmission.

In terms of radio regulations, etc. I live in the USA. I plan to do this as a personal project. While I would put the source online, I don't see making a product of it.

Any thoughts on what radio system to use?
 
Last edited:
Sounds like a fun project.

Hopefully some of many people up here who know a lot more will have more information and suggestions.

It might be interesting to see how fast a a flash sync you need and which of the wireless modules will satisfy it.

Right now I am playing with LoRa (RFM95) USA modules, using Radiohead and currently one to one using RHDatagram and maybe going to RHReliableDatagram)

One to many...

It would be pretty easy to hack up a couple of programs to try it out. To start off with you could have your master one simply do a broadcast message to all of the slaves and see if that is fast enough. Might try out a few different types of radios to see which ones have the least delay.

You could then refine it (example RHDatagram) where you set all of the remotes to the same address, then when the master does a send all of the configured remotes should receive it... But this is using unreliable communications. If you wanted more bidirectional support you could give each slave a different address and maybe have them talk to master and register their address, then the master could send a series of messages, but I would wonder if the delays might be an issue...

Again sounds like fun!
 
LoRa sacrifices data rate for range. Semtech has a calculator where you can enter various factors such as bandwith, spreading factor, & payload size and determine the total air time for your packet. BTW: all these things are configurable with the Radiohead library.

Here's a link to where you can download the calculator:

http://m.semtech.com/apps/product.php?ct=38&pn=SX1276

Scroll down to the "Tools and Software" section and follow the "LoRa Calculator" link.

I ran the calculator with highest bandwith and low spreading factor, and a payload size of 1 byte. The Time on air was 11.9 mSec. I'm not sure this latency would work for syncing photo flashes. I'm not familiar with the RFM96, it may perform better in terms of "time on air".

Way back when I was hooked on photography, I seem to recall that there were fiber optic links for syncing remote flashes. While not nearly as convenient as a wireless setup, they just might do the trick in this case.

I agree with Kurt that this sounds like a fun project. Hopefully, some of the other radios may better meet your needs in terms of latency.
 
Yeah, at this point, I don't know how fast the flashes are (and I'm in a hotel room on vacation until next week). If I had to guess, it is probably the speed of your normal IR control (and for all I know, it may even be encoded as an IR control).

Yeah, I've thought of fiber optic cables, but it would be nice not to have wires of any sort. In fact, in the underwater setups, Olympus has fiber optic cables that attach on the outside of the dive box (so you don't have to breach the box for flash support), and it connects to the underwater flash.
 
I assume it all depends on the shutter speed used for flash sync. On a classic SLR film camera I recall that 1/125 sec was the norm.

My Canon underwater setup uses fiber optic for the remote flash, which is why I thought about it.
 
dgranger said:
I assume it all depends on the shutter speed used for flash sync. On a classic SLR film camera I recall that 1/125 sec was the norm.

My Canon underwater setup uses fiber optic for the remote flash, which is why I thought about it.
Click to expand...

No, I don't assume it depends on the shutter speed at all for the flash commander communication, other than second curtain operation. When you press the shutter, a command is given to fire the flashes to fire small bursts. The camera measures the reflected light from the flashes and the background light, and decides on the settings to use. The settings are sent out via a second flash, and then the picture is taken for real, with all of he flashes using those settings (and the settings are for 4 groups of flashes). Logically, the only time the shutter speed is an issue is second curtain when the flashes are done at the end of the cycle instead of at the beginning.

The flash sync speed is due to having two fabric curtains that are timed such, that both are open during the flash sync speed. At faster speeds, the sensor/film is illuminated for a small period of time as the two curtains move, and eventually the whole sensor/shutter gets exposed in stages. Early film cameras had much slower sync speeds (1/30 and 1/60). In general, most of the 4/3rds and micro 4/3rds cameras have sync speeds of 1/180, with a few that go to 1/250.

Here is an explanation for DSLRs and mirrorless with mechanical shutters. Newer cameras have an additional option for electronic shutters, which has its own set of issues):
 
Last edited:
That does sound fun. At 500th of a sec flash sync - you only get 2 ms total . . . Unless you have an "M" setting that sends the signal out before the shutter activates before the shutter activates to allow the Magnesium in the bulb to ignite and get bright in good time ... or in this case let the radio do it's job.
 
I, perhaps incorrectly, assumed that latency in communications between the camera and the remote flash would be a problem. I understand that the 4 flash calibration may be less sensitive to latency as the camera might hold the shutter open until all the calibration data is collected. However, when it comes time to then send out the final flash settings isn't there a time window during which the flash is expected to fire?

My point was that with some radio communications methods (LoRa in particular), the flash wont get the command for at minimum, ~12 mSec after it's sent by the camera. To me, that seems like a pretty long time. My concern was that the actual flash sequence might lag the shutter exposure interval. However, if the flash event is pulsed over a period of time and the camera delays opening the shutter to allow time for the flash to fire, this may not be as much of a problem as i thought.

Thanks for the link. I really had no idea how a DLSR shutter worked. In fact, it's still a bit fuzzy to be honest.
 
Well I ordered some Feather RFM69HCW 900Mhz and 2 different light sensors (one that provides an analog signal, and the other a digital signal via i2c that covers a larger range) to play with when I get back from vacation.

If I read correctly, you can turn off the packetizing and error correction. Hopefully, it will be fast enough, but we will see.
 
Last edited:
Well i took a look at the RF69 module in the Radiohead library.

Mike McCauley provides some pertinent info in the 'h' file:

Code: 
/// All messages sent and received by this RH_RF69 Driver conform to this packet format:
///
/// - 4 octets PREAMBLE
/// - 2 octets SYNC 0x2d, 0xd4 (configurable, so you can use this as a network filter)
/// - 1 octet RH_RF69 payload length
/// - 4 octets HEADER: (TO, FROM, ID, FLAGS)
/// - 0 to 60 octets DATA 
/// - 2 octets CRC computed with CRC16(IBM), computed on HEADER and DATA

The above isn't strictly true as the default init turns off CRC gen/chk. So 11 bytes + payload per packet.

Later, he talks about performance:

Code: 
/// Some simple speed performance tests have been conducted.
/// In general packet transmission rate will be limited by the modulation scheme.
/// Also, if your code does any slow operations like Serial printing it will also limit performance. 
/// We disabled any printing in the tests below.
/// We tested with RH_RF69::GFSK_Rb250Fd250, which is probably the fastest scheme available.
/// We tested with a 13 octet message length, over a very short distance of 10cm.
///
/// Transmission (no reply) tests with modulation RH_RF69::GFSK_Rb250Fd250 and a 
/// 13 octet message show about 152 messages per second transmitted and received.
///
/// Transmit-and-wait-for-a-reply tests with modulation RH_RF69::GFSK_Rb250Fd250 and a 
/// 13 octet message (send and receive) show about 68 round trips per second.

So in the continuous transmit test he's sending 11+13 bytes in about 1/152 secs or ~6.6 ms which equates to ~274 us / byte.

Your packets would be shorter w/ a payload of 1 byte so 12 * 274 us = ~3.28 ms / packet.

He cautions about shortening the preamble and sync bytes, but since you are single master and broadcast only you could easily comment out the 4 byte header, leaving 8 * 274 = ~2.19 ms / packet.

I caution you that the rf69 driver exhibits the same potential for an interrupt "race condition" as found in the rf95 driver, so if you find yourself struggling with hangs or similar misbehavior you might check out this.
 
May not be as fast pure rate wise but the very basic 433mhz/900mhz units used with rcswitch library may get you a option that does what you want at low cost
https://github.com/sui77/rc-switch
There is also virtual wire
https://www.pjrc.com/teensy/td_libs_VirtualWire.html that talks more about the radio's but will be adding more abstraction.

They contain no controller so they are processor intensive but may give the most control over timeing out of anything I can think of at the moment. One problem with these is that there is no feedback for error checking or anything, but I guess the occasional failure here would just manifest as needing to take a photo again so the simplicity may be acceptable.
 
The 433/915 ASK radio modules require a preamble to synchronize the receiver. Both the rc-switch and virtualwire libs use approximately 32-36 bit periods for the sync preamble. Also, the bit rates on these radios are pretty low. Mike McCauley did some performance measuring and reported the following results:

Unit tests show that the receiver PLL can stand up to 1 sample in 11 being inverted by
noise without ill effect.
Testing with TX-C1, RX-B1, 5 byte message, 17cm antenna, no ground plane, 1m
above ground, free space

At 10000 bps the transmitter does not operate correctly (ISR running too frequently at
80000/sec?)
At 9000 bps, asymmetries in the receiver prevent reliable communications at any dis-
tance
At 7000bps, Range about 90m
At 5000bps, Range about 100m
Click to expand...

Mike's Virtual wire bit encoding scheme is more efficient that that used in rc-switch. Using rc-switch, a message with a preamble and single data byte would take ~22 ms to send. With virtual wire, a message consisting of preamble, Start-Of-Message symbol, and a single data byte would take ~10 ms (at 6000 bps). It may be possible to shorten the preamble and drop the SOM symbol, but that would be a research project that at most would cut the time-on-air to ~5 ms. Note that even the {preamble, SOM, data} message format would require some hacking of the virtualwire lib.

So I'm not sure that any of the cheap radio modules provide very low latency communications.

I wonder if the camera accounts for latency in the remote flash units during the pre-flash calibration? It seems likely that it would observe the actual flash(s) during the exposure evaluation period, so measuring the time between it's command flash signal and the first remote unit's calibration flash might already be built in? It seems that the camera would need to account for remote flash latency to achieve good shutter sync (unless it assumes 0 or fixed latency).

All in all, this sounds like a fun project with some interesting research aspects. I'm looking forward to reading what Michael comes up with.
 
Last edited:
dgranger said:
LoRa sacrifices data rate for range. Semtech has a calculator where you can enter various factors such as bandwith, spreading factor, & payload size and determine the total air time for your packet. BTW: all these things are configurable with the Radiohead library.

Here's a link to where you can download the calculator:

http://m.semtech.com/apps/product.php?ct=38&pn=SX1276

Scroll down to the "Tools and Software" section and follow the "LoRa Calculator" link.

....
Click to expand...

Sorry this is a bit off topic but is there a list of free public Lora gateways anywhere? I'm interested in the activity level around St Charles Missouri before I decide to buy a radio board.
 
Sorry, I'm not aware of any such registry.

The RF9x LoRa modules are pretty much sub 1 km range in non elevated, line of sight environments. Moreover, the LoRa spreading algorithms greatly reduce the potential of interference with other transceivers in the area. For my application, I'm using a 433 mhz LoRa as a beacon / repeater and several others as trackers. Even though the beacon will be airborne, I don't anticipate any significant interference issues. However my location is a bit more rural, north of Boulder on the Colorado front range.
 
While I probably will do it as a low priority hobby project, after I posted the initial article, there is now a solution. Nissin introduced the Air10s commander + D700A flash system that work on Olympus/Panasonic micro 4/3rds camera. The commander uses a 2.4Ghz radio system to control the flash. Currently, it requires you to use Nissin flashes with radio controls (D700A and i60A).

There is a receiver (Nissin R) that for other camera formats (Canon, Nikon, Sony) supports the existing manufacturer flashes, but current Olympus is not supported. Hopefully that will be fixed in the future.

The current price of the Air10s + D700A is ~ $300: https://www.bhphotovideo.com/c/product/1306097-REG/nissin_nd700ak_ft_di_700a_flash_air_1.html.
 
Status
Not open for further replies.
Back
Top