Wireless Module vs. Custom Implementation

Interested in adding wireless functionality to your project?

There's two main ways of doing this - with a premanufactured Module or a custom implementation. I've used both in the past and right now I'm working on a project right now where I need to use both approaches. There's a lot of hype out there with people arguing that one approach is better than the other but I thought it would be good to record exactly what I encounter with both approaches on this project. The technology used for both of these implementations is nearly the same which makes for a good comparison and both required internal antennas.

Custom Radio Implementation

Design

• Figure out best antenna for the application: this depends on required performance as well as the enclosure used for the product.
• Design matching circuit: While most RFICs and antennas have a 50 ohm impedance, some may differ and a small matching circuit is required. This needs to be done by an RF engineer. For most applications the RFIC manufacturer provides a reference design. For some reason that eludes me these always contain rare components that are a pain to source, and the reference design exhorts you not to change anything or else it will screw up your performance
• Layout the PCB with the RFIC, antenna, and matching circuit. Most EDA packages have an option for automatically setting the width of the trace based on the desired impedance, as long as the PCBs are manufactured consistently each time. Heh.
• It's a good idea to get the RF circuit reviewed by someone else, to help prevent stupid errors. And because it's "black magic" to most of us. This can be done by the RFIC manufacturer or the antenna manufacturer. Antenova (Antenna vendor) has a nice service whereby you give them some money and they design the matching circuit for you.
• Firmware is lots of fun (sarcasm here) because you get to have to test that any change to your application may adversely affect the network stack. For simpler protocols this may not be much of an issue but if you're using more complex protocols (Zigbee, WirelessHART, etc.) this can get extremely time consuming.

 So now the PCB has been designed. What usually happens is that you go and fabricate the first few PCBs and find that performance doesn't match the reference board, so a few rounds of fixing is required. Next is manufacturing.

Manufacturing

• Usually the reference designs use a 4-layer PCB, to get a good ground plane for RF performance. And as I mentioned above, life is hell if you try to modify the reference design, so you're pretty much stuck.
• Impedance Control - Life is sweet as long as the PCBs are manufactured consistently. However, that's never the case due to all kinds of process variations in the PCB manufacturing process. So this is that little checkbox you see when you get PCB quotes that makes everything more expensive, because the PCB manufacturer has to test and verify the characteristic impedance of each PCB panel, and if it's out of spec then they have to toss them out.
• Source exotic RF components - as I mentioned previously, the reference designs often use components in the RF signal change that are extremely difficult to find. This becomes oh so much fun when you start production, as the CM will either complain or tell you that your lead time is very long (20+ weeks).
• Design RF test fixture - Rarely if ever will a variation in the electronics manufacturing process produce better RF performance, almost always RF performance will suffer if something wasn't assembled correctly. So, you'd better test each device for RF performance. Fairly straightforward if the device has a connector but if it has an internal antenna then much thought needs to go into the RF test fixture as it needs to be shielded to prevent interfering with other devices under test. And you'd better design a system to record the RF performance of each device being tested, too, for SPC.
• It's a minor issue, but if you're doing a cost analysis be sure that you look at what the cost of PCBs, manufacturing, components etc. is based on your actual volume. The module companies get components in 1M quantity discounts whereas you or I are stuck with whatever our actual volume is, usually lower. This can be an ugly surprise and make a custom radio implementation much more expensive down the road.

Certification
This is fairly straightforward if you're only doing FCC but can get expensive if you're targeting multiple countries. For FCC certification you should create a special version of your firmware that controls the radio so that their life is easier. I was working on one product that chirped out a small (20mSec) message every few minutes. That drove the test house crazy because it was very difficult to measure radiated emissions. So we modified the firmware to continuously send RF data. And there's nothing that firmware guys love to do more than stop writing code for The Next Best Thing so that they can create a custom spin of firmware just for RF testing. (sarcasm here). I've found that test houses always need to be "babysat" with someone from your company while the test is happening, that way it's easier to ensure that things are being done correctly, and that you can fix any problem that may arise. Getting FCC certification for a simple RF product usually costs around $9k in direct expenses (e.g. test house fees, FCC fees, etc.) and another $10k in indirect expenses (paperwork, creating test firmware, babysitting the test house etc.).

Module Implementation

Design

