RF2500T Peer to Peer demo question

No? Nobody has worked on this at all or can give me any insight? Not even Jen-Michael Gross has anything to say?  Wow! Now I know I'm in trouble.

Maybe it's because I've recently added a picture to my profile and everyone is jealous of my looks.

Anyway, I am still working on this. To be more specific there is a section of the code in main_UART_Bridge.c in the LINK_TO version where it is waiting for a connection, it is waiting for SMPL_Link(&LinkID) to return a value of SMPL_SUCCESS. It works fine initially but if the power is cycled on the LinkListen end it can't recover the connection. Essentially it needs to re-enter the  waiting for connection loop when the link is lost.

 

I'll continue to try some stuff, maybe I can just move that loop down into the main running loop.

 

Mike

Mike,

I haven't touched the P2P mode on the RF2500T in a while, so won't be able to give you a quick answer without digging into the project. However, I cross-posted this question over in the SimpliciTI forum as there are more experts on the subject over there. Hopefully their Jens-Michael will chime in.

http://e2e.ti.com/support/low_power_rf/f/156/p/90585/314244.aspx#314244

 

Regards,

Dung

Michael Unger said:

Not even Jen-Michael Gross has anything to say?

The various peripherals (RF, CC, BT and even USB) are nothing I have used so far. So while I may have something to say, chances are that someone else has more important things to say. And since my spare time in office has drastically shortened lately, I usually skip this kind of questions when scanning the board. As well as problems related to demo software, CCS/IAR specific problems or setting up any MSP FET for Windows or Linux or MAC.

But since you asked...

No, it's not your picture. At least not for me. I've seen worse ones, including some with myself as the subject. :)
I just thought that there will be several people around who already worked with the RF2500 and the Peer-to-Peer demo and therefore can help you way better as someone who neither had one of these devices nor has a copy of the demo code or the time to look into it.

Indeed, a peer-to-peer connection can be a tricky thing. We had similar problems in our setup until I implemented sort of an idle timeout. We too have usually one sender and one receiver. If the sender fails and comes up again, fine. The sender will try to establish a new link, the receiver will detect that it is the same one, and all is fine. But when the receiver reboots, the sender will continue sending, the receiver will not know wha tto do with this linkless incoming data and the link breaks.
So our receiver now sends a signal periodically too on this link. If the sender does not receive this signal for some time, it will start from the beginning and try establish a new link.

It's basically the same you encountered and solved more or less the way you came up with too. Except that our concept ha slong been extended to a star-like structure (receiver being an Access Point for meny sensors) with time-slice mechanism forconnecting up to 64 sensors on the same RF channel without disturbing each other. But the need for resynchronizing all ends if one resets, and the basic concept of using timeouts and logins are still the same even if there is no dedicated 'link' between access point and sensor anymore. (like switching from TCP to UDP)

Dung,

Thanks a lot. Obviously the SimpliciTI forum is where I should have posted in the first place. Sometimes, the multitude of forums can be confusing.

 

Jens-Michael,

I am, of course, just teasing you. I, like many others, appreciate your regular contributions to the forums very much. Thanks for your insights, I will continue to go down that road. Right now I am just doing a peer to peer type demo but eventually we are going to want to have just one receiver with many sensors. Sorry for spelling your name wrong.

Mike

Michael Unger said:

I am, of course, just teasing you

I thought so, but it's good to have it confirmed :)

Michael Unger said:

Sorry for spelling your name wrong.

No problem. It has enough redundancy to not being confused :)

Michael Unger said:

Right now I am just doing a peer to peer type demo but eventually we are going to want to have just one receiver with many sensors.

Indeed, except for few applications, a fixed pairing of two endpoints is not the best approach if the connection is done on a shared media such as RF. Imagine having a different phone for every person you want to talk to (well might be handy if you want to separate wife and girlfriend(s)). Implementing it as a starting point for testing the low-level functionality of sensors and connection is a good starting point (or for a techdemo), but then you might soon arrive in a dead end. Keeping the later expansion for a point-to-multipoint protocol in mind when developing the 'base version' saves a lot of reworking later.

Hi Mike,

Did you by any chance able to resolve this issue?.. 

thanks,

Lanz

Leo,

Thank you for your reply, I haven't looked at this in a while but may get back to it at some point.

Best Regards,

Mike