RF Transceiver using the MRF49XA


Transceiver breakout boards

I’m just finishing up my last class ever!!!  (for credit, anyway.)  It was a really fun, mostly because I decided to have fun with my last class, and make it a 4/5 (undergrad/graduate).  This meant that it was much easier and less theory-heavy than those that I’m used to.  Anyway, as a grad student, I was expected to do something extra, and I decided to make a RF transceiver module.  I looked around for a little while, and I settled on the Microchip MRF49XA.  In general, it’s a nice chip.  It has about the same capability as the Micrel MICRF6xx modules that I’ve used in the past.  The Micrel modules cost $20/ea. and the Microchip IC is around $3.  I was able to make the whole breakout board for the MRF49XA for less than the Micrel module alone.  One of these days, I should dig out my notes from the Micrel project and post them, but I digress.  I noticed a distinct lack of programming information using the MRF49XA, so I’m posting not only my schematic and PCB, but the software library I wrote for the Atmel AVRmega.

Breakout board schematic

The schematic I created for the breakout board is, in large part, copied from the reference schematic from the datasheet.  There are a few parts that make up the complete schematic, including power regulation, microcontroller interface, RF balun, and the IC.  Everything but the balun is really easy to understand, the power input can be +5 volts or more (probably up to about 14 volts) while using the LM317, or if the LM317 is omitted, +3.3 volts.  The MRF49XA is really a 3.3 volt part, and expects 3.3 volt I/0.  Originally, and on the PCB I had made, I had 2 ground pins.  Since then I realized it would be useful to output regulated 3.3 volt output, so I changed one of the grounds for that.  The only other major portion of the circuit is the balun.  This is used to transform the balanced RF input/output from the IC to the unbalanced antenna connector.  This circuit also provides power to the RF power amplifier inside the IC.

Breakout board top

Breakout board top

The PCB designed from the schematic is also fairly straight-forward.  A few things are worth noting, however.  I’ve added some silkscreen between 2 of the pins on the LM317.  These are to indicate where you could jumper if the breakout board is supplied with regulated power.  I used a 0805 0-ohm resistor (see the image below).  The voltage output of the LM317 is selected with R1 and R2.  I decided not to include the “stop” layer on this image so as to not clutter it, but near the word “Fence” there is a strip without solder mask over the vias.  If you wanted to isolate the RF from the outside, you could build a fence out of copper foil (or something).  The Antenna connector is a end-launch SMA, though it could also be raw coax if you want to save some money.

Close up

The only pins necessary for complete functioning of the device are the standard SPI set (MOSI, MISO, SCK, !CS), and IRO (interrupt request out).  The IRO pin is not strictly necessary, but HIGHLY recommended.  The MRF module uses the IRO pin to notify the microcontroller of a few time-sensitive events, such as FIFO full/empty conditions.

MCU interface while transmitting (click to enlarge)

The diagram included above (from the MRF49XA datasheet) provides a useful overview for the transmitting process.  The take-away message is that you first send the “Transmit data enable” (TXDEN) command, which loads 0xAAAA into the transmit FIFO.  You can either leave this in there, as a preamble, or replace it with data of your choice.  Then, you send the “Transmit carrier enable” (TXCEN) command.  At this point, the PLL starts, and the PA turns on, then transmission starts.  When the first full byte leaves the FIFO the IRO asserts.  Hopefully this forces the MCU to jump to your interrupt service routine.  Once there, if the CS pin is held low, the MRF will bring SDO (MISO) high.  This is a clear signal that the FIFO needs attention.  You can continue this process for as long as you have data.  Once you’re done, you need to load a “dummy byte” into the FIFO so your last data byte makes it out.  Finally, on the next interrupt, shut down the transmitter by sending TXCEN and TXDEN = 0.

Receiving FIFO usage (click to enlarge)

This diagram illustrates another detail of the interface to the MRF.  Also borrowed from the datasheet, it describes the way to access the receive FIFO using SPI.  Typically, SPI interfaces don’t have a notion of registers quite like I2C does, but the MRF does.  To get access to the receive FIFO you initiate an SPI transfer to the MRF module with the contents equal to the address of the receive FIFO.  In this case it’s 0xA000.  Once the first byte of the transfer is complete, the MRF begins outputting the FIFO value on the SDO pin.  It is also possible to gain access to the receive FIFO using FSEL (FIFO Select, called “Data” on the schematic) pin.

Baseband Bandwidth calculation (click for full size)

