SDT 5000 User Manual
Document MBUD-0109v11
The valid values are: CONTINUOUS, POLLED, and STANDBY. The default value is:
CONTINUOUS.
8.2.1 CONTINUOUS MODE
During continuous mode, the SDT 5000 processor and transceiver are always powered and the
unit can transmit or receive messages over the satellite at any time. This mode will result in a
continuous current draw from the 12V power source and is not recommended for power-limited
applications.
Pros: Able to receive unsolicited host messages, lowest message latency.
Cons: Highest power consumption.
8.2.2 STANDBY MODE
In Standby mode the processor is active but the transceiver is off. Standby mode is generally the
most power efficient mode that does not lose RTU data. The SDT 5000 will draw less than 20
mA while sleeping. The total power consumed will depend on the duty cycle of sleep time to
wake time. During the sleep state, the unit is in a low power state and satellite communications
are shut down while it waits for a local event to occur. The SDT 5000 wakeup enables the
satellite communications. The SDT 5000 will wakeup on the following events:
•
The SDT 5000 schedule event,
•
Any of the configurable events. See section 3.2, Events,
•
RTU data sent to the host,
•
The RTU port DTR signal asserted can wakeup the SDT 5000.
After a wakeup the SDT 5000 will remain ‘awake’ for a configurable period of time. This time is
called “Message Wait Time”. The message wait time is configured with the ‘satcfg wait’
command. The message wait time (re)starts when the unit is idle and all connections have
dropped. The message wait time is the time the unit will wait for a message from the host before
going back to sleep.
Pros: Lowest power mode
Cons: Unable to receive unsolicited host messages.
8.2.3 POLLED MODE
Polled mode provides a compromise between Standby mode and Continuous mode. Polled mode
automatically cycles the transceiver power. The power consumed should average to less than 50
mA over the polling interval. Polled mode takes advantage of the fact that the Datahub makes
multiple connection attempts for every host initiated connection request. The transceiver only
needs to be powered up during one of the retry attempts to successfully establish the connection.
Refer to Figure 7 for a illustration of the underlying concept.
Version 1.1, 03/24/06
Page 43
