Hi,
My organisation are building up a prototype to test if the CC1101 transciever module can be used in our final product. We need to build a fast frequency hopping system. We were quite disappointed that there is only little help about implementing frequency hopping on the CC1101.
We are using the fast calibration method for frequency hopping, i.e. saving all FSCAL1 - 3 values and then just writing them to the Transciever everytime a frequency is hopped. However there seems to be something which we are overlooking, because it cannot work.
Can somebody tell me the exact procedure to do this procedure?
Thanks in advance.
Simon
Wow, no answer? Got the same question regarding the CC430 (same radio as the CC1101). CC430 Spec says it can do FHSS but with some heavy explanation on how.
Any other help here? Thanks.
Hello John,
SimpliciTI 1.2 has a Frequency Hopping implementation.
Simon,
How fast do you want the FHSS to run, how many channels are you looking for?
This will help me frame my answer.
Regards,/TA
---------------------------------------------------------------------------------------------------------Please click the Verify Answer button on this post if it answers your question.---------------------------------------------------------------------------------------------------------
Simon, thanks for the reply.
I'm only doing about 50 samples (@ 16bit) per second using only 5 packets each (max). It's a control signal and not audio. I was thinking about how I would implement (ignorance disclaimer here). I would scan many channels for the top 10 RSSI values, share the pattern with these channels, and hop to the pattern. If someone got lost, maintain a fixed channel to pick it up... or something like that.
My delayed response was because my eMail wasn't being monitored (Outlook just stopped using this one???).
Thanks,
John
John,
I recommend using a timer to setup a schedule for each burst of data and if you have a predefined hopping pattern (easily done by storing a table in Flash) you will get a very simple system that works very well.
what i am saying is that SimpliciTI might be overkill for what you trying to do.
Seems easy enough, but I'm sure there are some basic error and recovery process I should use (ie, how to recover communication, what if some channels become repeatedly weak (move to a new set?) and so on. I'll look through the SimpliciTi as an option, but a flowchart on basic hopping would be ideal.
Which MCU are you using? I might have some sample code that you could start with.
/TA
I'm using the CC430F5137.
Here is a demo that I have written for doing frequency hopping on 50 channels using a CC430 (the standard development kit)
All the exiting code is in "TRX_ui.c". This demo just sends "random" data back and forth and count the errors.
It is compiled in IAR, but it also works in CCS.
Regards/TA
8510.TRX_demo_CC430.zip
Oh cool! I assume the Radio core and the 430 interface (interrupts and stuff) are pretty much the same as with any CC430 (we actually migrated all our code from the 6137 to the 5137 - so we're getting used to the differences).
However, we're challenged by a problem where SmartRF Studio parameters (exported) don't work with our SW (simple protocol, fixed channel). But that's another question and we may need help from the community there as well. We have a very sharp programmer on this, but we're all new to TI (he's more of a driver developer at Intel and not so much an SoC developer).
Thanks for the sample code!!!
If you are having problems with the SmartRF Studio register exports, you may be missing some registers that were changed but not exported. I am not sure how the default export file is created, but when I compared it to the file supplied with SimpliciTI, there were differences. So I ended up adding registers to the export list to match what was in the SimpliciTI header file.
Tim Barr
Multitech Systems Inc
Thanks Tim, bonus info! We have plenty to chew on now.
Tim,
I wrote the original code based on the basic "LED Demo" (Less than FIFO, Fixed Length). I assume all the RF functions would be standard (like Strobe and stuff).
Our prototype was a Chronos talking to the 6137 kit and it worked. When we migrated from the Chronos (6137) to our board (5137), my same code in the new 5137 couldn't talk to the 6137 Kit, and definitely transmitting. However this odd couple could send packets through SmartRF (stronger signal too). Doesn't make sense...
So we were trying to get the settings from SmartRF to work with our code, but not much luck. So next we'll look to verify nothing was missed in Reg settings from SmartRF as you mention. We plan on getting to the frequency hopping part once we get through this anomaly.
Just sharing our background in case this scenario rings a bell...
The RF section, the MSP core of the CC430F6x and CC430F5x is the same and the code from a F6 will run on F3 by a simple re-compile with new headers.
I think the like issue you are having is that your new board has a new RF XTAL (maybe partnumber, loading caps, traces) and the actual frequency you end up operating is wrong.
If you have a spectrum analyzer this is easy to check, but if you do not have a spectrum analyzer please increase the RX filter bandwidth of the receiving device until it works. The you can poll a register called FREQOFF_EST (See page 728 of the CC430 User Guide (http://www.ti.com/lit/ug/slau259d/slau259d.pdf))
You may have nailed it. I was using a pair of 27pF for my loading caps on the 26MHz crystal (instead of 15pF as with the kits). The BOM for the 5137 Typical circuit showed 27pF in the table with a note on the calculation which threw me off. I don't know what the 27pF means - maybe total capacitance?
Got some new ones order and will try your other suggestion to widen the Rx "safety net".
Thanks again!