Before going into some details on the implementation of the library, I’d like to talk briefly about the RF frequency, deviation, and bit rate determination.  I’ve attached another snippet from the datasheet (hopefully the last one), and I’m going to go through the math quickly with numbers for my application.  I’m using 434 Mhz band, with 9600 baud, using a 10ppm crystal.  This means that fxerror = 10 * (434000/1000000) = 4.34 Khz.  Then, our deviation must be 9.6 + 2*fxerror + 10 = 28.28; the closest modulation is 30 Khz.  Therefore, BBBW = 30*2 – 10 = 50 Khz.  The closest BBBW is 67 Khz.

Spectrum plot from alternating 1s and 0s

I recently gained access to a spectrum analyzer courtesy of the OSU Robotics Club.  This is a spectrum plot of 0xAA, or alternating 1’s and 0’s.  It’s a little strange that the distance between peaks is about 90 Khz, as it should be more like 60 Khz.  The comb-like appearance on the flanks is probably from the transceiver switching from 1 to 0 across the scan.

Transmitting ‘1’

This plot is while transmitting all 1’s.  It’s obvious this is much cleaner, but very little information is actually being transmitted here.

With respect to the Atmel AVR library that I wrote, it includes a header file devoted entirely to defining the registers and bits as defined in the datasheet.  Each section includes a comment block description, and in the cases where some bit values need to be calculated, the equations used.  On the occasions where a bitfield is used for some integer value, I include a mask to ensure that if the derived values overrun the width of the bitfield they don’t pollute unrelated settings.  Below, I’ve included an example.

/*******************************************************************************
 * Convenience definitions for band setting
 *
 * These defines are provided for use configuring the MRF49XA module.
 * Select the frequency band for the given hardware by uncommenting the
 * appropriate line.  Set the crystal load capacitance using the MRF_XTAL_LD_CAP
 * value.
 *
 * The load capacitance is given by the following equation:
 *
 * Cap pF = 8.5 + (LCS / 2)
 * LCS = (10 - 8.5) * 2
 *
 * For 10pF: LCS = (10 - 8.5) * 2 = 1.5 * 2 = 3
 *
 ******************************************************************************/
#pragma mark General Configuration Register
#define MRF_GENCREG		0x8000		// General config. register
#define MRF_TXDEN		0x0080		// TX Data Register enable bit
#define MRF_FIFOEN		0x0040		// FIFO enable bit
#define MRF_FBS_MASK		0x0030		// Mask for the band selection
#define MRF_LCS_MASK		0x000F		// Load capacitance mask
// 10pF Crystal load capacitance
#define MRF_LCS			3		// Crystal Load capacitance
// Frequency band settings
#define MRF_FBS_434		0x0010		// 434 mHz band
#define MRF_FBS_868		0x0020		// 868 mHz band
#define MRF_FBS_915		0x0030		// 915 mHz band

All of the files in the library depend on a “hardware.h” file that defines the qualities of the hardware.  The hope is that this file is the only place that implementation-specific code lives.  There are some holes still, however.  Finally, the mrf49xa.c and mrf49xa.h files behave the way you would expect.  The module requires a total of 5 pins and one interrupt.  Some of those pins may be shared with other SPI devices.

void MRF_init(void);

uint8_t MRF_is_idle();
uint16_t MRF_statusRead(void);

// Packet structures
// the maximum payload size
#define MRF_PAYLOAD_LEN 40
// Space for preamble, sync, length and dummy
#define MRF_TX_PACKET_LEN	MRF_PAYLOAD_LEN + 5

typedef struct {
	uint8_t	length;
	char		payload[MRF_PAYLOAD_LEN];
} MRF_packet_t;

// Packet based functions
void MRF_transmit_packet(MRF_packet_t *packet);
MRF_packet_t* MRF_receive_packet();

I’ve included a snippet of the header file above so I could mention the basic process for using the MRF module.  The MRF_init function expects the SPI bus to be configured, and it performs the basic initialization of the device.  Once it’s started, the interrupts on the AVR must be enabled.  In the main loop (or at least as often as a packet can be transmitted) you should call MRF_receive_packet.  This function will return NULL if no packet was received, and a pointer to a packet structure if it was.  MRF_transmit_packet takes a packet structure and transmits it.  This is an asynchronous operation, and you may use the packet structure (or it’s memory) once it returns.  This is useful if you want to use a packet structure created on the stack.  It is possible to get yourself into trouble with MRF_packet_transmit, as it spin-loops on a lock set in the ISR.  If for whatever reason that lock isn’t unlocked at some point you can hardlock.  I’ve done my best to ensure that it doesn’t happen, but beware.

