CC1312R: Asynchronous Frequency Hopping Spread Spectrum with CC1312 - possible?

P M

Part Number: CC1312R
Other Parts Discussed in Thread: ENERGYTRACE, SYSCONFIG, LAUNCHXL-CC1352P1,

I am evaluating the CC1312/1352 for use in basic star architecture sensor network.

I have read this TI paper on implementing FHSS using the CC12xx www.ti.com/.../swra482.pdf

I would like to implement this FHSS scheme using the CC1312, but it appears there are some challenges.

This post (e2e.ti.com/.../713199 seems to hint that the CC1312 or the latest SDK or both cannot either have long enough preambles or cannot implement the necessary sniff mode to accomplish detecting a sensor node transmitting on one of 50 or more channels during the duration of the preamble.

Because it may be necessary to implement a repeater, I have avoided what is likely the most common response to my question - using the TI 15.4 stack's FHSS - which has no repeater mode available out of the box.

Is it possible to implement an FCC 15.247 compliant ASYNC FHSS scheme with the CC1312?

Could you point me to any examples for how to do fast RF sniff and longer preambles using SimpleLink/Easylink?

Any confirmation and pointers in the right direction would be much appreciated!

Thanks!

over 3 years ago

0 Siri over 3 years ago

TI__Guru* 79421 points

I am not familiar with FCC 15.247, but what I know is that while on the CC12xx you can calibrate for all the frequencies you want to use , and then just write back the calibration results whenever you want to change frequency, this is not possible on CC13x2, and you need to perform a calibration every time you want to change frequency. If you are changing frequency more that a certain amount, you will also need to do a new setup command

Also, the comment about preamble, is not related to how long preamble the CC13x2 can transmit. It can transmit as long preamble as you want it to, if you are using the advanced TX command. You can take a look at the rfWakeOnRadioTX example to see how this can be done. However, the CC12xx only needs 4 bits of preamble to be able to detect a sync word, while the CC13x2 needs several bytes. The CC13x2 also needs more preamble bits in sniff mode to be able to detect a preamble, than what is the case for CC12xx.

The fastest way to do sniff mode on the CC13x2 is to only look for RSSI and not look for preamble. How long time this will take will depends on your RF settings (What RX BW you use etc.)

Siri

0 P M over 3 years ago in reply to Siri

Prodigy 90 points

Siri - thank you for your response. I have some followon questions:

1. If I understand correctly, because the CC13x2 takes requires a longer preamble to detect a sync word and requires more bits of preamble in sniff mode, you are suggesting that one use RSSI detect to try to decide if a node is transmitting?

2. Because on the CC13x2, one cannot pre-calibrate the channels, one has to calibrate with each frequency change - and if the change exceeds 1.5%, one has to also issue a new setup command. Can you help me calculate (or provide an example or equation) to determine the amount of time required to switch frequencies and execute an RSSI detect? FCC 15.247 requires > 50 channels for the tx power I would like, thus I need to be able to change frequencies 50 times and do a RSSI detect on each in less time than it takes one note to transmit a long preamble. I suspect the components are the time to execute the set frequency, the time to perform the calibration, and the time to execute one cycle of RSSI detect, and the time to enter RX mode (if one wants to begin receiving a packet before the preamble is over).

Thank you

PMM

0 Siri over 3 years ago in reply to P M

TI__Guru* 79421 points

1) It is correct that detecting RSSI is faster than detecting preamble. However, when only looking for RSSI, you will get more false hits if there is noise in the channel on the frequency you are looking at

2) I recommend that you do this testing yourselves. You can for example use energyTrace on the LP and play around with the rfPacketTX example in the SDK.

Please see http://www.ti.com/lit/swra478 on how this can be done. The rfPacketTX example goes into sleep between every packet so it executes a setup command and a CMD_FS before every packet. By looking at the current profile you can see how long time it uses from SLEEP to TX. You can also change the code so that it goes in and out of TX and just calling CMD_FS between each packet. This will give you the time it takes to change frequency when only a CMD_FS is needed.

The RSSI response time depends on the RF settings you need to use. When you have the correct RF settings for your PHY, you can use the CMD_PROP_CS to find the RSSI response time. You need to configure the command to look for RSSI, and then you can use energy trace to see how long it stays in RX before it returns.

Siri

0 P M over 3 years ago in reply to Siri

Prodigy 90 points

Siri,

Thank you for your response.

In digging into the WoR examples for the cc1312 in ccs10 and Simplelink SDK 4.10, I come across this in the README file for the rfWakeOnRadioRX example, in the Packet Preamble section it states:

"At 50kbit/s 2-GFSK a 4 byte preamble is only 650 us long. This means that to not miss a packet, the receiver would have to wake up more than 1500 times per second. This is generally not a feasible solution, and does not save a lot of power.

