SimpliciTI weak points

Thank you for your comments.  The SimpliciTI team does appreciate them.  Discussions like these will only help to improve SimpliciTI alltogether.

That said, SimpliciTI does have a few warts, some of them are by design and some are simply errors.  Whether or not these issues are bugs or features will, of course, depend on your point of view.  In general, SimpliciTI has been implemented as a stripped down stack by design for two main reasons.

1. SimpliciTI was intended to be an acceptable primer stack for people new to working with packetized radios.
2. SimpliciTI was intended to work as a basis for development of proprietary cusotmer systems.

With respect to 2 above, it has become evident that not everyone wants to take over control of the complete software library for each product.  We are currently working on ideas to help customers manage this.

As to your direct points...

1. There is no mechanism to modify the CONSTATE_JOINED from the existing SimpliciTI API.  However, I don't think this is the appropriate thing to do based on your scenario.  If the ED has succusfully joined a network, then it will have a copy of the LINK_TOKEN for that network otherwise it would never have identified itself as having joined the network.  Thus if you fail to link after joining, you merely need to re-attempt the link as the LINK_TOKEN should be valid for the lifetime of the network having previously joined.
2. You are correct, there is no mechanism to invalidate the Link ID's associated with a link being torn down.  This is partly because the allocation method for Link ID's does not keep a complet table of allocated and not allocated Link ID's.  Instead, a simpler approach was chosen in which every new link established uses the next logical Link ID up to 255.  Yes this has been a limitation for some people in the past.  Your code to invalidate the Link ID's is one solution.  Your use of the word "crawl" alludes to the time it takes to properly manage the Link ID table and this was merely one trade off we chose to make.
3. Calls to SMPL_Init should reset all of the system or guard against it happening more than once.  This is because you can have multiple links on a single radio.  You wouldn't want to clear out the entire link table if you are merely trying to unlink one link.  I would consider a seperate operation to enable reinitializing the system rather than a blanket policy of allowing it anytime a link is torn down.  It just seems risky to me.  However, there certainly can be times when it is appropriate to completely re-initialize the radio and up to now, we have simply suggested resetting the processor but I know this can be problematic if user application code is not compatible with this policy.
4. This is a pathological quirk of the linking process within SimpliciTI.  In some cases I have know clients to utilize this to allow their ED's to be completely powered down rather than merely go into low power mode.  However, there are plenty of use cases where this cannot be guaranteed to work and in those cases an inadvertent loss of power by an ED can destroy the ability to reconnect with that node unless the entire network is restarted.  Since we have some people who view this as a feature and some who view it as a bug we now have some legacy issues with finding a valid correction for it.
   In general, if you only set up one link from an ED to an AP or there is only one link setup in a P2P network between two nodes, then you can depend on this working if the device that issues the link request (i.e. call SMPL_Link) is the one that powers down.  If the device calling SMPL_LinkListen fails, the entire network must be power cycled.

I doubt the above is exactly what you were looking for, but since I cannot envision every possible network application for which SimpliciTI will be applied, I cannot guarantee it will work for all applications either.  There are other issues as well such as the limited number of nodes a network can support and also the limiting number of Link ID's available regardless of whether or not you can recycle them.

I would welcome continuing this discussion as well as invite others to chime in with their experiences using SimpliciTI.  Please feel free to include Pros along with and Cons as it is always good to see we are actully making good choices as well.

I would like to express my appreciation for your calm descriptive statements regarding how SimpliTI has limited you as this is the proper form for discussing how to better SimpliciTI overall.

For those of you who wish to simply vent, please find another forum first, then after you have calmed down, please come back and explain SimpliciTI's limitations in full detail.

Thanks and regards,

Jim Noxon

Thank you very much for such a detailed description. For me this is very usefull. I do not want to complain. I just want to understand how SimpliciTI works and how I can solve my task with it. I'd like to apologize that my view is only limited to one scenario and my ideas my conflict with other use-cases.

Just a few questions to clarify things to me.

ad 1. You suggest to issue repeated SMPL_Link from ED to establish the connection properly. So this is probably then only a limitation of AP as datahub example, that is requiring Join to be followed LinkListen. AP may LinkListen periodically without bindings to Join. The only problem is then that LinkListen is a blocking call and this will limit the AP other functions if it periodically listen for link, without previous Join. To me my solution looks like a good trade-off  for fail to link policy. The AP discards the Join and ED that does not receive a Link  tries to Join again.  (Actually ED in my case is repeating SMPL_Link with random delay until the delays exceed the time defined in LinkListen). If it has any drawbacks - like there are accumulating "joins" somewhere, I'd like to know them.

ad 2. This limitation does not hit me hard, as the number of EDs is reasonable so far and I can manage the LIDs. I understand it may be not the best approach for larger networks. It would help, if Unlink issues at least some callback flag, that would trigger this clean up (similar to Join), so it does not need to be run periodically, but I do understand this would require to extend the callback functionality. The best would be of course to get LID in callback on unlink.

ad 3. Solution I have seems correct to me. I've added another parameter to SMPL_Unlink, that says I want to completely reinitialize stack on next SMPL_Init or just disable this particular connection (the parameter sets or resets sInitDone). I also have another function that only re-initialize RF by calling MRFI portion of SMPL_Init. This is probably what you meant as separate operation to reinitialize?