And, finally, links to the files.  If there seems to be sufficient interest, I’ll open up a SVN (maybe Google Code, who knows) with these files and a main program useful for telemetry and the like.  Post in the comments if you’re interested, or send me a line.

hardware.h

MRF49XA_definitions.h

MRF49XA.c

MRF49XA.h

spi.h

spi.c

Also, the PCB is available as a public design from BatchPCB.  I’ll include a bill of materials if necessary, though the components are clearly printed on the silkscreen.

Oh!  before you ask: No, I don’t know what the range is.  The longest I’ve tried is about 20 feet, and there weren’t any errors, but it was only about 100 bytes.  The chip is rated to 7dBm, I think, so go from there. 🙂

Update:

Here is a simple bill of materials, I used the Eagle export feature, and attempted to place digikey part numbers for each part.  I’m not saying they’re all right, you may want to make sure you’re getting what you think is correct.

partlist.txt

Also, here are the eagle files.  They aren’t necessarily finalized

eagle_files.zip

, , , , , , , ,

  1. #1 by ngart on December 9, 2010 - 3:09 pm

    Kind of hard to make this if you don’t provide a BOM. Are you releasing the eagle schematic at all?

  2. #2 by admin on December 9, 2010 - 3:55 pm

    I just updated it to include a parts list and eagle files.

  3. #3 by Nick on December 11, 2010 - 8:01 pm

    Hi, good job!
    I have a question, I’m using the same IC and I don’t understand how to read de FIFO. I’m using the FINT options instead of IRO, and my problem is once the sync bytes were detected, the FINT pin always interrupt me, I read the FIFO through SPI, and 600us next, the FINT it’s again (and none data is from transmitter). If you know what can be wrong, please let me know. Thanks in advance.

  4. #4 by admin on December 11, 2010 - 10:17 pm

    Hmm, That’s a good question. I sounds like, for whatever reason, you aren’t able to read from the FIFO. I assume that the FINT pin keeps interrupting you because the FIFO isn’t cleared. How are you reading the FIFO? Are you using the FSEL pin? Are you using the TXRXFIFO register? I think once you get the FIFO read correctly you’ll be on the right track. If you’re still having trouble later I’ll capture and post logic analyzer data for reading from the FIFO.

  5. #5 by Vatsal on December 15, 2010 - 2:53 am

    Superb work bro..
    Very nice PCb design..
    Thank you very much it will help me a lot..i am working on PIC18F4550 instead of AVR..!

  6. #6 by admin on December 15, 2010 - 7:06 am

    Glad I could help. Most of the code should just work, though you’ll have to make some changes. There is a Microchip application note that has PIC code, if you haven’t found it already.

  7. #7 by Jared on December 23, 2010 - 8:24 pm

    I am currently working looking into a complex project requiring 15 remotes having to report to 1 microcontroler. It has to be a fast set up and very stable, free of interference, and reliable. Each button press has to go through. I found this project and thought maybe you would have suggestions. I have a budget of $450. More info: http://forum.allaboutcircuits.com/showthread.php?p=311680#post311680

  8. #8 by admin on December 23, 2010 - 9:43 pm

    Huh, that’s pretty interesting. I’m not sure how to go about assuring constant reliable operation over RF. It sounds like a gameshow buzzer type system, and if that’s true perhaps the best thing to do is do some carrier sense multiple access (CSMA) Media Access Control system. The problem is that it’s possible for a pair of units to sense an empty channel and begin transmitting at the same time. In that case, it is impossible to know which was first. Also, these transceivers aren’t capable of detecting collisions. Perhaps, if you were able to synchronize their clocks using transmissions from the main node to the edges, you could use retransmission as each button press packet could include a timestamp. That way, you compare timestamps rather than arrival time.

  9. #9 by Seb on February 1, 2011 - 9:29 pm

    Hi,
    Which spi.h library are you using?
    Can’t seem to find any on google, using the defines in hardware.h.
    Thank you for the good work!

  10. #10 by hpux735 on February 1, 2011 - 9:49 pm

    Oops!! Sorry. I didn’t include those. I wrote my own. It’s really basic, the point is only to make it easier to switch between hardware and software SPI. One of my development boards didn’t have accessible hardware SPI pins. (They were used for the programming interface.) I added them to the post.

    As a point to anyone using this code, is there any interest in opening up a github project to share some development work? I’d like to add some extra features to the firmware, such as a managed serial port mode where the bytes are more reliably packetized and error checked. Another idea is to add some dynamic configuration of the transceiver parameters. Right now, you’d have to re-compile the code to do anything.

  11. #11 by Issam on February 12, 2011 - 7:52 am

    Hi , unlike the ‘ MRF24J40MA ‘ I can’t find any addresses for the registers in the MRF49XA ‘s datasheet ,however you wrote “To get access to the receive FIFO you initiate an SPI transfer to the MRF module with the contents equal to the address of the receive FIFO. In this case it’s 0xA000.”
    where did you get this information from ?
    Thanks

  12. #12 by hpux735 on February 12, 2011 - 7:52 pm

    It’s on page 17 of the MRF49XA datasheet. Good luck.

  13. #13 by Issam on February 13, 2011 - 9:28 am

    Do you mean the power on reset values ? they are quite different from the addresses written in the “MRF49XA_definitions” file, except for the first bytes, it is not the case for ‘CFSREG : POR= A680 , addr = A000’ and ‘WTSREG : POR = E196 , addr = E000’ registers.
    Thanks

  14. #14 by hpux735 on February 13, 2011 - 9:40 am

    After reading your question a few times, I think in understand the confusion. SPI isn’t really an address-oriented protocol. Therefore, it isn’t immediately clear what’s happening here. The address length isn’t fixed. For example, STREG has no address. Any time you do a read on SPI while sending ‘0’s over MOSI you’ll get that register. Notice that every other address starts with a ‘1’. It’s a bit like a huffman code, except the address length more-or-less corresponds to the number of bits are left over after the register bits are taken out. The address is, then, whatever higher-order bits are written as explicit ‘1’s or ‘0’s on page 17. Or, on a register description page, such as GENCREG on page 20, it’s called the CCB (or Command Code Bits). Hope this helps.

  15. #15 by Issam on February 14, 2011 - 10:38 am

    Ok , that was helpful , but I am still confused a little bit
    “The command code bits (1001100b) are serially sent to the microcontroller to identify the bits to be written in the TXCREG ”
    it dosen’t make sence , I thought that CCBs are sent from the microcontroller and then the MRF49XA puts the following configuration bits in the appropriate register.
    thank you .

  16. #16 by hpux735 on February 14, 2011 - 10:48 am

    Ultimately, yes. You’re right. There is some funky language in the datasheet. Sometimes that MRF49XA is referred to as the “microcontroller.” Follow along with the way you think it works. It sounds like you’re almost there.

  17. #17 by Issam on February 14, 2011 - 1:28 pm

    What about the reading ? if I want to read the RXFIFOREG for example I will send ‘B0XX’ to the MRF49XA , then I will immediatly receive the RXDB = XX byte (page 31), right ? , I mean the real received data will be replaced by XX !!!! .
    Thanks .

  18. #18 by hpux735 on February 14, 2011 - 1:45 pm

    Right. If you use SPI to send BOxx on MOSI then the module will place xxyy on MISO. where xx is unknown/doesn’t matter and yy is the register contents.

  19. #19 by Issam on February 15, 2011 - 12:41 am

    OK , I understand now ,thanks for your help and for your time.

  20. #20 by Venkat on February 16, 2011 - 7:04 pm

    @hpux735
    Hi,
    Thanks for all the explanation regarding the functioning of the MRF chip. I have two pcb’s based on the Microchip’s schematics, both hooked up to a PIC16F688. One is set as transmitter and the other as receiver. The TX mod sends a packet of 4 bytes every second. I can tell some RF is coming out from a RF sensor. The RX mod is set to wait on IRO. The FIFO is enabled, RXCEN is on. I see a voltage fluctuation on the RSSIO pin on the RX mod. But IRO is stuck at ‘1’. I can swap the two modules and still the same deal. With the above info can you tell what I may have missed. ?
    Thanks a lot for your help.

  21. #21 by hpux735 on February 16, 2011 - 9:38 pm

    I think I know exactly the problem you’re having. Pages 32 and 33 of the data sheet discuss the FIFORSTREG. This register defines the behavior of the FIFO. I may have omitted a small detail about this behavior. It’s not enough to simply leave the 0xAAAA in the TXFIFO to make a packet. There must also be a preamble, either 0xD4 or 0x2DD4 (depending on the state of the SYCHLEN bit in FIFOSTREG). You must prepend this to your packet, before your data. Once the receiver hears these bytes on the air it begins filling the FIFO. Hope this helps.

  22. #22 by Venkat on February 17, 2011 - 1:58 pm

    @hpux735
    The TX mod sends the following sequence:
    Turn off TX and RX in PMCREG
    enable TX reg in GENCREG
    turn on TX in PMCREG
    send B800|0x20
    send B800|0x2d
    send B800|0xd4
    send B800|0x04
    send (4) ‘a’ s
    send B800| 00 (dummy)
    turn off TX
    Of course there is a wait for SDO after every send.
    Did I miss anything?

  23. #23 by hpux735 on February 17, 2011 - 2:08 pm

    Are you waiting for an SDO before sending the first byte (0x20, what is that anyway?)? You need to make sure the 0xAAAA is transmitted. That’s used to initialize the AFC (automatic frequency control) and allow the squelch to open and everything.

  24. #24 by Venkat on February 17, 2011 - 3:15 pm

    @hpux735
    My bad, the 0x20 should be 0xAA.
    Yes i do wait for SDO before each send. I am explicitly sending only one 0xAA. Other one should be already in the TX reg, right? May be I will send another one explicitly.
    Thanks for your time.

  25. #25 by hpux735 on February 17, 2011 - 3:19 pm

    It depends on whether you wait for SDO after
    “turn on TX in PMCREG”

    but before
    “send B800|0×AA”.

    Also, you may be able to enable to enable the output from the demodulator. I don’t remember on what pin it is. That may help with debugging…

  26. #26 by Venkat on February 17, 2011 - 3:26 pm

    @hpux735
    Yes i do wait before ‘send B800|0xAA’. OK, I will try a few things and see how it goes. Thanks again.

  27. #27 by Venkat on February 17, 2011 - 3:42 pm

    @Venkat
    One quick question:
    After CS is brought down, and the first byte is sent as B800|0xAA,
    Does it matter if the data byte 0xbb is sent with B800|0xbb or directly as 0xbb? I see examples of code that do both. The CS is brought up after all bytes are sent.

  28. #28 by hpux735 on February 17, 2011 - 3:53 pm

    @Venkat
    I’m not really sure. I’ve always done it as a 16-bit write as (0xB8|0xbb). I don’t know if it would work another way.

  29. #29 by ether on February 24, 2011 - 6:44 pm

    Hi,

    Why did you pick such a low data tx rate 9600 so what would it take to increase this and what is the upper limiting factor for the design
    Maybe i skimmed but how is your atmel ucontroller connected to the MRF*
    Also i see leads attached presumably to an antennae have you any part nos for them?
    Did you have a test program to transmit/receive data?

  30. #30 by hpux735 on February 24, 2011 - 8:15 pm

    I chose 9600 baud because it’s being used to transfer GPS NMEA-0183 data with a signaling rate of 4800 baud. In this case, 9600 baud is a compromise between having overhead for checksums and packetization and noise immunity. The upper bound set by the TX FIFO is 172 Kbps. If you used the raw demodulator output, the maximum is 256Kbps. What leads do you mean specifically? I have part numbers for everything, but I don’t know what you mean. The test program is in the article, they’re the .c and .h files. It runs on atmel MCUs.

  31. #31 by Venkat on March 4, 2011 - 10:12 am

    @hpux735
    For some reason, my RX unit is not synching up. I dont get an interupt at all. The TX unit is definitely emitting RF (as I can detect it with my RF probe) bu cant tell if there is any modulation on it. Do you have an assembler listing of a simple RX – TX setup? I am running in ASM not C. I think I have the routines coded right, but I must have missed something. What could that be?

  32. #32 by hpux735 on March 4, 2011 - 10:28 am

    I don’t have anything in ASM, sorry. One way to tell if there is modulation (assuming you have a radio that can tune to the frequency you’re using) is to tune a radio to whatever frequency that you’re transmitting on. Put a VERY low bit rate signal to be modulated, if you have to do something like 0xFFFF 0xFFFF 0x0000 0x0000 so be it, and listen to the sound the radio makes. The sound you hear on the radio will be similar to the modulated signal. For example, if you use an FM radio then you’ll hear a tone with the same frequency as your modulation rate. If you use an AM radio you’ll hear 2 tones that change along with the modulation rate. Also, if you can get access to a spectrum analyzer, that would be a huge help.

  33. #33 by Venkat on March 4, 2011 - 10:44 am

    @hpux735
    ok, thanks.

  34. #34 by Venkat on March 6, 2011 - 8:25 am

    @hpux735
    OK, I have sdcc setup now. Do you have a complete set of source files that you can share? Just to get the TX/RX working between MRF and pic16f688? The files listed above seem to be missing some .h files. Thanks.

  35. #35 by hpux735 on March 6, 2011 - 9:08 am

    Everything should be there… Which specific files are missing?

    You’re still going to have to do some porting work to make it work on the PIC processors. The provided code will only really work out-of-the-box on Atmel ATmegaX8 series processors.

  36. #36 by Venkat on March 6, 2011 - 9:40 am

    @hpux735
    These are some of the errors:
    hardware.h:15:20: error: avr/io.h: No such file or directory
    hardware.h:16:27: error: avr/interrupt.h: No such file or directory
    MRF49XA.c:14:24: error: util/delay.h: No such file or directory

    I understand some porting will be required. I just want to see the sdcc output mrf38xa.asm file for mrf49xa.c to check if I have something out of whack in my code.

  37. #37 by hpux735 on March 6, 2011 - 10:44 am

    @Venkat

    Those files are from the AVR Libc distribution. I’ve attached a zip file that contains them. They’re not likely to work for you, but at least you might be able to infer the meaning of the function calls…

    http://alternet.us.com/wp-content/uploads/2011/03/AVR-files.zip

  38. #38 by Venkat on March 13, 2011 - 7:45 am

    @hpux735
    OK! got it finally. The problem was that my TX loop had 26 instructions (in ASM). I was running the MC with the clock from MRF (1 MHZ) so the bit loop was over 100 us. This was causing underrun and hence the RX unit never got the 2DD4 correctly. Once i lowered the baud rate, the two units are talking. Thanks for your help.

  39. #39 by hpux735 on March 13, 2011 - 10:10 am

    That’s great, glad I could help.

  40. #40 by Seb on April 21, 2011 - 10:51 am

    Hi,
    Just double checking: your PC4 is linked to the RESET pin of the MRF49 right?
    Probably needs moving to hardware.h then 🙂

    Also, if anyone’s interested, I’m finalizing code for a USB/RF transceiver based on this chip. Had to change your code slightly to pack everything in 96bytes of RAM, but it looks cool now.

  41. #41 by hpux735 on April 21, 2011 - 11:02 am

    I didn’t have anything connected to the RESET pin of the MRF. I left it floating. The only pins I connected are interrupt request, SPI (SDI, SDO, CS, SCLK) and power. Sometimes I use RSSI, but not always. I’d love to see your USB transceiver stuff. I was toying with that idea, also.

  42. #42 by Seb on April 22, 2011 - 5:02 am

    Ah ok, it’s just that you’re using PC4 in the interrupt routine, so I was wondering where it goes. I’ll keep you posted about the USB transceiver, once it actually works 🙂

  43. #43 by john on May 23, 2011 - 6:58 pm

    Good writeup and subsequent help, just got my own circuit working with a attiny84. One issue I had was insufficient SPI speed for the transmit rate, so the synchronizing packets would be sent disjointed and not synchronize it. Something other might want to watch out for too.

    I used a PCB small loop antenna (7x10mm), which requires only a track on the board, and get 60m clear LOS transmit out of it, and around 15m indoors.

  44. #44 by Steve on July 8, 2011 - 3:55 pm

    What do I do with the BBBW and Deviations once I calculate them ?

  45. #45 by hpux735 on July 9, 2011 - 12:01 pm

    Once you find the ideal number, mine was about 50khz, you look for the nearest available bandwidth setting in the data sheet. Then, you use it to initialize the chip. The example in the data sheet and I rounded up. I suppose you could round down if you think there may be near by interference sources, but it will attenuate your desired signal. By the way, the register for setting this value is described on page 27 of the data sheet.

  46. #46 by Steve on July 20, 2011 - 8:21 pm

    @hpux735

    yeah but Im confused as to what register get what , can you clarify, thanks for responding

  47. #47 by hpux735 on July 20, 2011 - 8:34 pm

    Bits 7-5 in the RXBW register. There is a table that converts BBBW values to bit patterns.

  48. #48 by aiqon on October 13, 2011 - 9:33 am

    hi,
    a noob question: how do you connect this board to a computer? Someone mentioned an USB/RF board but this very circuit needs some I/O board like arduino to be programmed,am I right?

1 2 3
(will not be published)

Please complete this capcha. I get almost 1000 spam comments a day! * Time limit is exhausted. Please reload CAPTCHA.