Tool/software:
Hi, I'm trying to work with LP-EM-CC1314R10 multiple RF transmitters and a single receiver. Is there any possible way to receive from multiple transmitters without payload loss at the RF receiver end and how to implement configurations for both transmitter and receiver to achieve the scenario?
Hi Theo,
From afternoon, the sensor status is always in orphaned state. We even tried by flashing the "collector" and "sensor" examples without any modification but the sensor is still not connecting with the collector, the status is showing as orphaned state only.
What could be the reason?. can you kindly help us?.
Regards,
Mani Vel
Hi Mani Vel,
for the packet sniffer you need to use one of the supported boards:
Another debugging option is to implement a second UART (https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1415402/lp-em-cc1354p10-adding-uart-interruption-to-wi-sun-coap-project).
Kind regards,
Theo
Hi Theo,
Thanks for your support.
From your list we could not find the launchpad that we are having (LP-EM-CC1314R10).
However when searching on online there is a Ti's packet sniffer V2.18.1, which supports the MCU that we are having CC1314R10..
Link : https://www.ti.com/tool/PACKET-SNIFFER#tech-docs
So, Would you please verify if we are able to utilize our launchpad (LP-EM-CC1314R10) as a packet sniffer or not?
If not we will ask our team to get us a new launchpad.
Best Regards,
ManiVel.
Hi Theo,
Currently we have only one LP-XDS110ET debugger so we couldn't test the smartRF Studio . Now we have ordered additional debugger .
In the meantime, we had performed a long-run test (one collector and two sensors) lasting around two days and made some changes to the band (ETSI), PHY (5 kbps, SimpleLink Long Range), mode (NBCN), and interval mentioned in "Application Note: TI 15.4-Stack Software. - Table 6.2.1 Sub1G".
Observation on long-run testing:
1. Even after two days, the collector is still able to receive sensor data from one of the sensors that is in line of sight (the sensor antenna and collector antenna facing each other) with an error rate of 1%.
2. The rest of the sensor antenna has been angled sideways toward the collector antenna with the 85% error rate. The sensor data is continuously being transmitted at the sensor end even though the collector was unable to receive any packets from this sensor after the test lasted for four hours.
Please kindly help us to resolve the issue.
Additionally, where we can find the details about the large network stability test , mentioned in the Table 6.2.1.
like
1. Which PHY that they have configured for testing the 100 nodes (in FCC and ETSI).
2. What is the maximum distance that they have placed the sensors.
3. Reporting time 20s means every 20s only the sensor data is transferred - is that our understanding correct?.
Regards,
Manivel
Hi Manivel,
the LP-XDS110ET is the debugger including the Energy Trace that can be used with Code Composer Studio to visualize the boards energy consumption.
Please give me the following information so that I can assist you:
1. I understood that you setup a test with 1 collector and 2 sensors. Which software examples are you running on the collector and on the sensors?
2. Please provide me a screenshot like the following example for the collector and the sensors, so that I can check all the 15.4 settings that you are using.
3. Which transmit power do you use for the collector and the sensors?
4. Where are the devices placed (distance, obstructions)?
5. How do you count sent and received messages? Did you also look at the RSSI?
6. Have you made any changes to the examples?
I can already answer:
1. Going through the lines of the table the configurations are:
2. For the Large Network Test the bards are placed in a rack setup and different network topologies are enforced by the software. This is only the software evaluation test for 15.4 Stack. The board hardware is characterized in various other tests. E.g. the boards antenna characteristics can be found here: https://www.ti.com/lit/an/swra496a/swra496a.pdf pages 178, 183.
3. This depends on the mode that you are using. In our User's Guide the different modes are explained in detail: https://dev.ti.com/tirex/explore/node?node=A__AITUIbVTzCdD7w7KebQ-qA__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK__BSEc4rl__LATEST
Please answer the points above and I will help you to fix your setup.
Kind regards,
Theo
Hi Theo,
1. We have been using the "collector" and "sensor" examples.
2. I had attached the .sysconfig image of both collector and sensor examples, followed by,
collector:
Sensor:
3. Now the transmit power we are using is 12 dBm for both the collector and sensor.
4. Sensor-1 distance 20 m antenna towards collector antenna and Sensor-2 distance 15 m antenna sideways to the collector antenna.
5. In the collector and sensor example, by default the temperature sensor data has been transmitted from the sensor and received by the collector.
In the collector "dataIndCB" function, there is a case "Smsgs_cmdIds_sensorData," which receives all the sensor data. In this case, we add an incremental count and transmit the count in UART.
In the Sensor "sendSensorMessage" function, the sensor data's are periodically transmitted from the sensor. In this functionality, we made an incremental count and transmit the count in UART.
For RSSI, Sensor-1 ranges between 50 and 60 and Sensor-2 ranges between 65 and 75, verified in the collector CUI.
6. For testing the range, we had newly imported these examples and only added UART configurations and incremental count transmitting through UART.
Regards,
Manivel
Hi Theo,
We made our setup according to the 5th configuration (ETSI - Poll :20s/ Track: 100s/ Report:20s - NBCN),
1. I would recommend you to adjust the polling interval to be in the specified range (e.g. 9000 ms). You can leave the reporting interval set to 20000 ms.
>> Ok. We will reduce the polling interval to 9s.
2. The RSSI looks good so please test again with the adjusted reporting interval as it might be a synchronization issue that occurs because the value is out of spec.
>> We will test with new configuration.
3. Can I ask you for which product this is for?
>> We are building a kind of Gateway application where it receives data from multiple transmitter devices. So we are testing the maximum range/power/nodes with our launchpad devices.
>> Currently we are testing in the NBCN mode with long range PHY setting in the Ti 15.4 stack "5 kbps, SimpleLink Long Range ".
>> Also in some application notes they recommended the frequency hopping mode for better performance. Can you add your thought on this?
Regards,
Manivel
Hi Theo,
We now received another debugger. So will test the different PHYs in the smartRF studio.
To inform you again we are building a product like gateway(a Collector) and sesnors where the Gateway should receive data from multiple sensors over a long range. The frequency band we are using is 868 Mhz (ETSI standard). We are majorly focusing on long distance and low power on sensor side.
We have some doubts and listed in the following,
1. As you mentioned earlier,
for TI15.4 only the Phys shown in sysconfig are supported. In SmartRF Studio all Phys that the device can support are shown. They correspond to different software stacks.
Please use for the testing the same Phy that you want to use in sysconfig for TI15.4.
>> So we need to test only 3 PHYs i.e available in the TI stack for ETSI using the smartRF studio?
Is our understanding correct?.
2. When reading the user guide, we understand the polling interval means, how often the sensor is polling the data from the collector. And the collector will set the polling and reporting interval to a sensor when it is connecting to a network (i.e Whatever we are configuring in the sensor.syscfg is only default value and collector will send the values configured in the collector.syscfg to the sensor when it is joining the network).
a. In our case the reporting interval may vary based on the sensor that the user is using, So can we configure different reporting interval to a sensor on a multi sensor network?.
b. If yes, do we need to change the polling interval to each sensor as well?
Kindly help us to understand.
Best Regards,
Muniyappan R.M
Hi Theo,
Thanks for your response.
Please correct this information if anything has changed or is missing.
>> The tests were done using the smartRF studio with two LP-CC1314R10 boards in Packet-Tx and Packet-Rx modes since we need to fix the PHY which suits for our requirement before going to the collector and sensor example.
Now regarding your questions,
1. Are the devices in line of sight and do you have interference in between them?
>> The devices are in the line of sight and We are currently tested with some interference.
2. What is the noise floor in your testing environment (if you haven't checked it you can use SmartRF Studio with the device in continuous RX to measure it)?
>> When running the SmartRF Studio with the device in continuous RX mode we are getting some RSSI graph. What is the ideal RSSI value for a good testing environnemt?;
3. At which height over ground do you test the devices and are the devices oriented towards each other?.
>> Yes both the devices are in same height over the ground and oriented each other.
4. Does the 2.5 kbps SimpleLink Long Range PHY fulfills your requirements of data rate or do you have higher requirements for the data rate?
>> Yes.
In general the 2.5 kbps SimpleLink Long Range PHY in combination with the highest tx power (for CC1314R10 = 14 dBm) will result in the longest range.
>> Thanks Theo. Now we are planning to run the tests again (with the smartrf studio only ) in the more noiseless environment possibly with the external antenna (Since we will use the same antenna in our product) and update you about the results.
Similarly you can also suggest us about the configuration parameters to achieve the long range with the CC1314R10 board.
We have some questions,
1. The smartRF studio is used to identify the ideal PHY for our application and there we could not select the NBCN/BCN/FH modes - right?.
2. Once we fixed the PHY using SmartRF studio, and configuring the the same settings in the collector and sensor example using Custom PHY option will result the same range irrespective of the Beacon/Non-Beacon/Frequency hopping modes?. Or there will be the difference ?.
3. Is there any range test conducted with the CC1314R10 board and is there any documents available?.
you have already shared us about the stability test results,
But we focused more about range. So Is there anything you can help us?
Best Regards,
Muniyappan R.M
Hi Theo,
Thanks for your valuable insights.
We are using the range estimation tool for testing the range for respected PHY, antenna, and absorption material.
At our office indoors, the noise floor value is around -120 dbm (attached the screenshot), yet we need to measure the noise floor value in the testing environment. When changing the noise floor value to -120 dBm in the range estimation tool., we could see the notable difference in the range. In the testing environments, the noise floor value might be low further, which could affect the range as well.
So It is quite difficult to achieve the good range with this noise floor level. Regarding your question,
1. We are unable to get the spectrogram of the current environment.
2. We sent our device specification to you in private.
Kindly help us to achieve a better performance. We really appreciate your continuous support and involvement to build a better product using the TI's devices and drivers.
Regards,
Muniyappan R.M
Hi Theo,
Thanks for you continuous support,
I am currently implementing different reporting interval for each sensor. Similarly I want to work on the polling interval as well. Because As a part of our requirement, we need to send the unique data from collector to the one particular sensor whenever needed ( but from the collector to sensor, the data can be sent at each poll time by the sensor.)
I have implemented the new commands by referring the training labs (Smsgs_cmdIds_genericReq and Smsgs_cmdIds_genericRsp),
typedef enum { // ... /* Device type response msg */ Smsgs_cmdIds_DeviceTypeRsp = 17, /* Generic request msg */ Smsgs_cmdIds_genericReq = 18, /* Generic response msg */ Smsgs_cmdIds_genericRsp = 19 } Smsgs_cmdIds_t;
I am assigning the data to one sensor from collector by using the Smsgs_cmdIds_genericReq using the API sendMsg(). It was sent to the respective sensor in the next polling request. In the sensor side I am processing the Smsgs_cmdIds_genericReq cmd and do our implementation.
We have the following queries,
1. All the sensors should be configured the same polling interval or we can change the polling interval to each sensor (by collector configuration message)?
For example if I set the polling interval as 1000ms in the collector side and connect 10 sensors, does all the 10 sensors should have the same reporting interval of 1000ms?. If yes,
a. If I assign a message to all the 10 sensors, whether it will be delivered to all the 10 sensors within 1 second (since all the sensors configured as 1000ms of polling time) without fail?
b. Whether It will affect the performance?.
2. Do we need to implement the response path as well from the sensor?. i.e using the Smsgs_cmdIds_genericRsp command.
3. How to handle the retry scenarios, Once the data is assigned to a sensor using the API sendMsg(), whether the stack will make the retires if it is failed to send on one polling request?.
4. Can I assign Multiple messages to one sensor within one polling request?.
Best Regards,
Muniyappan R.M
Hi Theo,
Thanks for your clarification.
So From your response we understood following things, correct me if I am wrong.
1. All the sensors in a network should have the same polling interval and can have the different reporting interval.
2. From collector to a sensor a, when a message is sent using the sendMsg() , it will be queued internally in the stack and it will be delivered to that particular sensor in the next poll (i.e when that particular sensor polls for data to the collector).
3. Similarly when sensor polls for the data, the collector will transmit one message from its queue and the queue will be emptied, which implies the collector could not send multiple messages for one poll request. So we need assign the data to a sensor based on the polling interval.
4. Retries performed automatically by the stack.
We understood these points well. We started implementing the same in our product as well.
Additionally we moved to the Frequency hopping mode (part of our requirement) .In frequency hopping the custom PHY is not supported, so we are currently using the PHY - 5 kbps, SimpleLink Long Range .
You mentioned that, we need to actually test the following scenario.
1. All the sensors should be configured the same polling interval or we can change the polling interval to each sensor (by collector configuration message)?
For example if I set the polling interval as 1000ms in the collector side and connect 10 sensors, does all the 10 sensors should have the same reporting interval of 1000ms?. If yes,
a. If I assign a message to all the 10 sensors, whether it will be delivered to all the 10 sensors within 1 second (since all the sensors configured as 1000ms of polling time) without fail?
Unfortunately we don't have that amount of sensor boards. So we tested with the following setup,
Setup : Collector device and two sensor devices. Frequency hopping mode. PHY - 5 kbps, SimpleLink Long Range - ETSI .Tx power 14dbm. I am having al these setup with in the 10meters.
Sensor configuration:
Collector configuration:
Our goal is to achieve the following 3 things,
1. Sensor to collector (one to one) communication.
From each sensor I am sending the sensor data in the configured reporting interval. (Sensor data transmitted and received count incremented on the sensor and collector respectively).
2. Collector to One sensor communication.
I am sending a message to one particular sensor (When pressed btn 1 -> Sensor 1 , btn 2 -> Sensor 2) using the newly added commands , Smsgs_cmdIds_genericReq and Smsgs_cmdIds_genericRsp. when this command is received I am toggling the green led in the sensor side (generic req transmitted and received count incremented on the collector and sensor respectively ).
3. Collector to all the sensor communication.
From the collector the Broadcast command is triggered every 10sec (configured in the sysconfig). I am toggling the red led whenever this broadcasted command is received on the sensor side (broadcast count transmitted and received count incremented on the collector and sensor respectively).
I have also removed the debug prints in all the files and added only one debug print which outputs broadcast count , sensor data count and generic req count in both sensor and collector side (will be printed every 10 sec on the collector side and sensor side). Also monitoring the led states in both the sensors.
My expected observation is :
a. Red led on both the sensor should be toggled in the same interval - Since the broadcast packet should be received on both the sensors.
b. When btn 1 is pressed , Green led on the sensor 1 should be toggled (I should wait for the polling interval). Similarly when btn 2 is pressed, Green led on the Sensor 2 should be toggled.
My observed results are:
1. No issues with the Sensor data count. (May be the distance is not that far)
2. The red led pattern in not matching some times between the sensor. i.e sometimes the broadcast command is not received by a sensor.
When printing the logs I could see, the broadcast transmitted count is not matching with the two sensor's receiving count.
3. When pressing the button 1 / button 2 , sometimes the green led is not toggled in the respective sensor.
When printing the logs I could see the generic request is showing as transmitted on the collector side but it was not received on the respective sensor - I have waited for more than 10 seconds (Since you have mentioned that the stack will make the retry attempts. my polling rate is 3 seconds).
May be I need to configure the Frequency hopping mode properly so I am continuing my testing. Is my expectation is correct? or I have missed something?. Kindly help us to achieve the goals.
Note:
From My previous post we have only one doubt:
For example if I set the polling interval as 1000ms in the collector side and connect 10 sensors, does all the 10 sensors should have the same reporting interval of 1000ms?. And all the sensors are associated at the same time,
a. All these sensors will wake up and poll the collector at the same time ,may be few milliseconds gap (Since all configured same polling interval) ?. If yes?, Will the collector able to send response to all the sensors? (Sometimes With my 2 sensor setup If I press both the buttons , the green led is not toggled on any of the one senor i.e the data is not received on one sensor)
b. Or all the 10 sensors will have the time slots for each to poll the collector?.
c. What happens If I increase the sensor count from 10 to 50? Whether it will affect the performance?
Regards,
Muniyappan R.M
Hi Theo,
Quick update.
As you have mentioned earlier, first we need to test this scenarios in NBCN mode ,so we reverted back to the NBCN mode and test the same scenarios.
Still I didn't get the sniffer setup, so how can we test the network efficiently?. I have enabled the one additional UART in the following way (in both collector and sensor)
And added the debug print in only one place in the sensor_process() and collector_process(). Is that ok?
Similarly in NBCN mode broadcasting is possible? especially if the sensors are a sleepy devices. I have read from some forum, that in Non beacon mode we cannot send broadcast data from collector. We need to send it individually to all the sensors but that also depends on their polling Interval of each sensor. Can you kindly clarify this?
We will first achieve the following goals in the Non beacon mode first.
a. Sensor to collector (one to one) communication.
b. Collector to a particular sensor (one to one) communication .
c. Collector to all the sensor (one to many) communication. (If it is possible in the NBCN mode)
Thanks for your continuous support.
Regards,
Muniyappan R.M
HI Theo,
Thanks for your response.
As we told earlier we reverted back to the Non-beacon mode and conducted the testing. Following are the results,
Setup:
1 collector board and 1 Sensor board (unfortunately we could not able to use 2 boards)
PHY : 5 kbps, SimpleLink Long Range.(ETSI)
Intervals:
Short Range test 1:
From Sensor to collector, sending data every 1 second (reporting interval).
From Collector to sensor, sending data every 10 seconds
Placed sensor and collector board in 15m distance inside our office and ran for 2 days.
We could see only 238 sensor data lost on the collector side (total sensor data tx count on Sensor side : 225316 ).
Similarly 15 polled data is not received on the Sensor side (total poll data tx count on collector side : 22499)..
Short Range test 2:
From Sensor to collector, sending data every 1 second (reporting interval).
From Collector to sensor, sending data every 4 seconds
Placed sensor and collector board in 15m distance inside our office and ran for 14 hours.
We could see only 2 sensor data lost on the collector side (total sensor data tx count on Sensor side : 51223).
Similarly 6 polled data is not received on the Sensor side (total poll data tx count on collector side : 12099).
long Range test:
(Tested on the National Highways, there is no walls in-between only vehicles are passing by)
We also tested upto 500m on LOS, and both the sensor to collector data (1 seconds once) and collector to sensor data is received properly (Only once the sensor was orphaned when a large truck is stopped on before the sensor board but it was rejoined immediately as soon as the truck was moved.)
In our testing we faced no big issues in the Non-beacon mode (Earlier I mentioned that I have issues in polling, it might be the debug prints that I have put in lot o places and used the button to send the poll data. But now I have removed all the debug prints except one place that too printing every 10 sec once , So everything is working fine now).
So can we move to the Frequency hopping and try to achieve the same in the FH mode? as our requirement is to use Frequency hopping.
Kindly share your thoughts,
Best regards,
Muniyappan R.M
Hi Theo,
We have enabled the Frequency Hopping settings on the Sysconfig and keeping the other settings same (the intervals, PHY). and did the testing,
Enabled only 2 channels for frequency hopping in both the sensor and collector side in both collector and sensor (Only for Initial testing)
From Sensor to collector, sending data every 1 second (reporting interval).
From Collector to sensor, sending data every 4 seconds
Additionally in Frequency hopping , the broadcast time is set as10seconds by default.
Running for 1 hour , 1 collector and 2 sensor devices. keeping all within 3m distance.
Collector:
Sensor data received: From S1: 2250 and S2:2306
Total Broadcast packets Tx : 237.
S1 poll data assigned : 494.
S2 poll data assigned: 331
On sensor 1 side:
Sensor data sent : 2255
Polling data received : 438
Broadcast packets received: 83
On sensor 2 side:
Sensor data sent : 2364
Polling data received : 298
Broadcast packets received: 86
So, within one hour sensor data missed count is 5 , 58 on the collector. and polling data also missed largely on both the sensors (Only selected 2 channels for the frequency hopping)
Do we need to do some modification in the configurations?. I have also asked my questions on the frequency hopping thread: https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1438395/lp-em-cc1314r10-using-frequency-hopping-mode-in-multiple-sensor-sleepy-devices-network
Note:
I have spoke with our team to remove the broadcast commands (Will set the broadcast dwell time to 0) and they agreed. So Now we will test only the one to one communication (Sensor to collector and collector to sensor) as we tested in the NBCN mode.
Similarly we will increase the Collector to sensor data time to 10 seconds i.e Keeping polling interval as 2000 in the sysconfig but assign the data from collector application every 10 seconds once.
So Will test further with this configuration. 
Kindly help us to get the good performance.
Regards,
Muniyappan R.M
Hi Theo,
Further testing with below configurations,
1 Collector and 2 x Sensors. All sleepy devices.
ETSI - FH mode - 5Kbps.
Broadcasting disabled.
Selected only 2 channels for hopping.
Reporting Interval - 1 second.
Polling Interval - 2 seconds
Test duration: about 1 hour, (One of the Sensor board went to unknown state before closing the testing - LEDs are solid and CUI also not working -> Might be a hardfault)
From Sensor to collector, sending data every 1 second (reporting interval).
From Collector to sensor, sending data every 10 seconds.
Following are the observation:
Collector:
C: [Addr:1, BC:0 SD:4394 Poll:441] Ts:5393915
C: [Addr:2, BC:0 SD:5335 Poll:423]
****************************************************************************************************************************************************************
Sensor 1 -> last valid log, (Board not in the running state , Hardware issue or Hard fault state)
S[1]: [BC:0,SD:4385,Poll:429] Ts:4519826
****************************************************************************************************************************************************************
Sensor 2:
S[2]: [BC:0,SD:5342,Poll:419] Ts:5689429
****************************************************************************************************************************************************************
So in 1 hour, no of Sensor data lost on collector side,
From S1 - No packets (Assuming All packets received before it goes to the hardfauld state).
From S2 - 7 packets.
S1 lost 10 polling packets. (Before going to the hardfault state.)
S2 lost 4 Polling packets.
Looks some improvement after removing the broadcasting and sending Collector data every 10 sec.
Kindly add your thoughts.
Kind Regards,
Muniyappan R.M
