CC1310 Long Range Mode Support

[andrewbrannan]

I'd like to experiment with using the CC1310 LRM (625bps, DSSS, FEC etc) settings provided by TI with Contiki.

Unsurprisingly, a quick copy/paste of LRM settings from SmartRF Studio into cpu/cc26xx-cc13xx/rf-core/rf-core/smartrf-settings.ch doesn't do the trick (using nullRDC, I dialling in ContikiMAC timings is a whole other challenge). Has anybody else done any investigation into getting this working? I have a feeling this will need communication with TI to figure out some magic overrides much like the IEEE settings.

[g-oikonomou]

It is very likely we'd need correct overrides and/or patches.

I'm not clear what you mean by copy/paste settings. Studio exports settings for CMD_PROP_RX and CMD_PROP_TX, we are using the _ADV counterparts of those commands. We therefore need to map correct fields one by one, is this what you did?

We also need to check what exactly it is that fails. Does for example CMD_PROP_FS succeed? Ditto for the TX/RX commands. Once those are in place and you are still not getting anything, then a sniffer would be your friend.

[andrewbrannan]

Yep that's what I did, "copy/pasted" the values for each field from SRFS to the corresponding struct initialisation done in smartrf-settings.c.

I'll do some digging this week and see where it breaks.

[g-oikonomou]

Great. rf-core.c and prop-mode.c will likely help, it would be good to command error codes if any.

[mdmobashir]

I did the same. Tried to find a difference between the lrcom.c file exported by SmartRF for both genfsk and lrm modes and update the prop-mode.c and smartrf-settings.c files with the differences. It does seem to work nullrdc, however, fails with contikimac. GenFSK modes works perfectly infact.

Following error is received at the receiver:

prop_fs: CMD_FS wait, CMDSTA=0x00000001, status=0x0809 on: prop_fs() failed

Any suggestions @stringr9 @g-oikonomou? I really wished it could work for a project.

The changes that I therefore made were as follows: File: prop-mode.c

1. changed rf_patch_cpe_genfsk() => rf_patch_cpe_lrm()   // included from rf_patch_cpe_lrm.h
2. changed rf_patch_rfe_genfsk() => rf_patch_rfe_lrm()      // included from rf_patch_rfe_lrm.h

File: smartrf-settings.c updated with following new values

1. MCE_RFE_OVERRIDE(0,4,0,1,0,0) => MCE_RFE_OVERRIDE(0,3,0,1,0,0)
2. Added HW_REG_OVERRIDE(0x505C,0x073C),
3. modulation.modType = 0x1 => modulation.modType = 0x0
4. modulation.deviation = 0x64 => modulation.deviation = 0x14
5. symbolRate.rateWord = 0x8000 => symbolRate.rateWord = 0x199A
6. rxBw = 0x24 => rxBw = 0x20
7. preamConf.nPreamBytes = 0x3 => preamConf.nPreamBytes = 0x5
8. formatConf.bMsbFirst = 0x1 => formatConf.bMsbFirst = 0x0
9. formatConf.fecMode = 0x0 => formatConf.fecMode = 0x8
10. pktLen = 0x1E => pktLen = 0x14
11. syncWord = 0x930B51DE => syncWord = 0x00000000

[iPAS]

@mdmobashir, would you please upload the files? I cannot find the places where we need to change, as you mentioned, in prop-mode.c and smartrf-settings.c of Contiki-OS. Which is the branch and revision that you are mentioning?

[mdmobashir]

Hi @iPAS , I'm made the changes to the following branch. https://github.com/g-oikonomou/contiki/tree/contrib/cc1350/lp-and-st Did you manage to get it working with contikimac dutycycling?

[iPAS]

