• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 54 subscribers
  • Views 611 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1000: Mica2 radio (CC1000) programmed to send at 5 second intervals, is sending at a faster rate

Asma Khalil
Intellectual 390 points
Part Number: CC1000

Hello,

I am testing the flooding time synchronization protocol on the mica2 hardware which contains the CC1000 radio and the atmega128L processor. I have it programmed using the open source code from github tinyos-release repo, that is where the settings of the CC1000 radio have been set. It appears as though all the settings are set properly however the only thing i can see is that they have the crustal frequency set to 8 MHZ instead of the recommended freq of 7.37 mhz.

My problem is I use the App RadioCounttoLEDs from the tinyos repo which runs a millisecond timer and I have indicated it to fire every 5 seconds (5*1024 = 5120 ms ticks). However, my device is sending at a much faster pace and is not very consistent. I measure timestamps of consecutive packets being sent and the difference is approx about 4.3 seconds +-0.5 seconds when it should be 5. I was wondering if this is because of the hardware, would it do that if it is not set at the recommended setting or is this due to a setting (software issue)?

Thank you so much!

Asma Khalil

  • 0
    Intellectual 390 points
    Oh also, when i measure my byte transmission time for the same device (a.k.a the time it took to transmit 1 byte , 8 bits, at the rate of 19.2 kbps that it was set at with the program) it also appeared to be sending at a faster rate (measured about 21.8 kbps instead of 19.2k) could this also be related to that issue? keeping in mind this would include encoding/decoding times, so is it possible that because of my radio clock running faster for some reason (not sure if there is a way to put that 'crystal freq offset' into a percentage so my numbers would make sense - please if there is let me know!) so that affects my timestamps taken every byte transmission so it would show a value shorter than the supposed 19.2kbps its supposed to be set at? like does this increase affect everything with the same 'offset' or is this not normal to happen?

    Thanks!!!

    Asma
  • 0 in reply to Asma Khalil
    TI__Mastermind 39860 points
    MICA2 is not a TI product and although the module includes the CC1000 we do not know the finer details.

    The data rate is derived from the crystal frequency and if there is a mismatch between the programmed crystal frequency and the actual crystal frequency the data rate will also be off. That said, if the crystal frequency is off by X ppm the carrier frequency will also be off with X ppm. Measure the carrier frequency and if this is only 10-20 ppm (say) off from the ideal the crystal error does not explain the offset in baud rate.
  • 0 in reply to Sverre
    Intellectual 390 points

    Hello,

    Thanks for your response!

    So I'm wondering now, am I able to do this same comparison of the crystal freq and data rate? aka if they have programmed at 8 MHZ and recommended is 7.37 MHZ, which calculated a ppm of 85482. now using this same value and the data rate of 19.2kbps, I would calculate that this data rate could be 19.2kbps +/- 1633 bps, this would give me an upper data rate of 20.8 kbps which is very close to the 21.8 kbps I calculated from my time-stamps, would this be valid? Or do I still need to physically measure my actual carrier freq vs the one I programmed it at and see if the ppm agrees with the 85482 ppm I calculated for my crystal?

    Thank you so much!!!

    Asma

  • 0 in reply to Asma Khalil
    TI__Mastermind 39860 points
    In C1000 you program a frequency range. I assume they have used 6 - 8 MHz range based on your post (i.e. MODEM0[1:0].XOSC_FREQ = 1). If you then use a 7.3728 MHz crystal you get 19.2 kbps data rate assuming MODEM0[6:4] = 5. If the crystal frequency is 8 MHz (say) the data rate will change by a factor 8/7.3728.

    In my previous post I guessed they have used a 7.3728 MHz crystal. In that case the ppm error will be the same for the carrier frequency and the data rate.

    If my assumption was wrong and they have used an 8 MHz crystal the data rate will be 20.8 kbps. Since I have no idea what RX FREQ and TX FREQ are used I cannot comment on what the expected TX frequency is, but if they used SmartRF Studio to generate the FREQ words with 8 MHz crystal the carrier frequency error will be in the ppm range. If the settings were generated with 7.3728 MHz crystal as input and they actually use an 8 MHz crystal the carrier will be off by a factor 8/7.3728.

    Maybe you can find the crystal frequency by inspection? read the top marking on the crystal casing.