Today I want to discuss with you the options of the system architecture based on the IEEE 802.15.4 network solution.
This article refers to the address: http://
There is always a matter of everything. If your project requirements meet the ZigBee®-Smart Energy standard, etc. due to power company regulations or RF4CE versatility issues for the same or multiple LCD TV product lines, you should not consider the network protocol because of the need to meet a specific standard. Already more or less existed. In this case, your time and effort should focus on the choice of vendors and hardware, carefully considering the maturity of the software you will get, the hidden costs of all chip vendors, and what tools you would like to develop when developing. And system level support. However, if you are not burdened by partnerships, compatibility requirements, or non-technical micromanagement leaders who make design decisions, there are certainly many options to choose based on system attributes, requirements or expected features, and performance requirements.
If your system has two devices on the network, then you must not complicate things. In an effort to help build the network boot sequence of a consumer ZigBee mesh network, it was discovered that there were actually only two devices in the system, communicating at most ten feet apart, and working together in an initial default configuration. Nothing is more frustrating than this. Communication must be supported whether it is only point-to-point, one-to-many or multiple-hop. Most chip vendors offer a range of network protocol options ranging from basic proprietary software with only radios and basic communication interfaces to more sophisticated ad-hoc (possibly multi-hop proprietary or standard protocols such as :ZigBee or 6LoWPAN, etc.). I recommend that even in this simple case, you should consider your requirements based on the simplest case. Among them, the device is pre-programmed as a fixed network with fixed addressing and pre-configured pairing. In the more active case, their devices are not known to each other in advance. Or, if your device must dynamically establish a unique network identifier, it must be paired (usually with some security restrictions). Whether proprietary (eg TI's SimpliciTI protocol, etc.) or standard (eg ZigBee or RF4CE, etc.), the so-called "Initial Default Configuration" protocol has some methods to accomplish these tasks. You must carefully consider whether the agreement meets your system requirements.
In addition to matching your system/product requirements to the appropriate network protocols, please understand your resources and design capabilities before you get caught up. For some product experts, they don't have the RF layout and software networking experience to build a solution from scratch, so I recommend looking for a module vendor. These modules can provide drop-in FCC, or a qualified pre-programmed solution. It allows you to set specific parameters (eg network ID, channel, application port identifier, etc.), connect to the network, search for and pair with another device, and send/receive basic application data via UART, SPI or other device to provide a Simple API. There are protocol limitations for using modules, and the cost of a single device is higher, but for lower product yields (less than 50K), we find that the cost of the module is much more than just making up for RF layout, design, assembly, and inspection. And the NRE cost of software development and testing.
Whether you're building a custom solution from scratch or from an existing solution "cut-and-paste", I hope you have the best luck in the development process, and hope that this short article starts with you. I used to give you some inspiration in some key aspects.
Author: Brian Blum, Texas Instruments (TI)
Single Phase Overhead Electrical Transformer
Oil Type Transformer,Distribution Electric Transformer,Electrical Transformer
Bao Ding Tian Wei Group Transformer Co., Ltd. , http://www.jspowertransformer.com