If we instead configure the transmitter to send a 100 ms long preamble, this means that the receiver only have to wake up 10 times per second to be guaranteed to receive the packet. This increases the latency in the system, but significantly reduces the average power consumption.

In this Wake-on-Radio example, the default setting is to send a 500 ms preamble and so wake up approximately two times per second to check for it."

For this example, the preamble (in rfWakeOnRadioRx.syscfg) is set to 4 bytes. I am trying to understand how the example states that it has set the preamble to be 500ms long, yet the preamble is set to only 4 bytes - could you help me understand if/how the preabmle is longer that 4 bytes in this example?

Additionally, in any example, when using the syscfg, the max preamble appears limited to 32 bytes. You had made the statement that with the Adv packet structure, one could have any length preamble. How does one setup a preamble longer than 32 bytes?

Best Regards,

PM

0 Siri over 3 years ago in reply to P M

TI__Guru* 79421 points

I do not think it is possible to configure the advanced TX command from sysConfig, and yo will need the advanced command to allow for long preamble. What is done in the rfWakeOnRadioTx example, is to call a function, initializeTxAdvCmdFromTxCmd, in the application.

It takes the command fields that are common for the two different TX API commands, and copy them from the ordinary TX command to the advanced TX command.

It then configure the preamble length in the advanced command, according to number of wake-ups you need per second:

RF_cmdPropTxAdv.preTrigger.triggerType = TRIG_REL_START;
RF_cmdPropTxAdv.preTime = WOR_PREAMBLE_TIME_RAT_TICKS(WOR_WAKEUPS_PER_SECOND);

If preTrigger.triggerType is set to TRIG_NOW, the command will send preamble as programmed in the setup command, if not, preamble will be transmitted until the trigger is observed.

Siri

0 P M over 3 years ago in reply to Siri

Prodigy 90 points

Hi,

Thank you for your last response.

I have taken a look at the rfWakeOnRadio (both TX and RX) examples and have attempted a prototype implementation for FHSS.

My setup:

I have CCS10, LaunchXL-CC1312R1, and LaunchXL-CC1352P1.
I am using 50kbps.
I am using the 1312 to transmit on a single channel in an adaptation of the rfWsnNode example. I have disabled looking for a Ack (thus no RX) and I have disabled the use of the sensor manager - and am simply looping with a delay and transmitting a packet of ~ 200 bytes, where I have added a packet count to the payload. I have the frequency set to 915mhz and the preamble to 32 bytes. I am transmitting a packet about 1Hz.
I am using the 1352P1 for receive in an adaptation of the rfWakeOnRadioRX example - where I am not really leveraging the WOR - I have changed the Rf_cmdPropRxSniff.startTime to be the current time and changed the .startTrigger.pastTrig to 1 - so that it will start as soon as I issue the receive command. I have set the pkt.Conf.bVarLen to 1 to allow for the transmitted packet sizes to be received and CRC checked. If I set the frequency to match the transmitter and use the debug watch window to see the packet as it is received in the callback, I see that every packet is received (my payload count increments by one and I don't seem to miss any packets).

If I change the receive to alternate between two different frequencies (one being 915mhz and one being ~ 100khz away), I seem to miss about 40% of the packets. To change frequencies, I have basically used the guts of the EasyLink_setFrequency function and issue the radio command within it of: RF_EventMask result = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, 0, 0); I change the frequency every time before I issue the RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropRxSniff, RF_PriorityNormal, &callback, RF_EventRxEntryDone); command. I am keeping track of how many times I change frequencies - and it seems that it reports many hundreds of changes (and thus sniffRX attempts) per second - making me conclude that it must be doing this frequently enought to start a sniffRX multiple times during the preamble of the packet being transmitted on one of the two frequencies. With this rate of sniff/rx, I would expect to be able to receive each packet.

I have tried using just the RSSI sense as well as both the RSSI and CORR sense - with no real difference...I still miss packets.

I have experimented with timing changes using corrPeriod, csEndTime, and endTime, with no real difference - in fact no real difference in frequency change rate which leads me to believe that the setFrequency operation is the dominate time component.

I am using this as a test before I expand this example to include attempting to receive on more frequencies (scanning frequencies for a preamble) - and then intend to lengthen the preamble being transmitted as necessary to accomodate the time to scan all 50 channels....I will then change the transmitter to change its TX frequency for every transmit.

It seems that I must be missing something simple to allow me to receive all the packets from the one frequency even thought I am alternating between two frequencies. What may I be missing here?

Thank you in advance!

0 Siri over 3 years ago in reply to P M

TI__Guru* 79421 points

