CC1310 Manchester encode with CC1101 compatible issue

Hi Ter,

Thanks a lot for your reply.

I have some question as below:
1. For CC1310 the Preamble & SyncWord can't used Manchester encode. how to do it ?

2. Would you please to provide me about HW_REG_OVERRIDE data. I cannot find it from TI website.

3.. Would you please provide CC1310/1350 TX & RX integrate sample code. We use individual TX & RX sample code to integrate by myself. We have some issue happen. Sometime RX can lost packet.

4. I use smartRF studio 7 to test CC1350. the HW is smartRF06 +CC1350 EMK. continue TX & RX. The interval time can't work under 40ms. but CC1101/CC1120 can do it under 40ms. We hope it can do under 20ms~30ms.

1) Since CC1101 sends a sync word using manchester coding. What you need to do on the CC1310 side is to program a sync word that is the manchester decoded version of the CC1101 sync word. If you are able to, use 2 byte sync on the CC1101 side.

2) The override I sent can be included in the override list SmartRF Studio generates (pOverrides[]) before the 0xFFFFFFFF end overrides delimit. An override is basically a register write but since not all registers are possible to access directly or have a different meaning dependent on which mode the radio is in the values are provided in a bit cryptic manner to avoid writing to something that should not be written to.

3) We have the examples provided in TI-RTOS. If you download the newest version and look at the Network node or Network Concentrator examples both do both Rx and Tx.

4) SmartRF Studio has some limitation on the timing since it the program has to get the values from the chip etc. In a program you will be able to do faster turn around.

Hi TER,

Thanks a lot for your reply,

for point 1: CC1101 is used in our MP product. We are hard to modify the MP MCU F/W. so Would you please help us to solve this issue. thanks a lot !!

B.R.

I assumed the the CC1101 side is fixed. Then you can do the other thing I suggested: What you need to do on the CC1310 side is to program a sync word that is the manchester decoded version of the CC1101 sync word.

Hi TER,

Thanks a lot for your reply.

We want to use RF WOR. If the preamble & syncWord use Manchester encode by H/W as the CC1101 , it'll save more power consumption.

as we develop CC1101 & CC1200 communication's experience . CC1200 preamble doesn't use Manchester encode.

wireless operating in the 868MHz , data rate 76.8kbps, interval time : 40ms, sometime the data bit can be shift.

Now we develop CC1310 . we turn off preamble. use program to do sync Manchester encode with CC1101 communication . it can work well. but we are afraid the same CC1101 & CC1200 issue will happen in CC1101 & CC1310

so please help us how to do preamble & syncWord use Manchester encode by H/W . that's very important for us.

Thanks a lot !!

CC1101 does manchester like the following:

Logic '0' = Low to High transition
Logic '1' = High to Low transition

The default CC1101 sync word 0xD391. Given that I haven't typed something wrong this is equal to 0xA65A9656 manchester coded. Eq if you want to receive a sync word sent by CC1101 using manchester you need to use 0xA65A9656 as the sync word on CC1310. The preamble is normally only used to settle the AGC, CC1310 will have no problems with a manchester coded preamble.

Hi TER,

Thanks a lot for your reply,

1. CC1101 is used in our MP product. so we use 32bit sync code. that can't modify. so we hope CC1310 can do Manchester encode.

2. We have run "RF Wireless Sensor Network Concentrator” & ”RF Wireless Sensor Network Node" 2 project.
We use non Manchester encode , They can run over 10 hours no problem.

We use Manchester encode : pOverrides--> HW_REG_OVERRIDE(0x52B4,0x270C) & formatConf.fecMode = 0xa
first time, after run 25 min, RF Wireless Sensor Network Node ADC value has variable , then Node doesn't send data.
second time, after 1hour RF Wireless Sensor Network Concentrator doesn't send ack message.
We have use sniffer to monitor RF data

When we use these 2 project for Manchester encode. They work is not stable. please help us to solve.

Thanks a lot!!!

I don't see any reason why adding manchester should be a problem. Could you please post the code giving us a opportunity to test it here?

Hi TER,

register set as below

rfWsnConcentrator_CC1310DK_TI_CC1310F128.rar

rfWsnNode_CC1310DK_TI_CC1310F128.rar

I intended to run this code today and see if I get the same issue but I ran into some problems. (I get an error message saying that the target could not be reset). I will give in a try tomorrow again.

I did a test slightly different than yours. I have taken the packetTx and packetRx examples and did the same modifications to the code as you have shown above. Now this has been running for 3 hours without any issues. Manchester send more data over the air so it could be that when running the example you are using that you get some timing issue. If something is sliding just a few us for each packet it could take some time before an timing error is viable. You can try to increase the distance between the packets and/ or smaller payload and see if that makes a difference.

Hi TER,

Thanks a lot for your reply.

Sorry, I forgot to tell you. I use CC1350EMK to develop my project. I have no CC1310EMK. Could you tell me you do this test use CC1310EMK or CC1350EMK ?

I modified ”.fecMode=0xa” & ”.modulation.modType=0x0” . They still work abnormal.

I'm actually using a CC1350 in my test. CC1310 or CC1350 will not impact the result for this test. Have you tested the same example as I did?

Hi TER,

If it's possible, could you send your sample code to me ?

Hi TER,

Thanks a lot

We used packetTx and packetRx examples to test, that's no problem.

but we used rfWsnConcentrator_CC1310DK_TI_CC1310F128.rar & rfWsnNode_CC1310DK_TI_CC1310F128.rar ( I have upload on 11/05), sometime the issue can happen.

Would you please use these 2 project to test ???

Our project need TX/RX interval work.

CC1350 ver