Modules Simplify RF Designs
Ready-to-use wireless modules provide a way to quickly get a design "on the air" when engineers find RF circuits and communication protocols fall outside their areas of expertise. Even when engineers have RF experience, a module still might make sense from the perspective of saved time and money.
According to John Schwartz, technology strategist at Digi International, designers can take advantage of a module manufacturer's economy of scale. "Other costs for RF development, testing and manufacturing, designing test fixtures, and certification add up," noted Schwartz. "Certification in the US, Canada, Europe and Japan runs about $US 30,000."
"Our modules have FCC modular approvals," said Colin Faulkner, product marketing manager for ZigBee products at Jennic. "We have tested the modules to meet or exceed the FCC requirements so a manufacturer can use a label on their product to refer to our FCC qualifications. So by using a module you get our certification and you know the module will pass any further tests."
Another advantage: Pin-for-pin compatibility. "We have modules that operate in the 868-, 900-MHz bands and in the 2.4-GHz band," explained Schwartz. "And these modules can operate in point-to-point, point-to-multipoint, mesh, and other configurations. A common size and pin functions lets designers use the appropriate module for a geographical region or application and still use the same hardware design. And in many cases, firmware requires no changes. All our modules have a common application programming interface [API], and although a command or two sometimes differ slightly, the structure remains the same. Designers always use the same UART port to control the module." The Digi API was designed with MCUs and MPUs in mind, so programming becomes straightforward.
"Designers also need to consider network stacks," noted Gordon MacNee, European field applications engineer at Jennic. "We offer the JenNet stack for proprietary systems when designers don't need interoperability with other vendors' equipment. We know JenNet works in very large networks and users don't need to join an alliance or pay a royalty fees to use it." Other module suppliers also offer their own proprietary protocols.
"We have seen increasing use of the ZigBee protocol particularly in smart-energy products," said Jennic's Faulkner. "Many engineers considered ZigBee synonymous with 2.4-GHz communications. So often they have their minds made up to use ZigBee. But after we talk about their application it turns out ZigBee isn't always appropriate for what they want to accomplish. Engineers can take advantage of many other communication techniques at 2.4 GHz. And we offer the IETF standards-based 6LoWPAN stack that runs "on top of" the JenNet networking stack for engineers who plan to use the Internet protocol [IP] for communications."
Developers also must think about the communication range they need. "Generally speaking, the lower the frequency, the better the range," said Digi's Schwartz. "People think 900 MHz is good, 2.4 GHz is better, and 5.8 GHz is best because they see computer clock rates increase and improve PC performance. In the RF world, it’s the other way around. At 5.8 GHz, signals can reach across a room. At 2.4 GHz signals penetrate a wall or two, and at 900 MHz, you get even more range."
"Because users' environments vary, we recommend developers use our API so they can build in fault tolerance and have a protocol that allows for occasional errors, for example," noted Schwartz. "Programming via the API lets you get information about whether or not a packet was properly delivered. Then a host processor can decide to retransmit it, wait a while and retransmit it, or try a different channel. You have the opportunity to handle many situations via operations through the API."
"To start, we recommend developers buy an evaluation or starter kit," said Jennic's Faulkner. "Then they can see what goes on when they communicate between modules. Next they can put a module in their own prototype and get it running. The kit provides a good reference design they can always go back to. We like customers to have common reference hardware so if they call and say, 'I can’t program this, or it doesn’t work like that,' we can send them a bit of code to drive an LED, check a push button, and so on." That way they can confirm the module does what it should, and the problem probably exists in their prototype hardware or firmware. "Designers find it helpful to go back to an evaluation kit to ensure their code runs properly or to help locate any program bugs," explained Faulkner.