• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 370 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

LP-CC1312R7: RSSI vs time get stuck & TX carrier drift during temperature test.

LP-CC1312R7: wmbus MTO rx not working properly while wmbus OTM rx is working with the same payload, sync word and CRC

thomas stichelbout
Prodigy 250 points
Part Number: LP-CC1312R7
Other Parts Discussed in Thread: WMBUS, , CC1312R7, CC1101, CC1200

Hi,

I have successfully performed rx measurements on Wmbus OTM sending packets either between 2 boards or between an ESG 4438C signal generator and a LP-CC1312R7 evaluation board in rx mode.

 This worked using the setup "50kbps , 25 kHz deviation, 2GFSK, 100kHz deviation"

OTM tx, working ok

OTM rx, working ok

 

Rx PER for wmbus OTM for different rx bw settings

 

PER vs tx frequency offset

Impact of frequency offset on PER for wmbus OTM ,  looks similar to figure 7-16 in the CC1312R7 datasheet.

I think the text is wrong for figure 7-16 in the DS for CC1312R7 as it is the same text for figure 7-15 too.

The receiver for  Wmbus OTM rx  settings can meet class 1.5 requirement for EN 300220.

I now would like to do the same on Wmbus MTO using the same sync word, payload, crc i.e. f carrier 868.95 MHz, 100kbps, 45kHz deviation, 

To do so i use the typical settings "WMBUS C-mode 100kbps , 2(g)fsk 235kHz rx bw, presilicon settings where i update the settings as following 

  • sync word : 543D543D  (wmbus frame B)
  • payload :756B7F56
  • crc : 80DE

MTO tx settings

MTO rx settings, not OK

There is a 1 byte offset for the received data which will therefore be considered as faulty.

I get the same results when using a signal coming from the transmitter from a second LP-CC1312R7 or from the ESG4438C

Is there a work around or another 

  • 0
    Prodigy 250 points

    script which could be used instead of WMBUS C-mode 100kbps , 2(g)fsk 235kHz rx bw, presilicon settings.

  • 0
    TI__Guru**** 317180 points
    thomas stichelbout said:
    sync word : 543D543D  (wmbus frame B)

    Could you refer to where in the spec you find this? As far as I see frame A and frame B don't use different sync words. 

  • 0 in reply to TER
    Prodigy 250 points

    from the info i received from my sw colleagues we should have for wmbus mode C

    Synch:
    Mode C FFA = 0x543D5C3D
    Mode C FFB = 0x543D543D

  • 0 in reply to thomas stichelbout
    Prodigy 250 points

    from the info i received from my sw colleagues we should have for wmbus mode C

    Synch:
    Mode C FFA = 0x543D5C3D
    Mode C FFB = 0x543D543D

    There might be a typo for frame A provided by my colleague, but the frame B sync word i used,  matches the pattern in 8.4.2 in EN 13757-4:2013

  • 0 in reply to thomas stichelbout
    Prodigy 250 points

    Extract from EN 13757-4:2013, section 8.4.2

  • 0 in reply to thomas stichelbout
    Prodigy 250 points

    in the same way the preamble pattern n* (01), where n=16 is also dictated by the standard.

  • 0 in reply to thomas stichelbout
    Prodigy 250 points

    If i use again the first pattern (50kbps, 25kHz devaition 2-gfsk, 100kHz rx bw) and modify the carrier to 868.95 MHz, 45kHz freq dev, 100kbps and 235.5 kHz and 2fsk instead of gfsk, i receive the data correctly without CRC error from the other evaluation board and signal generator .

    I am just not sure based on previous chip experience (like CC1101 or CC1200) that all the analog parameters for the radio will be set correctly if i don't use the right configuration as a starting point .. like for example CC1200 obscure registers such as SYN_CFG1 , IF_MIX_CFG and AGC_REF 

  • 0 in reply to thomas stichelbout
    TI__Genius 10365 points

    Hi Thomas,

    Please refer to App Note SWRA522E CC13xx Combined wM-Bus C-Mode and T-Mode: https://www.ti.com/lit/an/swra522e/swra522e.pdf
    Section 2.1 describes the RX settings and Section 3 describes the implementation of a software example - Figure 1 shows how the patch is implemented for the  CC13xx.

    Of relevance to your issue:
    The receiver will be set up to look for a 2-byte sync word (0x543D) and then to interpret the next byte received as the length byte. NOTE: Remember that the signaling byte is removed by the patch. Figure 1 shows that for C-Mode packets, the CC13xx device will not send the last byte of the sync word (the byte containing info regarding frame format [A or B]).
    ...
    Because the patch is supporting both C-Mode and T-Mode and the receiver is unaware which packets will be received, the receiver is only searching for a 16-bit sync word (0x543D) because this is common for both modes.

    So, please could you try using a 16-bit sync word for your RX settings and share the results?

  • 0 in reply to ZC
    Prodigy 250 points

    we would not be using the default stack stuff if we are going to implement a wmbus mode C solution for this so i am not sure why should i spend to investigating tool setup which don't implement that standard correctly ? I just want to check the receiver performance vs EN300220 and make sure it fits the different regional variants we have today

    The WMBUS C-mode 100kbps , 2(g)fsk 235kHz rx bw, presilicon settings works between 2 boards if using only  0x543D as sync word (i.e 16-bit) 

  • 0 in reply to thomas stichelbout
    TI__Guru**** 317180 points

    - Are you just going to use C-mode (meaning no need to be able to also receive T-mode packets)? If so you don't need to use the CT patch as described in the app note, don't use the patch. For some reason the 100 kbps settings has been implemented as 15.4 compliant meaning that Studio is difficult to use for your use with this setting. Probably the easiest is to modify the 50 kbps setting to 100 kbps, increase the RX BW to 196 kHz.  

    thomas stichelbout said:
    tool setup which don't implement that standard correctly

    Not sure what you mean, the patch used for the c-mode settings, as the app note shows, handle the required fields. SmartRF Studio does not show in the what is sent between sync word and the payload in the GUI.

    This app note show how you can set some of the same parameters that you are used to from the transceivers: 

    www.ti.com/.../swra682

  • 0 in reply to TER
    Prodigy 250 points

    ok thanks for your feedback. We will only use the C-mode in receive. In previous products we have experienced that we had to have separate receiver to cope with mode c and mode T as the specifications in mode T are wide in term of frequency deviation. Most of our product operate in mode c which more energy efficient as they are battery driven, without support for mode T anyway.

    The wmbus standard specifies in section 8.4.2 how long the sync word should be and only half of the length of this sync word it is implemented by smartRF studio due to the twist described above ... so the receiver will fail when receiving real wmbus packets with the proposed scheme in smartRF studio.

    It will also prevent to try to receive replay of pre-recorded wmbus frames which was what i started with in the first place before reducing my ambitions based on the problem i was facing with the tool.

    I ll continue to use the modified settings from 50kpbs as proposed and note in my documentation that final optimisation will be required as described in SWRA682.

    For wmbus C mode OTM, i could see that the rx bw of 98 kHz could be reduced a little to gain an extra 0.5 dB on the sensitivity.  

  • 0 in reply to thomas stichelbout
    TI__Genius 10365 points

    Hi Thomas,


    Thank you as well for flagging the potential issue with the datasheet - we will look into that also.

    Regards,
    Zack