You may experience difficulty when placing dial-up data calls to some parts of the world, including (but not limited to): The Middle East, Southeast Asia, China, India, Russia and Taiwan.
The end-to-end data call quality and probability of connection is governed by the ability of modems at the Iridium gateway to synchronize with modems at the termination location.  Modem synchronization is directly impacted by voice compression that is used by international telephony carriers.  International telephony carriers typically compress the analog speech, and consequently modem tones, to reduce their bandwidth requirements for carrying calls.  This compression can alter the modem tones resulting in reduced connection speeds, dropped connections, or no connections.  PSTN connection quality is not unique to Iridium data services.  The same problem would exist if you made a data call to these locations from your home computer.

To improve connection speed and reliability when dialing your ISP, it is recommended that you choose an ISP access number in the Phoenix, Arizona area if possible (area codes 602, 480 and 623) to reduce the PSTN distance between the Iridium gateway and the ISP location.  Also (and outside this area), please make sure that your ISP supports 2400 baud rate connections.

To verify the software version on a 9505/A, enter *#91# on the handsets' keypad.
To verify the software version on the LBT (internal to the RST box) enter *#91# on the keypad of an Intelligent Handset.  This is also available on the Status tab of the Beam Management System (BMS) software (in the ‘LBT Firmware’ field).

Some of the earlier, original versions of the 9505A handsets do not support certain commands that the SatDOCK utilises, and require a flash upgrade by Iridium. Any 9505A handset with a part number of SUG0088MH and an IMEI beginning with 300014 should be sent back to Iridium for repair / replacement. The cost of the repair / replacement is free, however the customer is responsible for shipping costs. Contact your service provider to arrange this.

If your handset does not fall within the above description, consult the SatDOCK Usermanual for more troubleshooting tips. (Download the SatDOCK Quick Start Guide Here and the SatDOCK Usermanual Here)

Before an SBD can be sent, the LBT (in the Beam Device) must be provisioned for data. This includes Data being activated on your account and a destination address setup for the SBD to be sent to.

The destination address can be set to a specific IMEI number, an email address, or a direct IP Address / port. – Your service provider will be able to assist you in provisioning of your device.

Refer to the Beam Data Guide for more information on sending SBD's.

• Placing at least one, and up to a total of four, IMEI(s) into the subject line of the email identifies the destination ISU(s).
• o If there is more than one destination IMEIs then list the additional IMEIs on the subject line separated with a single space between each IMEI.
• White listing may be used to restrict the originator of MT-SBD messages to particular IMEIs. This restriction will fork for email and Direct IP.
• The message must contain a properly formatted sender (“From:” address), otherwise the message will be dropped by the GSS.
• The data message to the ISU must be carried as an attachment to the email:
  • The attachment name must have a ‘.sbd’ file name extension: E.g. ‘importantdata.sbd’
  • File names must be 80 characters or less. (Including the .sbd extension.)
  • File names are not case sensitive.
  • The maximum size of the binary message (not the Base64 version) is ISU specific and is between one byte and the maximum MT message size stated in Section 1.5
  • The GSS will reject message sizes that are too large for a particular ISU type.
• The attachment must use standard Multipurpose Internet Mail Extensions (MIME) Base64 encoding as defined in RFC 2045.
• Multiple messages may be queued by a single email by including the additional separate attachments in the email message, subject to the maximum number of messages permitted in the queue.
  • Note that if one of the attachments has an incorrect extension (.sbd), while others are correct then no error indication email will be sent.
  • A single email with multiple attachments creates a MT-SBD message fro each attachment. In other words – one email with ten attachments creates ten entries for the destination ISU.
• The message body plays no role in the message transfer process; any information contained in the body will be discarded.
• A maximum of 50 messages may be in any ISU’s queue at any one time regardless of whether they where sent as an individual message with attachment or a single message with multiple attachments. The GSS will reject any message over this limit.