Thank you @mdmobashir and @g-oikonomou. After I used the branch, the CC1310EM boards work well on GenFSK+ContikiMAC mode. A file, smartrf-settings.c, is almost similar with the one gotten from SmartRF Studio software. I also tried to compare the transmission powers of the boards that are uploaded with such Contiki's branch, and the boards that are control with SmartRF Studio. The received RSSI results are the same. So, I imply that https://github.com/g-oikonomou/contiki/tree/contrib/cc1350/lp-and-st works well. However, I still cannot find the way to implement LRM on it, even in NETSTACK_CONF_RDC==null. I will continue trying.

[mdmobashir]

Hi @g-oikonomou, Was wondering if there is any update to the following branch https://github.com/g-oikonomou/contiki/tree/contrib/cc1350/lp-and-st It supported Prop mode but now is unavailable. I tried to run rpl-server/client example on cc1350 with the contiki-master and packet fails to get delivered. Thanks :)

[g-oikonomou]

I merged that branch a couple of days ago. Did you update your local master to latest version?

[mdmobashir]

Yes, I did a fresh clone of the latest version. I notice some restructuring of the source as well. For example, earlier, rf_prop_cmd.h was imported from driverlib and now it has been moved to rf-core/api as prop_cmd.h. Am I missing something to make rpl-server/client or example-collect run?

[g-oikonomou]

I've no idea about those examples, sorry. If you say the branches used to work, then master ought to work!

[g-oikonomou]

So to expand on that, the code restructuring that you mention was present in those branches.

[mdmobashir]

Any example that you suggest I should try to test comms? I want to test out prop-mode on cc1350. Any input from your experience would be great :).

[g-oikonomou]

I'd try the cc2650 examples first, the simple demo or the web demo.

[g-oikonomou]

But really, anything that worked for you with the branch, should work with master now.

[mdmobashir]

Sure, let me see if I've made some error in executing. Thanks :D I'd give it a second shot.

[mdmobashir]

To elaborate on the restructuring, yes, the files seems to be renamed and placed in different folders. For example, earlier, smartrf-settings included the following

#include "driverlib/rf_mailbox.h"
#include "driverlib/rf_common_cmd.h"
#include "driverlib/rf_prop_cmd.h"

But now, it is including the following headers which are slightly different.

#include "rf-core/api/mailbox.h"
#include "rf-core/api/common_cmd.h"
#include "rf-core/api/prop_cmd.h"

[g-oikonomou]

That's intentional. It was part of #1931. If you were using #1932, you were also using these changes.

[mdmobashir]

I see. Thanks for updating me on this. Did it also lead to changes in the prop-mode.c content? The newer version is different.

[g-oikonomou]

I am starting to get a little bit confused here. My point is, if you used the branch I used for #1932 then you should be seeing pretty much zero changes between what you had and the current master.

The combined changes in #1931 and #1932 were quite extensive (61 files changed), if you are interested in seeing what exactly changed and why I would suggest looking at the git log for the two pulls. The entire history is visible here: https://github.com/contiki-os/contiki/pull/1932/commits

[mdmobashir]

That's helpful. I'd try to understand the changes. Currently, I'm facing the following error with prop-mode: prop_fs: CMD_FS wait, CMDSTA=0x00000001, status=0x0809 on: prop_fs() failed transmit: on() failed

[g-oikonomou]

Are you saying that cc2650 examples on master don't work off the shelf? Have you made any changes?

[mdmobashir]

Let me try it from scratch again and check with you :) Yes, cc26xx-demo was throwing that error with logs enabled on prop-mode.c.

[g-oikonomou]

I also need to know what board you are using please, and please confirm that the #1932 branch was originally working properly for you.

[mdmobashir]

I'm working on cc1350 launchpad and wish to to test out the lrm mode of communication.

Yes, my initial try with #1932 was working fine over long communication range with nullrdc (contikimac was having some issues).

[g-oikonomou]

OK great. This issue is about LRM in the first place, so we can get back to that in due course.

For now, off-the-shelf master should work with zero changes. If #1932 was working for you and master is now not, then some other change on master (one before merging) must be getting in the way.

If master (no changes) doesn't work for you, checkout the #1932 branch (this should be pretty easy to achieve by checking out a6b14a0) and try it (again, no changes).

