Optimising RF12 library for low latency, high speed

(9 posts) (2 voices)

Tags:

No tags yet.

edwardhorsford

Hi JCW,

Received my JeeNodes a couple weeks ago and have been happily tinkering with them.

I'm interested in using the RFM12 as part of a larger system for high-speed photographic triggering. In this system I don't need to send much data, but what I do need is:
Extremely low latency from trigger condition to trigger command being received on the other end.
High repeatability of timings (I need to sync both wired and wireless devices to all trigger at the same time)
Only need one-way communication from source (trigger) to destination (receiver).

I've done some tests with RF12 demo code, triggering off pin changes immediately before and after packets are sent or received. With a payload of 2 bytes am measuring a latency of 2.45 - 2.47 milli-seconds. Fiddling with the library to up the baud rate to 115.7kbbs, I measure 1.23 - 1.26 milliseconds. This is certainly excellent, but not fast enough for my requirements.

Unfortunately, whilst I'm reasonably familiar with Arduino code, I have trouble following the library code - let alone modifying it. I wonder if anyone here might offer some pointers for things that can be touched to both reduce the latency and reduce the variation. My target is 500 micro-seconds and under 5 micro-second variation.

Things I'd think would help (but don't know how to implement):
Keep source devices in permanent transmit mode, ready to send.
Keep destination devices in permanent receive mode, ready to receive.
Pre buffer commands / payload into source radio, ready to send.
Remove checks for whether airwaves are clear (Either I trigger within the timeframe, or the moment is lost).

Any help greatly appreciated. If anyone's interested, this is the kind of thing I've been working on: http://tinyurl.com/ykzna38

Posted 11/03/2010 14:47:11
jcw

You might want to consider not bothering with the RF12 driver at all - see the transmit-side code at http://wiki.jeelabs.net/p/38

- consider reducing preamble to 2 bytes i.s.o. 3
- use a 1-byte sync code i.s.o. 2
- use a 1-byte checksum or send the 1's complement byte as check
- you probably need a trailer sync byte

That makes 5 bytes. Would take 420 µS @ 115.7 kbaud, leaving you with a 20% margin. Looks like you'll have to push this to the very limit. See also Stephen Eaton's Strobit project - http://code.google.com/p/strobit/ - it was created with the same purpose in mind, as I understand it.

Posted 11/03/2010 17:12:11
edwardhorsford

Hi Jean-Claude,

I've come across the Strobit project already, though haven't seen it updated regularly.

Thanks for the link. Do you have an example of the receive side code? I can mostly follow what the code in the link is doing, but after reading through the RF12.cpp library file, I don't think I could get the receive side going on my own.

I'm guessing I'd need to change the line "rf12xfer(0xCA83); // FIFO8,SYNC,!ff,DR " to rf12xfer(0xCA8B) to set one sync byte (If I'm reading correctly, you're using the second sync byte as the group code?). Unsure about preamble / checksum.

Thanks for the help.

Posted 11/03/2010 20:28:36
jcw

I don't have a stripped example of the receiver code - hold on, there is an old example which might be useful:
http://news.jeelabs.org/2008/12/11/good-rf-with-rfm12b/

Yes, 2nd byte is netgroup.

Premable can be reduced by simply removing "TXPRE2, TXPRE3" from the enum (or maybe just one, not sure how many are required as minimum).

Checksum: I'd remove it from the packet altogether, and add some other sort of redundancy (repeated payload byte in 1-s complement, for example). You do need a trailing SYN, so don't omit the TXTAIL. But as I said before, I'd forego the (complex / interrupt-driven) RF12 driver altogether since you're trying to push the RFM12B to its limit.

Posted 12/03/2010 23:20:44

edwardhorsford

Hi Jean-Claude, thanks those links were most helpful, and I'm starting to follow some of what the library is doing.

After some small modifications I seem to have the send side working fine with the full message as in that example. I Modified the init commands to match the rf12 library, and the rf12demo code now sees it fine.

