Pages

Wednesday, 23 November 2011

So Many RF Solutions, So Little Time

I've been a bit bummed out the past few days, due to the fact that I totally botched the addition of my HC-05 BT-serial module onto my current prototype (the Bluetooth module is supposed go to on the other side, not pictured), and I even managed to burn my thumb in the process. These Bluetooth modules don't exactly have a friendly footprint for the low-tech hobbyist with an old-fashioned soldering iron. I managed to short VCC to GND on the module and must have cracked some middle-layer traces on it, or just fried it, while trying to clean up my soldering job. One Bluetooth module, R.I.P. <sniff>




Researching parts for a project can be a real time-sink -- you can get bogged down trying to choose just the right part for so long that you don't get anything actually done on your design. It's worse if you have a short attention span like me. However, sometimes you see a part that just looks so much better you've just gotta stop what you're doing and re-design for it. Let's hope my judgement is right on this one..

On a whim I did some searching tonight to see what other RF modules might be out there. I knew of the very cheap and simple 433MHz car-remote style RF modules, which are simple regenerative radio thingies that use Manchester encoding, but their max data rate seems to be about 4KB/s which isn't high enough for my project's intended use (Manchester encoding requires at least twice the data rate of the endpoint due to its balanced 1-0 level requirements -- each 1 and 0 must be transmitted as two bits, either 1-0 or 0-1).

However, my inner geek is now extremely excited to get my hands on these babies: 2.4GHz (same band as Bluetooth) but with:

  • raw SPI interface
  • 126 RF channels
  • 256kbps/1Mbps data rate
  • full error detection/correction
  • no crazy QFN pads. Simple 8-pin header.
  • cheap modules available (half the price of HC-05 boards if you shop around)
Hot, sweaty spec pr0n here: nRF24L01+ datasheet

UPDATE: I saw some pages talking about the TI CC2500, another 2.4GHz transceiver and wondered if it had any clear advantages over the nRF part. Here's a PDF that compares the two (obviously from Nordic Semi, but the advantages seem clear on power saving and data rate.)

These look to be easier to work with for prototyping (.100" header, yay!), easier from a software standpoint (sigh, my dual-rate software UART code may be for naught) and, I hope, lower latency/jitter than Bluetooth devices. I've emailed Nordic Semi to see what they say about that... but if nothing else it'll make for a cheaper board, simpler firmware, and less burned thumbs for me :)

UPDATE: Nordic got back with a reply today, and it sounds like the nRF24L01+ can transmit 32 bytes of data, with an ACK even, in approx. 165us -- crazy fast. I was hoping for 10ms or so latency but with this device I might be able to get <1ms, far exceeding my requirements. The more I read the spec sheet the more I am impressed.

5 comments:

  1. What is the matter with crazy QFN pads

    ReplyDelete
  2. They're too small for my primitive soldering iron :) I must buy a hot-air reflow tool.

    ReplyDelete
  3. Indeed, the typical bluetooth Serial ports on ebay and alibaba etc have latencies of around 5 - 20ms!

    Terrible if you're dealing with high precision data.

    I did some latency tests here if you want to see:

    http://adriangin.wordpress.com/2012/08/21/bluetooth-uart/

    ReplyDelete
    Replies
    1. Forgot to mention also that bluetooth does have it's advantages especially when connecting to a PC or Bluetooth Enabled device!

      I suppose it's the price you pay right?

      Delete
    2. Thanks, your article was very informative. Yep, the latency would be a bit too high for what I'm hoping for (MIDI-related music stuff). I have to get back to work on my project to see how well the Nordic part works in practice...

      Bluetooth would have been cool, giving the ability to pair with Android phones etc. but for what I'm doing it can be a more proprietary protocol.

      Delete