[mdmobashir]

Sure @g-oikonomou . Thanks for the effort. Much appreciated :) Let me get it to run again.

[mdmobashir]

One quick follow up question. In the latest merged master, why has the support for cc1350 removed? #1932 has cc1350 in the platform while in the latest, only cc1310 and cc2650 are provided.

[g-oikonomou]

You must be doing something wrong in your local copy, it's there!

[mdmobashir]

I'm referring to the latest version here which I cloned. https://github.com/g-oikonomou/contiki/tree/master/platform/srf06-cc26xx/launchpad To compile for cc1350, I had to create my own makefile as it is not there. I hope I'm not missing something basic. Using the following to make: make TARGET=srf06-cc26xx BOARD=launchpad/cc1350 cc26xx-demo.bin CPU_FAMILY=cc13xx

[g-oikonomou]

You are looking at the wrong github repository ;) I have not updated master on mine yet, you should be using contik-os/contiki

[mdmobashir]

Gosh. Sorry! But even this has cc1310 and cc2650 platforms. https://github.com/contiki-os/contiki/tree/release-3-1/platform/srf06-cc26xx/launchpad

[g-oikonomou]

Sorry this is rapidly becoming a discussion on how to use git and github. I can't help with that within a Contiki issue, there are plenty or reading resources elsewhere :)

[mdmobashir]

Sure, I'd figure out. True :D Thanks a lot though ;) P.S. I had been repeatedly pulling the wrong release. Found it. Time to try myself!

[mdmobashir]

So I got things to work. Thanks @g-oikonomou .

Had a question regarding contikimac's selection of certain values for following contikimac parameters if you have some suggestion

#define CONTIKIMAC_CONF_AFTER_ACK_DETECTED_WAIT_TIME (RTIMER_SECOND / 920) #define CONTIKIMAC_CONF_INTER_PACKET_INTERVAL (RTIMER_SECOND / 220)

For prop mode the default values in Contiki are 920 and 220 respectively. In my tests this failed for contikimac and values 200 and 150 worked perfectly. Is it because the lrm bitrate is lower requires more time for Hardware ACK detection? How can we find the precise time for these parameters?

** Should I clean up the previous comments since they were not relevant to Contiki but usage of Git?

[g-oikonomou]

Don't bother with cleaning up previous comments.

I believe the ContikiMAC paper (or was it the tech report?) provides the logic behind the selection of those timings if you want to have a look at it. As I've said, for me it's mostly been a trial and error (and somewhat painful) process.

If you got LRM to work properly, we'd definitely like to hear details about it!

[mdmobashir]

Yes, coming up with 200 and 150 had been lot of trial and error as well.

For long range mode, I had to merge certain settings from smartrf studio for 625bps setting and managed to get it to work. Was trying to figure out those two parameters since nullrdc works perfectly but contikimac repeatedly fails.

Let me read ContikiMAC report. From my previous experience with telosB motes, these values were there in datasheet but I'm still confused for CC1350.

Would love to share once it is sorted too :)

[g-oikonomou]

Unless my memory is failing me, the SmartRF settings that work for NullRDC should also work for ContikiMAC once the latter is configured correctly.

If you share Smart-RF settings that work for nullrdc, then perhaps others might be able to help.

[mdmobashir]

I've shared the changes made to prop-mode and smartrf-settings below. Hope someone can test to confirm and fix the contikimac timing requirements :) https://github.com/mdmobashir/contiki-lrm

Meanwhile trying myself...

[bverdu]

Hello, I have tested the changes and found the following results: Platform CC1310 Launchpad XL nullrdc Channel 0 tests done with rpl demo, rpl-border-router ,6LBR, cc26xx-web-demo

I have modified smart-rf-settings.c for the CC1310. I have done the tests for 625bps legacy lrm mode and also for 5Kbps SimpleLink Long Range mode and modified prop-mode.c with correct patches

