Other Parts Discussed in Thread: CC1312R, , TIMAC
This is example code from a couple years back but I am basing some work on it to achieve a mesh network with the CC1312R.
I am having trouble with the push_leaf configuration connecting when the channel mask is changed in single_fh_channel mode. Attempting to change to 922.4MHz. I have tried some other channels with the same issue, but testing was not as exhaustive as 922.4MHz.
Can the same behavior be observed (confirmed)?
This is the setup used.
macOS Catalina 10.15.6
Code Composer Studio 10.1.0.00010
SimpleLink CC13x2 26x2 2.40.0.81
TI v 18.12.6.LTS
xdctools_1_51_01_18_core
CC1312R LaunchPad Rev.D (rev E silicon)
TIDA-010024
tidcey4a.zip
6LoWPAN_Mesh_TI_15_4_Example_CC1312R_V2.0.0.0.exe
From this link
https://www.ti.com/lit/zip/tidcey4
Please note, the link to the same file on this (other language) page is broken, perhaps someone should look into this.
https://www.tij.co.jp/tool/jp/TIDA-010024
Build configurations
+ debug_push_leaf
+ debug_root_push
For testing these changes were made
Application/subg/config.h
Line 37, uncomment //#define SINGLE_FH_CHANNEL
Line 172, change to the following
#define CONFIG_FH_CHANNEL_MASK { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, \
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
0x00, 0x00, 0x00, 0x00, 0x00}
Line 192, change to the following
#define FH_ASYNC_CHANNEL_MASK { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, \
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
0x00, 0x00, 0x00, 0x00, 0x00}
The two above change enable channel 118 (byte 14, bit 6), 925.8Mhz (if my calculations are correct).
Perform a clean and build for the three projects:
+ debug_push
+ debug_push_leaf
+ debug_root_push
debug_push connected in 2-3 minutes after being powered up.
debug_push_leaf does not connect, even after 7 hours.
Next change the values back to the following, clean and rebuild.
Notice the debug_push_leaf does connect within 2-3 minutes.
Line 172, change to the following
#define CONFIG_FH_CHANNEL_MASK { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, \
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
0x00, 0x00, 0x00, 0x00, 0x00}
Line 192, change to the following
#define FH_ASYNC_CHANNEL_MASK { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, \
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
0x00, 0x00, 0x00, 0x00, 0x00}
At the moment I don’t have a way to monitor packets but will try to setup something to do packet monitoring with using one of the LaunchPads.
The below following was observed as well.
After the 902.2MHz debug_root AND 902.2MHz push_leaf were powered up the 922.2 push_leaf connected for some reason, I am still investigating the circumstances to how it connected under these conditions.
At this time there were 4 LaunchPads operating
+ 902.2MHz push_leaf
+ 902.2MHz root_push
+ 922.4MHz push
+ 922.4MHz root_push
In the above situation the 922.4MHz push_leaf connected within a few minutes (green LED turns on). This occurred only once, I have not been able to reproduce this behavior.
I will be attempting to setup a LaunchPad to monitor the packets and be able to observe more detail soon, but wanted to get this initial post up in the mean time.
Could I get a brief explanation of how channel selection and such as handled for the RX and TX? It is not clearly apparent where in the stack the is occurring.
EDIT: it appears I have located somewhat if what I was looking for, but this is far, far deeper than I wanted to dig into the inner workings. I am not sure I want to go much deeper, this appears not trivial to understand.
ROM/fh_rom_init.c references this struct in the following file...
simplelink_cc13x2_26x2_sdk_2_40_00_81/source/ti/ti154stack/fh/fh_ie.h (TIMAC 2.0 FH IE API as written in the file header) The function prototypes all appear to reference extern MAC_INTERNAL_API.
typedef struct { uint8_t regulatoryDomain; uint8_t operatingClass; uint32_t ch0; uint8_t channelSpacing; //0:200kHz, 1:400kHz, 2:600kHz uint16_t noOfChannels; } FHIE_channelPlan_t;
My assumption is that this struct is used in the stack to setup the operating channel, and the CC1312R can only have one channel selected (or tuned on) at a time for transmission or reception.
I am assuming this above sets the channel band plan from which the channel numbers are derived, which then are selected as a channel number.
From this above information the frequency hopping is not a feature of the 802.15.4 MAC stack per say, but it is built into the hardware, as it is in the ROM API files. The API provides the interface to setup the feature it seems. I am wondering how much of the 802.15.4 MAC is implemented in hardware vs software, is this an easy question to ask? I will try to search some documentation on this subject, maybe it is included in the CC1312R technical references.
EDIT:
I mistook the channel number, the cells in the spreadsheet didn't drag down correctly, I am using 922.4MHz (channel 101) for communications.
I was able to get the sniffer setup and am attaching the log, I think the issue is in the push_leaf since the non-leaf connects ok.
These are the updated settings I used for the channel mask.
#define CONFIG_FH_CHANNEL_MASK { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ 0x20, 0x00, 0x00, 0x00, 0x00} #define FH_ASYNC_CHANNEL_MASK { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ 0x20, 0x00, 0x00, 0x00, 0x00}
The packet sniffer picks them up correctly on 922.4MHz, so I believe the channel setting is correct.
An image and the capture file is included before, all settings (encryption key, etc) are default as was downloaded.
Uploader is picky, I had to make a zip file, the packet capture is inside.