Fastest way to get a 1 bit trigger from an Xbee pro?

[T Chap]

I am exploring an idea for using an Xbee on a module attached to a camera shoe. At the flash head, I will have an Xbee that goes to a Propeller for setting the power to the flash head. That string will consist of a start byte, id byte, 4 data bytes. The power control is not sent at the time of the flash/sync trigger. The flash sync should be detected by up to 16 heads all at the same time, in the quickest way possible, and the plan is to not have the sync as part if the packet mentioned. Ideally, direct from the contact on the hotshoe to the sync input on the cable would be fastest, bypassing the Prop on the receiver for sync purposes. So. the question is, is there a method to use RTS or or some other method as a single bit to the receiver Xbee, so that the data does not even need to be read, the hotshoe fires some pin, the receiver outputs a response upon seeing the trigger. On other remote receivers, I notice that the sync line sits at 7v, and goes low for 50us on the trigger. The plan is to have the hotshoe fire the flash, but have a PC/mac GUI output the control voltage settings per light over Xbee, have a receiver at the head with a Prop parsing the ID and values for flash power and modeling light power(0-4V). If there is no flow control that would work, am I stuck with using a start byte that all receivers/Props parse immediately and manage the 50us trigger pulse. I do not have the Xbee's to test this timing, who knows if this is viable. A typical shutter speed for flash is 1/125 - 1/500.

Anyone have a guess at the speed to get a single bit/byte from a Prop pin>XbeeXmit>XbeeReceive>Propparse>Proppin out?

[Duane Degn]

I don't know of a way to do this with an XBee but some other transceivers have a raw mode where the data isn't packeted or anything like that. For example Nordic nRF24L01+ modules have some sort of continuous mode (for transmitting audio I believe) and might be able to send a bit very quickly. I personally haven't tried using the raw mode with the Nordic modules.

The Nordic module could also be configured to send a single byte (I think) packet. As soon as a packet is received, the IRQ pin goes low on the receiving module. The can transmit at 2Mbps which I believe is faster than the fastest baud rate of an XBee.

These modules cost less than $2.50 (shipped) on eBay. There's a link to the eBay modules in post #1 of my index and a link to a driver in post #2.

I believe there's an audio driver for these units in my "Panic Buttons" project. (I can't recall the author of the object right now (Mark T maybe?)).

Anyway, my guess is this would be easier to accomplish with the Nordic modules.

[T Chap]

Thanks for the info Duane. Lots of nice features, including 125 frequencies starting at 2400mhz. I will get the Sparkfun board to test.

[T Chap]

One is the photo of the flash remote I am studying,. The other is the sparkfun device. Rather coincidental, the remote I am studying offers 16 frequencies, 16 channels. The Nordic allows 125 frequencies. The sparkfun breakout board has 8 pins. The remote device has 8 pins broken out. My bet is this product is using the Nordic.

[Duane Degn]

I was looking through the nRF24L01+ datasheet.

I think the smallest possible packet is 57 bits.

This includes a one byte payload. The fasted the one byte could be written to the device is (8 * 100ns) + 4ns or 804 ns seconds. (The Prop wouldn't actually be albe to do this but it shouldn't take it much longer than 804ns.

The Nordic module (@2Mbps) takes 0.5ns to transmit a bit. So the 57 bits would take 28.5ns to transmit. According to page 42 of the datasheet this amount used twice to calculate the transmit time giving a total of 57ns.

From what I understand, there appears to be 272us overhead in the transmit and receive. There's also a 10us pulse to the CE line required by the transmitter.

So from the time data starts being loaded into the module to the time the IRQ pin is pulled low by the receiver should take:
804ns + 57us + 10us + 272us = 339.8us.

At least that's the way I interpret the datasheet.

As you can see, the time it takes to load the data to the module is relatively small (804ns). So even if the Prop takes four times as long to load the data than the 804ns figure, it wouldn't effect the result much.

The nRF24L01+ doesn't have a "raw" mode I had mentioned previously. The older Nordic module nRF2401a has a "Direct Mode" that doesn't use packets. I haven't done the math for the nRF2401a module's transmit time, but I'd be surprised if if were better than the nRF24L01+'s transmit time.

[T Chap]

Thanks for posting the info Duane. If this company is in fact using the same device, they are boasting 256 bit encoding, and delay time of 1/4000sec. For the flash, certainly they are trying to send the minimum info. So if 1/4000 = .00025, or 250us, then I don't see how the math works out as doable based on your conclusions. However, maybe there is some way to send something shorter I am missing.

I only see one PCB antenna, no chip antennas, so it is assumed both the lighting power and flash are all happening on the same tranceiver.

[sylvie369]

Have you looked at the use of the XBee's I/O line passing? You set up the transmitting XBee and the receiving XBee to be "bound" by setting the IA parameter, and then set up the appropriate pins on the modules to be inputs (on the transmitter) and outputs (on the receiver) using Dn commands (where n is the pin number). Then whenever the input pin on the transmitting XBee is high, the corresponding pin on the receiving XBee will also be high, and when the pin on the transmitting XBee is low, the corresponding pin on the receiving XBee will also be low. You can set the sample rate up to every 1 ms, and set it to transmit on every sample (though that's a lot of transmitting, and the XBee will not keep up). Alternatively you can set it to transmit only when it detects a chance in the input's digital value.

