Automated GSP-1620 Configuration for User Devices
It is fairly easy to implement custom data interface configurations for Globalstar devices. For example, a GSP-1620 (or a GSP-1600) can be configured to have a default bootup port speed of anywhere from 9600bps to 38400bps (default) to 115200bps. In addition, it can be configured via the AT+IPR command to operate as slow as 300bps. On the other hand, the GSP-2900 can only operate at a port speed of 19200bps. In addition, the data parity settings, presence/absence of DSR, and other functionalities may differ between customer equipment. Therefore, we believe that it is “best practice” for a general-purpose digital controller board to be able to detect and adapt to the capabilities and characteristics of the attached Globalstar communication device.
If an integrated product is useful to the market, it will be used by a wide variety of users, with a range of modem interface requirements, corresponding to the wide range of connected devices. Rather than developing multiple product versions, the smart integrator will design his device so that it will automatically adapt to the interface characteristics of the customer equipment, and also automatically adapt to the interface characteristics of the Globalstar device (e.g., GSP-1600, GSP-1620, GSP-2900). We recommend that the baud rate of the controller board (or other peripheral) should be made flexible. Upon power-up, the device should use an auto-baud process to determine the data port speed of the connected Globalstar device. The device should start its autobaud search with the last successful data port communication speed. Once the product has determined the data port speed of the modem, it should use the (Hayes-standard) ATI command to determine what type of Globalstar device it is connected to (201=GSP-1600, 205=GSP-1620, 203=GSP-2900). The product should then configure its communication parameters accordingly (baud rate, SMS functionality, presence/absence of DSR). If the automatically determined configuration is different than the last successful configuration, the product should connect to a land-based maintenance server and report on the current settings so that the server will have the correct information. This is especially useful when a ground-based server must contact the remote modem and must therefore know how to communicate with the remote modem, whether via SMS or asynch data call.
Although the above suggestions may require some additional software to be implemented into the product, our experience indicates that this level of automated configuration and enhanced functionality will dramatically reduce the number of trouble calls.