The maximum recommended signal drop from the satellite antenna to the Iridium transceiver (either in the 9505A phone, 9505A LBT, or a Beam product) is 3dB. 
Cable: For optimal performance, we recommend using the shortest length of cable and the fewest number of connectors possible.  You must ensure that the cable used conforms to this.  An example of attenuation for RG213 cable is 0.33dB per metre @ 1.6Ghz, therefore the maximum cable length is 8m (allowing up to 0.5dB for cable interconnections).  LMR400 cable in comparison has a better attenuation figure of 0.18dB per metre.Satellite Line Of Sight: For best performance, the user’s antenna must be able to “see” the entire sky from approximately 8 degrees above the horizon. Nearby tall buildings or similar structures, heavily leafed trees, mountains, etc. can degrade performance as they block the signal between the equipment’s antenna and the satellites. Having a completely open view of the sky plays a very important role in maximizing performance, as the Iridium satellites cross the sky from horizon to horizon during a call connection.A good rule of thumb is that all surrounding obstructions should be lower than the top of a fist, which is extended at arms length, and the bottom of the fist placed on the horizon. Note that Iridium performance is immune from natural environments such as clouds, fog, rain, snow, wind and smoke.

Refer also to “Assuring Quality of Iridium Service” in the Antenna Installation Guide

All wireless devices, including satellite telephones, are susceptible to RF (Radio Frequency) interference from other electronic devices. This problem is especially evident when numerous antennas and broadcasting devices are located within close proximity to each other.

A good example would be onboard a ship. It is important that certain considerations be taken into account for best performance when an Iridium system is installed.

Causes of RF Interference:
Some subscribers have contacted Iridium regarding the loss of signal quality when they operate their equipment near active INMARSAT terminals. The power with which INMARSAT units transmit can overpower the Iridium unit’s ability to properly maintain a quality connection with the Iridium satellite constellation. INMARSAT terminals are often found in the same locations as Iridium subscribers, such as harbors, airports and especially onboard ships.

The location of the INMARSAT unit’s antenna in relation to the Iridium unit’s antenna plays a significant role in determining the degree of signal degradation that an Iridium subscriber can expect to experience. All Iridium units are susceptible to this interference, regardless of the type of antenna being used.

Generally speaking, an Iridium unit, be it a handset using its integral antenna or a fixed terminal when attached to an externally mounted antenna and located within 15 and 45 meters (50 to 150 feet, respectively) of an operating INMARSAT mini-M or Standard-C terminal, will likely experience degraded performance.

Other sources of RF interference such as Globalstar units, radar devices and broadcast stations can provide interference for Iridium units, but usually are not encountered as frequently as INMARSAT terminals.

Refer also to “Assuring Quality of Iridium Service” in the Antenna Installation Guide

For more information on SIM PIN please review the following guide

• SIM PIN Configuration guide

For more information on SIM PIN's please review the following guide

• SIM PIN Configuration guide

Yes, The user must use “AT Commands", through the data port.  The AT commands use the standard GSM ‘PDU’ format

Available for download here

The Expiry Period determines how long the Iridium Service Center will attempt to deliver a message before deleting it.
• The default Expiry Period is 192 hours (8 days).
• The user can change the default Expiry Period as follows (on a Motorla / Iridium handset):
- Press the ‘Envelope’ key.
- Scroll to ‘Message Settings'. Press OK.
- Scroll to ‘Expiry Period'. Press OK.
- Enter the Expiry Period (in hours), up to a maximum of 192.
• The phone will accept any value between 1 and 24 hours in increments of one hour. Over 24 hours, the phone will round down to the nearest multiple of 24 hours (1 day increments).
• If 0 hours is entered, the expiry period will be set in the system to the default period of 192 hours (8 days).

Solution 1:  Recipient phone # or e-mail address entered incorrectly. Make sure phone number was entered as 00 or +, Country Code, Phone Number. Make sure e-mail was entered with a space between the e-mail address and the message.  For a Telstra SIM and Telstra SMCS, the phone number is all that is needed, e.g. 0409xxxxxx.
Solution 2: Check expiry period.  If recipient did not turn on their phone within the expiry period, message was deleted before delivery.

Below is a table showing the compatibility between Iridium and Telstra regarding SMS'