AnsweredAssumed Answered

SSI implementation issues

Question asked by manninen.jarno on Oct 19, 2015
Latest reply on Oct 20, 2015 by manninen.jarno

I think that there are some issues with the SSI implementation that I would like to point out. I hope that you could post this forward to the firmware developers of the module.

First, the SSI WIND event does not conform to the specified asynchronous indication format(UM1695, rev.5, page 4), which is

<cr><lf>+WIND:<number>:<descriptive string><cr><lf>

Instead the generated WIND event is

<cr><lf>+WIND:56:Insert message to client:<ID>

So in the other words the ending <cr><lf> are missing. This looks nice and fine for human operator on the console, but will require workaround the line parser which I would like to omit.

Second, if the response is not sent in time the device sends notification of this using just plain text “TIMEOUT OCCURRED!. It would be better if the initial indication was formatted correctly and the timeout indication would be another WIND indication. Once more this requires special handling which is not good.

Thirdly there is a possibility of probable race condition here. SPWF expects the host to send the response after sending the WIND indication. However at the same time the host might be starting some AT command or pushing data to the device. This might result in some wrong data being displayed on the SSI replacement. Consider following:

                                                                                                                                                                                                                                                                                               
           

SPWF

           
           

Host

           
           

send: <cr><lf>+WIND:56:Insert message to client:<ID>

           
           

send: AT+S.SCFG=something,whatever

           
           

receive: AT+S.SCFG=something,whatever

           
           

receive: send: <cr><lf>+WIND:56:Insert message to client:<ID>

           
           

display:  AT+S.SCFG=something,whatever

           
           

send: Data for SSI

           

So, instead of expecting data directly, the SSI replacement should be operated via AT command, say AT+S.SSIR=<data for response>, this way it handling of SSI response data would be explicit.

To summarize I propose following changes:

       
  1. Fix SSI event to conform to syntax: <cr><lf>+WIND:56:Insert message to client:<ID><cr><lf>
  2.    
  3. Add new event for missed SSI completions: : <cr><lf>+WIND:79:Missed SSI completion:<ID><cr><lf>
  4.    
  5. Make SSI responses explicit via at command: AT+S.SSIR=<data for response>

I believe that this would make use of SSI features much easier on the host, as need for special cases and workarounds would be eliminated.

Regards,
Jarno

Outcomes