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.

SmartRF Studio 7 missing SimpliciTI ack frame

Other Parts Discussed in Thread: CC2511, CC1101, CC2510

Hello,

I have an USB CC2511 dongle and i connected it to a smartRF04EB board in order to
watch packet transmitted between Z430 RF2500T modules.

I use SmartRF Studio 7 application to see data.

I have one Access Point and one Peer.
My peer send a packet to AP and the AP send back an auto acknowledgement.

I can see the data packet transmitted to AP on SmartRF Studio but i can't see the ACK frame.
I'm sure that this ACK frame is transmitted because i can see it on another application ("Packet Sniffer").

More over the ACK frame is good because the peer toggle a LED when transmit successfull (ACK is received).

Here is a screenshot of SmartRF application (we can see only transmitted data frame but not ACK frame...):

Do you have any idea? 

Max


 

  • Hi,

    I'm not sure why the ACK is not shown in SmartRF Studio and will report it to the developers. I am however curious, why do you use SmartRF Studio as a packet sniffer instead of the SmartRF Packet Sniffer software?

    Br,
    ABO 

  • Hello ABO,

    We use SmartRF just for see register and test some configuration (frequency, power, modulation...)
    We have some other device like CC1101 and we already use SmartRF with it. The goal here was
    to validate that we can use the same soft (Smart RF) and hardware (SmartRF 04EB) for sniff data.

    Since we use SmartRF for other project, i want to understand why i can't see the ACK frame and so
    if i make a mistake or if it's a bug...

    Packet Sniffer is a good soft and i use it too.

    Thank you,

    Max.

     

  • It may be possible that Smart RF Studio uses the ACK to determine if the packet is valid. If it receives an ACK it displays the packet data, and does not display data if it does not see the ACK.

  • Hello,

    No i already tested that, with or without ACK, frame is displayed.
    A sniffer should show all the packet transmitted over the air and i think SmartRF doesn't try to
    understand the packet meaning.

    Max.

  • Maxime GUYON said:
    A sniffer should show all the packet transmitted over the air and i think SmartRF doesn't try to understand the packet meaning.

    That is true. SmartRF Studio displays the packets received by the sniffing device. If there are any kind of address or CRC filtering, the packet is discarded by the sniffer device and never reaches the SmartRF Studio software.

    Br,
    ABO 

  • Actually there is no CRC filtering since i can see some packet with a bad CRC.
    More over in advanced tab on "Adress config", there is  "No address check" selected,
    so basically no filter are enabled i think...

    I can't figure out why the ACK is not showed.

     

  • There is a parameter in SmartRf which is in "Settings->Polling Interval"

    The lowest value is 100ms:

    The ACK frame is sent about 2ms after the data packet is send so what
    happening between two poll if two packet are received (data+ack)? 

    [EDIT] I have the same issue with the repeated frame (by a Range Extender) and the ACK answer. The two are not showed.
    Normally they arrive 4ms after the data packet is send (I see it in "Packet Sniffer") 


    I think it's the polling setting in SmartRF which is not enought small.
    If a frame arrive in less than 100ms then frame is lost (buffer overflow).

    It's not a normal thing i think because in the help we can read that buffer overflow can occurs and are displayed:

    But i never got a buffer overflow on the screen...
    So if it's not a buffer overflow, the polling time should not be the problem... 

    In Packet Sniffer, it works i can see all packet.

    Max

  • The polling interval is for the state indication (IDLE/TX/RX) of the connected device, displayed in the low side of the Device Control Panel. It should not have an impact on the the performance in Packet RX test function.

    The EB Buffer overflow indication is, I think, only supported for transceivers. Packet reception is handled differently for transceivers, however I see that this is maybe not clearly stated in the help document.

    SmartRF Studio does not program anything onto System on Chips (SoC) such as CC2510 and therefore uses polling to check whether a new packet is received. It may be that this polling is not capable of catching the ACK packets. The best option, I think, is to export the register settings you want and import them into the SmartRF Packet Sniffer.

    Br,
    ABO 

  • Hi,

    I know that SmartRF doesn't program the chip because i just correct a problem with the USB dongle which was
    temporally dead (USB was not anymore in the device under Windows and the LED was always OFF)
    "PacketSniffer" was not able to dectect the key. So i reprogram it with smartRF Flasher and sniffer hex file.

    Now it works again.

    In fact it's not only the ACK frame which is not catch, but also a full frame (send by a Range Extender for example) which is not captured too.
    The two are send quickly after the data packet is send (4ms).

    Max

  • Hi,

    The problem is related to the packet handler implemented for SmartRF04EB. The USB MCU on this board is different from the USB MCU used on SmartRF05EB, CC Debugger and TrxEB. The implementation for SmartRF04EB does not have any buffer handling. The packet handling is a lot slower since it is controlled from the PC side. Each time a packet is received, the packet must be read and processed on the PC side before the device is ready to receive the next packet.
    In this case the receiver will not be ready when the ACK answer is sent over the air. That also means that the "buffer overflow" feature is not supported by SmartRF04EB.

    Just to verify what TIABO already mentioned about the polling interval: This is only used for polling of the radio state. The polling is turned off when starting in packet mode.
    This can be seen when the indication on the right bottom corner changes to "N.A" (Not Applicable).

    Hope this clarify any doubts about what's going on.

    Regards,
    Øyvind

     

  • Dear Maxime GUYON,

    You got the solution for the problem? I have similar problems with you. I'm using SmartRF05+CC2520EM as IEEE802.15.4 packet sniffer. It misses ACK frame.

    Anybody has any idea to correct the problem?

    B.R.

    seyoo

  • Hello,

    I think there is no solution with use SmartRF as you can read from Øyvind post:

    The implementation for SmartRF04EB does not have any buffer handling. The packet handling is a lot slower since it is controlled from the PC side. Each time a packet is received, the packet must be read and processed on the PC side before the device is ready to receive the next packet. 
    In this case the receiver will not be ready when the ACK answer is sent over the air.

    Anyway the solution is to use Packet Sniffer http://www.ti.com/tool/packet-sniffer

    Sorry but it's the only solution I found.

    Max

  • thank you for your fast reply.

    I'm using TI packet sniffer based on CC2520EM+SmartRF05EB.

    I remember when I use CC2420EM+SmartRF04EB the packet sniffer can show ACK frame correctly.

    Also, in the earlier version of the packet sniffer,  CC2520EM+SmartRF05EB could show ACK too.

    But, from 1 or 2 years ago, the packet sinffer  can't show the ACK frame.

    Max, can you see the ACK frame in the packet sniffer based on  CC2520EM+SmartRF05EB?

    seyoo.

  • Hello,

    It's make a long time I tested it but as far as I remember:

    In Packet Sniffer 2.16.2 the ACK was displayed (This version is 1 years old I think, but no more...)

    With SmartRF05EB the ACK was never displayed....

    Regards