However, I can't yet get the receive side code to work reliably. I'm tending to get several miss-reads, causing the checksum to fail. Since the rf12demo code sees the message perfectly, I'm guessing it's something to do with the timing on the receive code. If you wouldn't mind taking a look:

Code is as per your examples with the ending as:
Send side:

void rf12init() {
   rf12xfer(0x80E7); // EL,EF,12.0pF
    rf12xfer(0x820D); // enable xtal, disable clk pin, enable lbd
    rf12xfer(0xA640); // 868MHz
    rf12xfer(0xC606); // C602 - 115.7 - 57.6Kbps (38.4: 8, 19.2: 11, 9.6: 23, 4.8: 47)
    rf12xfer(0x94A2); // VDI,FAST,134kHz,0dBm,-91dBm
    rf12xfer(0xC2AC); // AL,!ml,DIG,DQD4
    rf12xfer(0xCA83); // FIFO8,SYNC,!ff,DR
    rf12xfer(0xCED4); // SYNC=2DXX?
    rf12xfer(0xC483); // @PWR,NO RSTRIC,!st,!fi,OE,EN
    rf12xfer(0x9850); // !mp,90kHz,MAX OUT
    rf12xfer(0xCC77); // OB1?OB0, LPX,?ddy?DDIT?BW0
    rf12xfer(0xE000); // NOT USE
    rf12xfer(0xC800); // NOT USE
    rf12xfer(0xC049); // 1.66MHz,3.1V
}
void setup() {
    spiinit();
    rf12init();
    pinMode(RFMIRQ, INPUT);
    Serial.begin(57600);
    Serial.println("RF12 Test Send Program");
}
void loop() {
    rf12xfer(0x0000); // read status register
    rf12xfer(0x823D); // !er,!ebb,ET,ES,EX,!eb,!ew,DC 
    rf12send(0xAA);
    rf12send(0xAA);
    rf12send(0xAA);
    rf12send(0x2D);
    rf12send(0xD4); 
    ChkSum = 0;     
    rf12send(0x30);
    rf12send(0x31);
    rf12send(0x32);
    rf12send(0x33);
    rf12send(0x34);
    rf12send(0x35);
    rf12send(0x36);
    rf12send(0x37);
    rf12send(0x38);
    rf12send(0x39);
    rf12send(0x3A);
    rf12send(0x3B);
    rf12send(0x3C);
    rf12send(0x3D);
    rf12send(0x3E);
    rf12send(0x3F);
    rf12send(ChkSum);
    rf12send(0xAA);
    rf12send(0xAA);
    rf12send(0xAA);
    rf12xfer(0x8201); 
    delay(200);
}
Receive side:

void rf12init() {
    rf12xfer(0x80E7); // EL,EF,12.0pF
    rf12xfer(0x820D); // enable xtal, disable clk pin, enable lbd
    rf12xfer(0xA640); // 868MHz
    rf12xfer(0xC606); // C602 - 115.7 - 57.6Kbps (38.4: 8, 19.2: 11, 9.6: 23, 4.8: 47)
    rf12xfer(0x94A2); // VDI,FAST,134kHz,0dBm,-91dBm
    rf12xfer(0xC2AC); // AL,!ml,DIG,DQD4
    rf12xfer(0xCA83); // FIFO8,SYNC,!ff,DR
    rf12xfer(0xCED4); // SYNC=2DXX?
    rf12xfer(0xC483); // @PWR,NO RSTRIC,!st,!fi,OE,EN
    rf12xfer(0x9850); // !mp,90kHz,MAX OUT
    rf12xfer(0xCC77); // OB1?OB0, LPX,?ddy?DDIT?BW0
    rf12xfer(0xE000); // NOT USE
    rf12xfer(0xC800); // NOT USE
    rf12xfer(0xC049); // 1.66MHz,3.1V
}
void setup() {
    spiinit();
    rf12init();
    pinMode(RFMIRQ, INPUT);
    digitalWrite(LEDG, 1);
    digitalWrite(LEDR, 1);
    pinMode(LEDG, OUTPUT);
    pinMode(LEDR, OUTPUT);
    rf12xfer(0x82DD); // receiver on
    rf12xfer(0xCA83);
    Serial.begin(57600);
    Serial.println("Test receiver program");
}
void loop() {
    uint8t i;
    rf12xfer(0xCA83); // Enable FIFO 
    ChkSum = 0;
    int pieces[16];
    for(i=0;i<16;i++){
      piecesi;
      digitalWrite(LEDR, 0);
    }     
    uint8t sum = ChkSum;
    i=rf12recv();
    digitalWrite(LEDR, 1);  
    rf12xfer(0xCA81); // Disable FIFO 
    if(sum==i){
      Serial.println("Checksum match");
    }
    Serial.print("Received was: ");
    for(int a = 0; a<16; a++){
    Serial.print(piecesa;
    pieces[a] = 0;
    Serial.print(" ");
    }
    Serial.println();
}
Once again, very grateful for your help.

Posted 13/03/2010 18:38:58

jcw

I don't understand (or don't remember?) the receive side of this early example. I suspect that the loop is getting false starts. Maybe check the status bits from the receiver to see what happens. I'm sorry but I can't help much more, I'm always using the RF12 driver these days.

