Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Syncing 2 LED Strobes Via RF 6

Status
Not open for further replies.

itsdonny

Materials
Jul 6, 2012
20
I hired an electronics engineer to design a portable LED lighting system that has bluetooth for controlling the LEDs (color change, strobe, brightness, etc.). One of the objectives is to have the ability for each LED lighting system to sync to one another. So for example if one system is strobing at a certain rate then you bring another system near it they would both synchronize and strobe at exactly the same time. My engineer says he thinks the bluetooth protocol would have too much lag to get them in sync. I was thinking about using infrared but these will often be used in direct sunlight so I don't think it would be reliable. I would appreciate any creative ideas in how you think this could be achieved.

Thank you!
 
Replies continue below

Recommended for you

The human vision simultaneity is orders of magnitude slower than BlueTooth.

I'd probably use a simple wireless scheme that sends out a single sync pulse occasionally. Skip all the protocols.

You can use IR also. It dumps scads of FCC hassles. You would need to modulate the signal and use the correct filters which both raise the signal to noise ratio considerably. It's quite do-able.

Back to the BT. You would find a repeatable time delay that you could just subtract out.[highlight #FCE94F][/highlight]

Keith Cress
kcress -
 
Hey, thank you, Keith. What you said makes a lot of sense. It seems easy enough to subtract the time delay if necessary. I appreciate your insight.

Don
 
Perhaps the bright flash of light itself would be sufficient for the 2nd strobe to detect (with a phototransistor) and synchronize with. It'd need to be delayed by a microsecond or so to avoid blinding itself.

Slave Strobes can do this open loop.
 
Lag sensitivity depends on what the eye sees. Conventional NTSC TV is 30-Hz interlaced, which means that getting a video refresh every 33-ms was adequate for normal TV shows back in the 1950s. Current generation TVs run closer to 120-Hz to 240-Hz, because video has much higher motion content than previously. Gamers typically start to complain about lag if the frame rate is less than about 80-Hz

Additionally, where the lights are in one's visual field makes a huge difference. Closer to the fovea, your color cones dominate, but are slower, while your peripheral vision is dominated by the monochrome rods, which are more sensitive to flicker. And, while your vision has lag, it is able to detect very short duration pulses, provided they're bright enough.

TTFN
faq731-376
7ofakss

Need help writing a question or understanding a reply? forum1529
 
Thanks everyone for your responses.

itsmoked, couldn't I use the bt chip as the radio transmitter and receiver? Since I'm going to have the bt chip there already I'm hoping I don't have to add another rf transceiver to the design.

VE1BLL, I like the idea and I think the strobe would be bright enough for some situations, but I need this to work omnidirectionally in direct sunlight, so I don't think it would be reliable like that.

IRstuff, that's interesting info about the eyes. I didn't know that. I think if I can get them to sync within 30hz of each other it will be good enough, even if some few millisecond delay is noticed that would be okay.
 
Yes you can certainly use existing BT! I didn't realize your design actually had it, I thought it was just contemplated. If your project needs sync for only human reasons your BT will be more than adequate.

Keith Cress
kcress -
 
Of course if the strobing is repetitive and at a reasonably constant rate over multiple periods, then even a moderate latency communications link can synchronize them precisely. The method would be analogous to Network Time Protocol, where computer clocks can be synced within about a millisecond even over a network with 100s of milliseconds latency.
 
I have used IR to communicate between a car and a gate gate that opens when the right car is getting close). And this works well in direct sunlight. You need an IR filter and you need to use a carrier frequency and a selective receiver, we used a simple tuned LC receiver. The carrier frequency was around 50 kHz (different than remotes and other IR applications) and had delays in the 2 ms range when working up to around ten meters. We also transmitted car ID, what company it belonged to, need for oil, fuel, service etcetera. Definitely doable and with IR, you avoid any FCC discussions.
As Keith says - just do it.

Gunnar Englund
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.
 
We read out about 10k of data from refrigerated rail cars into a laptop from about 10 feet in bright sunshine.

Gunnar do you recall what current you drove your IR LED at? Did you use more than one?

Keith Cress
kcress -
 
I'm still working on this project to get the BT devices to sync. I got an email from the engineer that is working on it and I wanted to get your take on it as to what the best solution might be. Please see his email below.

Thanks,
Don
__________________________________________________________________

Hi Don,

I am writing to update the project progress.

There is a problem with the BLE. The Nordic chip needs a BLE stack (a kind of firmware) to run as a BLE application. My code runs on top of this stack. When two BLE devices talk to each other, one is master and the other one is slave. However, the stack now just allows us to program the chip as a slave when communicating with the smartphone. In order to synchronize the strobe signal among many systems, we cannot uses the BLE protocol. I am searching the solution for this problem and I'm considering some options as mentioned below:

1. The phone is master and every light system is slave. The phone is required.
The synchronization can be done only if there is a phone in the area. This phone can then play the master role.

2. The phone is master and every light system is slave. The phone is not required.
I'm putting forward this method now. Only the transmission from phone to (one) light system is BLE protocol. The communication between two (or more) light systems is our defined protocol. During the synchronization, BLE stack will be disabled and I will use the radio link directly. Thus the phone then cannot detect and connect to the light system. I can add one more button on the light system to enable the BLE stack again when configuring the light system from phone.

ps: actually, now there are 2 BLE stack:
1. Slave (official)
2. Master (beta)
3. Master and Slave (can switch between two mode): This stack is still under developing.
 
Sounds reasonable. A Master can be connected to several Slaves whilst a Slave can only be connected to one Master. So if you want peer to peer functionality (eg. two generic light systems to talk directly to each other) then BLE will not do. You need to have the master present to relay the messages.

Alternatively, since the master/slave designation only occurs after connection, you could do something a bit tricky like two light systems somehow deciding who should adopt the master role for the present connection. But that's not really how BLE was intended.
 
Thanks guys for the responses. I'm hoping to not have to add another chip if possible to keep the costs down with production. Liteyear, it sounds like your idea would work with 2 light systems but I'm wanting it to work with multiple systems. So whenever a new system came within range it would just sync up. Perhaps one of the Nordic BLE chips with the built in ANT+?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor