CC1150: Invalid RF State on Startup when connecting to Smart RFStudio 7 through the CC-Debugger

Is this a two layer board and are all traces etc shown? If the answer is yes, this looks like a very poor RF layout. It's strongly recommended to use the same amount of vias from the die apddle to ground (5 or more) and use a ground plane to ensure good grounding. 

- Do you have a scope available? If so, could you see if the xtal has started

- If not, do you have a logic analyzer, check the state of SO.

Yes this is a two layer board. I'm working with the free version of Eagle, so two is the max I can do for now.

At this stage I'm less concerned with the level of RF layout, I'm working on whether or not this will be a viable chip to implement into a project to replace the Linx chip that is currently being used. 

It's also worth noting that this is only my second or third attempt at a board that operates with RF at all, so everything is a learning curve. Thanks for the blunt feedback about the poor layout...

Moving forward I will approach my boss about paying for the full version of Eagle to allow me to use more than two layers to get the internal power planes. This should also help with the overall profile of the board as it will be implemented in a wearable device.

Unfortunately I do not have a scope or logic analyzer readily available to me. I packed up what I could and brought it home when my government imposed closing nonessential businesses two weeks ago.

The one board worked immediately and with multiple power cycles and connections to the debugger, which would tell me the xtal was working at some point, so it seems strange that it would suddenly stop communicating at the same time as the other board throwing the error.
There is also voltage present across the crystal if that is any indication that it's at least being excited. There is 0.75V on pin1 and 0.05V on pin2 of the crystal.

2-layer should be sufficient. I would recommend looking at the CC1101 and CC1150 reference designs and use that as a starting point. 

- Ground plane 

- Vias to ground

- RF routing on the same side of the PCB as the chip.

What is the voltage on the RBias and Dcoupl pin? 

Ok will do. I'll take a closer look at the layout in that package and consider your points for my next layout.
The schematic for the 433 design is what I based my schematic on - the files just don't open in Eagle or I would have used them verbatim.

Do you think this design is usable as it stands for basic communications with SmartRF Studio?
That is mostly what I wanted to achieve, then maybe getting two boards to talk and prove that settings can easily be changed by a tech in the field who wouldn't have to completely understand the electronics involved.

The voltage on RBias seems to be floating between 5mV and 12mV. 12mV when I first measured it and down to 5mV after double checking that I was still getting voltage elsewhere.

The voltage on Dcoupl is 3.18V (same as Vin).

The voltage on RBias should be around 1.25 V and DCoupl should be around 1.78 V meaning that you most likely have a short or wrong connection somewhere. 

Ok thanks, I'll dig in and take a closer look for mixed connections and shorts.

I've done up a new board layout with the suggestions mentioned above.

I started with just a ground plane on the bottom, then thought about adding one on the top layer as well to more closely match the TI board layout. So the ground vias are redundant, and if everything else checks out, I'll remove them before ordering the boards.

One thing I noticed int he TI layout is that none of the headers seem to match the pin out for the CC-Debugger, is that intentional?
I also wanted a way to push RS485 data through to the chip from other circuitry (if I get that far) hence why I brought GDO0 and DGO1 to a separate header, is that a sufficient way to do that?

Before I jump the gun again and just order these, can I get some feedback on this layout?

Cheers,

Scott

I would strongly advice to look at our ref designs since you layout still is not a good RF layout

"So the ground vias are redundant": In RF it's nothing that is a redundant ground via. Some reasons: A via add inductance so many in parallel decrees the total inductance. Feedback loops: Decoupling caps need as short as possible feedback loop back to chip ground.See the layout part of http://www.ti.com/lit/an/swra640c/swra640c.pdf for more detail.

The decoupling caps should be placed close to the power pins, see the reference design. It looks like you have placed all in a line which will have no effect.

How are you going to use this board in the end? Are you only going to control the board with a CCDebugger and not use the chip together with a MCU to make an application? 

Ok I will move the decoupling caps around to be closer to the power pins - I just thought it would be easier to assemble if they were all together (I'm building these by hand).

That layout resource is excellent, thank you!

Good to know about the vias. Is it more optimal to have less inductance (more vias) then?

This board is mostly just to be absolutely sure that I can do everything I want with the chip before trying to integrate it into a full design. And apparently hash out my design short comings when designing RF circuits.

The long term goal for me is to integrate the CC1150 into an existing board to replace the Linx TRM module in use.

For right now all I want is for the CC1150 to be a dumb transmitter/receiver; Take the RS485 data in and just pump it out over the programmed frequency / receive data and pass it to the rest of the circuit. No encoding, no error checking, and minimal peripheral circuitry.
- It's only function is to send and receive camera control signals in a wearable camera system.
- And ideally the addition of this chip and it's peripherals wouldn't impact the size (too much) of the board already in use which I have down at 2.5cm long x 2cm wide x 1cm tall.

So I'd be using the CCDebugger to program what frequency and channel to use, but then have it operate without the debugger present. Treating the debugger as more of a programmer to allow for changes to occur in the field.

I know this is under using the functionality of the chip, but for the first run at this chip I don't want to over complicate the substitution from the older tech to the new.

I would welcome your feedback on how plausible this is or if you know of a different chip that would achieve what I'm looking for.
- My only issue with the Linx chips is that they come at specific frequencies only (315, 418, 433, 915, etc) and there is no way to adjust them (ie channels) if that frequency is already overrun in a specific area.

Thanks!

From the description above I get a feeling that you don't yet have full overview of what CC1150 can and can't do. Please re-read the datasheet. 

The CC1150 is a transmitter only, is it a typo that you wrote that you need transmitter/receiver?

The CC1150 is  transceiver meaning that you have to have a MCU in the system to control it. CCDebugger can be used if you want to control the chip with SmartRF Studio. 

If space is limited I would look into a wireless MCU + IPC which will get the number of external parts down. 

I would recommend also to use the packet handler in the chip. It's possible to get a lot better radio performance if preamble + sync is used and I would advice to take the RS485 data and wrap them with preamble + sync + CRC before sending them on the air. 

Well now I feel like an idiot... I must have read transceiver once and then ran with it having the dual functionality I'm after.

For ease of design I would like the same transmitter/receiver on both sides even though I'll be working on a one way communication system.

Space is absolutely a limiting factor for this project.

For a full system on chip, would the CC1110Fx or CC1111Fx be suitable? That's the only (TI) wireless MCU I found in the sub 1GHz range.

Right now with the Linx chip there is no packet handling, so I'm looking at replicating that to start before adding in the packet handling.

So far I've forced the change from a very rough prototype board to an actual PCB in the units, so I'm making baby steps.

Thanks for pointing this out, time to switch gears!

Could also have CC1310, CC1312 etc which is a couple of generations newer than CC1110Fx. Both will be suitable for your application. 

For these radios you are making it more difficult for your self if you are not using packet handling. 

Since you are planning to use RS485 I would believe that you need a RS485 interface in addition to the RF chip.