• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 55 subscribers
  • Views 941 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2510 and MRFI inteface

Ian Barnes68507
Prodigy 210 points
Other Parts Discussed in Thread: SIMPLICITI, CC2510, CC2500, MSP430F2274

Hello,

I'm have the CC2510 Mini Development Kit and I am trying to use the MRFI API directly for my own proprietary protocol. This is because both end points in the network will be battery powered, so I cannot afford to use the full SimpliciTI stack because the power drain of an always on receiver would flatten the batteries too quickly.

Previously I have a simple transmit/receive setup working based on the PER_TEST in swrc085b. This only achieves one way communication, but it works reliably. The packet of data I am currently sending is only 1 byte.

I want to use the MRFI library because I believe this handles the hardware correctly especially when moving from idle, rx and tx. I have managed to cut the example down included in the SimpliciTI download, so the I only call MRFI_Init() and MRFI_RxOn(). But my MRFI_RxCompleteISR() never gets fired when I use my existing transmit code to send a packet from another CC2510.

I have checked the following:

  1. The configuration of the two radios is the same.
  2. The RF interrupt handler fires in mrfi_radio.c when I hit the button on my transmitter and it makes it to the section commented CRC  and frame length check. At this point the mrfiIncomingPacket structure is filled with all zeros - both frame and rxMetrics so it drops out of the handler before calling RxCompleteISR().

The only thing I thought it could be, is maybe the MRFI library requires packets of a certain structure - does anyone know if this is the case? Or does anyone have a cut down example of using the MRFI API directly?

Many thanks, Ian.

  • 0
    Prodigy 185 points

    Hi i also have a question regarding this. I am using CC2500 and want to only use the mrfi layer and not the whole simpliciti as i need to develop my own mac protocol.  However i would like to know that for a simple transmit and receive with only the mrfi.h and not the other headers like nwk.h,

    1) What is the existing frame format of it

    2)How do the associate with each other. Do they still use the Link process ??

    3)What is the transmission speed of a MSP430F2274 with a CC2500 Transceiver

    4)Whenever i send data issit sent as a broadcast? Since no LinkID or a mote address is specified

     

    thanks.

  • 0 in reply to Muhammad Razali
    TI__Genius 14940 points

    Ian,

    If your only concern is power, you may not need to limit yourself to the MRFI layer only.  You can make IOCTL calls to put the radio into low power mode and then sleep your processor.  After your processor wakes back up you can wake up the radio.  These hooks were installed into SimpliciTI because it was intended to be used in low power networks.

     

    Muhammad,

    Since you are wanting to rewrite the network layers, you will be using only the MRFI layer.  You will need to make some modifications to the MRFI layer or at least remove the non-MRFI information in the nwk.h file, etc.

    1) The existing frame format is described in the SimpliciTI specification.  It shows what the MRFI layer format is and how the SimpliciTI frame format is wrapped inside it.

    2) There is no association at the MRFI layer.  If you need association between radios you will need to rewrite this code yourself.

    3) The transmission speed of a CC2500 Transceiver can be as high as 500kbps.  If you are asking what the average data throughput is with overhead etc, that will depend on your system including the number of radios in your network and how much traffic is expected as this will cause the collision rate to impact overall through put.  Only your system design can determine the actual through put available for you.

    4) By definition, the MRFI layer broadcasts all packets and each receiving radio will receive the packet (unless you have hardware address filtering turned on in which case only those packets with a valid first address byte will be received).

    Jim Noxon

  • 0 in reply to Jim Noxon
    Prodigy 210 points

    Jim Noxon said:
    Jim Noxon wrote the following post at Mon, Apr 18 2011 8:02 PM:

    Ian,

    If your only concern is power, you may not need to limit yourself to the MRFI layer only.  You can make IOCTL calls to put the radio into low power mode and then sleep your processor.  After your processor wakes back up you can wake up the radio.  These hooks were installed into SimpliciTI because it was intended to be used in low power networks.

     

    Hi Jim, many thanks for your advice. Can I just clarify one point further? The application is for a wireless door lock, both the lock and remote are battery powered. The idea was to wake the lock micro every second to check if there are any remotes transmitting and if not go back to sleep - that way I can avoid the 20mA or so receiver current from being a continuous current draw. The down side is the remote would have to transmit for more than 1 second for an overlap to occur.

    Do you think I could get away with this application using calls to the full stack? The only thing that worries me is, how will the stack in the remote handle transmitting when it gets no ACK from the lock because it's asleep. Will I still be able to blast out messages from the remote quickly enough to make sure the lock gets one when it wakes? The faster I can send out non ACKed messages, the less time the lock has to be awake each second giving a longer battery life.

    Kind regards, Ian Barnes.

  • 0 in reply to Ian Barnes68507
    TI__Genius 14940 points

    Ian,

    Your system sounds plausible.  With regard to the need to transmit for a full second by the remote, although this is possible, it would probably do you better to transmit and then wait for a received packet from the door lock.  After a small timeout, say 10ms, repeat this process until a full second (or more) of time has elapsed.  In this way, you wake up the door lock once a second and only need to listen for the length of one cycle from the remote device.  If you do receive a packet from the remote device, respond in the window the remote has opened up.

    At this point both devices have identified a communication process is underway.  If the two packets are enough to complete the process, then you are done.  If you need to do more communication, you can complete it at this time.

    The advantage of this approach is the door lock will still only turn on once per second for say 15ms to 20ms to detect a packet from the remote.  If one is detected then the remote can immediately go into communications mode and not wast any additional time in transmit wasting power unnecessarily.  Thus the average time the remote will need to be on should be 50% or 1/2 second as the distribution of when the initial transmit occurs should be a uniform distribution making the expected value 1/2 of the period or 1/2 of 1second.

    Jim Noxon

  • 0 in reply to Jim Noxon
    Prodigy 210 points

    Jim Noxon said:

    Ian,

    Your system sounds plausible.  With regard to the need to transmit for a full second by the remote, although this is possible, it would probably do you better to transmit and then wait for a received packet from the door lock.  After a small timeout, say 10ms, repeat this process until a full second (or more) of time has elapsed.  In this way, you wake up the door lock once a second and only need to listen for the length of one cycle from the remote device.  If you do receive a packet from the remote device, respond in the window the remote has opened up.

    At this point both devices have identified a communication process is underway.  If the two packets are enough to complete the process, then you are done.  If you need to do more communication, you can complete it at this time.

    The advantage of this approach is the door lock will still only turn on once per second for say 15ms to 20ms to detect a packet from the remote.  If one is detected then the remote can immediately go into communications mode and not wast any additional time in transmit wasting power unnecessarily.  Thus the average time the remote will need to be on should be 50% or 1/2 second as the distribution of when the initial transmit occurs should be a uniform distribution making the expected value 1/2 of the period or 1/2 of 1second.

    Jim Noxon

    Many many thanks Jim. I have tested this using the full SimpliciTI stack with ioctls to enter low power mode. It works as advertised, I wake to 10ms every second to listen for packets.

    Kind regards, Ian Barnes.