CC1110EM433_REFDES: Optimizing FHSS for UART Bridge example on SIMPLICITI 1.2.0

Hi Ali

Unfortunately we do not have any resources that can help you with your task, but I can give you some general guidelines on how you should go along debugging this.

You say you get into a situation where data is getting missed. You need to try to narrow down if the problem I related to the UART or to the RF. By monitoring the UART lines with a logic analyzer together with the GDO signals from the radio it might be easier for you to figure out where the problem is. I have also attached a document describing several test signals that can be output to pins to help you figuring out what is going on in the code. DN114_ Test_Signals_for_debug_purpose_in_CC111xFx_ CC251xFx _and_ CC243x.pdf

It might also be a good idea to debug one thing at the time, and first get the UART up and running properly the way you want before starting to look into reducing packet size etc. to be able to reduce the hop time. I know there is a design note regarding a SimpliciTI-compiant UART driver ().

I am sorry that I could not be of any more help.

BR

Siri

Hi siri!

I am confident and i have checked it myself that if i keep the FHSS turned off from the macro,the UART Bridge functions perfectly without a single byte missed on either side...all the packets from tx end reach the receiver side perfectly one after the other even with zero ms delay between UART Packets...9600 bps equal 960 bytes per second which is what i am seeing at the receiver...As soon as i turn the FHSS on,my application goes into limbo and i hardly get 50% packets to the other side...my issue i beleive is with the management of the nwl pll backgrounder function...and i dont know what do do...i tried reducing the hop time to as low at 1 second but nothing works...please refer this issue to Mr jim nixon if possible who is the author of this fhss modification of simpliciti

Best regards

Ali

Please refer my query to Mr Jim nixon.He is the author of the fhss bacgrounder function implemented on Simpliciti

I am afraid that Jim is not longer working for TI. Have you tried my suggestion and debugged this with different signals output on the GPIOs to figure out what goes wrong? If this is only a problem when doing hopping, I would assume that it is timing related. If you for example output the LNA_PD and PA_PD signals signals and monitor then you will have full overview of when your devices are in RX and TX state. You can compare the original example that works (when monitoring these signals) to the same signals when running your code that do not work, and see if that will give you some clues as to where things go wrong.

Siri

By original example you mean hopping turned off..yes that way i am able to send and receive data flawlessly...the original example out of the box doesnt work at all the way i want to work with it...i had to remove receiver code from transmitter and transmitter code from receiver and then i was able to send and receive data flawlessly with hopping turned off...your debug signals are helpful but i have seen using the In circuit debugger that the data is not being missed at RF level...the i have used LEDs to show data activity and tx and rx blink at the same level...i suspect its the UART tx function that clashes with nwk pll backgrounder function only when i turn on the hopping..

Can Mr prashantS look into my problem please?

Best regards

Ali

Ok i will see these 2 signals with and without hopping and get back to you...in the mean time forward my issue to mr prashantS

prashantS is no longer working fro TI

Siri

Hi siri

Since everyone who could help me has left TI...:)..lol..

I managed to look deeper into the nwl pll mechanism and found out that nwk pll packet is being exchanged between master and slave frequently and that keeps the rf core busy hence my very high rf data exchange at application level is having race condition with that nwk packet exchange...the only solution to this problem is to device a nwk pll mechanism that would reduce the bidirectional nwk exchange to uni directional nwk exchange...master clock sends the pll data for syncing the slave every 1 or 2 second and the slave only receives this master time stamp and hence the bidirectional data exchange at rf level is reduced and more may be given to application layer process it uart packet exchange just like in the case of FHSS turned off...i will execute my plan and will share with community soon with results

Besy regards

Ali

Ok this is a sad news btw

Hi siri!

Yes it is a little unfortunate but since the release of CC1310,majority of the developers have shifted forward.I myself  am using CC1310 in my new designs but for some old designs i have to stick to CC1110,i am almost there and i have found the cause of the problem and will be sharing my solution once i am done testing it in near future...

Best regards

Ali