• Figure out best module for the application: this depends on which protocol you're using and even more importantly, how easy it will be to integrate with the rest of the application. Examples are key here, as I'd rather take 10 good examples than 100 pages of specifications.
• Writing the firmware is an order of magnitude easier with a module, because changes to your application can't break the network stack since the network stack is running on its own processor inside the module. Also makes for less code to maintain in my experience. (20kB vs. 240kB)
• Since the module has all the RF stuff on it (RFIC, antenna, matching circuit, etc.) you just need to ensure that you pay attention to any ground plane requirements for the module. 

Manufacturing

• With a module your application will drive the PCB requirements, whereas with a custom radio implementation the RF section will limit your PCB options. So, for simple applications you can get by with a 2-layer non-impedance controlled PCB. Much cheaper and faster to prototype too.
• You will need to ensure that you can source the module as needed. It's best to find a module that is carried by a few distributors so if one is out of stock then you can get it from someone else.

Certification
If you are using a pre-certified module then certification requirements are much less. Here's a good article about it from Digi (I don't like their modules but they have good information):
http://www.digi.com/technology/rf-tips/2007/11

Conclusion - Which is the best approach?
The answer probably comes as no surprise - it depends on a number of factors.

Cost
For low volume products (less than 10k per year) the module solution is almost always less expensive due to the high up-front costs of developing a custom radio solution. For higher volume products then you'll need to do a valid cost comparison. If it is unsure whether the product will become high volume then I recommend the module approach, as it will be much faster and less expensive up-front. Then later if it turns out that the product line is indeed high volume then you can do a cost comparison. However, if you're going high volume then oftentimes the module manufacturers will work with you on pricing so that it becomes a wash whether to continue using a module vs. re-engineering a custom solution.

Expertise
If your company lacks RF experience then you're probably better off going with the module approach, as it will be much easier than trying to learn RF. Most companies that choose the custom radio approach will end up outsourcing most of the RF work but your company will still need to learn about RF so that you can solve the inevitable manufacturing issues.

Time to Market
One aspect of time-to-market that oftentimes gets overlooked when comparing a modular approach with a custom radio is firmware development time. If the module comes with lots of relevant examples then life is good since you will be able to get up and going quickly and you won't have to learn the intricacies of the network stack. If you're developing a custom radio solution then you'll get to learn the network stack in-depth, which will obviously take much longer.

Reading the supply voltage using the MSP430's internal Analog to Digital Converter

Many times you need to measure the supply voltage (Vdd) of the MSP430. The MSP430 has an ADC input channel which is connected to Vdd/2. The divide by two is required because the MSP430's internal reference is 2.5V, so Vdd must be divided by two for full resolution.

Two simple routines for reading the supply voltage of the MSP430 family are shown below. Some MSP430 devices use the 10-bit ADC, e.g. the MSP430F2274, and some use the 12-bit ADC, e.g. the MSP430F248. Refer to the datasheet for your part to determine which is used. 

Using the ADC10:

/** Reads the MSP430 supply voltage using the Analog to Digital Converter (ADC).
On ez430 boards, this is approx. 3600mV
@return Vcc supply voltage, in millivolts
*/
unsigned int getVcc3()
{
ADC10CTL0 = SREF_1 + REFON + REF2_5V + ADC10ON + ADC10SHT_3;  // use internal ref, turn on 2.5V ref, set samp time = 64 cycles
ADC10CTL1 = INCH_11;                        
delayMs(1);                                     // Allow internal reference to stabilize
ADC10CTL0 |= ENC + ADC10SC;                     // Enable conversions
while (!(ADC10CTL0 & ADC10IFG));                // Conversion done?
unsigned long temp = (ADC10MEM * 5000l);        // Convert raw ADC value to millivolts
return ((unsigned int) (temp / 1024l));
}

Using the ADC12:

/** Private helper method to setup ADC for one-shot conversion and read out value according to registers.
Inserts a delay before beginning conversion if REFON
@return the raw ADC value with the specified commands.
@todo move the VREF warmup to startup and leave on to avoid 17mSec blocking delay each time?
*/
unsigned int getAnalogInput(unsigned int adc12ctl0, unsigned int adc12ctl1, unsigned char adc12mctl0)
{
#define ADC_VREF_DELAY_MS 17   
ADC12CTL0 = adc12ctl0;
ADC12CTL1 = adc12ctl1;
ADC12MCTL0 = adc12mctl0;
if (adc12ctl0 & REFON)                    // if internal reference is used...
delayMs(ADC_VREF_DELAY_MS);           // 17mSec delay required to Vref capacitors
ADC12CTL0 |= ENC;                         // Enable conversions
ADC12CTL0 |= ADC12SC;                     // Start conversions
while (!(ADC12IFG & 0x01));               // Conversion done?
return ADC12MEM0;    // Read out 1st ADC value
}


