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.
TIDA00759 is the 10 year coin cell PIR using the CC2650. I would like to reproduce this using the CC2340R5. TIDA00759 generated the packet framework using SmartRF Studio. I tried doing the same for CC2340R5 but when I do the code export from SmartRF I can't figure out how to get it to include the BLE packets in the code generated. I am using SmartRF Studio 8. This snippet is in the CC2650 code, how do I get it in the CC2340R5 code?
BTW the actual target is a temperature/humidity sensor. We are looking at the HDC2080 and HDC3020. Would something else be more power efficient? Application is for HVAC.
// BLE ADV NC
rfc_CMD_BLE_ADV_NC_t RF_cmdBLEAdvNC =
{
.commandNo = 0x1805,
.status = 0x0000,
.pNextOp = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
.startTime = 0x00000000,
.startTrigger.triggerType = 0x0,
.startTrigger.bEnaCmd = 0x0,
.startTrigger.triggerNo = 0x0,
.startTrigger.pastTrig = 0x0,
.condition.rule = 0x1,
.condition.nSkip = 0x0,
.channel = 39,
.whitening.init = 0x0,
.whitening.bOverride = 0x0,
.pParams = 0,
.pOutput = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
};
How do the BLE adv. address, data info options work? I can't get them to do anything.
Also Smart RF Studio is not detecting my CC23405 Rev A which Digikey sent me on Nov 30. It works from CCS. Why is Digikey sending those, messages on the forum say they are unsupported now? My XDS110ET is Rev B.
I think I understand what is going on now, SmartRF Studio 8 Code Export is generating code which uses ti/drivers/rcl. That works as expected. Under Packet TX there are only options for Random, Hex, Text payloads. So it appears SmartRF Studio 8 v1.0.1 is missing a choice for TX of BLE advertising packets -- and that's the option I need.
Hi,
Thank you for reaching out. We will look into this and get back to you as soon as possible. To clarify, are you looking to implement a BLE project with the custom RF settings provided by SmartRF or are you planning to implement BLE packets in a proprf example?
Best Regards,
Jan
I believe the rfPacketTx NoRTOS sample is the closest example in the CC2340 SDK. In order to save power TIDA00759 does not use the BLE stack. Instead it just directly makes BLE advertising packets using the low level packet driver.
I want to do the same thing but instead use the CC2340. So CC2340 sits in deep sleep waiting for IRQ from temp sensor. Then it wakes up and sends the BLE advertising packet. The sensor is transmit only. The scheme used by TIDA00759 is extremely power efficient since it avoids using the BLE stack and RTOS.
I'm at the stage now of looking at rfPacketTx.c and trying to figure out how to convince it to send BLE advertising packets.
This is the essence of what I need, how do I convert this function from TIDA00759 (CC2650) over to RCL for CC2340r5? I can't locate any examples of how to make BLE advertising packets using RCL. The code doing that is inside OneLib so I can't look at it. I thought I should be able to get SmartRF studio to generate it for me, but doesn't have that option.
static void sendPacket(uint8_t data)
{
uint32_t time;
/* Init Radio parameters */
RF_Params_init(&rfParams);
/* Construct payload */
packet[0] = 07;
packet[1] = 59;
packet[2] = data;
/* Configure packet */
ADV_params.advLen = PAYLOAD_LENGTH;
ADV_params.pAdvData = packet;
ADV_params.pDeviceAddress = (uint16_t*)&radioBleDevAddr;
ADV_params.endTrigger.triggerType = TRIG_NEVER;
#if PACKET_TYPE == ADV_IND_TYPE
/* Configure radio for Adv IND packet */
RF_cmdBLEAdv.startTrigger.triggerType = TRIG_ABSTIME;
RF_cmdBLEAdv.startTrigger.pastTrig = 1;
RF_cmdBLEAdv.startTime = 0;
RF_cmdBLEAdv.pParams = (uint8_t*)&ADV_params;
#else
/* Configure radio for Adc Non connectable packet */
RF_cmdBLEAdvNC.startTrigger.triggerType = TRIG_ABSTIME;
RF_cmdBLEAdvNC.startTrigger.pastTrig = 1;
RF_cmdBLEAdvNC.startTime = 0;
RF_cmdBLEAdvNC.pParams = (uint8_t*)&ADV_params;
#endif
/* Request access to the radio */
rfHandle = RF_open(&rfObject, &RF_prop, (RF_RadioSetup*)&RF_cmdRadioSetup, &rfParams);
/* Set the frequency */
RF_postCmd(rfHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, NULL);
/* Configure packet transmission time */
time = RF_getCurrentTime();
time += PACKET_INTERVAL;
#if PACKET_TYPE == ADV_IND_TYPE
/* Send Adv IND packet */
RF_cmdBLEAdv.startTime = time;
RF_Event result = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdBLEAdv, RF_PriorityNormal, NULL, NULL);
#else
/* Send Adc Non connectable packet */
RF_cmdBLEAdvNC.startTime = time;
RF_Event result = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdBLEAdvNC, RF_PriorityNormal, NULL, NULL);
#endif
/* Close radio to save power */
RF_close(rfHandle);
/* Power down the radio */
RF_yield(rfHandle);
}
Hello Jon,
In general, I would not recommend emulating BLE functionality through RCL directly. May I ask if you can consider unsing an example project such as basic_ble and configure the device to only send advertisements? The project can be found at <SDK>\examples\rtos\LP_EM_CC2340R5\ble5stack.
Please let me know if this is a possibility.
BR,
David.
I have that installed and I am running it. But that means I have to have FreeRTOS and the BLE stack running which is going to use a lot more power (ie battery life). For example I don't want the BLE stack turning on the receiver, this design is transmit only.
I really liked this design which is very power efficient
Low-Power PIR Motion Detector With Bluetooth Smart & 10-Year Coin Cell Battery Life Reference Design
That design simply wakes up, sends an advertising packet and then goes back into deep sleep. No BLE stack, No RTOS,
Hi Jon,
I'll take a look at this and get back to you in 2-3 business days.
Thanks,
Toby
Appears this question has been asked before, but there is no solution in the responses.
e2e.ti.com/.../cc2340r5-rcl_command_submit-and-rcl_command_pend-returns-0x8a
Yes, thanks for referencing other related post.
That one is a similar post, with some differences. They are trying to accomplish a BLE RX using a non-BLE stack project.
In my experience, performing a TX should be easier than performing a RX, all things being equal.
We have migration guides available here: https://dev.ti.com/tirex/content/simplelink_lowpower_f3_sdk_7_20_01_10/docs/proprietary-rf/proprietary-rf-users-guide/proprietary-rf-guide/migration-cc23xx.html
For BLE specifically, here are the BLE commands: C:\ti\simplelink_lowpower_f3_sdk_7_20_01_10\source\ti\drivers\rcl\commands\ble5.h
This can be used in addition to the migration guide above.
As a disclaimer which should be mentioned before, CC2340 and CC26xx are different device families, and have a different radio architecture; it is not a guarantee to have 1-1 compatibility from perspective of non-BLE-stack components.
Can I use the generic rfPacketTx example to send a BLE advertising packet? I used the BLE generic settings and then tried a lot of combinations for the data. I can't get anything to show up in my BT Sniffer. Does the modulation need to be adjusted or something like that? I don't have RF test equipment available to see how it is transmitting.
This should be Channel 39. #define FREQUENCY (2480000000U)
Getting a BLE advertising packet out of the generic rfPacketTx example code would be sufficient for my needs. No problem if I need to construct the packet myself.
Can you check if you see packets on the BLE sniffer if you do the following:
Use SmartRF Studio 8 for the CC2340, and perform a "packet tx" test with the BLE PHY.
I have the Rev A CC2340R5 eval board, SmartRF Studio 8 won't recognize it. I see from other messages that I need a Rev B.
I am sure sniffer is working, it is picking up hundreds of packets from other devices. And when I run the BLE samples for CC2340 board I can see those.
I have the Rev A CC2340R5 eval board, SmartRF Studio 8 won't recognize it. I see from other messages that I need a Rev B
Understood, here I recommend to acquire a Rev B board, as that is the one which will be compatible with the latest SDK.
The motivation for my request to try with SmartRF Studio 8, is to see if the BLE packets sent from their are detectable by the BLE sniffer (so, it's good the BLE sniffer is known to work). If the SmartRF Studio 8 packets are detectable from the BLE sniffer, then you would be able to integrate the code export from SmartRF Studio 8 to your CCS project to send packets detectable by the BLE sniffer.
I have ordered another CC2340R5 eval board direct from TI. Not happy with Digikey for sending me a Rev A two weeks ago.
I think the code export from SmartRF Studio has changed between 7 and 8. In 7 it exported all of the necessary code to make the BLE packets. In 8 it is only exporting the setup code for the chip. I tried to use 7 to get the old code export but CC2340R5 is not supported in 7.
You went down the same path which prompted me to write the initial question. I wanted sample RCL code to send a BLE packet. So I said.... I can use SmartRF Studio to generate it for me (which worked for the CC2650). But when you generate the code for the CC2340R5 using SmartRF Studio 8 - it doesn't generate the BLE packet code anymore. And CC2340R5 is not supported in SmartRF Studio 7.
I tested the SmartRF Studio 8 export on my end with rfPacketTx: loading CC2340R5 Rev B firmware with exported SmartRF Studio 8 settings, I am able to transmit packets which are detectable by a separate device (CC2652R7 BLE mode) in SmartRF Studio 7.
Once you have your Rev B board, you should be able to achieve the same.
The exported files to use from SmartRF Studio 8 are rcl_settings_generic.c/h.
It may be a Rev A Board (PCB) with latest silicon (CC2340R5).
Can you check if it works with SmartRF Studio 8?
No luck, behaves the same as the previous board. SmartRF Studio 8 won't recognize it, but CC Studio does. There are other reasons Studio 8 might not work, for example a driver problem, but I don't have any other way to check it.
I will try exporting rcl_settings_generic.c/h with rfPacketTx tomorrow and see what happens.
SmartRF Sudio sees the XDS110 but it won't open it.
I tried copying rcl_settings_generic.c/h into rfPacketTx but could not see anything on the sniffer.
Can you zip up your project and send to me? That would let me verify if these boards actually work with the code from smartrf studio.
The boards do work, I can see packets from the CC2340R5 BLE demo app.
Hello E2E community member,
Thanks you for asking your question concerning TI's SimpleLink Devices on the E2E Forum! The subject expert who can best address your inquiry is out of office for the holidays. After returning in early January, they will review your post and provide an initial response within 24 hours.
Regards,
Jan
I got SmartRF Studio working with one of my boards. The problem was that it won't run under a VM (I tried KVM, VirtualBox and VMware). Once I borrowed a Windows laptop I was able to see the packets from SmartRF Studio in my BLE Sniffer. So that verifies that I have working hardware.
What I am completely unable to achieve is working source code to send BLE advertising packets using RCL. (no RTOS, no BLE stack). I have tried many combinations of RCL commands including the BLE specific ones.
ctxAdvertiser = RCL_CtxAdvertiser_DefaultRuntime(); txCmd = RCL_CmdBle5Advertiser_DefaultRuntime(); txCmd.ctx = &ctxAdvertiser;
I need a tiny working demo of sending a BLE advertising packet using RCL soon or management is going to move me back to our Nordic based products. Please include how to enable RCL logging in the example.
Attached is the modified example I mentioned previously.
This enables CC2340R5 --> CC2652R7 (probably works for any CC26xx device in SmartRF Studio 7).
On the Receiving side, use Channel 17 (2440 MHz).
rfPacketTx_LP_EM_CC2340R5_nortos_ticlang.zip
It works with 7.20 F3 SDK.
If you want to just run the FW:
Thanks, I am able to see packets generated with this code. I will use this code to expand on this technique for making a beacon.
Meanwhile I have been working on a parallel implementation using FreeRTOS and the BLE stack. I can't get non-connectable to work. I will start a new thread for that.
Once I get both schemes working I will compare the power profiles.