# Iridium Communications



## SBD Status Message Definition

SBDs are limited to 512 Characters



## SBD Sprint 10/29

Summary of SBD issues:

1. Need one createStatusSBD (or whatever) method that both recovery and surfaceOps call **[DONE]**
2. processConsoleCommand should be reasonably rigorous. Starting commands with a $ and ending with a LF (or CRLF) should be fine.
3. We should maintain the ability to have multiple commands in one SBD attachment
4. I think whatever Iridium method actually loads a message into the modem looks for a specific variable inside the method for the message. **[PLEASE CLARIFY]** We should pass this method the message to be loaded. ***At present we load the buffer in one action then in a separate call load it to the modem*** 
5. It would be nice to have one sendSBD (or whatever) method inside the Iridium calls that sends the SBD. This method would be called by both recovery and surfaceOps. ***I do not recommend at this changeset, its a multi-message interchange with the modem that has proven reliable in the state machines for both states, until we implement a sub-state machine method for the whole interchange, which I would do after this round of edits gets tested.***
6. Right now there's a very convoluted way to acknowledge a command was received by inserting an ACK inside a SBD status message and sending it again. Seems like a better way, assuming we can do the stuff above is to just send a short AckSBD (or whatever) with a createAckSBD method that just says something like "date,time,ACK,<the command(s) it received and processed>" or "date,time,NAK,<the command(s) it received and couldn't process>" or something like that.
7. It may be too much for right now but it would sure be nice to have one "sendSBD" method in the Iridium class that whoever needs to send a SBD can call.
8. I don't know if we can process multiple MT messages in the buffer. That would be nice. And we should check that all my if (MTStatus == 1) checks should be if(MTStatus >0) or some other more correct logic.