CC1101 BoosterPack

[zborgerd 62]

In fact, I'm pretty sure that you could take the reference deign from TI and just make a Launchpad board with it.

 

http://www.ti.com/tool/cc1101-cc1190em915rd

[HylianSavior 37]

Made it a bit tighter and added a ground plane (to the whole board), as suggested.

Thoughts?

 

[zeke 693]

That crystal placement is questionable. You should try to have it as close to the IC as physically possible. Try nudging it left and upwards.

 

Then, try nudging IC1 upwards as well. Now that I think about it, I think I'd try to move it to the top-left area of the board.

 

After moving all the components around will allow your copper pour will flow completely around all the components.

 

You could also put a copper pour on the blue layer as well. It will be extra RF insurance for a two layer pcb.

 

As a result, you'll have a great ground plane that triangular void in the bottom left of the board will be gone.

 

What do you think?

[HylianSavior 37]

That crystal placement is questionable. You should try to have it as close to the IC as physically possible. Try nudging it left and upwards.

 

Then, try nudging IC1 upwards as well. Now that I think about it, I think I'd try to move it to the top-left area of the board.

 

After moving all the components around will allow your copper pour will flow completely around all the components.

 

You could also put a copper pour on the blue layer as well. It will be extra RF insurance.

 

As a result, you'll have a great ground plane that triangular void in the bottom left of the board will be gone.

 

What do you think?

 

Edited board added above.

Moved the xtal over as well as some other components.

[zeke 693]

The picture is too big to see it all.

[HylianSavior 37]

The picture is too big to see it all.

You could right click>open in new window.

Otherwise, a handy link: http://dl.dropbox.com/u/538662/cc1101.png

[zeke 693]

You could right click>open in new window.

 

Well, I'm embarrassed :oops:

 

I never even thought of that.

 

 

I'd still recommend doing a ground pour on the blue side of the board as well.

 

Connect it to the red ground plane with 0.032" vias spaced evenly. You'd be amazed at how well that will clean up the RF leakage.

 

Good work! :thumbup:

[HylianSavior 37]

How's this?

[RobG 1,892]

I would make it even tighter, like on the pics below, so there are practically no tracks between RF components (if you move IC1 little bit higher, you should have no problem doing that.)

Also, no signals should be running under RF section (P1.7)

 

[HylianSavior 37]

After much neglect, I redid the entire board, using the Launchpad libraries. Made the traces much tighter this time.

 

Anyone have any opinions on antenna placement? Is it a better idea to move it away from the rest of the components, or just have it the way it is now?

[bluehash 1,581]

Should be ok. Zeke is better at this.

[pabigot 355]

I missed most of this discussion, but if it isn't too late: A feature I haven't found on any CC-related MSP430 board is a connection from one of the GDx lines to a pin that supports timer capture. This is critical for high-accuracy correlation of event times between multiple observers in a wireless sensor network. (IMO all GDOs should be connected to interrupt-capable lines since this simplifies transmitting/receiving large packets, but this particular use requires CCR support too.)

 

I can't tell which schematic is current, but at early image it looked like GDO2 was unused; it also looks like pins 8-13 are unconnected, and further that the G2553 has CCR capability on all six of those pins. If all these impressions are true, would it be possible to add this feature?

 

If quid-pro-quo is relevant, I've written a couple low-level drivers for these radios and would be happy to contribute to an open source library supporting the board, especially if it has this feature.

[HylianSavior 37]

Hmm, that's a good suggestion. I don't actually have much experience with the CC1101. I'll look into it.

 

Edit:

Thinking of revising antenna design using this DN: http://www.ti.com/lit/an/swra160b/swra160b.pdf

[pabigot 355]

To bring this back into the open (we'd been discussing in PM what I want to do, and the question arose why having GDO0 on P1.4 isn't enough):

 

There are many GDO signals that are useful, and all three lines (GDO0, GDO1, GDO2) are needed for to use the chip to its full extent. All the following applies to the CC2500 as well as the CC110x. From my RF1A implementation on the CC430 (which is an MSP430 with an integrated CC1101), I use these interrupts:

 

1) Detect start and end of transmission/reception. Other than use for ETA, this is the most reliable way to detect completion in the case of radio errors. One GDO required for the duration of a TX or RX (on a CCR line if ETA is used).

 

  // IFG9 (GDOxCFG=6) positive to detect sync word
 // IFG9 (GDOxCFG=6) negative to detect end of packet

2) Detect packet FIFO overflows. This is necessary when attempting to send or receive more than 63 bytes of payload. Two more lines required for the duration of a TX or RX.

 

  // IFG4 (GDOxCFG=1) positive to detect RX data available
 // IFG7 (GDOxCFG=4) positive to detect RX FIFO overflow

 // IFG5 (GDOxCFG=2) negative to detect TX data available
 // IFG8 (GDOxCFG=5) positive to detect TX FIFO underflow

 

That's three lines needed during TX and RX, and there are only three on the chip. Recall also that GDO1 is used as SO while CSn is held low, so any RF-related signals are not usable while communicating with the chip (e.g., to read or write the FIFO to make room for the rest of the packet). For reliability, you need the FIFO ones to be available even while talking with the chip, so both GDO0 and GDO2 are necessary.

 

It may be possible to reduce the number of lines needed at a cost of increased code complexity detecting errors or managing state, or by giving up on functionality like packets larger than 63 bytes. It's also true that if the MCU is one of the 14-pin models, it probably has other resource limitations that prevent full exploitation of the chip features. But for 20-pin models like the G2553, having full access to everything would be very nice, if doing so doesn't risk breaking the 14-pin use case. (I am not an EE so can't offer any suggestions on how to accomplish that.)

 

(For completeness: For passive monitoring of the signal environment to avoid jamming another transmitter, you also want two interrupt lines:

 

  // IFG12 (GDOxCFG=9) positive to perform clear channel assessment
 // IFG13 (GDOxCFG=14) positive to detect signal presence

They don't co-exist with TX/RX, but do need to stay active while communicating with the chip, so three lines is again the minimum for a robust solution.)

[zeke 693]

Should be ok. Zeke is better at this.

 

:oops: