Showing posts with label wireless. Show all posts
Showing posts with label wireless. Show all posts

Sunday, January 8, 2012

Initial look at the new Bluetooth wireless hardware and software, know as Bluetooth LE, 4.0 or Smart

The Apple iPhone 4S was the first hardware out the gate with support of this new wireless protocol. Now a few months later 3 or 4 Android phones are hitting the market with support as well.

A couple things make this technology really interesting for sending data at low to mid range data rates, say from 10 bytes per second up to a hundred thousand bytes per second.

It does look to have a few warts out the gate and there are other players in the market today and on the way. But my sense is they have put together enough of the right pieces, that in combination with the 'Bluetooth' name, market penetration and consumer understanding such that it will become the low power device connection standard.

The first benefit is that the sensor or 'end point' devices will consume very low power, battery life should range from multi-days to years and the power source need not be more that one AAA battery. Or even smaller, for example hearing aid batteries. And not to far out devices powered by solar and also using other energy harvesting methods.

The second benefit is that it is under the Bluetooth wireless family name. With Billions of phones and computers currently in the market with Bluetooth 2.x built-in, so many consumers know how Bluetooth is able to make a wireless headphone or data transfer connection today. This is a consumer adoption barrier reducer. Although Bluetooth Smart is really a combination of new wireless hardware and software that only shares some common data structures, high level API architectures and runs in the same frequency range as the current Bluetooth 2.x technology. To make it clear, a 'Bluetooth Smart' device will not communicate with ANY of the existing Bluetooth 2.x phones, devices or adapters in computers, cars or anything else prior to the iPhone 4S. More on these family incompatibilities in a bit.

Bluetooth sits in a 'distance between devices' area between 'under a foot' to 15 feet. This is a space that the current Bluetooth devices have done a very good job of providing 'cable-less', reliable and low cost connections. Bluetooth Smart improves that with lower cost and lower power while improving the connection setup speed and simplicity. There is and will be overlap with this technology and Wifi on the high speed and distance side and the new emerging NFC ( near field communication ) technology on the close in financial transaction side. However the strength of Bluetooth Smart will keep it in control of this zone around your phone and computer. And it is going to open up wireless communication by many other devices in this zone. Examples include household appliances, door locks, sensors, medical devices, fitness devices and many yet to be thought of applications.

