• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 8 subscribers
  • Views 4284 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2510, GFSK, Manchester

J. Todd Elson
Prodigy 130 points

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).

  • 0
    TI__Guru**** 317180 points

    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.

  • 0 in reply to TER
    Prodigy 130 points

    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.

  • 0
    Prodigy 130 points

    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).

     

  • 0 in reply to J. Todd Elson
    Prodigy 130 points

    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).