Another thought - perhaps the receiver is getting overloaded, try placing the units further apart or using less well-matched wire antennas while testing.

This sort of stuff can be extremely hard to debug, with two completely different sides involved.

Posted 13/03/2010 20:31:08
edwardhorsford

Thanks for the pointers. Since it works with the RF12demo, it won't be the placement or antennas.

I agree that it's probably something in the loop reading at the wrong time. As far as I can see it waits for IRQ to be pulled low (signalling data ready), then reads a byte. It loops like that for 16 bytes then spits out the message. Perhaps something needs resetting after reading the byte? The other possibility is that the SPI communications are different and not coping as best they could.

I'll keep at it. Thanks for the help.

Posted 13/03/2010 20:58:59
edwardhorsford

Spent some of this evening hacking your [previously] well written library. Time is currently coming in at 373µS with units 12 inches apart, measured with my work's 'scope.

So far, what I'm sending is:
2 x sync bytes
2 x data bytes
1 x postamble (don't think it worked without this)

I found that omitting the preamble didn't have any noticeable effect. I might implement triggering on the first byte (with second for config changes), which might get the time down further.

I wonder if you have any comments on some of my hacks:
I'm measuring post rf12xfer(RFXMITTERON) - is there any reason not to keep this on permanently? it seemed to introduce a 300µS delay before IRQ was pulled low.
removed rf12xfer(0x0000) at start of rf12interrupt(). Does the rf12 need this to be read each time?
changed the SPISS digitalWrite within rf12xfer() to direct I/O manipulation - assume these are for portability to other processors.

Might try going with one sync byte and having an extra data byte for a checksum of sorts. We'll see how reliable that is.

Thanks for your help. I'll definitely be buying some more JeeNodes for experiments soon.

Posted 15/03/2010 23:23:39
jcw

Wow - impressive work.

- Transmitter always on: I suspect there's all sorts of stuff going on in the RFM12B, in your case it seems like a good idea to keep TX on and sidestep all that, but keep in mind that you'll be hogging the frequency band (which is not allowed for 868 MHz in Europe).
- rf12xfer(0x0000) in ISR: I always wondered about that, then just left it in, but now that we have good baseline apps to test with, it's probably easy to verify whether it really needs to be there
- getting rid of digitalWrite(): I'm all for it, see also http://news.jeelabs.org/2010/01/12/c-templates/

The postamble is probably needed to push the last byte out, otherwise if you send the last byte and shut down the transmitter, it will never get sent since the bits need time to pass through the FIFO.

Thanks for sharing. I'm pleased to see someone else go through the RF12 driver code, given that it's fairly complex.

Posted 16/03/2010 00:11:32