Just wanted to make a quick post showing a slightly newer version of the Roflocator up for sale. I currently have 3 in stock and ready to ship. If you are interested in purchasing, please email me at admin@leetupload.com for details, click the PayPal button below or visit my Tindie page!
Note: For international orders, please contact me for the exact cost of shipping.
In the meantime, here are some new pictures!
I want to use this page to convey my thought and build process when building the Roflocator. The reason why I developed this device was because I once lost my quadcopter over an interstate and somehow found it in a parking lot across the highway by guessing its trajectory. I figured that there would be a market for some type of locator that does not rely on the pay-as-you-go model, such as the GSM GPS locators.
Breadboard Version
My first rendition consisted of the below pictures where I had a full arduino uno board and a 433MHz antenna that communicated the GPS coordinates to the other arduino and displayed them on an LCD screen. At this stage, I did not consider too much about the capabilities of the current 433MHz radios. After testing it out in the field, I quickly learned that this would not work (I could only walk down two flights of stairs before it would lose radio signal).
After doing a heavy amount of research, I stumbled upon the low power forums for radios and learned about the RFM69W. There were many new obstacles that I ran into when trying to get this device to work with my current setup. I had to choose the RFM69W model over the RFM69HW given that the latter pulls 130mA and the former pulls 45mA. The microcontroller that I settled on (after ruling out putting together my own arduino, due to the level of cost and effort) was an arduino mini pro, which has a maximum draw of 150mA — this would explain my choice for going with the lower mA pull with the radio, provided that I have a GPS and/or an LCD screen pulling power as well from the microcontroller. Another restriction for the RFM69W was that it could only pull power on 3.3v, which was yet another limitation that I had to overcome (originally when I had the arduino uno, which has a 3.3v and a 5v output, I had to use a voltage divider when my GPS had to use the only free output of 5v).
After using a wire that was the 1/4 wave length of a 433MHz signal as my antenna, I upgraded it to a 50 ohm impedance helical antenna measured at a full wave length of my 433MHz signal. This greatly improved the performance of my still breadboard setup, allowing my signal to propagate through apartment buildings and shrubbery. Much of my antenna and frequency tuning/analysis consisted of uploading new register modifications to the RFM69W (such as bitrate, power level, frequency deviation modulation, etc.), walking outside, and seeing how far I could go with the new register adjustments — all of which was quite the arduous process.
Perfboard Version
Now that my product seemed to be coming together, I wanted to make it more official looking as opposed to just a breadboard. I ordered a couple of perfboards and some wire, and got to work. I quickly learned that my soldering skills were not quite up-to-snuff. Countless nights I spent soldering all 150+ pins. I threw myself into the deep end. Between soldering on headers onto all of the modules, soldering them onto the perfboard, routing the wires in a neat and organized fashion across the perfboard, then soldering the wires onto the connectors, it was a rough time.
PCB Design and Printing
With my finished perfboard product in hand, I had another obstacle to overcome: PCB design. I had no prior knowledge as to how any of this worked. I didn’t know what tracing was, what Eagle was, and how important pitch was. To create my board, I had to first create all of the other boards in Eagle that would be used to create the size of the holes and traces onto my two PCBs. This process took me about a week or so to complete. Considering that the only diagram I had in Eagle was the arduino pro mini, I had many more modules to create before I could lay them out. I used OSHPark to print out my boards, and had a great experience with them. Unfortunately, for my first batch of boards, I did not make the drill hole sizes large enough to accommodate the pins for my RFM69W. After yet another deep end of the pool experience, and another set of PCB boards later, I had printed and received my first custom set of successful PCBs.
Vendor Relationships
Dealing with the vendors was a quest in itself. Negotiating with manufacturing facilities in China to solder the headers onto my modules proved to be difficult, given the following: they wouldn’t want to do it because of the cost associated with it, and that English was not their strong suit. With the help of my Chinese friends to craft a convincing email, this still proved to be difficult. After many emails back and forth, I received, after 3 weeks of waiting, my arduino pro mini soldered with the headers. Success. Other obstacles I ran into was with receiving my radio module with the breakout board surface mount soldered on — these guys were saints. They went out of their way to surface mount and include their breakout boards for free along with a just $1 charge for soldering the headers on as well. The only trouble I had was a bit of the email communication back-and-forth, and I received the headers soldered on at an angle (though, this was due to the boards not being the standard width that would fit on a board with 2.54mm holes spacing, so the tech was making an assumption and attempting to be courteous). That’s no matter though, as the pins were slightly adjusted to accommodate my PCB’s pin spacing.
Finished Product
After getting the boards professionally soldered on all together, I had almost a finished product. Now all I needed to do was to solder the on/off switch together, cut out two holes in the PCB case to fit my components, and hot glue it all down. I just finished this a few hours ago prior to writing this article.
The Roflocator Welcome Screen
Inside of the LCD receiver
Prior to placing the receiver into the case The GPS transmitter
Final Thoughts
I am thankful to say that this project is complete, and I have gone from stem-to-stern through the product development process: I developed the product, wrote the firmware, QA’d and performed frequency analysis, negotiated with vendors for sourcing, designed and printed the PCBs, and put it all together in a final product box. This has been a great experience for me in the hardware world and I hope to continue to expand my knowledge in this space.
Have you ever lost your quadcopter? Do you lack the means of tracking your quadcopter? The Roflocator is the solution to your problems. This device tracks your quadcopter and constantly notifies you of its current coordinates. It’s simple to install, cost effective, and easy to use.
How does it work?
The Roflocator has two transceivers that can transmit and receive data over a large range. One of the transceivers sits on the quadcopter while the other is kept on your person. Once a GPS connection is locked with enough satellites (typically under 10 seconds in optimal conditions), the transceiver will begin to beacon the coordinates specifically to your transceiver. The coordinates will then be displayed on the LCD screen and you will be able to keep track of your quadcopter’s exact location at all times.
What is included?
1 x quadcopter GPS transceiver
1 x receiver
Who is this solution tailored toward?
People who wish to track their quadcopter without the hassle of paying for a monthly SIM card along with the cost of a device to transmit the coordinates, or for individuals who wish to fly their quadcopter in a remote area where cell phone coverage covered is scarce.
What will the final product look like?
The final product will have an ABS plastic enclosure for the receiver with a 9v battery enclosure. The PCBs will be professionally manufactured and lead free (ENIG finish).
Customizable Orders
Below is a list that articulates what packages you will be able to purchase. The GPS enclosure will be the only feature that will alter the price.
Battery connector: 9v Battery or 3.7v Lithium Ion Polymer
GPS Enclosure: Yes or No
Firmware: Longitude/Latitude Only (longer battery life) or Altitude, Speed, and Longitude/Latitude (shorter battery life)
Prototype Pictures
Quadcopter GPS Transmitter
Receiver
The GPS coordinates are partially blurred in this photo.
Installing in WLToys V262 quadcopter
Technical Specifications
Quadcopter GPS Transmitter
Radio Frequency: 433MHz
Range (line-of-sight, optimal conditions apply) : ~1KM
Range with Interference: ~200M
Battery: Default is a 9V battery — customizable to accept 3.7V Lithium Ion Polymer rechargeable battery
Receiver
Radio Frequency: 433MHz
Range (line-of-sight, optimal conditions apply) : ~1KM
Range with Interference: ~200M
Battery: Default is a 9V battery — modifiable to accept 3.7V Lithium Ion Polymer rechargeable battery
LCD Resolution with backlight: 48px x 84px
Enclosure: ABS Plastic
When and where can I buy this?
By following the link below, you will be able to pre-order The Roflocator. Please allow 3-4 weeks lead time for production.
I wanted to mount a Nexus 7 tablet in my vehicle after seeing posts on mbworld.org. Could be fun, right?
Well, here are some things to consider:
I will address these later.
Benefits
Here is what you will need:
Software:
Now that we have our materials, let’s mount the tablet. Open the lid where the current monitor resides in the vehicle. With the lid up, measure underneath where you want your shower door catches to reside. What’s nice about these is that there is a white nub that is spring-loaded and will rest right underneath your screen door lid and exert pressure against the bottom of the monitor “floor”.
Once that’s all measured, place the cover on the tablet and mark where you want the shower door catches to lay on the Nexus 7 tablet case. Use my pictures below for reference.
Great. Next, take the rubber feat and place them in the recessed area where the tablet will be sitting. These will be behind the tablet and act as a means of supporting the tablet as it is being forced in place by the shower door catches.
Excellent. Plug in and sync up the tablet to the ViseeO Tune2Air WMA1000. This will enable us stream music from the tablet, through the car speakers, and control skipping song tracks from our steering wheel. This is a life-saving device. The sound quality is brilliant. Also, remember to plug in your tablet. This is pretty important. I wove the wire out the back, onto the dash, in between the windshield and the dash (it slides down inside easily). I then ran it through the passenger’s side, in the side of the glove box (after taking the side cover off). I then plugged the USB cable into the DC inverter which is plugged into the switched cigarette lighter.
Next, setup Tasker. I use my phone as a hotspot for the tablet. I am also lazy. This is where Tasker comes into play. Create a profile with Tasker such that WiFi tethering is enabled when your car’s bluetooth is enabled (this happens when the key in the ignition is turned to the first or second stage). Have it disable WiFi tethering when the key is placed into the off stage. There are other nifty things you can do with Tasker as well. Such as, turning the screen on along with the WiFi and bluetooth when any sort of charge is entering the tablet. Perform the opposite action when DC is cut from the tablet. There are plenty of other functions you can do with your tablet, but this is just a start.
Here is the final product:
Lessons Learned
Now, my tutorial does not stop with the above. This just so happens to define where I thought I was finished. Here are the problems that arose, and how I fixed them to the best of my abilities.
Heat
Where I live, it can easily be 100F out during the summer, and humid. And be incessant. How did I solve this issue? Well, I have tinted windows, so that helps marginally. I make sure that the sunroof shade is up, and I park in the shade whenever I can. But most importantly, I got a windshield shade. That pretty much did the trick for me! Prior to that, my tablet would be scalding hot to the touch, and would auto-shutdown. Lesson number one.
Battery Life
This is a big one. Considering that the purpose of this project was to semi-permanently install this device in my vehicle, it’s gotta get juice somehow. Here were my ideas and how the evolved over time:
Well, this would be great, in theory. Within a 24 hour period, I would lose 10% of my tablet’s battery life. I figured that my alternator would charge it back up during my commute to work or anywhere else, but I would only pull a few percent per trip. This was after exploring the option of “fast-charging” provided from the hacked kernel, ElementalX. In theory, the tablet would be able to stay on for approximately 10 days, then I would have to take it out and charge it prior to my next trip. Not worth it, in my opinion.
This one didn’t last me very long. Sure, I saved battery life, but waiting for the tablet to boot up each and every time I switched on the ignition was infuriating. Especially since it took probably a 2 or more full minutes for the tablet to turn on, all of the apps to load, and for Pandora to start playing my music. If still interested, though, you can achieve this with the following command:
fastboot oem off-mode-charge 0
When the tablet receives any form of DC, it will power on the tablet.
Nope. Not a good idea. Unswitching your cigarette lighter by messing with the fuse (I think that it is fuse #71 for my car) can cause overheating and not good things to come thereafter. Other than that, your battery will miraculously drain. Not a good idea.
I tried this, and my battery pack died in 4 days. So much for trickle-charging.
This was my final solution. Now, I can do numerous things to improve this setup: I can put a Qi charger on the back of the tablet and run that to the battery pack, which in turn is plugged into the battery pack. The other USB cable will run to the cigarette lighter. In between, I can fashion a switch to cut off the USB cable running from the Qi charger, and re-engage when the vehicle is off. When I re-enter my vehicle, I flip the switch back off again. At some point in time my battery pack will need to be recharged in my home. One way to stave-off this issue slightly would be to find a faster means of charging the battery. The highest input charge I’ve found on a battery pack so far is 20V @ 2A.
If you have anything to contribute to this project, please leave a note in the comments. I hope that this helps someone!
A fairly-well documented article has already been written about this for RTL-SDRs. But what about the USRP folks out there? The article’s cited files to use are even RTL-SDR geared. The easy response to that would be to suck it up, and purchase an RTL-SDR dongle. Well, you would be mistaken. Not every location has GSM bands that fall under 1.7GHz (specifically 850MHz for AT&T and T-Mobile). In some locations, CDMA rides on these bands. This can be a bit frustrating. Well, look no further than here. Fire up your USRP (read: HackRF, BladeRF, USRP, etc.) and follow the directions for the RTL-SDR here and stop at the point where it asks you to load their cfile for testing.
From here on out, follow these directions.
Replay attacks are probably the most rewarding tests to perform with a software defined radio — instant gratification (that is, if it works). No need to know the modulation, baud rate, deviation, frequency — well, you definitely need to know the frequency. You get the idea. From a post I submitted a while back with replaying a wireless outlet switch, it took a bit of work. But this is not always necessary, especially if your end-goal is simple replay, and not crafting of custom packets.
Given the aforementioned blog post, I was able to replay the signal for the wireless outlet switch and execute a simple “on” and “off” command (replaying the same command while the device is off, turns it on, and vice-versa). With the power of a USRP (if you can manage to buy one and make it stably work with GNU Radio, good for you), one is able to replay messages recorded by the USRP.
To record a message, one needs to know the frequency, bandwidth, and an educated guess at the appropriate gain (depends on your setup), are all necessary. Below is an example of a flow graph to be used for the recording piece. The source is the radio that is capable of RX, and the sink is the file we will write. We record and write in complex-float (aka complex). We do not need to demodulate, as it will replay as the file is.
To replay this content, we simply point to the source file and direct this to our now sink, which is a radio capable of TX/RX. We keep all of the previously recorded variables the same, otherwise the radio will have a spasm and our results will not be desirable.
Good luck and have fun!
Who out there misses all of the dog barking, grunting, and terms of endearment toward women provided by our beloved DMX? Something tells me that he is missed on our radio waves. With this brief entry, I will quickly breeze through showing how you can broadcast DMX one more time in your neighborhood (if your country allows for this, of course — this experiment was done at low db…).
I’m still learning how to use GnuRadio Companion (GRC), but I thought it would be of use to share this with the community, those that wish to have a bit of instant gratification with their newly acquired [HackRF, BladeRF, Ettus, etc.] and freshly compiled GRC on their nix VM. Below is a screenshot of my GRC setup along with the GRC file thereafter. The file source (as you can see in the screenshot below) had to be down-sampled at a rate of 16bit in order for GRC to be able to broadcast the audio file. I have it on loop, and the signal to transmit this onto can be adjusted with a slider. This setup is for an Ettus B100. However, with some minor tweaking, this should work on the previously mentioned TX/RX devices.
To modify your audio file, install ‘sox’ along with any libraries needed for whatever file you are handling. If handling an MP3 file, search for libsoxmp3 (or something to that effect). For the file in question, I ran:
sox DMX\ -\ What\'s\ My\ Name.mp3 -b 16 dmx_whats_my_name.wav
That’s it! Now your neighborhood will thank you for rejuvenating a lost art and making it available to everyone, once again.
In my previous post, I discussed the possibility of controlling one of those handy remote controlled outlets. Well, I got a hold of one, and decided to put my previous post to the test. I’ve even included a video, along with the code that I used. What more could you ask for? In the video, I attach my monitor to the remote control outlet switch and use my RFCat device flashed in my previous previous post to send a custom packet of data via 433.925MHz to the device. As you can see, the same signal is sent each time, turning the device on and off via its relay.
To better understand what is going on in this code, refer to my previous post that I have mentioned numerous times already.
#!/usr/bin/env python
import sys
import time
from rflib import *
from struct import *
import argparse
import pprint
import bitstring
keyLen = 0
baudRate = (1 / 0.000158) # pulse width
frequency = 433945000
repeatNum = 5
def ConfigureD(d):
d.setMdmModulation(MOD_ASK_OOK)
d.setFreq(frequency)
d.makePktFLEN(keyLen)
d.setMdmDRate(baudRate)
d.setMaxPower()
d.setMdmSyncMode(0)
print "[+] Radio Config:"
print " [-] ---------------------------------"
print " [-] MDMModulation: MOD_ASK_OOK"
print " [-] Frequency: ",frequency
print " [-] Packet Length:",keyLen
print " [-] Baud Rate:",baudRate
print "[-] ---------------------------------"
#raw what we are sending
bin_str_key = "1111010101010101110000010"; # This is the RC Switch Outlet payload;
#make it longer so it looks right
long_bin_key = "";
for k in bin_str_key:
x = "*"
if(k == "1"):
x = "11100" # <mossmann> A zero is encoded as a longer high pulse (high-high-low)
if(k == "0"):
x = "1000" #<mossmann> and a one is encoded as a shorter high pulse (high-low-low).
long_bin_key = long_bin_key + x
print "[+] Binary (PWM) key:\n\t",long_bin_key,"\n"
# Elongate this by 7 iterations since this is what the remote outlet switch requires
long_bin_key_modified = long_bin_key*7;
key_packed = bitstring.BitArray(bin=long_bin_key_modified).tobytes()
keyLen = len(key_packed)
print "[+] Key len:\n\t",keyLen,"\n"
print "[+] Key:\n\t", key_packed.encode('hex'),"\n"
print ""
d = RfCat()
ConfigureD(d)
print "[%] Transmitting key: ",repeatNum," times\n"
d.makePktFLEN(keyLen)
for i in range(0,repeatNum):
sys.stdout.write( "." )
d.RFxmit(key_packed)
sys.stdout.write("Done.\n")
Radios have been around for a long time. Security has not played a very long role within this realm. Consequently, precautions such as CRC, encryption, etc. are not always considered during the transmission of a radio signal. The below tutorial will highlight a replay of a modulated ASK/OOK signal that is non-return-to-zero (NRZ) encoded.
The 433.925MHz band is commonly used across many devices found all over our surroundings. From wireless doorbells to garage door openers, this band is fairly active in our daily lives. The demonstration of replay we will be covering will be wireless RC switches that are common in European households. These devices can be controlled wirelessly to turn on and off any electrical device connected. Naturally, this is an interesting device to investigate. Below is a picture of the device mentioned.
In short, signals are sent as NRZ encoded in the signal as it is sent to the receiver, and subsequently decoded and the function is processed. NRZ line code is binary code where a ‘1’ is represented as a positive voltage and a ‘0’ is represented as a negative voltage. The longer the pulse width, the greater the amount of data. Below is an example of NRZ:
So that we have a more controlled environment and since this is in the US, we will be using an Arduino Uno, an RF link set, and an Arduino ported RC Switch library. This will serve as our example remote controlled RC switch since they are not as common here as they are overseas.
Materials needed:
RTL-SDR (or some device which can at least receive; USRP, etc.)
SDR-Sharp (again, or equivalent; gqrx, HDSDR)
Some wires
Bread board
RFCat (see previous article)
Let’s get started. First, we need to connect and configure our Arduino with the RF Link set and program our microcontroller as a transmitter with the rc-switch library. In the below image is my setup as an example. For my RF 433MHz transmitter (as both the transmitter and receiver tend to vary in pin count and voltage), I have 3 pins on my transmitter: GND, VCC, and DATA. On the breadboard, connect the transmitter directly and connect the appropriate pins — GND to the GND pin on the Arduino, VCC to 5v pin, and DATA to whatever digital pin you choose.
http://rc-switch.googlecode.com/svn/wiki_images/wiring_transmitter.png
With the Arduino physically configured correctly, fire it up and commit the following code (modifying to your pin setup where necessary).
/*
Simple example for sending
http://code.google.com/p/rc-switch/
*/
#include <RCSwitch.h>
RCSwitch mySwitch = RCSwitch();
void setup() {
mySwitch.enableTransmit(2); // Using Pin #2
}
void loop() {
mySwitch.send("1100101"); // Send the message 0x65, in ASCII, ‘a’
delay(1000); // 1 second delay per transmission; 1000ms
}
Now that the Arduino is setup, we need to find the signal by using RTL-SDR and SDR-Sharp on our Windows box (you can use gqrx or HDSDR if you are so inclined). Note that the signal generated from the RF link set is not the best. The frequency that it resides on varies at times. However, it should be right around 433 ~ 434MHz. Since this is an AM modulation, select “AM” when listening for the signal.
Once you find the signal, record it as a WAV file. Open the signal in Audacity and examine the transmission. As you can see below, it is a fairly straight-forward signal. Without looking at the source code, we can assume the following: it is NRZ encoded, it has been pulse width modulated (PWM), and it is ASK/OOK (Amplitude Shift Keying / On Off Keying — this essentially means with OOK that the carrier is switched on and off in order to convey the presence and absence of data [binary representation]). The last piece of information we need to gleen from the signal is the baud rate. To calculate the baud rate of a signal, follow the steps below:
Set the tool at the bottom to length and change the measurement to samples
Get the sample rate of the audio (in this case, it is 62,500Hz)
Formula for getting the baud rate:
1 / (samples / samplerate) → 1 / (22 / 62500) = ~2,840bps
Most of the time, this will work, be accurate enough, and serve as one of our variables in our recipe for RFCat.
Given that this signal has been PWM’d, we need to elongate each pulse width to the appropriate length. Unfortunately, most of this takes trial and error. Thankfully, AndrewMac put together the perfect script which addresses these concerns in conjunction with RFCat. With our RFCat dongle in hand, we will be able to transmit our hand-massaged signal which will hopefully be well-received by our Arduino receiver. When dealing with RFCat, we need to define different settings prior to transmitting our data. Given everything we learned earlier about the signal, we need to define the following as such:
d.setMdmModulation(MOD_ASK_OOK) d.setFreq(frequency) d.makePktFLEN(keyLen) d.setMdmDRate(baudRate) d.setMaxPower() d.setMdmSyncMode(0)
We first set the modulation to ASK/OOK, set our target frequency to 434042000Hz (433.925MHz), essentially define how long our message is, set the baud rate to 2840bps, ensure that the transmission is set to full power, and to disable any preamble or syncwords, set Sync Mode to 0.
With the assumption that you have a somewhat solid understanding of RFCat (from previous articles) as well as python, the below script will help us execute the above with the necessary padding and PWM adjustment such that we receive a matching transmission.
/*
Script by AndrewMac of andrewmohawk.com
*/
#!/usr/bin/env python
import sys
import time
from rflib import *
from struct import *
import argparse
import pprint
import bitstring
keyLen = 0
baudRate = (1 / 0.000350) #because the pulse width is 350 in the code
frequency = 434042000
repeatNum = 30
def ConfigureD(d):
d.setMdmModulation(MOD_ASK_OOK)
d.setFreq(frequency)
d.makePktFLEN(keyLen)
d.setMdmDRate(baudRate)
d.setMaxPower()
d.setMdmSyncMode(0)
print "[+] Radio Config:"
print " [-] ---------------------------------"
print " [-] MDMModulation: MOD_ASK_OOK"
print " [-] Frequency: ",frequency
print " [-] Packet Length:",keyLen
print " [-] Baud Rate:",baudRate
print "[-] ---------------------------------"
#raw what we are sending
bin_str_key = "1100101";
#adjust the key to make it longer so that the pulse width is correct
long_bin_key = "";
for k in bin_str_key:
x = "*"
if(k == "1"):
x = "11100" # <mossmann> A zero is encoded as a longer high pulse (high-high-low)
if(k == "0"):
x = "1000" #<mossmann> and a one is encoded as a shorter high pulse (high-low-low).
long_bin_key = long_bin_key + x
print "[+] Binary (PWM) key:\n\t",long_bin_key,"\n"
padAmount = len(long_bin_key) % 8
for x in range(0,8-padAmount):
long_bin_key = "0" + long_bin_key
print "[+] Binary Padded (PWM) key:\n\t",long_bin_key,"\n"
key_packed = bitstring.BitArray(bin=long_bin_key).tobytes()
keyLen = len(key_packed)
print "[+] Key len:\n\t",keyLen,"\n"
print "[+] Key:\n\t", key_packed.encode('hex'),"\n"
print ""
d = RfCat()
ConfigureD(d)
print "[%] Transmitting key: ",repeatNum," times\n"
#startString = "11101";
startStringBin = "000000000000000" + "1000100010001000111001000"
startkey_packed = bitstring.BitArray(bin=startStringBin).tobytes()
d.RFxmit(startkey_packed)
d.makePktFLEN(keyLen)
for i in range(0,repeatNum):
sys.stdout.write( "." )
d.RFxmit(key_packed)
#endString = "011";
d.RFxmit('\xFF')
sys.stdout.write("Done.\n")
To briefly explain what the code is doing, we are taking our pre-defined settings such as modulation, baud rate, etc. and applying it to our RFCat configuration. We then take our key that we wish to send (already dissected from the Audacity screenshot taken above) and assign it to the variable bin_str_key. We then alter the key so that all ‘1’s are 11100 (high-high-low) and the ‘0’s are 1000 (high-low-low). Our original key (1100101) is now mutated into a new binary PWM key which now appears as 11100111001000100011100100011100. Our pulse width is now accurate. The next step is to pad the binary PWM key, convert it to bytes (so that the data is not sent out as ASCII), and then take the length of the now-in-byte format binary PWM padded key in order to set d.makePktFLEN(keyLen) so that RFCat has a fixed key length when sending the data. Now that the beef of our information has been created, we now need to create the start and end bits so that our Arduino program knows when our data transmission begins and when it ends. After all of this is defined, we then execute the following RFxmit() functions in order: d.RFxmit(startkey_packed), d.RFxmit(key_packed), and d.RFxmit(‘\xFF’). The end transmission appears as: 00000000000000010001000100010001110010001110011100100010001110010001110011111111
This message is then sent ~30 times given that our receiver is a bit finicky, and that it is a requirement for the signal to be sent 10 times to be considered a complete message (as per the rc-switch source code). However, to check and make sure that the signal was originally sent correctly, modify repeatNum to equal ‘1’, re-record the signal in SDR-Sharp, and line-up the result against the originally recorded Arduino frequency. It should look virtually the same.
Take your Arduino and use the following code to receive:
/*
Simple example for receiving
http://code.google.com/p/rc-switch/
*/
#include <RCSwitch.h>
RCSwitch mySwitch = RCSwitch();
void setup() {
Serial.begin(9600);
mySwitch.enableReceive(0); // Receiver on interrupt 0 => that is pin #2
}
void loop() {
if (mySwitch.available()) {
int value = mySwitch.getReceivedValue();
if (value == 0) {
Serial.print("Unknown encoding");
} else {
Serial.print("Received ");
Serial.print( mySwitch.getReceivedValue() );
Serial.print(" / ");
Serial.print( mySwitch.getReceivedBitlength() );
Serial.print("bit ");
Serial.print("Protocol: ");
Serial.println( mySwitch.getReceivedProtocol() );
}
mySwitch.resetAvailable();
}
}
Thereafter, configure the receiver component you have and wire it identically as you already have on the Arduino, except rearrange the order of the wires. With my receiving component my pin order from right to left is: GND, DATA, DATA, VCC. In my setup, I only use the first data pin. The below diagram may be of use.
http://seeedstudio.com/wiki/images/0/0f/315433RF.jpg
Assuming that your signal matches up, go ahead and run the script with a higher repetition than 1 iteration, such as 30+. With any luck, your signal should have been successfully replayed!
What is RFCat?
RFCat is firmware/python-client combination written by “atlas”. This software takes the once-limited TI CC1111EMK and broadens its abilities. Taken from the GrrCon page (where you can buy it for $110 pre-flashed and ready for you to use out of the box) describes RFCat as:
@Signed, flashed RfCat USB Radio Dongle (based on Chipcon CC1111EMK-868-900), making the opacity of Proprietary protocols into transparency and capacity for attack
Capable of transmitting/receiving/snooping/SpectrumAnalysis on frequencies between 300-928MHz and more (officially 315, 433, 868, 915MHz ranges, but we’ve seen more than that) using modulations 2FSK, GFSK, MSK, ASK, and OOK and baud rates 0 – 250kbaud
Why would I use this?
Good question. Well, if you are a Software Defined Radio enthusiast like me, this is an excellent tool for testing the robustness of radio protocols on various embedded devices. Since this piece of hardware transceiver with the modulation, etc. taken care of for you, this is the perfect device for helping with your every day exploration of radio signals.
Enough chit-chat. Below I have mapped-out how I “made” my un-flashed CC1111EMK into a fully-functional RFCat dongle. It cost me about $80 going this route; saving a little bit of cash, learning a lot through trial and error, and having the ability to re-flash my device again when a RFCat firmware comes out made this venture worth it.
What do I need?
SUBSYSTEMS=="usb" ATTRS{idVendor}=="1d50" ATTRS{idProduct}=="6049" SYMLINK+="RFCAT_BL_C"
SUBSYSTEMS=="usb" ATTRS{idVendor}=="1d50" ATTRS{idProduct}=="604a" SYMLINK+="RFCAT_BL_D"
If you would like further details on an example project while using RFCat, head over to Andrew’s blog — he has a great write-up using RFCat and harnessing Python’s power!
Also wanted to point out that I could not have done this without the help of user “poutine” and “AndrewMac” from the Freenode IRC in channel #rfcat. Thanks again!