I did a test where I used SmartRF Studio as the transmitter and the rfWakeOnRadio example (modified) as you described, as the receiver. I experienced the same thing. I was changing frequencies between 915 MHz and 915.5 MHz. All packets were sent on 915 MHz. What I saw was that even if the receiver was on a different frequency, the radio would still detect RSSI and also preamble, but it would not be able to receive a proper sync word.

When I change the frequencies to 915 and 915.9 MHz, I would receive all packets.

Siri

0 P M over 3 years ago in reply to Siri

Prodigy 90 points

Thank you for your response.

Indeed, I changed to receiving on the node transmit frequency and a second frequency farther away and I received all packets.

This brings up a closely related question. My goal is to accomplish asynchronous FHSS using the cc13xx parts. I will have to transmit on 50 or more channels to be legal at 50 KHz rate. Therefore I will have to scan/rxSniff on the 50 or more channels faster than the duration of the preamble from a transmitting node to be assured of intersecting the preamble of the transmitted packet (and not miss packets).

If I am scanning linearly and approach the frequency on which a node is transmitting a preamble, it would seem, from what you point out, that as I get to some sufficiently close adjacent frequency, that I risk detecting RSSI and going into RX only to not be able to detect the sync word and packet – and thus miss that packet due to detecting CS/RSSI/preamble and going into RX too soon on the wrong frequency. Would you agree? If so, what approach(s) might you suggest?

It would seem that some of the options might include (please comment):

Doing preamble correlation in addition to just carrier sense in the hopes of not going into RX on the adjacent channel…however this would lengthen the required preamble length (and thus transmit time and lower node battery life) would it not?
Instead of scanning linearly, to follow a pseudo random hop pattern for the rxSniff in the hopes of intersecting transmitted preamble on the exact transmit frequency, without sensing carrier/rssi on the next closest channel in the hop pattern (in the absence of other noise of course). Seems like an endless chase for more accurate rxSniff forcing longer preambles so we can scan all channels in a preamble time.
Increasing the RSSI threshold…but this has the effect of not detecting weaker transmitting nodes at some point – and thus reducing range or forcing higher tx power/lower battery life in the nodes.
Use few enough channels and have them spaced far enough apart such that a linear scan will not detect carrier on adjacent channels because of their spread in frequency. (This doesn’t seem feasible for the 902-928 band, 50 channels still are only ~ 515khz apart)
Somehow improve selectivity or narrow RX bandwidth for rxSniff (I don’t’ have a good understanding of the tradeoffs of slightly narrowing the rx bandwidth but maintaining the same data rate).

Was this behavior (of detecting adjacent cs/rssi/preamble) also present in the cc11xx/cc12xx parts during rxSniff?

Thank you in advance!

0 Siri over 3 years ago in reply to P M

TI__Guru* 79421 points

It takes indeed longer time to detect a preamble compared to only RSSI. However, in my test I used both RSSI and preamble, and did still get a problem when I had 500 kHz between the two channels. You can try to play around with both RSSI and Preamble threshold. Setting a higher RSSI threshold will off course limit the sensitivity to this threshold. You can also try to narrow the RX Filter BW, but this might reduce the sensitivity.

Would it be possible to first scan all the channels and just read the RSSI threshold for each of the channels that report an RSSI level above threshold? After scanning you select the channel with highest RSSI and start looking for preamble and sync word on this channel.

For further support on this case I will hand it over to our RF/HW group as they have more knowledge on these topics.

Siri

0 TER over 3 years ago in reply to Siri

TI__Guru**** 317180 points

P M: Which (hardware) related questions still needs an answer?

0 P M over 3 years ago in reply to Siri

Prodigy 90 points

Siri,

Thank you for your response.

I don't believe I have any hardware specific questions still to answer, but I do have a few more software questions.

First - I have 50channel async FHSS with acknowledgements and retries working - so thank you very much for you assistance to this point.

I want to be able to dynamically adjust the RSSI threshold used in the RxSniff command. What is the best method to sense the background noise level across the band? While I have been able to use the received RSSI value (via the rxConf in the RxAdvCommand) - I have not been able to find a way to access a noise value on a channel(s). Could you point me in the right direction for how to accomplish this? It seems like one would want to continually be calculating an average noise floor to allow the threshold for the sniff to adjust up and down.

I want to revist the frequency synthesizer calibration on a cc1312 module. In creating my prototype FHSS, I am not explicitly calling for any calibration - I am simply changing the frequency by calling RF_runCmd with a RF_cmdFs - where I have changed the RF_cmdFs.frequency and .fracFreq. Am I missing an explicit calibration step or is this handled automatically when running the RF_cmdFs?

Can you point me to an example for using the CC13xx part's encryption features to encrypt and decrypt the payload of a packet?

Best Regards,