• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 16 subscribers
  • Views 2484 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.

CC1020 AX.25 protocol compatiblity

Enrico S.
Intellectual 290 points
Other Parts Discussed in Thread: CC1020, CC113L, CC1120, CC110L, CC115L

Hi!

I'm developing a CC1020+MSP430 based RF system, capable to communicate with a TNC by means of the AX.25 protocol. I've read this post, too: http://e2e.ti.com/support/wireless_connectivity/f/155/t/114825

and searching for a confirm/deny about what I think: change to a newer CC chip. Here my thought:

Reading the CC1020 datasheet, says that in RX a sync preamble of alternated bits should be received (for a given lenght) and then also a sync word (of a given lenght and valuie). The datasheet is talking about the actual data content (like a word of 0b010101...), which means, for a manchester code adopted, a value of 0b011001100110… modulated on the carrier.

Now 3 questions arise:

  1. What is the difference between the bit preamble and word sync? Is the word sync swappable with the head flag of value 0x7E used in the AX.25, instead the 0xD391 as suggested?
  2. The protocol compatibility still exist if such preambles are required? If not, are those preamble avoidable?
  3. To be compatible, should I change the CC model?

I hope to be clear.

  • 0
    TI__Mastermind 39860 points
    CC1020 is not recommended for new designs as this is an old product. That said, the part will not be made obsolete and is sold in millions per year. The question is if you target narrowband applications or not. AX.25 is typically low data rate, but I do not know if you are going to certify against narrowband regulations as defined in e.g. EN 3000 220. If yes, then CC1120, which is the next generation narrowband transceiver, is a better device than CC1020 in all respects. For wideband applications you should consider the Value Line devices (CC110L, CC113L, CC115L) - cheaper than CC1020 and more functionality built into the chip.

    As mentioned in the post you refer to we recommend a minimum 3 byte preamble for AGC settling, bit synchronization and for setting the data slicer level correctly when using CC1020. The sync word is used for byte sync and is up to the user to define the number of bytes. You could for instance combine part of the preamble and the 0x7E to make a longer sync word (e.g 0xAA 7E). CC1020 is capable of being AX.25 compatible.

    CC11xL and CC1120 have automatic on-chip packet handling features and do not start to receive data before a valid sync word is found. You can program the chip to look for e.g. 0xAA 7E. For CC11xL you should precede the sync word search by carrier sense detection (i.e. the chip will only look for a sync word if the power level at the antenna is above a pre-defined programmable threshold). CC11xL and CC1120 are capable of being AX.25 compatible
  • 0 in reply to Sverre
    Intellectual 290 points

    Firstly, thanks.

    Sverre said:
    CC1020 is not recommended for new designs as this is an old product.

    It's a continuation of a design which was using this chip, in a university environment: at this moment those chip are directly available, but of course an upgrade can be taken in to account for future developments.

    Sverre said:
    AX.25 is typically low data rate, but I do not know if you are going to certify against narrowband regulations as defined in e.g. EN 3000 220.

    We don't need any certification, and the system bandwidth is compatible with the CC1020.

    What I am missing is how can be AX.25 compatible (you're right and I know people use it for this protocol) if the protocol it self do not mention a preamble possibility. I'm rather new in this field: is a normal approach  to put a preamble and sync words regardless the protocol and the OSI layers? If I'm sniffing for a transmission, I can be in the situation of a TNC which send N times the 0x7E packet just to wake up the receivers and after M received opening flags the TNC start with the real packet. But this (rather common) situation do not provide any sync word. Am I missing something?

  • 0 in reply to Enrico S.
    TI__Mastermind 39860 points
    The CC1020 requires a preamble for AGC settling, bit synchronization and for setting the data slicer level correctly (this is not unique for CC1020).

    The AGC, which sets the gain in the RF front end, only looks at the power level and no 0-1 transitions are required in the received signal. That is, a continuous stream of 1's or 0's would work just fine.

    The bit synchronizer and data slicer works on data transitions (i.e. 0->1 and 1-> 0) and both requires a finite number of transitions. If the preamble is 0x55 or 0xAA you get transitions for each bit received and will give the fastest synchronization and calculation of slicer level. However, 0x55 or 0xAA is not the required preamble (it just gives the most transitions in a given time) and you can use any preamble you like as long as it contains some transitions. In your case, if I understand correctly, you will transmit N time 0x7E and although 0x7E only have 2 bit transitions it will work to set up the AGC, synchronizer and data slicer. The key is that N is big enough. We typically recommend 3 bytes of preamble if the preamble is 0xAA. Assuming 1 byte is for AGC settling you need 2 bytes for the synchronizer and data slicer (15 transitions) When using 0x7E 7E... you need more bytes to get the same number of transition.

    If you are allowed to add 0xAA (or 0x55) to the transmitted data I suggest you do this. However, you will still receive the data if you it is preceded N x 0x7E though (assuming N is big enough).
  • 0 in reply to Sverre
    Intellectual 290 points
    Ok, very helpful. 0xAA or 0x55 represent a preamble: I got the meaning and I can calculate how many 0x7E I can use. I was thinking that (for hw reasons) a transition per every bit was a mandatory, that is a good news.
    And the sync word? You seem to treat preamble and sync word as the same thing, but the datasheet seems not: it provides different codes, saying that "The sync word should be significantly
    different from the preamble" - section 12.10.
  • 0 in reply to Enrico S.
    TI__Mastermind 39860 points

    A typical protocol will have preamble + sync word (SOF) + data payload + CRC. 

    Preamble is used to set up the AGC, bit synchronization and bit slicer. The sync word (or SOF) is used for byte synchronization. Typically the interfacing MCU will search for a  sync word (SOF) and when this is found the following received bits are interpreted as the data payload.

    If you do not have a preamble which is different from the sync word (SOF) you might find the sync word at different places within the transmitted data each time you go into RX. The MCU needs to handle this.

    Example 1: assume you transmit 0x7E 7E 7E 7E 7E 7E 7E 7E 7E 7E  01 02 03 and use 0x7E as an RX sync word qualifer you will in some cases only need 6 bytes (say) of 0x7E for AGC, bit synchronization and bit slicer. 0x7E number 7 will be received  correctly as a sync word and 0x7E 7E 7E 01 02 03 will be the data following the sync word.

    Example 2: same as above, but you now need 9 bytes (say) of 0x7E for AGC, bit synchronization and bit slicer. 0x7E number 10 will be received  correctly as a sync word and 0x01 02 03 will be the data following the sync word.

    From the above you will see that having a sync word which is significantly different from the preamble is an advantage, but not required.  

  • 0 in reply to Sverre
    Intellectual 290 points
    In this case I think that I already handle this in the MCU: I constantly search for a preamble sequence of 0x7E, always put toghether the bits to find this sequence. Then discard it while keeping the synchronisation on the word aligned on the opening flag (0x7E). Of course, if the sync is lost due to a bit change in the propagation medium, the packet will be misinterpreted and w/out any ACK signal from me, the sender will try to send again.
    In that case, any overnumber of transmitted flag will be discarded until the payload will start to be received. In this case, any quantity of flags can be sent and so seems useless (while receiving N flags) the requirement of the preamble (e.g. 0xAA or 0x55). A lower number of flags could bring an higher BER and similar. I will try to implement this.

    What I say seems also to be AX.25 compatible since, from what I read, most TNCs tends to send the opening flag as soon as the carrier become active. Thanks.