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
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:
send: <cr><lf>+WIND:56:Insert message to client:<ID>
receive: send: <cr><lf>+WIND:56:Insert message to client:<ID>
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:
- Fix SSI event to conform to syntax: <cr><lf>+WIND:56:Insert message to client:<ID><cr><lf>
- Add new event for missed SSI completions: : <cr><lf>+WIND:79:Missed SSI completion:<ID><cr><lf>
- 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.