ad 4. This one makes me worry. If I have star network with one AP and many EDs, each ED having only one link to AP, nothing else, then in this case there is no problem as the only one that issues the LinkListen is AP, right?

In vice versa case - EDs are still powered, but AP gets reset in a star network case. To detect that AP does not receive ED packets any more, one may issue a SMPL_SendOpt with ACKs. If ED does not receive response from AP with reasonable misses, then it calls SMPL_Unlink, that disables link on ED, but is ignored by AP and tries to join again.

I am glad this discussion helps both sides.

There is nothing you need to apologize for.  Open discussions like this are constructive and therefore a good thing.  It is my responsibility to contrast your suggestions against the larger community of SimpliciTI users.

As to your questions...

1. There are no "Accumulating Join" issues that I am aware of.  The Join request merely returns the appropriate Link ID token for the Linkee to use.  It is the CONTEXT_JOINED on the Linkee that limits multiple join requests.  There are several things that could be done differently or better both within SimpliciTI and also using the example code you reference.
   
   Within SimpliciTI, the only network application which executes the call back function is the Join application.  It would be nice to have the Link application also execute the call back function but then we have the issue of determining if the call back function is being entered because of the Join or the Link request.  It could be argued that the call back function should be called for all applications (user as well as network) but this could also be considered an over-complication of the system.  It really depends on what you are trying to accomplish.
   
   As for the example code, the AP sees a Join request as a need to enter the link listen state.  If this fails, then as a fail to link policy the ED could send a broad cast message requesting a link window be opened and when the AP gets this message it could increment the Join semaphore thus allowing the link listen window to only be opened when appropriate.  This would alleviate you issue of the blocking nature of the link listen window being done unnecessarily.  Slightly more complicated but no need to modify (and continue to do so for future releases of) the stack.
2. This again alludes to the possible need for the call back function to be called by all of the network layer applications not just the Join application.  It would provide the user some additional insight into what events are happening within the system.  At this point I'm not sure what the best approach would be for SimpliciTI.  This is definitely something on the ToDo list but when and how has yet to be decided.  Maintaining legacy operation is a huge part of that process.
3. Yes, having additional parameters to the unlink function is one way to manage this.  Probably if it were to actually be implemented, it would most likely take the form of SMPL_UnlinkOpts just as SMPL_SendOpts provides additional arguments allowing legacy operation of calling SMPL_Send without them.
4. Correct.  As long as the AP is the only one issuing the link listen, and all the ED's have only one connection to the AP, then in this special use case, the ED's can power down and up all they want and it will appear as though they have statically re-commissioned the link to the AP automatically.  However, if the AP ever loses power, all ED's must go through an actual Link process if they wish to talk to the AP again.
   
   Your solution to the AP losing power appears to be a viable solution to me.  I cannot see any reason this wouldn't work.  However, I am not all seeing so bear that in mind!  :-)

Adam Pribyl said:

I am glad this discussion helps both sides.

Me too!

Jim Noxon 

Thanks for the idea with ED broadcast to open the LinkListen window. This sounds interesting.

I understand the need to maintain legacy operation (i.e. backward compatibility) is a huge chunk of work, but to be honest - SimpliciTI is open source (in its way). This is not a closed, precompiled library, where one has to maintain backward compatible behaviour. Declaring SimpliciTI 2, that would solve some of weaknesses in some incompatible way, would be OK for me. I am not going to reprogram the thousands of devices having my FW just because a new SimpliciTI realease is out anyway. What I am trying to say is, that I do not see a legacy operation of new versions of SimpliciTI as a priority. Everybody can maintain his version - that is what is open source about. As I said - just my use case

Thanks again for your time and effort.

Adam Pribyl

Adam Pribyl said:

SimpliciTI is open source (in its way).

Well, yes and no.  It is provided in source form but the EULA limits its use to TI radios so it is still owned by TI.  Slightly short of true open source ideology.

There are additional problems with backward compatibility beyond merely keeping a copy of the currently used code.  SimpliciTI is provided as an API and if the API should change significantly, utilizing the update could potentially address bug fixes but at the same time generate bugs from an existing users application code as the intended operation of the called API function may no longer operate the same way.  Also, there is the issue of changing the packet format to one which would confuse older systems using an older version of SimpliciTI.  Such generational interoperability can be a make or break issue with some companies.

SimpliciTI 2 is a reasonable approach but we would still need to at least maintain bug fixes for SimpliciTI 1.  Something similar to how Microsoft has maintained patches for XP long after they were shipping newer operating systems.  This too requires resources.

I guess it depends on how much you depend on the SimpliciTI source library to work without error.  If you assume it is merely a starting point for your code development and the final product code version has few vestiges of the original drop of SimpliciTI in it, then probably not much of a problem.  If you would like SimpliciTI to be a turn key solution then backwards compatibility can be a significant concern.

Jim Noxon

Jim, could you please post a link to the SimpliciTI EULA? Is there some kind of nice PDF of that? Thanks a lot!

Dear Adam pribyl,

you are saying that,  If ED has bad signal, it may Join but not Link. What is the reason behind this. according to me radio sends packet, what is the relation of packet signal strength respect to join and link.

Regards

Shijo Thomas

Dear Sir,

If ED has bad signal, it may Join but not Link. What is the reason behind this. according to me, radio sends packet, what is the relation of packet signal strength respect to join and link.

Regards

Shijo Thomas