First tests: only the rpl demo works, but no more packets are received after the 8th. On rpl-border and 6lbr the node is present but it is not possible to access the http server (only half the TCP handshake is done) or the coap server.

the RDC debug log on the node and on the rpl-border-router shows "nullrdc tx noack" and "null-rdc: ignored ack" messages.

I have tried to tweak the NULLRDC_CONF_ACK_WAIT_TIME value in hope to solve these timings issues but after tried for hours, I didn't found a stable working value, the good value seems to be between (RTIMER_SECOND / 220) and (RTIMER_SECOND / 280) but I have a random behaviour when I test values in this interval, sometimes, the message "nullrdc tx noack" apears first, sometimes, this is "null-rdc: ignored ack", with same setting. I have also set the value #define PROP_MODE_CONF_RX_BUF_CNT 8 the project-conf.h of the border router without improvement.

Second test: I have totally disabled the ack check in nullrdc.c by adding this line (L200): ret = MAC_TX_OK; Whit this dirty ack, I am able to access the web server and I can do coap requests.

Third test: finally, I have enabled ContikiMAC with debugging info. I didn't obtain any connectivity, the border router receive node broadcasts but the node don't receive anything, here are the log for approx 5 minutes between c26xx-web-demo and rpl-border-router:

Node:

Starting Contiki 3.x
With DriverLib v0.47020
TI CC1310 LaunchPad
IEEE 802.15.4: No, Sub-GHz: Yes, BLE: No, Prop: No
 Net: sicslowpan
 MAC: CSMA
 RDC: ContikiMAC, Channel Check Interval: 16 ticks
set_channel: 0 = 0x035f.0x2000 (863125)
 RF: Channel 0
 Node ID: 31380
CC26XX Web Demo Process
CC26XX Web Server
CC26XX CoAP Server
6LBR Client Process
CC26XX MQTT Client Process
CC26XX Net UART Process
on: We were on. PD=1, RX=0x0002 
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
prop_fs: CMD_FS wait, CMDSTA=0x00000001, status=0x0809
on: prop_fs() failed
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=2, len=62, no ack, no collision), done

Border Router:

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 127.0.0.1  netmask 255.255.255.255  destination 127.0.0.1
        inet6 fe80::e111:26f2:461e:5fd6  prefixlen 64  scopeid 0x20<link>
        inet6 fe80::1  prefixlen 64  scopeid 0x20<link>
        inet6 fd00::1  prefixlen 64  scopeid 0x0<global>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 Net: sicslowpan
 MAC: CSMA
 RDC: ContikiMAC, Channel Check Interval: 16 ticks
set_channel: 0 = 0x035f.0x2000 (863125)
 RF: Channel 0
 Node ID: 57542
*** Address:fd00::1 => fd00:0000:0000:0000
*** dropping large 2000 byte packet
2, rssi=-14
contikimac: data (47)
read_frame len=62, rssi=-14
contikimac: Drop duplicate
contikimac: data (47)
contikimac: send broadcast
contikimac: send (strobes=1, len=95, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=1, len=95, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=1, len=95, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=1, len=95, no ack, no collision), done
read_frame len=62, rssi=-14
contikimac: data (47)
read_frame len=62, rssi=-14
contikimac: Drop duplicate
contikimac: data (47)
contikimac: send broadcast
contikimac: send (strobes=1, len=95, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=1, len=95, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=1, len=95, no ack, no collision), done
*** dropping large 2000 byte packet
*** dropping large 2000 byte packet
*** dropping large 2000 byte packet
*** dropping large 2000 byte packet
*** dropping large 2000 byte packet
-link but no route src=fd00::1 dst=fd00::212:4b00:e09:7a94
*** dropping large 2000 byte packet
9:7a94
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:e09:7a94
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:e09:7a94
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:e09:7a94
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:e09:7a94
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:e09:7a94
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:e09:7a94
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:e09:7a94
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:e09:7a94
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:e09:7a94
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:e09:7a94
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:e09:7a94
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:e09:7a94
contikimac: send broadcast
contikimac: send (strobes=1, len=95, no ack, no collision), done
read_frame len=62, rssi=-15
contikimac: data (47)
read_frame len=62, rssi=-15
contikimac: Drop duplicate
contikimac: data (47)
contikimac: send broadcast
contikimac: send (strobes=1, len=95, no ack, no collision), done
contikimac: send broadcast
contikimac: send (strobes=1, len=95, no ack, no collision), done

