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.

CC1120 - issue with Smart RF Studio

Hi All,

I got following question from the customer:

'I stumbled across a problem with the SmartRF Studio and I was wondering if You could help me. When I use RX Sniff Mode payload of the received packet is represented in a strange way.
For example, I send a packet, fixed length, with no address, with payload size 4 bytes. The payload is HEX: 12 49 32 F6.
In Packet TX Mode I get HEX:    15:52:35.937 | 12 49 32 f6  |    0
In RX Sniff Mode I get HEX:  15:54:17.796 | 18738 | f6 43 a1  |    0

DEC 18738  is  HEX 49 32. I dont understand what happens with the first byte, and why is the entire payload not in hexadecimal.'

Thank you in advance.

Stella

  • Hi, it looks like you found a small bug. In package RX/ TX you can select to include the sequence number or not. In sniff mode you don't have that option and it looks like Studio in sniff mode assume that the first two byte is the sequence number. I'll let Tools know..

  • As a afterthought I think the sequence number is needed for the sniff mode demo. By sending/displaying the sequence number the user has a easy way to check if all packages are received. If the number is skipped it is easy to loose packages without knowing it if the sleep time is too long compared to the number of preamble sent. 

  • Hi Stella,

    The options you have to view packets in RX Sniff mode is a bit limited compared with the Packet RX mode. Both variable length and the sequence number is expected in RX Sniff mode. What you see is that the first byte is handled as the length byte and is not part of the payload. The two next bytes, "49 32" are seen as a sequence number.
    Unfortunately what you want to do is not really supported in the packet view of RX Sniff mode.

    The intention was to keep it as simple as possible, but I can see that supporting this case would be useful.
    It will be put on the list of future improvements for SmartRF Studio.

    Regards,

    Øyvind

  • Thank you ALL for the information.

     

    Stella