PDA

View Full Version : Want to make me some Propeller Code?



Philldapill
01-05-2009, 12:37 PM
A certain person with a kitty cat as his avatar has introduced me to, what looks like, a wonderful little chip. It's an nRF24L01 wireless tranciever from Nordic. It looks like it's got great range, very fast speed(2Mbps), and very small. It looks like an easy chip to interface to the propeller, so if anyone wants to write some code for it, I'll produce a couple of chips and finished PCBs to work with, and to keep for yourself. If need be, I'll also pay to have it done.·I really want to get this thing going as I have many uses for it, but not the know-how or time to learn it.

Thanks again, Leon! :)

SRLM
01-05-2009, 01:12 PM
If anybody takes the deal up, please post it in the obex! Help the community...

Philldapill
01-05-2009, 01:25 PM
Oh definately! From what I can see, these modules would be an insanely cheap addition to the communities "tools". I think Leon said they were about $2 each for the chip, and it looks like a single module could be built for about $15... Heck, someone supply the code, I'll supply the modules for cheap! From the datasheet and the recommended circuit schematic, one of these modules would be about 1.3" x 0.6"... pretty small and could easily plug into a propeller with 3.3V supply. I'm salivating...

Sleazy - G
01-05-2009, 02:13 PM
If you ask me , the reliable sources have told me nordic has problems, and is the reason·behind its inexpensive dollar-to-distance ratio.· From what ive heard, it's an untested protocol.··And·I think if you develop on it's platform, you will owe royalties.··If you want reliable wireless, go to digi's XBEE ZNET 2.5 modules.· They kick butt.· 1mW will get you 100m range, 50mW will·do a mile. 802.15.4 protocol.· Point to point, 128 bit encryption.· Auto-networking drop in style, ya dig.· Theyve got modules that do 40 miles (line of sight)
·for 180$ or so.· Only 1W .· Go and find out what kind of power a CB radio needs for 40mi.· Its most likely 1000 times over the legal civilian·limit.· Im pretty sure it's all royalty free.

The best part about these... they have the configuration of "transparent" operation, where the modules behave as a serial line replacement.· Killer.· The serial objects in the object exchange default to XBEE's protocol. 8 bits 1 stop bit no parity?· I could be wrong, i just know that it works without modifying the object.· Simple serial is one. Just find a serial object written by chip and it will work with the XBEE modules without any software mods.

If you have government code-cracker friends like mine, theyve most certainly told you·that bluetooth is a joke with regards to security.·· Specifically, passwords are shared between points without encryption, in configuration stages.· For XBEE, 128 bits is would take quite a few weeks to crack under ideal circumstances. ·Like roadrunner circumstances. Bluegene? The algorithim is only a few years old.· Modules act like routers.· I think max baud rate 4 times faster than A 56k modem. Decent for anything short of streaming video.· 3 on board ADC channels.· IDE configuration PC application.