I have added debugging information in prop-mode.c L803 to show frame len and rssi value:

int8_t rssi = (int8_t)data_ptr[len];
PRINTF("read_frame len=%d, rssi=%d\n", len, rssi);

I think the main issue in only timing settings, both for nullrdc and ContikiMAC, but I think contiki is optimized for 50kbps 2-GFSK radio settings and we should find a way to calculate the good value accordind to the desired bitrate.

[Qain0130]

We used "https://github.com/mdmobashir/contiki-lrm" to change cc1310 launchPad to lrm mode,but we have some problem.

We use contiki/examles/ipv6/rpl-udp/udp-client.c and udp-server.c. rdc :nullrdc and open csma.c debug

When client send packet to server. the beginning of the normal transmission but after a period of time the server will not receive the packet sent by the client,but client still sending.

hope someone can help us to solve this problem.

Server log csma: send_packet, queue length 1, free packets 31.csma: scheduling transmission in 0 ticks, NB=0, BE=0.csma: preparing number 0 #0x20002df0, queue len 1.csma: rexmit ok 1.csma: free_queued_packet, queue length 0, free packets 32.DATA recv 'Hello 3 from the client' from 23RSSI = -14 LQI = 127 .DATA recv 'Hello 3 from the client' from 23RSSI = -14 LQI = 127 ..DATA recv 'Hello 4 from the client' from 23RSSI = -14 LQI = 127 ..csma: send_packet, queue length 1, free packets 31.csma: scheduling transmission in 0 ticks, NB=0, BE=0.csma: preparing number 0 #0x20002df0, queue len 1.csma: rexmit ok 1.csma: free_queued_packet, queue length 0, free packets 32.csma: send_packet, queue length 1, free packets 31.csma: scheduling transmission in 0 ticks, NB=0, BE=0.csma: preparing number 0 #0x20002df0, queue len 1.csma: rexmit ok 1.csma: free_queued_packet, queue length 0, free packets 32.csma: send_packet, queue length 1, free packets 31.csma: scheduling transmission in 0 ticks, NB=0, BE=0.csma: preparing number 0 #0x20002df0, queue len 1.csma: rexmit ok 1.csma: free_queued_packet, queue length 0, free packets 32.csma: send_packet, queue length 1, free packets 31.csma: scheduling transmission in 0 ticks, NB=0, BE=0.csma: preparing number 0 #0x20002df0, queue len 1.csma: rexmit ok 1.csma: free_queued_packet, queue length

[Rosa-Phoebe]

Hello, I recently do some work on TI simplelink LRM with Contiki-NG SubGHz TSCH on TI CC1310 launchpad and I change time slot template 400ms for simplelink LRM 5kbps. And I also use LRM settings from SmartRF Studio and change some variables for cc13xx configurations and definitions in fold contiki-ng\arch\cpu\simplelink-cc13xx-cc26xx for 5kbps LRM. But when I run it on CC1310 launchpad and it seems crash and reboot when send EB packet. Does anyone give some good suggestions? I post the log information as follows. The mac error code is 4. Thank you very much.

I have debugged simplelink-cc13xx-26xx radio driver using printf function. I found that for simplelink LRM, in netstack_sched_prop_tx function, CMD_STATUS(netstack_cmd_tx) is always PENDING after executing RF_scheduleCmd function. I don't know whether this problem is caused by LRM 5kpbs 400ms time slot template. Is there anyone come across this problem and give some good suggestions? Thanks.