I can't tell you how quick that is, but it may allow you to eliminate the two Props from the loop entirely. Disregarding timing issues, it's the straightforward way to communicate one bit between two XBees. There's some information on it here:

http://www.faludi.com/2006/12/03/xbe...t-io-with-adc/

He's passing the value from pin 1 on one XBee to pin one on the other XBee.

[T Chap]

From Nordic


250 us response time can be hard to acheive, but it is do-able.

The smallest on-air payload using ShockBurst (see chapter 7.9 in datasheet) is:

130uS PLL startup + 1 byte preamble + 3 byte address + 1 byte payload, and CRC disabled.

Given a 2MBit data rate, this equals to a total on-air time of 150us.

Note that you will then have a lag of about 8 us before the interrupt is asserted to the external MCU on the receiver side, which means that the MCU's on the receiver and transmitter side have a total of 92 us to upload and receive data over SPI and fire the flash.


For the response time I have suggested, it includes no loss of packets.

[T Chap]

I may be making a mountain out of a mole hill. I have based my need to sync at 250us on another manufacturers specs o 250us delay, 'which allows for a 1/2500sec shutter speed. Nobody shoots normal photography this fast, and 1/125 - 1/500 is typical with flash. Since this is not a commercial project, the sync speed does not need to be as fast as the other manufacturer.

[Duane Degn]

The smallest on-air payload using ShockBurst (see chapter 7.9 in datasheet) is:

130uS PLL startup + 1 byte preamble + 3 byte address + 1 byte payload, and CRC disabled.

Given a 2MBit data rate, this equals to a total on-air time of 150us.

This is kind of strange. Chapter 7.9 is about using "ShockBurst" mode rather than "Enhanced ShockBurst" mode but "ShockBurst" mode is limited to 1Mbps.

[T Chap]

BTW here is a paper on Xbee timing.

http://www.digi.com/support/kbase/kb...ltdetl?id=3065

[T Chap]

I will get in some of the Sparkfun modules this week to play with. Is the Duane demo the best place to start with these?

[Duane Degn]

I don't know of any other demos. I found the current demo can lock up.

I have a better one I'll clean up and upload this weekend.

I'll probably put the new cleaned up version in both the thread and the OBEX.

The last time I checked, the object for nRF24L01+ modules in the OBEX had some serious flaws (it only receives one byte of the packet and can't transmit).

[Mark_T]

I don't know of a way to do this with an XBee but some other transceivers have a raw mode where the data isn't packeted or anything like that. For example Nordic nRF24L01+ modules have some sort of continuous mode (for transmitting audio I believe) and might be able to send a bit very quickly. I personally haven't tried using the raw mode with the Nordic modules.

nRF24L01+ raw mode? For transmitting audio? Perhaps you mean that packet auto-acknowledge is optional? That means you can get much better throughput, but the latency is unchanged I think. I've written a driver that can handle one channel of 24 bit 48kSPS, but no error detection/correction - at that rate there's no time to do much else as it takes up nearly all of the time driving SPI in one cog and copying the packet buffer in another cog before its needed by the next packet.

I probably promised a while back to cleanup my code and release it to the OBEX but haven't done so - I'll kick it to nearer the top of the todo list...

[T Chap]

I have a feeling that it will be fast enough if I can just get it too work reliably.. But, I had a thought about SPI coming out of the receiver.... what if you send an FF and there were no other cases of an FF normally coming out of the receiver, does the data output remain active(high or low for a 1?) throughout the 8 bytes, or does the data pin toggle per bit. If in fact it could remain at a steady voltage until the FF has passed, could the Prop count the duration of the data output, and detect an FF, eliminating some amount of time for the packet to even need to complete sending to the Prop, as well as the time to parse the string after it is received. Just thinking out loud.

[Duane Degn]

I have a feeling that it will be fast enough if I can just get it too work reliably.. But, I had a thought about SPI coming out of the receiver.... what if you send an FF and there were no other cases of an FF normally coming out of the receiver, does the data output remain active(high or low for a 1?) throughout the 8 bytes, or does the data pin toggle per bit. If in fact it could remain at a steady voltage until the FF has passed, could the Prop count the duration of the data output, and detect an FF, eliminating some amount of time for the packet to even need to complete sending to the Prop, as well as the time to parse the string after it is received. Just thinking out loud.

The time I quoted above was just until the IRQ pin went low. No data had been read out of the module yet. If the IRQ is low, you can assume the correct address had been used. I suppose it's possible for the module to pick up some false triggers if you've disabled any error correction but I doubt (based on no experience or knowledge) it would be much of a problem.

[Duane Degn]

nRF24L01+ raw mode? For transmitting audio? Perhaps you mean that packet auto-acknowledge is optional?

I was just making a guess at the method you had used to transmit audio. I later found there isn't a "raw" mode with the nRF24L01+

I probably promised a while back to cleanup my code and release it to the OBEX but haven't done so - I'll kick it to nearer the top of the todo list...

I might have promised to do the same with my code.

Last one to the OBEX is a rotten egg.