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.
I have two CC2510-based devices communicating with each other using GFSK at 250 kBps. I'm not testing in an anechoic chamber, but the environment is fairly RF-quiet. The RSSI values are about -45 dBm. Bit error rates are decent but not great considering high RSSI--1% or so. When I enable Manchester, the error rate drops noticeably. Is there an explanation for this? I would rather not drop my throughput by a factor of two, and would like to know if there is another way to improve the error rate (mod rate, mod type, etc).
What are the data you are sending? If the data has few transitions the tracker could possible loose sync. Manchester coding introduces a lot of '0' to '1' transisions and hence the tracker have a easier job.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to TER:
Generally the data has plenty of transitions; in one verified case a byte 01001110 was received as 01001111. The last bit was flipped at a location where there was a transition after three consecutive ones, I am surprised this would be a problem. I agree with your point in general, and Data Whitening would probably help in that case. I might try it anyway. I would like to solve the problem some other way besides Manchester because I take a 2x hit on my data throughput.
We improved performance significantly by:
1) Correctly calibrating the frequency synthesizer (fixed a bug in the code, it was calibrating for some frequencies in our hop table, but not most)
2) Implementing frequency offset compensation; the device calculates an offset from the nominal frequency for incoming data, but does not apply the offset to outgoing data unless you write the offset (FREQEST) into a register (FSCTRL0.FREQOFF).
In reply to J. Todd Elson:
And when using frequency offset compensation, only use the offset when the data is qualified (carrier sense, preamble quality threshold, sync word, packet length, and CRC). Otherwise, the compensations are inaccurate and the radio ends up so far off in frequency that it stops communicating (sometimes it will recover if the input power is high enough).
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.