Globalstar Product Management – Technical Support

Quick-Connect for Remote Data Transmitters

 How can I design an automated remote data collection device to have the highest probability of connecting to Globalstar’s packet data (PD) system, with the quickest connect times and fastest data throughput?

ANSWER:  For the vast majority of interactive data users, nothing special has to be done to achieve very fast connection times.  If someone connects a standard Windows or Mac computer, and dials #777, they are normally connected with a fully functional internet connection in 5-15 seconds, with this small variability usually a result of where they are located, how good of a sky view they have, and which other applications are running on their laptop.  Nothing special has to be done.  So, that is the standard case.  Nothing special.

There have been instances where it has taken longer to get a connection, or where even this level of variation is of concern.  These situations almost always involve a custom processor or chip, often in an embedded system.  Embedded systems are often intrinsically different than laptop systems because they:

  • often use a custom operating system build
  • sometimes connect far more frequently than a browser laptop
  • sometimes send very small amounts of data in each session.  As a result, minor variations in connection setup time have a proportionately greater impact.
  • Since the processor does not have a full PC/Mac OS, it is often difficult to run diagnostics directly on the device and alternate troubleshooting methods must be used

We have found a combination of root causes for a microprocessor to take longer to connect, including:

  1. Problems with the location of the device, whether it has a good sky view, whether there is local radio interference
  2. Use of a product that is not Globalstar Certified
  3. Failure to randomize when calls are dialed
  4. Improper management of the power-up/power-down of the GSP-1720
  5. Failure to use proper wait times during AT communications
  6. Incompatibilities between the processor’s LCP option set, its TCP/IP stack and those of the Globalstar system
  7. Applications that are running on the processor which interfere with the network communications
  8. Serial port driver problems.  Leaky serial port.  Poor OS control of access to serial port.

