This is perfect timing for me, as I've been experimenting with the Texas Instruments CC110L attached to an ESP8266 running the Arduino stack. I started on this after having written an SDR receiver application to receive my electric and water meter readings using an expensive rtlsdr dongle and a raspberry pi. Thanks for sharing!
What? RTLSDRs go from ~$9-$20 max (I got mine for $10 on eBay), and a Raspberry pi is $35. The PandwaRF is ~$150 USD alone. Does the CC11xx series chip in this device make a difference to your use case?
Well, I was more talking about a general device to assist in reverse engineering various RF protocols (and that was before I found the price for this device :) ). Now knowing the price, it puts it up with the YardStick One, which is probably out of my price range (I'm cheap). The CC110L + ESP8266 setup that I'm working with currently cost me about $12 shipped, combined (eBay as well).
The selling point on using the CC11xx vs. generic rtlsdr is the scanning speed. The particular protocol that my electric and water meters speak is spread spectrum with 400kHz channel spacing and 25 channels. I'm able to park my rtlsdr on a frequency and get about 1/4 of the packets (luckily there is no change in channel during packets). I've tried scanning, but the dongles I have just aren't quick enough. The meters themselves actually use the TI chips, so I know they're up to snuff.
Ah, I see. I have a HackRF and several USRPs, so I'm kinda spoiled in terms of bandwidth and capabilities. You could try combining more than one RTLSDRs into one virtual stream using GNURadio. Check this out: http://www.rtl-sdr.com/combining-the-bandwidth-of-multiple-r...
The only catch is that it is not phase coherent, but if you're doing FSK or AM then that's perfectly fine.
I've had a HackRF on my wishlist ever since discovering Mike's awesome SDR video series. That said, I wouldn't want to dedicate the device to the meter reading (hence my trying to pare down to the bare essentials).
Funny you mention using multiple dongles, I've actually been doing just that while working out the protocol to capture as many messages as possible. Except in my case, since 2.4MHz gets me exactly 6 channels, I can just run multiple instances of my application, each looking at their own 2.4MHz chunk of spectrum. No need to truly synchronize them.
As someone with some but not much exposure to RF, can anyone shed some light on how this is different from a regular transmitter/receiver hooked up to a pi (I've done just this with a pi zero for ~$20) and what the use cases for this might be?
It's an SDR, so it can transmit and receive over multiple frequencies. It's basically a programmable transceiver that can be used to interact with many different protocols and transmission encodings on different frequencies. Looks like it also has some specialized abilities for security stuff, e.g. brute forcing RF codes.
Technically I don't think it is an SDR, as it's not using software to generate arbitrary modulation schemes. The chip is capable of transmitting data through certain modulations.
Yes, it is not a SDR because CC1111 doesn't send the I/Q samples, so no custom demodulation possible. Only support some standard modulation AM/FM/FSK, ...
Another RF neophyte here - what's the selling point or applications of an RF transceiver over the 300 - 928 Mhz band? It looks like those frequencies were used for TV broadcasting but the spectrum has been reallocated, and there's not a lot of unlicensed space to play with. Given this what kind of applications are there for this device?
15 comments
[ 2.4 ms ] story [ 44.5 ms ] threadThe selling point on using the CC11xx vs. generic rtlsdr is the scanning speed. The particular protocol that my electric and water meters speak is spread spectrum with 400kHz channel spacing and 25 channels. I'm able to park my rtlsdr on a frequency and get about 1/4 of the packets (luckily there is no change in channel during packets). I've tried scanning, but the dongles I have just aren't quick enough. The meters themselves actually use the TI chips, so I know they're up to snuff.
Funny you mention using multiple dongles, I've actually been doing just that while working out the protocol to capture as many messages as possible. Except in my case, since 2.4MHz gets me exactly 6 channels, I can just run multiple instances of my application, each looking at their own 2.4MHz chunk of spectrum. No need to truly synchronize them.
http://www.ti.com/corp/docs/landing/cc1111/ - is the chip they're using.