Another huge benefit that Bluetooth Smart has, has nothing to do with technology, but rather that the benevolent technology dictator, Apple, [ or happy walled garden, if you prefer a positive spin on Apple's control ] has now opened Bluetooth Smart on the iPhone 4S and most likely all future iOS hardware to all hardware and software developers. Prior to iOS version 5 and the iPhone 4S only limited types of wireless data transfers in and out of iOS devices was allowed. Now a iPhone 4S can send and receive any type data from a custom iOS app with no restrictions placed on it by Apple [ although the app will still need to be 'approved' by Apple for sale in the App Store ]. So what does this mean? It means that a hardware developer can build one device that will communicate with Apple, Android and other phones and devices, as long as they have the Bluetooth Smart hardware and software support. Examples of this include health and fitness equipment [ I am wearing a Bluetooth Smart heart rate sensor as I write this ]; gaming devices, it will now be possible to write a app or game that will easily communicate between a iOS device and an Android device. There is no doubt that leading edge wireless connected devices [ The Internet of Things ] will often first appear in the Apple iPhone space, now these devices will be able to appear on the larger market [but often lower priced] Android market at the same time [ the availability of the app on the device is the only gate ].

All of these positives make me believe that Bluetooth Smart is going to be the standard going forward in this 'zone' and we are about to see a big wave of new wireless connections between things.

The roll out of devices with Bluetooth Smart is going to take a couple years, that is the turn over period of many 'smart phones' today based on carrier contract length and the technology price/pain obsolescence curve. The hardware development kits are starting to rollout and get on the radar screen of companies and developers with ideas. The first Bluetooth Smart devices have hit the market already, including the Wahoo heart rate belt I am trying. The ramp up of more of these devices will take about twelve to eighteen months, and getting the software bugs and battery life tuning will take about the same period. So the two year window [ starting from 4th Qtr 2011 ] of mass adoption seems about right.

To some of the challenges that the adoption faces......

First, there is the good/bad thing that is the name Bluetooth. Yes, many current phones have Bluetooth. However, they will not talk to devices with this newer Bluetooth Smart hardware. New phones that are rolling out, including the iPhone 4S have both the old and new Bluetooth radios and software built in. This will allow them to talk to both type devices. Devices that have this ability are given the Bluetooth marketing name 'Bluetooth Smart Ready'. Get the difference? The word 'Ready' at the end signifies that the device has the hardware and software to talk to Bluetooth 2.x and Bluetooth Smart devices. So, having devices around for a number of years to come that only take old Bluetooth 2.x is going to be one of the challenges to adopting this new Bluetooth Smart. I think the naming of the technologies is not very clear, though I am not sure I can think of a better set of names that would make it clear to the consumer market. Plan a lot of devices returns and tech support hours during this transition period. Here is a web page at the Bluetooth industry group that tries to explain the terms and technologies.

Another challenge is from the other wireless technologies either encroaching on this zone or directly compete with it. The biggest [and perhaps the only ] direct competitor is a wireless technology called ANT+. It has been used in the sports and fitness areas for the last 18 months. It is probably an equally good wireless technology as Bluetooth Smart, it just did not get traction in the other areas of use in this 'zone'; for example wireless audio, headphones speakers. Not getting adaption in this large use case has limited its adoption. A number of Android phones have ANT+ technology built into them today, probably millions of phones, but a vast majority of the phone owners have no idea it is there. Most of the ANT+ hardware vendors are moving to Bluetooth Smart, but this transition will be a small slow down. Mostly, I think, will be due to media sound bites playing up this 'dead end' for some users and their devices.

The other direct challenger in this area is the Zigbee/802.15.4 technology. They have been a long time player in this space, the longest I think and perhaps have the strongest technology. However, other than their new standards in the home remote controls and home energy market [ smart meters ] they have not been able to gain a foot hold in the consumer space. I do not think they will either, perhaps too bad. But perhaps one of the examples of the better technology not winning.

The 'encroachment' challenges may come from the WiFi hardware manufactures. They have been promising a WiFi radio that will cover the current WiFi use cases as well as the current Bluetooth ones. And do all of the same 'new' low power/low cost stuff as good or better [ their belief ] as Bluetooth Smart. But these radios have seemed to be 'right around the corner' for at least the last year. I think they will produce a hardware device that may meet all of these goals, but I think will be too late to market. Wifi will need to scale across a very large data transfer range, from gigabits to bits while doing this with compatibility [ at least in name like Bluetooth ] and power budget. I don't think WiFi will win, but I think we will see devices and this will add to the transition confusion of Bluetooth Smart. At the other end, I do not see the NFC/RFID technologies trying to move 'up' into the Bluetooth zone, the technology does not seem to support the data rates and power budgets that Bluetooth use cases need. There is talk that Bluetooth Smart will try to move down into the NFC zone, specifically for financial transaction applications. This battle is still to be fought, however NFC has a strong foot hold and seem to be getting support from the credit card companies. There are other battles going on around who owns this market, other than the encryption chip technology, I do not think this will be decided by wireless chip vendors.

Another thing that I think will cause some bumps in the Bluetooth Smart adoption is the current licensing and developer tools costs. While the cost of Bluetooth has been going down for the consumers, these price reductions have come due to more sales of phones and other devices not due the Bluetooth license and tools costs being reduced. As the open hardware trend is expanding, Bluetooth licensing remains proprietary. I think this closed development community will stifle innovative ideas for use of this ubiquitous connectivity of devices.

I have been experimenting with a Texas Instruments prototyping kit for Bluetooth Smart, it is based on their CC2540 chip family. I have several devices that I have wired up talking to a iPhone 4S and desktop computers using the Bluetooth Smart system. I do not have a Android device as yet with the Bluetooth Smart hardware. I've been following the developer forums at TI and a couple of other hardware manufactures that have Bluetooth Smart chip sets just now in the market. It is still a learning period of a lot of developers [ and hacks like myself ], but much progress is being made. At least by those that have deep enough pockets for the compilers and license fees.

Get ready for a MASSIVE explosion of The Internet of Things [ #IoT ] in the next couple of years, our phones, tablets, appliances and transportation devices are going to be connected to tens of other devices during the day and night.

TI CC2540 Development KitTI iOS CC2540 Demo

Tuesday, January 26, 2010

RFID passport privacy issues uncovered: A Traceability Attack Against e-Passports

This paper by Tom Chothia and Vitaliy Smirnov at the University of Birmingham shows another example of why open source vetting and more transparency are necessary before massive Internet of Things systems are rolled out.

Their conclusion:
'Our work shows the inherent dangers of using RFID tags in personal items.'

Berg Insights research: 1.4% of world wide wireless connection are machine to machine (M2M)

The research firm, Berg Insights, did a study at the end of last year  that finds that 1.4 percent of wireless communications is from one machine to another. And this is predicted grow by 26% per year. In the USA, Berg says the current percentage of wireless M2M connections is 4.3%.

This is the 'Internet of Things' growing at a very fast pace. This research only focuses on the mobile/cellular market, so the machine to machine communications in other frequencies [WiFi, Zigbee, Dash7] are even larger.

From Berg's research paper:

New M2M initiatives launched by major mobile operator groups are expected to have a positive influence on demand, stimulating new large-scale projects. Regulatory developments are predicted to have a major impact on the telematics industry. The EU is expected to propose formal legislation for the introduction of eCall by 2014 but in Brazil the fate of Resolution 245 is more uncertain. Another significant development to watch will be the progress of the Dutch government’s plans to introduce a nationwide electronic road charging system for all motor vehicles.

Saturday, January 23, 2010

TI eZ-430 Chronos watch based wireless door lock

Ziyan Zhou and Zachery Shivers are two smart young guys studying at Rochester Institute of Technology. They have created a very nice project based on the low power TI 430 microcontroller and 9xx mHz wireless chips from Texas Instruments. I beat up on TI in a previous blog entry for their shoddy code review that allowed a big security bug to slip through in their Zigbee chips. Despite that fail, TI creates some very nice hardware that is enabling the Internet of Things. This project by Zhou and Shivers is a great example of what is going to explode in the coming months and years. They do a very nice job of reviewing security issues in their design. Give their project and the others at the TI430 low power design contest web site a look, good stuff! Vote for the one you think is tops, my vote was to Ziyan [Joe] and Zach.

Monday, January 18, 2010

TI Zigbee chips in SmartMeters easily hacked

It was very sad to see this article about the shoddy job that was done in creating a solid PRNG for the Zigbee smart meters that the TI chips are installed in. Apparently a large number of the current meters have the TI Zigbee hardware:
Texas Instruments to patch smart meter crypto blunder

You have to wonder about the quality of any other software coming out of that group. Were is the QA, code review? This reenforces my opinion that open source is the best path for much of the systems development going on now. Unless you can afford a Space Shuttle software development effort, I do not see other good routes to good software. This was such a basic blunder, with so much very recent history of similar shorts cuts causing WiFi systems to be vulnerable how could this happen?

This guy, Travis Goodspeed, and a couple of others are doing a real service getting these issue out in the light. And I am guessing with no help from the likes of TI, Zigbee or others.

While it not clear if this mistake will make it any more possible for hackers to 'bring the grid down'. It sure looks like it will slow the deployment of energy saving and GHG reducing solutions for residential and commercial buildings and that is bad enough.

Come on, you can do better!

Sunday, January 3, 2010

Zwave Home Automation, Leviton RS232 Serial Interface RZC0P basic wiring for USB Serial Adapter

I've started to work with a ZWave home automation control product from Leviton, the RZC0P-1LW. This device allows the control of Zwave based wireless home automation devices via a RS-232 interface.

The Zwave system is a proprietary system requiring a licensing agreement with Zwave Alliance group. Joining this group and paying some level of fees gives a developer access to programming and related information. The lowest level of membership in 2009 appears to be the Affiliate Member with an annual fee of USD300 and perhaps the requirement to purchase a USD500 hardware development kit.

There are a couple of other ways to programmatically work with Zwave devices, there are several home automation software and hardware systems that put one or more layers on top of the Zwave proprietary protocol. Doing a Google search of home automation and zwave will give you a list of these product. There are even a couple of open source projects that have reverse engineered parts of the Zwave control protocols and devices.

And a third way, in a sense a mini home automation layer, is to use one of these RZC0P devices in an existing Zwave network. As far as I can tell so far, the RZC0P cannot be the primary controller of a Zwave network. And every Zwave network requires one of these primary controllers to add, delete and manage the devices in a Zwave network. However, the RZC0P can be included as what is called a secondary controller. And a small amount of documentation has been created by Leviton to show you how to do basic functions to Zwave devices via ASCII commands to the RZC0P.

I've studied the Zwave products, vendors and public information for a couple of years. More on what I have found about it and my opinions later.

But for now, I wanted to share some tech work I did to get the RZC0P running on a small Zwave network I have set up to explores of of the uses of these devices for both Aging In Place and Energy Management.

I am not a RS-232 expert nor an electrical engineering guru. But I have spend enough time in both of these areas that I knew that I had a problem talking to the RZC0P pretty quickly. I had the documentation on the ASCII commands and the RS-232 configuration requirements. Using these, I hooked the RZC0P up to a IBM Thinkpad with a build in RS-232 port and was able to start communicating with the device right a way. The problems came with I tried to move my testing to a Apple OS X computer with a KeySpan USA-19HS USB serial adapter. I wanted do my testing using the Python language and tools and was more comfortable with using these tools on Linux and OS X.

The problem I encountered was that I could not get the RZC0P to respond to commands when attached via the KeySpan USB serial port. I did not try the KeySpan USB adapter on the Windows machine, but I suspect from reading some posts on the web that I would have found a similar problem. I found several other people that indicated they were only successful in communicating with the RZC0P using a serial port directly attached to the Windows machine.

At first I suspected that I was not correctly toggling some of the RS-232 control signals, however the devices cable and documentation point to, but do not directly spell out, that only TX, RX and Signal Ground pins are required on the cable and no software or hardware handshaking is done.

A further interesting fact appear as I played around with various terminal emulators on OS X and cable combinations. At various points of these changes, the RZC0P would start communicating. I struggled to find the pattern that made it work.


Well bottom, apologizes for my long route to my conclusion here.. I suspect that the RZC0P has some bug or non-standard implementation of RS-232 electrical interface. I found that if I used a RS-232 break out box between the Keyspan USB serial adapter and the RZC0P, with just the three pins, TX, RX and Signal Ground connected, the unit would work consistently. I could plug and unplug it, power it off and it would always come right up and communicate with the Mac software. So what was special about this RS-232 break out box?

The breakout box connects a set of LED from the TX and RX lines to signal ground via pull up resistors. This allows you to visually see the signal states change on these and other lines on the RS-232 specification. The breakout box I was using is a totally passive unit that adds no power or logic to the RS-232 signals it monitors.

So my conclusion is that the signal ground and RX/TX lines on the RZC0P are wired internally in some way that caused the logic circuit to not correctly start RS-232 communications without some electrical connection/kick between the RX/TX lines ad signal ground line.

My solution to the problem was to build a mini 9 pin DB-9 Male to Female adapter that recreated the passive monitoring circuit I found in the RS-232 breakout box.

I am guessing there is a better and simpler solution to this problem, but this seems to be working, and you get some visual feed back of the communications occurring via the two LEDs. Below is a picture of the finished adapter.

aw9345lzw.jpg

Here are the parts and steps:

Parts:
Male 9 pin DB-9
Female 9 pin DB-9
2 - 560 ohm 1/4 watt resistors
2 - LED
wire to connect pin 2 to pin 2, male to female DB 9
wire to connect pin 3 to pin 3, male to female DB 9
wire to connect pin 5 to pin 5, male to female DB 9

Steps:
Connect pin 2 to pin 2, male to female DB 9
Connect pin 3 to pin 3, male to female DB 9
Connect pin 5 to pin 5, male to female DB 9

Connect pin 2 on the male DB-9 connector to one lead of a 560 ohm 1/4 watt resistor
Connect the second lead of the 1st 560 ohm resistor to the anode lead of the 1st LED
Connect the cathode lead of the 1st LED to pin 5 on the male DB-9 connector

Connect pin 3 on the female DB-9 connector to one lead of the 2nd 560 ohm 1/4 watt resistor
Connect the second lead of the 2nd 560 ohm resistor to the anode lead of the 2nd LED
Connect the cathode lead of the 2nd LED to pin 5 on the female DB-9 connector


Friday, December 18, 2009

Review by Walt Mossberg @ WSJ of USB connectable Diabetes Meter

One of the areas I am interest in is easy to use medical measurement devices. Weight, blood pressure, temperature, glucose, pulse, breathing, sleep patterns are among the measurements that can be recorded as part of proactive medicine. These will let us Age In Place much more successfully.

AW78U0E794.jpg

Walt Mossberg has a review of a device that is a small first step toward easy to use and record products, the Bayer Contour USB blood glucose meter

A key piece that is missing from this device, is wireless upload, you have to connect it to your PC via USB. The technology in the area of low power wireless short range communication has really shot forward. I think any device that does not easily transfer its measurements wirelessly to a personal computer or some home health gateway is not useful enough to really jumpstart proactive medicine.

As Walt points out, the other major missing aspect of this device is it lack of ability to upload it's reading to one of the Personal Health Record systems, for example Microsoft HealthVault or Google Health. This is key so that a person's doctor and caregivers can have near real time information about these measurements.

So this is the right direction, just not enough of a step forward yet. Give Mr. Mossberg's text or video review read/listen.

I am excited about wireless devices that will help us live a much more healthy and happy total life.

Sunday, December 13, 2009

Using the Nordic nRF24L01+ 2.4GHz transceiver with Adruino

I picked up a Nordic nRF24L01+ breakout board and keychain remote FOB from Sparkfun.com a while ago to see about using it as part of a Aging In Place electronics project. Finally got around to experimenting with the pair this weekend. It was a cathartic break from working a plumbing problem.

I could not find much info on using it with the Arduino platform. To get my feet wet I just moved an example program written for AVR PIC to Arduino's language. I have posted it below.

The Nordic communication chips seem to be a good product for low power, long life remote control. The questions of range and clashes with other products in the 2.4GHz bands are still open.

The steps to talk with the Nordic chips are very straight forward. It uses the SPI communications for interfacing and has a simple interrupt architecture for status [the code below does not use the interrupt]. The Sparkfun breakout board is a nice starting point as it allows hookup to either 5 volt or 3.3 volts products by providing onboard voltage for the Nordic. And the Nordic chips are natively able to talk 5 or 3.3 volt.

I will compare some of these functions and price points with some of the other similar products out there. The Texas Instruments wireless products are one set that I want to compare.




// nfr2401_02
// 13-December-2009
//
// learning how to communicate with a Nordic nfr2401 wireless communications module.
// this program will set up a nfr2401 as a receiver and receive data from the key presses on a Sparkfun Nordic nfr2401 keyfob.
//
// parts:
// Transceiver nRF24L01+ Module with Chip Antenna Sparkfun sku: WRL-00691
// Nordic FOB Sparkfun sku: WRL-08602
// Arduino Deiecimila
//

// based on Nordic-FOB-Tester-v10.c written by Nathan Seidle at Sparkfun.com in 6-19-2007
// based on article and code 'Interfacing a Serial EEPROM Using SPI' at Arduino.cc by Heather Dewey-Hagborg

// SPI registers defined in basic Arduino:
// SPCR SPI Control Register
// SPDR SPI Data Register
// SPSR SPI Status Register

/* Arduino SPI register info
Data registers simply hold bytes.
For example, the SPI data register (SPDR) holds the byte which is about
to be shifted out the MOSI line,
and the data which has just been shifted in the MISO line.

Status registers change their state based on various microcontroller conditions.
For example, the seventh bit of the SPI status register (SPSR) gets set to 1
when a value is shifted in or out of the SPI.

The SPI control register (SPCR) has 8 bits, each of which control a particular SPI setting.

SPCR
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| SPIE | SPE | DORD | MSTR | CPOL | CPHA | SPR1 | SPR0 |

SPIE - Enables the SPI interrupt when 1
SPE - Enables the SPI when 1
DORD - Sends data least Significant Bit First when 1, most Significant Bit first when 0
MSTR - Sets the Arduino in master mode when 1, slave mode when 0
CPOL - Sets the data clock to be idle when high if set to 1, idle when low if set to 0
CPHA - Samples data on the falling edge of the data clock when 1, rising edge when 0
SPR1 and SPR0 - Sets the SPI speed, 00 is fastest (4MHz) 11 is slowest (250KHz)

*/

#define DATAOUT 11 //MOSI
#define DATAIN 12 //MISO
#define SPICLOCK 13 //SCK
#define CHIPSELECT 10 //CS, also called SS slaveselect

#define NFR_CE 9 // nRF2401 sets the chip to RX or TX mode
#define NFR_IRQ 8 // active low interrupt from nRF2401

byte clr; // temp to hold discardable SPI return data

byte data_array[4]; // holds data in packet received from Key FOB

byte incoming; // holds status register of nfr2401

int button_presses; // holds count of number of times a button had been pressed on FOB [since battery replaced]


// routine to send and receive a byte on SPI

char spi_transfer(volatile char data)
{

SPDR = data; // Start the transmission
while (!(SPSR & (1<<SPIF))) // Wait the end of the transmission
{
};

return SPDR; // return the received byte
}

// main arduino setup routine

void setup()
{
Serial.begin(9600);

Serial.println("Configuring the nRF2401.");

pinMode( DATAOUT, OUTPUT);
pinMode( DATAIN, INPUT);
pinMode( SPICLOCK, OUTPUT);
pinMode( CHIPSELECT, OUTPUT);

pinMode( NFR_CE, OUTPUT);
pinMode( NFR_IRQ, INPUT);


//interrupt enabled,spi enabled,msb 1st,master,clk low when idle,
//sample on leading edge of clk,system clock/4 rate (fastest)

SPCR = (1<<SPE)|(1<<MSTR);
clr=SPSR;
clr=SPDR;
delay(10);


digitalWrite(CHIPSELECT, HIGH); //disable SPI comm with device
digitalWrite(NFR_CE, LOW); //chip disable the nRF2401


digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
spi_transfer(0x20); //enable RX irq, CRC enabled, be a receiver
spi_transfer(0x39);
digitalWrite(CHIPSELECT, HIGH); //disable SPI comm with device

digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
spi_transfer(0x21); // disable auto-acknowledge
spi_transfer(0x00);
digitalWrite(CHIPSELECT, HIGH); //disable SPI comm with device

digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
spi_transfer(0x23); // set address width to 5 bytes (default, not really needed)
spi_transfer(0x03);
digitalWrite(CHIPSELECT, HIGH); //disable SPI comm with device

digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
spi_transfer(0x26); //air data rate 1 Mbit, 0dBm, setup LNA
spi_transfer(0x07);
digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device

digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
spi_transfer(0x31); // 4 byte receive payload
spi_transfer(0x04);
digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device

digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
spi_transfer(0x25); // rf channel 2 (default, not really needed)
spi_transfer(0x02);
digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device

digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
spi_transfer(0x2a); //set RX pipe 0 address
spi_transfer(0xe7);
spi_transfer(0xe7);
spi_transfer(0xe7);
spi_transfer(0xe7);
digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device

digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
spi_transfer(0x20); // RX interrupt, power up, be a receiver
spi_transfer(0x3b);
digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device

Serial.println("Done setting up.");
digitalWrite(NFR_CE, HIGH); //receiver enable the nRF2401

}

// main arduino program loop

void loop()
{
Serial.println("Startup up communications with nRF2401.");
Serial.println("Waiting for message from Nordic Key FOB.");

// loop forever
while(1)
{
digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
incoming = spi_transfer(0xff); // get nRF2401 status register contents
digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device
// transmission received from FOB
if (incoming & 0x40)
{

// get data from nRF2401
digitalWrite(NFR_CE, LOW); //disable receiver in the nRF2401
digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
spi_transfer(0x61);
data_array[0] = spi_transfer(0xff);
data_array[1] = spi_transfer(0xff);
data_array[2] = spi_transfer(0xff);
data_array[3] = spi_transfer(0xff);
digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device

digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
spi_transfer(0xe2); // flush RX FIFO
digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device

digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
spi_transfer(0x27); // clear RF FIFO interrupt
spi_transfer(0x40);
digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device
digitalWrite(NFR_CE, HIGH); //receiver enable the nRF2401

// figure out which key on FOB was pressed

switch( data_array[0] )
{
case 0x17: Serial.print("Left button "); break;
case 0x1e: Serial.print("Bottom button"); break;
case 0x1b: Serial.print("Right button "); break;
case 0x1d: Serial.print("Top button "); break;
case 0x0f: Serial.print("Center button"); break;
default: Serial.print( "No button! "); break;
}
// display the total number of times that a button had been pressed on the FOB
// since battery in FOB replaced
button_presses = (data_array[1] << 8) + data_array[2];
Serial.print(" pressed ");
Serial.print( button_presses, DEC );
Serial.println(" times.");

// wait a bit before checking for another key press packet, may need some adjusting.
delay(10);
}
}
}