www.digi.com (http://www.digi.com), you can get xbee modules direct.·

Not many people develop these.· Just about as new as the propeller itself (2.5 yrs or so).·







Post Edited By Moderator (Chris Savage (Parallax)) : 1/5/2009 8:00:10 PM GMT

Leon
01-05-2009, 05:56 PM
Most of the wireless keyboards and mice use the Nordic chips. No royalties are payable. What are the problems you have mentioned?

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Oldbitcollector (Jeff)
01-05-2009, 09:35 PM
Sparkfun has a board based on this chip.. (I'll bet it could be done a lot cheaper)
www.sparkfun.com/commerce/product_info.php?products_id=705 (http://www.sparkfun.com/commerce/product_info.php?products_id=705)

It looks like an SPI interface. Not my cup of tea, but it shouldn't be too hard for
someone with a little experience that direction. Good project!

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Check out: Protoboard Introduction (http://jeffledger.googlepages.com/Protoboard_Introduction.pdf) , Propeller Cookbook 1.4 (http://ucontroller.com/Propeller%20Protoboard%20Designs%20for%20the%20Beg inner.pdf) & Software Index (http://forums.parallax.com/showthread.php?p=770318)
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us (http://propeller.warrantyvoid.us)
Got an SD card connected? - PropDOS (http://www.orrtech.net/propdos/)

Leon
01-05-2009, 10:50 PM
Here is the C code for my test programs:




/*
** Rx.c
** Receive test program for PIC18F4520 and nRF24L01 or nRF24L01+
** Uses the Microchip C18 compiler
** Based on SFE code for the CC5X compiler in 24L01demo_V01.c
**
** The LED is flashed five times when data are received.
** The received data in the buffer may be checked using the
** debugger Watch window.*/

#include <p18cxxx.h>
#include <spi.h>
#include <timers.h>

// Pragmas
#pragma config OSC = INTIO67
#pragma config PWRT = ON
#pragma config MCLRE = OFF
#pragma config BOREN = OFF

//function prototypes
void init(void);
void reset_RX(void);
void configure_RX(void);
unsigned char spi_Send_Read(unsigned char);
void dly(unsigned int);

// Defines
#define SPI_SCK LATCbits.LATC3 // Clock pin, PORTC pin 3
#define SPI_SO LATCbits.LATC5 // Serial output pin, PORTC pin 5
#define SPI_SI PORTCbits.RC4 // Serial input pin, PORTC pin 4
#define SPI_CSN LATCbits.LATC2 // CSN output pin, PORTC pin 2
#define SPI_CE LATCbits.LATC1 // CE output pin, PORTC pin 1
#define SPI_IRQ PORTBbits.RB0 // IRQ input pin, PORTB pin 0
#define SPI_SCALE 4 // postscaling of signal
#define LED LATAbits.LATA0
#define PB PORTAbits.RA1

// Macros
#define nop() _asm nop _endasm

void main(void)
{
unsigned char i;

init();
configure_RX();
while(1)
{
if (SPI_IRQ == 0) //wait for anything
{
for (i = 0; i < 5; i++) //flash LED 5 times if data received
{
LED = 1;
dly(63973); // 200 ms delay
LED = 0;
dly(63973); // 196 ms
}
dly(63973); // 196 ms
reset_RX();
}
}
}

// initialise 18F4520
void init(void)
{
// run internal oscillator at 8 MHz
OSCCON = OSCCON | 0x70;
while (OSCCONbits.IOFS == 0)
;

PORTA = 0x00;
ADCON1 = 0x0F; // set up PORTA to be digital I/Os
TRISA = 0x02; // PORTA<7.2,0> outputs PORTA<1> input
TRISCbits.TRISC3 = 0; // SDO output
TRISCbits.TRISC5 = 0; // SCK output
TRISCbits.TRISC2 = 0; // CSN output
TRISCbits.TRISC1 = 0; // CE output
TRISBbits.TRISB0 = 1; // IRQ input
OpenSPI(SPI_FOSC_16, MODE_00, SMPMID); //open SPI1
OpenTimer0( TIMER_INT_OFF &
T0_16BIT &
T0_SOURCE_INT &
T0_PS_1_256 );
}

//configure nRF24L01 for receive
void configure_RX(void)
{
unsigned char i, j;

SPI_CSN = 0;
SPI_CE = 0;

//PRX, CRC enabled
spi_Send_Read(0x20);
spi_Send_Read(0x39);
SPI_CSN = 1;
SPI_CSN = 0;

//disable auto-ack for all channels
spi_Send_Read(0x21);
spi_Send_Read(0x00);
SPI_CSN = 1;
SPI_CSN = 0;

//address width = 5 bytes
spi_Send_Read(0x23);
spi_Send_Read(0x03);
SPI_CSN = 1;
SPI_CSN = 0;

//data rate = 1MB
spi_Send_Read(0x26);
spi_Send_Read(0x07);
SPI_CSN = 1;
SPI_CSN = 0;

//4 byte payload
spi_Send_Read(0x31);
spi_Send_Read(0x04);
SPI_CSN = 1;
SPI_CSN = 0;

//set channel 2
spi_Send_Read(0x25);
spi_Send_Read(0x02);
SPI_CSN = 1;
SPI_CSN = 0;

//set address E7E7E7E7E7
spi_Send_Read(0x30);
for (j = 0; j < 5; j++)
spi_Send_Read(0xE7);
SPI_CSN = 1;
SPI_CSN = 0;

//PWR_UP = 1
spi_Send_Read(0x20);
spi_Send_Read(0x3B);
SPI_CSN = 1;
SPI_CE = 1;
}

void reset_RX(void)
{
unsigned char i, j;
unsigned char buffer;

//Read RX payload
SPI_CSN = 0;
spi_Send_Read(0x61);
for (j = 0; j < 4; j++)
{
buffer[j] = spi_Send_Read(0);
}
SPI_CSN = 1;

//Flush RX FIFO
SPI_CSN = 0;
spi_Send_Read(0xE2);
SPI_CSN = 1;
SPI_CSN = 0;

//reset int
spi_Send_Read(0x27);
spi_Send_Read(0x40);
SPI_CSN = 1;
}




unsigned char spi_Send_Read(unsigned char byte)
{
SSPBUF = byte;
while(!DataRdySPI())
;
return SSPBUF;
}


void dly(unsigned int c)
{
INTCONbits.TMR0IF = 0;
WriteTimer0(c);
while (INTCONbits.TMR0IF == 0)
;


}









/*
** Tx.c
** Transmit test program for PIC18F4520 and nRF24L01 or nRF24L01+
** Uses the Microchip C18 compiler
** Based on SFE code for the CC5X compiler in 24L01demo_V01.c
*/

#include <p18cxxx.h>
#include <spi.h>
#include <timers.h>

// Pragmas
#pragma config OSC = INTIO67
#pragma config PWRT = ON
//#pragma config MCLRE = OFF
#pragma config BOREN = OFF


//function prototypes
void init(void);
void transmit_data(void);
void configure_transmitter(void);
unsigned char spi_Send_Read(unsigned char);
unsigned char spi1_send_read_byte(unsigned char byte);
void dly(unsigned int);


// Defines
#define SPI_SCK LATCbits.LATC3 // Clock pin, PORTC pin 3
#define SPI_SO LATCbits.LATC5 // Serial output pin, PORTC pin 5
#define SPI_SI PORTCbits.RC4 // Serial input pin, PORTC pin 4
#define SPI_CSN LATCbits.LATC2 // CSN output pin, PORTC pin 2
#define SPI_CE LATCbits.LATC1 // CE output pin, PORTC pin 1
#define SPI_IRQ PORTBbits.RB0 // IRQ input pin, PORTB pin 0
#define SPI_SCALE 4 // postscaling of signal
#define LED LATAbits.LATA0
#define PB PORTAbits.RA1

// Macros
#define nop() _asm nop _endasm

void main(void)
{
init();
configure_transmitter();
while (1)
{
transmit_data();
LED = 1;
dly(63973); //200 ms delay
LED = 0;
dly(40000); //3.27 s delay
nop();
}
}


void init(void)
{
// run internal oscillator at 8 MHz
OSCCON = OSCCON | 0x70;
while (OSCCONbits.IOFS == 0)
;
PORTA = 0x00;
ADCON1 = 0x0F; // set up PORTA to be digital I/Os
TRISA = 0x02; // PORTA<7.2,0> outputs PORTA<1> input
TRISCbits.TRISC3 = 0; // SDO output
TRISCbits.TRISC5 = 0; // SCK output
TRISCbits.TRISC2 = 0; // CSN output
TRISCbits.TRISC1 = 0; // CE output
TRISBbits.TRISB0 = 1; // IRQ input
OpenSPI(SPI_FOSC_16, MODE_00, SMPMID); //open SPI1
OpenTimer0( TIMER_INT_OFF &
T0_16BIT &
T0_SOURCE_INT &
T0_PS_1_256 );
}

void configure_transmitter(void)
{
unsigned char i, j, data, cmd;

SPI_CE = 0;
SPI_CSN = 0;

// PTX, CRC enabled, mask a couple of ints
spi_Send_Read(0x20);
spi_Send_Read(0x38);
SPI_CSN = 1;
SPI_CSN = 0;

//auto retransmit off
spi_Send_Read(0x24);
spi_Send_Read(0x00);
SPI_CSN = 1;
SPI_CSN = 0;

//address width = 5
spi_Send_Read(0x23);
spi_Send_Read(0x03);
SPI_CSN = 1;
SPI_CSN = 0;

//data rate = 1MB
spi_Send_Read(0x26);
spi_Send_Read(0x07);
SPI_CSN = 1;
SPI_CSN = 0;

//set channel 2, this is default but we did it anyway...
spi_Send_Read(0x25);
spi_Send_Read(0x02);
SPI_CSN = 1;

//set address E7E7E7E7E7, also default...
spi_Send_Read(0x30);
for (j = 0; j < 5; j++)
{
spi_Send_Read(0xE7);
}
SPI_CSN = 1;
SPI_CSN = 0;

//disable auto-ack, RX mode
//shouldn't have to do this, but it won't TX if you don't
spi_Send_Read(0x21);
spi_Send_Read(0x00);
SPI_CSN = 1;
}

void transmit_data(void)
{
unsigned char i, data, cmd;

SPI_CSN = 0;

//clear previous ints
spi_Send_Read(0x27);
spi_Send_Read(0x7E);
SPI_CSN = 1;
SPI_CSN = 0;

//PWR_UP = 1
spi_Send_Read(0x20);
spi_Send_Read(0x3A);
SPI_CSN = 1;
SPI_CSN = 0;

//clear TX fifo
//the data sheet says that this is supposed to come up 0 after POR, but that doesn't seem to be the case
spi_Send_Read(0xE1);
SPI_CSN = 1;
SPI_CSN = 0;

//4 byte payload
spi_Send_Read(0xA0);
spi_Send_Read(0x34);
spi_Send_Read(0x33);
spi_Send_Read(0x32);
spi_Send_Read(0x31);
SPI_CSN = 1;

//Pulse CE to start transmission
SPI_CE = 1;
dly(65000); //delay 69 ms
SPI_CE = 0;
}


unsigned char spi_Send_Read(unsigned char byte)
{
SSPBUF = byte;
while(!DataRdySPI())
;
return SSPBUF;
}

void dly(unsigned int c)
{
INTCONbits.TMR0IF = 0;
WriteTimer0(c);
while (INTCONbits.TMR0IF == 0)
;
}




Porting it to the Propeller should be trivial. Get the SPI function working first, you should be able to write data to the Nordic chip registers and read it back.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/5/2009 4:05:35 PM GMT

Philldapill
01-06-2009, 03:22 AM
Oh, I'm giddy. I can't thank you enough Leon! Now, we just need to convert it to ASM/spin! I'm working on getting a board made as per the datasheet. Sleazy G, I dig, but what problems are you talking about? I'd really like to get some more info. I'd hate to get knee deep in all this, then find out that the claimed distance is more like 5 feet...

soshimo
01-06-2009, 03:48 AM
The nRF24L01 is used a lot in AVR circles. The only problem I've seen is the SPI interface is a little cranky. There's been some reports of timing issues using avr chips for the spi interface. They are also very configurable so you have to be careful about what settings you use in order to get results.

As for bluetooth. SG is completely correct. Even 805.11b and g are not secure (they were not meant to be due to export regulations - can't make your world opaque to big brother, sorry). I worked on a CDMA precursor protocol (called FDMA) in the late 80s for the military (well, I actually fixed the gear that used the protocol - a telemetric data transceiver). Now, that protocol was secure. I had to check out a book under lock and key to troubleshoot that particular piece of gear. They don't even allow bluetooth devices inside secured server rooms in the military today (at least marine corps doesn't as of 2 years ago when I had a gig with the USN). You have to leave your borg device at the door if you want to check out a hard drive and enter the secure room. If you are looking to transmit sensitive data I would look at some kind of encryption algorithm. They actually make ASIC's for doing just that - you pass in a string and it passes out an encrypted blob.

Also, quick question - this line of sight only right? I don't believe these modules work other than line of sight. Make sense as most RC transmitters - which have a distance of about 3000 feet (1/2 mile) will die horrid deaths if line of sight is broken. Try walking behind a big building while flying your plane - then walk over to where the pieces are and hope you have enough CA glue to fix it all.

Philldapill
01-06-2009, 04:02 AM
LOL @ Soshimo

If you've ever seen the show Robot Wars, that will be the type of application(for now). My university is sponsoring our Robotics team and we will be designing a robot to compete with other robots. It will be fairly line of sight, since we have to be able to see the robot to control it... However, the tranciever will be located inside the robots metal body... We might be able to add an external antenna.

So, the problems we have so far are:

1. LOS issues - for good reception, you will need line of sight
2. Data interface issues - very finiky about the exact configuration of the device
3. ?

soshimo
01-06-2009, 04:21 AM
@Phil - forgot to add that there are some SPI problems reported. Usually timing issues that have to be worked out in software though - not really a hardware issue. More like a challenge.

Oh, and I love that show Robot Wars. They used to play it on comedy central (still trying to figure that one out) before comedy central got so corporate. Now I think you can catch it on A&E sometimes. That and that one show - myth busters - are probably the only times that energy is radiated from the electron tube sitting in my room.

Philldapill
01-06-2009, 05:13 AM
Aye. I'm excited about this. Our team is going to CA in April to be on the American show BattleBots which isn't so heard of, but still way cool.

I doubt the SPI issues are too hard to work out. Leon seems to have given us a sort of template for the code, so it shouldn't be too hard.

soshimo
01-06-2009, 05:22 AM
/agree phil - and that was on an avr too. AVR != Propeller by a long shot. I think you are good to go and the code that Leon posted looks clean and well documented so it shouldn't be too hard to RE the algorithm out of there for spin or assembler. You could almost just read the comments and write the code yourself, which is probably what will end up happening. You don't have a choice of a language which is syntatically similar to C and the resource naming is different for the PIC compiler. You will probably have to take a look at a datasheet to figure out what all the special register names are (unless you already know), not to mention that the propeller doesn't have a concept of ports like the pic micros do, you have a flat array of IO pins to use and they are all pretty much the same (I think scl/sda have internal pull ups and one may be open drain, not sure, don't have datasheet handy and am too lazy to look).

There's still a bit of work to do to ensure that what you have here will work for prop - but I've usually found that something hard to do in pic or avr land is a no brainer in propeller land so you shouldn't have too many issues. Also, I believe there may be some SPI code in obex already, so the low level protocol details can be hidden and you can work on high level constructs and not have to worry about pulsing pins and the like.

Luis Digital
01-06-2009, 06:46 AM
The Chip has good price (http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=41939), but the complete circuit not (http://www.sparkfun.com/commerce/product_info.php?products_id=691).

Leon
01-06-2009, 07:06 AM
It only needs a few low-cost parts:

22pF C1 0402 NPO, +/- 2%
22pF C2 0402 NPO, +/- 2%
2.2nF C3 0402 X7R, +/- 10%
4.7pF C4 0402 NPO, +/- 0.25pF
1.5pF C5 0402 NPO, +/- 0.1pF
1,0pF C6 0402 NPO, +/- 0.1pF
33nF C7 0402 X7R, +/- 10%
1nF C8 0402 X7R, +/- 10%
10nF C9 0402 X7R, +/- 10%
8,2nH L1 0402 chip inductor +/- 5%
2.7nH L2 0402 chip inductor +/- 5%
3,9nH L3 0402 chip inductor +/- 5%
22kΩ R2 0402 +/-1%
16MHz X1 +/-60ppm, CL=12pF

Probably about $2 in production quantities, including the PCB.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

soshimo
01-06-2009, 07:26 AM
@Luis - yes, but the trouble with RF is that you don't usually want to prototype or breadboard it, especially at the frequencies these guys operate. From my experience in the Navy, RF is a very cantankerous beast and can be caused to fail by some of the most mundane circumstances - such as a vibrating ground plane (which is a very common occurance in helicoptors, unfortunately). I would pay the money, or at least looking at making my own PCBs with a decent ground plane and good component placement. Again, I'm not an EE, but there were certain cards in a certain sonobouy receiver which I can't really go into detail about, but suffice to say that when this said piece of gear went down it was almost always r&r the card (I did I-level, or component level troubleshooting so I would usually troubleshoot down to component level - not in this case) and return to depot. The replacement cards looked decidedly different. Moral to the story - even the engineers get it wrong sometimes when working with RF. Instructors in the Navy referred to FM as <bleeping> Magic. http://forums.parallax.com/images/smilies/tongue.gif Well, I think all of RF is <bleeping> magic TBH.

Philldapill
01-06-2009, 10:33 AM
I agree. Just about all EM is <bleeping> magic. I was talking to a professor today about what REALLY produces inductance... something that seems so simple, still isn't understood at all.

Philldapill
01-06-2009, 10:49 AM
Leon, all those capacitors look like they should be 5% tolernace, except the 2%'s. Do you know where to find these?

soshimo
01-06-2009, 12:10 PM
/agree Phil - it's easy to forget that current through any conductor produces magnetic fields and back emf due to lenz's law, alternate that current and you get inductance also potentials separated by insulation produces capacitance which can occur from something as simple as two traces close together on a pcb. Which is why ground planes are so important and you don't want high speed signals to be traveling next to each other.

Leon
01-06-2009, 01:09 PM
RS has 1% ones in stock (ATC). Farnell has 2% ones (Johansson). Digi-Key probably stocks them.

RF isn't difficult, even at 2.4 GHz. Radio amateurs deal with it all the time. There is some good software around, like Microwave Office.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Philldapill
01-06-2009, 01:41 PM
I'm putting together a PL for these. You're right, Leon, it's looking like the parts and PCB should be around $2. The chip is $2.05

Wow - $4 in parts for a wireless comm. link. Maybe after assembly $10? Pretty cheap! I sure hope this works...

By the way, someone PM'ed me saying he might be able to get some code together in his spare time. I'm going to go ahead and order a couple of these from sparkfun and send them to him, so he can start work on getting a driver going for the propeller. If anyone else is interested in getting some code done, please let me know through PM.

Cluso99
01-06-2009, 03:25 PM
I am wondering if the prop could produce the 16MHz to save the xtal ? Just a thought.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

cruising (http://www.bluemagic.biz)]cruising[/url]

This is a bold test.

Philldapill
01-06-2009, 03:32 PM
Aye, I've wondered that as well, Cluso99. However, I think that if the propeller were to generate the signal, it would take an entire cog to toggle a pin on and off at that rate. I bet it COULD be done, but seems like a waste of a cog. However, if I can't find one of these crystals that is in spec, we just might have to! I've got all the parts sourced(for under $2) EXCEPT the right crystal. Leon?

Leon
01-06-2009, 05:32 PM
I bought a few from my Nordic distributor. The 12 pF load capacitance isn't standard.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Cluso99
01-06-2009, 09:53 PM
I was wondering if the counter could be set to automatically generate 16MHz in the background allowing the cog very specific use. Otherwise it will take a full cog. The PCB could be wired for either with a link. As you may note, I haven't played with the counters.

It could be used as a cool standalone RF terminal (VGA, Keyboard, and RF serial interface) http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

cruising (http://www.bluemagic.biz)]cruising[/url]

This is a bold test.

4Alex
01-06-2009, 10:08 PM
Couldn't resist putting my 2cents.

I used both XBee Pro and Nordic. They both work well. However, in the end, I've dropped XBee Pro and work only with Nordic now mainly because the footprint is SO MUCH smaller and they work very reliably. I have never encountered problems with this IC, it really rocks with chip antennae, very little detuning, etc. I bought Nordic initially from SparkFun (2 ranges) but my preferred supplier/distributor is http://www.semiconductorstore.com (you can get a dev kit that includes a dongle for your PC, very practical). BTW, SparkFun as a tutorial on their experience with Rf ranges and this also applies (from my humble experience) to XBee Pro at http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=48&page=). Nordic sells an extensive line of ICs and derived products, their documentation is stellar, and their products are widely used (mainly in Europe). Finally, Nordic is not Bluetooth. Like XBee Pro, it shares the 2.4GHz ISM public bands. I would recommend these transceivers without hesitation.

Cheers,

Alex

Luis Digital
01-07-2009, 06:55 AM
Cluso99 said...
I was wondering if the counter could be set to automatically generate 16MHz in the background


Yes that work without problem.

Philldapill
01-07-2009, 08:12 AM
Can a 16MHz crystal with a different load capacitance be used, as long as the capacitors match it?

Sleazy - G
01-20-2009, 07:30 PM
Heres the differences, and why I noted nordic as having "problems" (aside from hearsay)

XBEE modules use DSSS (Direct Sequence Spread Spectrum), just like 802.11 networks. XBEE has its own IEEE 802.15.4 designation. This results in less chance of getting hacked by sniffers, less chance of getting jammed inadvertantly (or intentionally), less chance of interference (it also employs collision avoidance). The signal appears as white noise on an analyzer.

Nordic uses GFSK(Gaussian Frequency Shift Keying), just like basic mode FHSS of bluetooth, and is very very hackable by sniffers and a man-in-the-middle intercept of initial transfer of network keys. Code cracker buddies of mine laugh at bluetooth's vunerability, and nordic should be similar, judging on the method. This method of modulation does however provide a higher bit rate than XBEE.

Nordic does not have IEEE wireless protocol specification, a one up for XBEE. XBEE also auto-configures any networks, has either API or transparent operation, will automatically route-find and will "hop" between modules when the destination module is out of range of the source module. You can increase range of the network by simply adding more modules pathwise, and without having to re-configure pre-existing networks. It also is self-repairing.

XBEE ver. 1 can get you 100m range with just 1mW , which is the same as Nordic. XBEE ver. 2 will get you 100m with 2mW. AND XBEE PRO ver. 2 modules will get a mile with just 50mW. DIGI even makes XTEND modules that can get you 40 miles , line of sight, with only 1 watt! pretty expensive @ 179$ for the 40 mile range modules , but it leaves the option available... And you can mix and match the XBEE modules of different ranges to a network of your choosing.

XBEE modules (so ive heard) should be able to range themselves accurately to within one meter. Im NOT actually sure if this is true, ive actually just read the info, about to try some ranging now.

Nordic does have the size and bitrate advantage, tho. It has its niche. I wouldnt try to achieve "secure" or long distance networks with Nordic. I would also not use Nordic in situations where high ambient 2.4Ghz flux is encountered. XBEE is much less suceptable to interference.

I also dont like Nordic's website or datasheets very much. DIGI's data sheets are written for engineers, Nordic's are written for techs (or so it seems)

Post Edited (Sleazy - G) : 1/20/2009 4:23:42 PM GMT

Sleazy - G
01-20-2009, 11:12 PM
Yeah, id just like to clarify, IEEE 802.15.4a can range down to 1 meter, not 802.15.4, I guess the "a" suffix is the difference in standard. I think theres some capability of rough-ranging with the basic IEEE 802.15.4, but you might need some sort of vernier calculation to get any real accuracy.

TJHJ
01-22-2009, 10:18 PM
I volunteered to write the code for the nordic chips for the obex, but today I was trolling around the obex and Ive been thwarted....

It seems its already been done, for those of you who want to give the nrf2401 a try, Thank Allen Marincak

obex.parallax.com/objects/112/ (http://obex.parallax.com/objects/112/)

Cheers,
TJ

wireless
06-09-2009, 03:33 PM
Hi all, I have read through this thread with great interest, particularly the code by Leon. A small twist to his project code based on MCU (PIC18F4520) and nRFL01+ chip, my MCU is PIC16F877A. The rest of the task i.e to configure the nordic chip for receiver or transmitter operation remains the same. I have few questions to Leon, ofcourse others may help too:

General Question: What changes in your code should i make? I am using a PCW C Compiler IDE to talk with my PIC16F877A.

Specific Qs: (1) in your code you used the internal osc. (8 MHz). Can i use #use delay (clock = 20,000,000) for my 20 MHz xtal oscillator definition?

Duane Degn
04-08-2011, 02:31 PM
Sorry for digging up such an old thread but I wanted anyone else who searches the forum about these Nordic modules and finds this thread to have this information.

The object (http://obex.parallax.com/objects/112/) TJ mentioned in post #31 has a pretty serious bug. It only passes one byte of the received packet to the calling object.

The object doesn't have a send method so I wrote one myself (using Leon's code as a guide).

Using my new send method I repeatedly sent "test" from one nRF24L01+ to a second nRF24L01+ module.

The second module kept receiving $74, $00, $00, $00.

The problem was the ReadPayload would save the packet into a local array "payload" and then return "payload" which would only return one member of the array. (I'm still not sure why the method returned a $74 instead of a "t".)

I was able to fix this problem by making the payload array global (I had also moved all the methods to my top object).

I plan to post an improved nRF24L01+ object soon. If anyone would like my test object let me know and I'll post it.

I'll post the code I write and any other followup information on a more recent thread I started about these modules.

http://forums.parallax.com/showthread.php?130707-Looking-for-Faster-Objects-for-Nordic-Wireless-Modules-nRF24L01-and-nRF2401A&p=988570#post988570

Thanks Leon for the C code you posted. It made writing a send method easy.

The author* of the object states he tested it with a Nordic FOB (http://www.sparkfun.com/products/8602). I'm assuming the single byte received was enough to tell which button on the FOB was pressed so the author didn't notice the bug in his object.

* The OBEX lists the author as Allen Marincak but the spin file states the author is Nikita Kareev.