Hi could anyone explain what the below means involving the configuration of the nrf24e1 radio:
transmitter:
const RFConfig txconf = { 15, 0x08, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x12, 0x34, 0x56, 0x78, 0x83, 0x6c, 0x04 };
Receiver:
}; const RFConfig rxconf = { 15, 0x08, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x87, 0x65, 0x43, 0x21, 0x83, 0x6c, 0x05 };
I am of the belief it is for the configuring of shockburst and payload (from manual) but am unsure what the numbers are for (in decimal-seems to not be obvious as what they are for)
your knowledgable help is greatly appreciated.
Jon
this is the full transmitter code:
#include <reg24e1.h> struct RFConfig { unsigned char n; unsigned char buf[15]; }; typedef struct RFConfig RFConfig; #define ADDR_INDEX 8 // Index to address bytes in RFConfig.buf #define ADDR_COUNT 4 // Number of address bytes const RFConfig txconf = { 15, 0x08, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x12, 0x34, 0x56, 0x78, 0x83, 0x6c, 0x04 }; const RFConfig rxconf = { 15, 0x08, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x87, 0x65, 0x43, 0x21, 0x83, 0x6c, 0x05 }; // LED is to be connected to this pin sbit LED_pin = P1^0; // Function prototypes void DELAY_LOOP_Wait(const unsigned int); void DELAY_100us(volatile unsigned char n); unsigned char SPI_ReadWrite(unsigned char b); void TRANSMIT_Packet(unsigned char b); void TRANSMITTER(void); void LED_Flash(); void INIT(void); /*..................................................................*/ void main(void) { INIT(); while(1) { TRANSMITTER(); } } /*------------------------------------------------------------------*- DELAY_LOOP_Wait() -*------------------------------------------------------------------*/ void DELAY_LOOP_Wait(const unsigned int DELAY) { unsigned int x, y; for (x = 0; x <= DELAY; x++) { for (y = 0; y <= 800; y++); } } /*------------------------------------------------------------------*- LED_FLASH() -*------------------------------------------------------------------*/ void LED_Flash() { LED_pin = 0; DELAY_LOOP_Wait(1000); LED_pin = 1; DELAY_LOOP_Wait(1000); } /*------------------------------------------------------------------*- DELAY_100us() -*------------------------------------------------------------------*/ void DELAY_100us(volatile unsigned char n) { unsigned char i; while(n--) for(i=0;i<35;i++) ; } /*------------------------------------------------------------------*- SPI_ReadWrite() -*------------------------------------------------------------------*/ unsigned char SPI_ReadWrite(unsigned char b) { EXIF &= ~0x20; // Clear SPI interrupt SPI_DATA = b; // Move byte to send to SPI data register while((EXIF & 0x20) == 0x00) // Wait until SPI hs finished transmitting ; return SPI_DATA; } /*------------------------------------------------------------------*- TRANSMIT_Packet() -*------------------------------------------------------------------*/ void TRANSMIT_Packet(unsigned char b) { unsigned char i; CE = 1; DELAY_100us(0); // Start with the address of the receiver: for(i=0;i<ADDR_COUNT;i++) SPI_ReadWrite(rxconf.buf[ADDR_INDEX+i]); SPI_ReadWrite(b); CE = 0; DELAY_100us(3); // Wait ~300us } /*------------------------------------------------------------------*- TRANSMITTER() -*------------------------------------------------------------------*/ void TRANSMITTER(void) { unsigned char b, bo, err; CS = 1; DELAY_100us(0); for(b=0;b<txconf.n;b++) { SPI_ReadWrite(txconf.buf[b]); } CS = 0; for(;;) { //b = ReadADC(); // Read ADC TRANSMIT_Packet(b); // Transmit data } } void INIT(void) { PWR_UP = 1; // Turn on Radio DELAY_100us(30); // Wait > 3ms SPICLK = 0; // Max SPI clock (XTAL/8) SPI_CTRL = 0x02; // Connect internal SPI controller to Radio }
You have read the manual?
www.semiconductorstore.net/.../NRF24E1 .pdf
Take a look at table 4.3.3 and forward.
Yes i have read the manual, i suppose what im confused with is what the hex numbers refer to with regards to that section??
Well, just glancing at it, you have 144 bits in positions numbered 0..143.
So, all you have to do is divide these 144 bits into groups of eight, and consider that a 2-digit hex number corresponds to an 8-bit binary number...
" www.semiconductorstore.net/.../NRF24E1 .pdf "
What a bizarre filename - what are all those spaces ("%20") doing on the end?!
Why bother with reproductions when you can get the genuine original free from the manufacturer:
www.nordicsemi.no/.../Product_Specification_nRF24E1_1_3.pdf
And with a sensible filename!
And more: www.nordicsemi.no/index.cfm
Well there are 15 hex numbers for each which in decimal are:
tx:8 8 0 0 0 0 0 0 28 52 86 120 131 108 4
rx:8 8 0 0 0 0 0 0 135 101 67 33 131 108 5
Which is 24 bytes and 96 bits but im not sure how they correspond to the 144 bits?
"Well there are 15 hex numbers ... Which is 24 bytes"
Pardon?
How many bits does a 2-digit hex number represent?
Thence, how many bits do fifteen 2-digit hex numbers represent?
Ok, thats 120 bits :-) leaving 24 bits......im guessing that these 24 bits correspond to the 24 bits used for Test in the manual, is this correct?
There is probably something wrong with my english but "reproduction"...
Are we talking about a cheap copy of a brand-name item? The referred document may have a number of spaces in the file name, but it is the same document revision, and a perfect binary copy.
By your standards, a user may never get anything but a reproduction anyway, since we won't have the opportunity of physically visiting Nordic Semi to read the "original" PDF output on the machine that has the Word original original ;)
"it is the same document revision, and a perfect binary copy."
Yes, but you only know that after you've seen the original.
That's my point: why bother with any 2nd source, when you can go direct to the original source?
Because that is a major reason for having cached copies of documents around the world. If everyone always links to the main site, the load can be quite high.
"Are we talking about a cheap copy of a brand-name item? The referred document may have a number of spaces in the file name, but it is the same document revision, and a perfect binary copy."
It should be, but a number of 'perfect binary copies' of PDF datasheets that can be downloaded by those cheap chip-finders are really modified PDFs that contain embedded javascript code.
The Acrobat Reader has javascript capability since version 6, and many of those 'cloned' documents are used to track user reading, sending over the user IP, document ID, and any other info the scripter wants to send.
Quite many of the datasheets I got from those 'chip find services' had some script added. I just wiped my system clean of them, and now only dowload the 'originals'.