/** Measures Vcc to the MSP430, nominally 3.3V
- ADC measures VCC/2 compared to 2.5V reference
- If Vcc = 3.3V, ADC output should be (1.65/2.5)*4095 = 2703
- Therefore (halfVcc/2.5)*4095 = ADC reading and (Vcc/2.5)*4095 = 2*ADC
- So Vcc*4096 = 5*ADC and VCC=5*ADC/4095

@return Vcc in millivolts
*/
unsigned int getVcc3()
{
unsigned int ctl0 = REFON + REF2_5V + ADC12ON + SHT0_15;  // turn on 2.5V ref, set samp time=1024 cycles
unsigned int ctl1 = SHP;                                  // Use sampling timer, internal ADC12OSC
unsigned char mctl0 = SREF_1 + INCH_11;                   // Channel A10, Vcc/2
unsigned long vcc = (unsigned long) getAnalogInput(ctl0, ctl1, mctl0);
unsigned long mult = vcc * 5000l;
return ((unsigned int)(mult / 4096l));
}

Making Development Boards That Don't Suck

Lately I've had to use a few microcontroller development kits from manufacturers that, well, suck. From unlabeled connectors/components to not bringing out the unused pins, I'm convinced that many designers of development boards never actually use them to design anything.

When I'm trying out a new design, I frequently make my own development board. By "development board" I mean a schematic and layout that is the same circuit as the end product but optimized for firmware development and debugging. This allows a few things:

• Firmware development can start sooner - this is probably the most important since FW typically takes an order of magnitude longer than HW design
• Verify PCB footprints for components - you can spend a month checking and double checking a PCB footprint, or just build it and verify it on a real PCB in a week.
• Power Measurement
• Fast layout. Since the point of a development board is to optimize for development not layout, you can make things a little larger and not worry about squeezing everything in.
• Related to the previous, a development board helps you get a feel for how small you can make the design once everything is working.

Here are the a few rules for how to design development boards that don't suck:

• Expose all the pins of the components on test points or at least SMT pads. Soldering wires to fine pitch QFNs is a pain in the ass, and forget trying to do anything with BGAs. I recently helped out a major IC manufacturer and soldered some of their dev kits together because they didn't expose the unused pins.
• Include a serial port (RS-232 is my preference).
• Related to the above, bring out all signals that you can on easy 0.100" headers. This makes development much easier since you can attach logic analyzers, scopes, etc. Label them all with their signal name (more on this below).
• Label liberally. Silkscreen is free, so on a development board label all components, as well as the signals on 0.100 headers, etc. Taking 5 minutes to label the signals on the PCB is faster than taking 5 minutes every time to look it up in documentation.
• If it is a RF design with an onboard antenna, make an option for a connector. Can be SMA, U.FL or whatever, but something that you can connect to directly. I like to do this with a component in the signal chain that can be populated one way for the onboard antenna, or rotated 90 degrees to go to the connector instead.
• Include a power connector and LDO to allow powering from a wall-wart. Makes it much easier to hand over to the firmware engineer and reduces unnecessary thought.
• Enable power measurement: add a 0.100" header between LDO output and power input. This will have a shunt that can be removed and an ammeter attached instead. For extra credit, do this for the major power subsystems of the circuit.
• Use full-sized JTAG connectors, and used shrouded (polarized) headers to prevent having to think about it.

Also, if this will be a commercially available development board (not just an intermediate step towards a final design) then there are a few more recommendations:

• Use larger packages to make it easy to assemble and modify. I like to use 0805s for all the non-RF passives, and use the largest package I can get for the micro. And label everything!
• If the board has onboard peripherals (LEDs, buttons, etc.) then make them able to be disabled (disableable?). My favorite way to do this is with "Cuttable Jumpers", basically an 0805 footprint with a trace connecting the two pads. That way a user can cut the trace to disable the peripheral but can also re-enable it by soldering on a zero-ohm resistor across the pads.
• Be sure that you include firmware drivers for all the peripherals. You have to develop them to test the board anyway, might as well provide them.

The best development boards I've seen (besides the ones that I've designed of course) are the Stellaris development boards from Texas Instruments. Sadly, that company also makes some of the worst development boards too.