Would anyone like to share a design with the CC2480 Z-Accel device? It would be great to hear some technical feedback and discussion on how this is being used in your application.
Anyone who would like to share their user experience with the usage of ZASA, the sample application code that comes with eZ430-RF2480
LPWRocks
"Customer Centricity, Enthusiasm, Mass collaboration and Great minds are the best path towards great products"
LPWRocks:Anyone who would like to share their user experience with the usage of ZASA, the sample application code that comes with eZ430-RF2480
I just wonder when will CC2480 fully support Zigbee on application layers?
The CC2480 supports the entire Z-Stack API including all APS commands and ZDO functionality. All hooks are in place so that if you wanted to build a Home Automation device you can implement the appropriate clusters and write the HA profile code on the host processor. As we extend our Z-Accel family of devices we will be considering other options.
PME_BLUM: All hooks are in place so that if you wanted to build a Home Automation device you can implement the appropriate clusters and write the HA profile code on the host processor.
All hooks are in place so that if you wanted to build a Home Automation device you can implement the appropriate clusters and write the HA profile code on the host processor.
I have allready implemented ZCL Foundation, ZCL and Custom Profile on host processor - this was plenty of work.
You might say, ZCL is part of App-Profile, but ZCL Foundation is basis for ALL current public profiles so can't agree your argument.
PME_BLUM: As we extend our Z-Accel family of devices we will be considering other options.
As we extend our Z-Accel family of devices we will be considering other options.
Can you give me some more information?
It is correct that the ZCL foundation is a basis for all public profiles, but depending on which profile is used you will be using a different subset of the ZCL so in most cases it's overkill to implement all of the clusters. Ideally we would put all clusters onto the network processor and have everything supported out of the box. In the future we will continue to expand our ZigBee and 802.15.4 portfolio of products so please stay tuned for future products and contact local sales for more information.
Hi Oz,
Great work. Thank you very much for your feedback. I guess what you would like to see in a sample application is a full RPC client on the host including ZCL and a public profile
Right ?
BTW:
You almost got my name right. It is Morten not Morton :)
LPWRocks.
I am using the eZ430-RF2480 evaluation kit. I am writing a stand-alone PC program in LabVIEW and communicating with the radio via the virtual COM port generated by the USB connector that comes with the kit. I am using the CC2480 Interface Specification SWRA175A to determine the API protocols needed to communicate with the radio via the serial comm port. I have been successful in executing many of the SYS Interface commands with my program (section 6.1 of the spec).
I have a question concerning the SYS_TEST_RF command (6.1.12). I have successfully executed the command to set the radio in unmodulated carrier and pseudo-random data modes confirming execution on different independent equipment. However, when I try to use the command to set the radio in "receive mode", I do not know how to access any data packets received by the radio while it is in this mode. There is no further documentation in the specification on how to do this.
Has anybody else used this particular SYS command with this kit? Any advice/assistance would be greatly appreciated!
LPWRocks:I guess what you would like to see in a sample application is a full RPC client on the host including ZCL and a public profile Right ?
I guess what you would like to see in a sample application is a full RPC client on the host including ZCL and a public profile
Hi Morten,
Thats right! You fully understand me!
OZ
Great and thank you for your feedback. Would you like to share some of your work on the client host with our community?
Hi mtrumm,
continuous RX is not meant for packet mode, only for RF testing to measure for example spur.
I guess you have connect the RF output when doing TX setup of modulated and unmodulated spectrum to a spectrum analyzer to see it work. Right ?
Hello LPWRocks,
Thanks for responding. First, you are correct, I did use a RF Spectrum Analyzer and another TI radio running on a ChipCon board to confirm proper Tx operation of the SYS_TEST_RF command.
I do not know what "measure for example spur" means, I am not an RF expert. I am a Test Lab engineer that was asked to develop a 802.15.4 "sniffer" program using LabVIEW (like a serial port sniffer, but for 802.15.4 wireless). I am using the EZ430-RF2480 eval kit because it comes with a SPI-UART converter USB device that make a virtual comm. port on a PC that is easy for me to access with LabVIEW.
I do understand that the Rx is not made to run in "packet mode", I am NOT really interested in interpreting specific data packets. However, it is my hope that the Rx function of the command does actually demodulated (down-convert) the RF signals into HEX code that I can read through the UART converter (otherwise, what is the point of the Rx feature of the command?). When I send out a pseudo-modulated signal using the same command, I can read the random HEX data sent on another radio/SW combination and want this same capability with the EZ430-RF2480 and LabVIEW. Do you believe this is possible?
Thanks!
Hi Mike,
The continous RX test mode was added due that there are some requirements with respect to regulations for RX spurious (harmonics, phase noise). ETSI and FCC have a requirement for this to be tested.This is the reason for this SYS_TEST_RF command.
It is related to maxium power and duty cycle I believe. Please check with local regulations authority.
Background info on the topic for a non-RF expert if you are interested:
http://rfdesign.com/mag/radio_characterizing_phase_noise/
http://rfdesign.com/images/archive/301Mini-Circuits58.pdf
http://en.wikipedia.org/wiki/Phase_noise
http://en.wikipedia.org/wiki/Harmonic
I have to answer your question :)
Sorry, but what you are requesting is not possible. This data is not available.Basically, you configure the CC2480 to be in this mode just see if there are any spurious to comply with FCC and ETSI requirement.
Anyway, this is great feedback. Based on what you are doing we can gain some excellent input. What should have been added is the "RF Promiscous mode" for RF monitoring of the IEEE 802.15.4?
This would haven been very helpful for you to develop a packet sniffer and also a low cost spectrum analyzer :)
Something like this:
http://www.ecsl.cs.sunysb.edu/cse591/RFMon.pdf
Hi,I'm currently working with ZASA. I'm trying to understand the full source code and modifying it to suit my application.I'm having this problem.while using ZB_SEND_DATA_REQUEST API given under SAPI, It only works with 0xFFFE as destination address provided that binding entry for the command ID has been already created. It doesn't work with 0xFFFF or 0xFFFD or 0xFFFC as destination addresses.But all address modes work well with AF_DATA_REQUEST even if binding entry doesn't exist for the command ID being sent.An another doubt I'm having is, the API ZB_SEND_DATA_REQUEST doesn't have any field for end point id's like in AF_DATA_REQUEST. So, even if ZB_SEND_DATA_REQUEST works with broadcast address mode, will the data be sent to all end points in the destination address?and also, when i send some data using AF_DATA_REQUEST (Command:0x2401), the SRSP from CC2480 is the type of AF interface(AF_DATA_SRSP (0x6401)) but the confirmation call back and the data indication are the type of SAPI (ZB_SEND_DATA_CONFIRM (0x4683) & ZB_RECEIVE_DATA_INDICATION (0x4687) ).
I want that to be AF data indication coz it comes with a timestamp & link quality field which is useful in my application.
If anybody can help me out of these problems, it would be great..
ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". TI AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY TI. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM TI.
Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.