Fastest way to get a 1 bit trigger from an Xbee pro?
T Chap
Posts: 4,223
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?
Anyone have a guess at the speed to get a single bit/byte from a Prop pin>XbeeXmit>XbeeReceive>Propparse>Proppin out?
Comments
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.
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.
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.
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/xbee-direct-io-with-adc/
He's passing the value from pin 1 on one XBee to pin one on the other XBee.
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.
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.
http://www.digi.com/support/kbase/kbaseresultdetl?id=3065
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).
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...
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.
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 might have promised to do the same with my code.
Last one to the OBEX is a rotten egg.