There is no one single cause for problems.  Globalstar recommends the following approaches to get a view of what is happening so that the problems can be identified and resolved.

  1. Location, Location, Location.  In order to have the shortest call setup times, it is essential to position the device in an optimum location.
    1. Sky View: The device should be able to see the entire sky, from straight up (zenith), down to 10 degrees above the horizon, in all directions – North, NE, East, SE, South, SW, West, NW.
    2. No Interference: The location should have no local radio interference.  When evaluating a site, or troubleshooting a device, remember that interference can be intermittent.  Therefore, it is important to collect enough data that you will be able to see interference that happens infrequently – for example, only every 10 minutes, or only from 9am-11am and 3pm-5pm.  Likewise, when evaluating device performance, it is sometimes evident that communications problems are happening only at certain times of the dat.  Further evaluation of these time periods may reveal that these times coincide with vehicle traffic or foot traffic.  Each situation is different and should be evaluated in the context of the installation.
  2. Use a Globalstar Certified device.  It is essential to use a Globalstar Certified device.  This process ensures that the product was integrated according to Globalstar specifications, that the correct antenna was used, that the antenna cable losses are acceptable, and that the integrator understands the requirements for call randomization, and the other factors that are mentioned in this technical note.
  3. Randomization of call times. Periodic, scheduled calls should be randomized over a 5-10 minute time period.
    1. Benefits of Randomization:
      1. Randomization of the calling time will greatly reduce the probability that your data call will be at the exact same time as other devices.  This will provide the best chance of avoiding traffic congestion from other non-randomized devices on the network.
      2. The call setup time will likely be faster and you will have a higher probability of call success.
      3. This will also reduce the power consumption of the remote unit.
    2. Explanation:
      1. Many integrators do not implement randomization and, instead, schedule data connections to be perfectly synchronized with GPS time.
      2. As a result, if your device is scheduled to connect to a landline server exactly on the stroke of the hour, or every 12 hours or every 6 hours, etc., it will be competing for resources from lots of other devices that will be trying to call at exactly the same GPS-synchronized time.
    3. Solution:
      1. Select a nominal reporting time that is offset from typical “even” times.  For example, choose a nominal reporting time of 17 minutes after the hour.
      2. Insert a randomized delay into your product’s software so that it will call sometime between 1 and 10 minutes after your nominally scheduled time.  This way, each call will be at a different amount of time after the hour and it will be very unlikely that your calls will be aligned with anyone else’s calling schedule.
  4. Management of the power-up/power-down of the GSP-1720
    • In order to achieve optimum performance and reliability of the GSP-1720, it is essential to follow the recommended power-up and power-down sequence.  This will ensure that the modem memory will always contain the most optimum parameters for system acquisition.
  5. Use the proper wait times during AT communications
    1. The GSP-1720 is designed for optimum power efficiency.  Also, it is designed to operate under a wide range of environmental conditions.  Therefore, it is essential to program microprocessors to wait the recommended time periods during various phases of modem initialization, call setup and call teardown.
    2. Use either an on-board application or an external “serial tap” cable to “sniff” and analyze communications between the microprocessor and the modem AT interface
  6. TCP/LCP compatibility of the device processor & software
    1. The fastest connection times will be achieved when the device is programmed to use the same LCP configuration that Globalstar supports.
    2. The LCP negotiation phase does not have the redundancy and recovery capabilities of a TCP session.  This can lead to long delays if incompatible options are being requested or if an improper setup sequence is being used.
      1. Use packet sniffer hardware/software to sniff and analyze packet communications, especially the initial communications.
      2. Look for multiple LCP requests that elicit either no response or an invalid response from the other side.
      3. Refine the LCP negotiation to include only the bare minimum options, and to carry out the negotiation in the expected sequence.
    3.  The integrator should investigate whether the processor is trying to set up a connection based on assumptions and features which are not supported by the Globalstar Packet Data (PD) system.  If this is happening, then extra setup delays will occur because the processor will continue to ask for, and wait for, setup of unsupported options.  Eventually, the processor reaches a timeout condition and moves to the next option.  The resulting connection history is often erratic and can be baffling because it seems that sometimes the connection takes a long time to establish while at other times, when too many timeouts occur, the link is dropped without ever getting connected.
      1. The most direct way to figure what is happening in these cases, remembering that each case is unique, is to run standard packet capture software on the communications link between the device processor and the Globalstar data terminal.  Do a packet capture, starting from when your device first connects to the Globalstar router, and analyze what is happening during the initial setup of the LCP and TCP/IP protocol.  The objective is to identify all the places where the initial negotiation is hanging.  The tapping of the communication can be done in software, in the processor or with hardware, by tapping the communication stream right at the serial cable input to the modem.  If there is a mismatch between the Globalstar network setup and the processor stack, it will be easy to see because there will be multiple requests from one side – usually the device processor – with no response from the PD system.  That will tell the analyst that the processor is requesting LCP features/options which are not supported by Globalstar PD and should therefore be omitted.
      2. Sometimes the integrator finds that it is not feasible to do a packet capture on his processor, or finds that the above investigation does not reveal any obvious problems.  In this situation, we recommend a variation of the first approach, where the analyst does a packet capture on a standard Windows or Mac system as these systems connect to the Globalstar system.  The results of this packet capture will show the analyst how the Windows and Mac systems are setting up their connections.  It will show which LCP options are being requested, in which order, and the associated wait periods.  Then he can bring that info to the software coders and ask them to make sure that their custom processor is following the same setup process.
  7. Other Applications that are running on the processor which interfere with the network communications
    1. In some cases, the problem is not with processor-infrastructure stack incompatibility, but with application software that is active on the remote data collection device.  We have found that in some cases, the client processor is trying to start up some application which freezes all network communications until this application can reach some host server on the internet. In one particular case on a Windows system, the culprit was a particularly protective implementation of an antivirus/internet protection software package.
    2. This is easy for developers/integrators to figure out once they are made aware of the possibility.  The first approach is to disable all non-essential applications and see how the connection time changes.  If this yields no results, then disable all the other applications until you are left with ONLY the communication software.
    3. Sometimes after you’ve set up a connection, the TCP socket is lost. So, if communication stops while the link is still up, try dropping the socket and establishing a new one because this process is often quicker than dropping the link and reconnecting.
  8. Serial port driver problems.  Leaky serial port.  Poor OS control of access to serial port.
    1. In some cases the serial port of the processor is not well controlled, and packets and other information “leak” into the serial port at times completely unexpected by the programmer.
    2. This can corrupt the data stream and either require retransmissions, which lengthen the duration of the data call, or cause the entire data call to fail.


Additional keywords:  gsp-1600, gsp-1620, gsp-1700, gsp-1720, gsp-2900, 1600, 1620, 1700, 1720, 2900, sdvm, sdm

Written by Joseph Crowley

November 11, 2017 at 4:09 pm

Posted in Uncategorized

%d bloggers like this: