27
burst of sentences is received. The queues in the MiniPlex are quite large and may contain up to 30
sentences of GPS data.
A couple of occasional blinks of the red LED over a period of a few seconds means that large bursts of
sentences are received and a queue is hitting its limit. Some sentences are discarded but most of them
will be forwarded without problems. Such a situation is totally acceptable and would mean that for
instance one depth, wind or position update is missed every few seconds.
A quite different situation may arise with some fluxgates or gyrocompasses. These devices may send
their heading sentences with a speed up to 40 sentences per second! Instead of queuing a burst of
sentences every one or two seconds, the multiplexer must queue a constant stream of sentences,
possibly utilizing the maximum bandwidth of the multiplexer. Such a situation can lead to a queue that is
constantly filled up to its maximum capacity. This in turn results in heading data that can be up to 20
seconds old when it is forwarded, which is totally unusable for any autopilot to steer on. Enabling the
“Real Time” option for this input can solve this specific problem. This option bypasses the queue entirely.
Only one sentence will be stored and forwarded when the time slot for this input arrives. Outside its time
slot, incoming sentences will be discarded. A lot of heading sentences will be lost now but the ones that
are forwarded are done so almost immediately. Hence the name “Real
Time”.
When the red LED is blinking severely or stays on almost continuously, it
is strongly recommended to investigate which instrument or input leads
to this overflow. The MPX-Config utility will show on which input the
overflow occurs by a blinking indicator in the “Input
Overflow” section.
Opening the Statistics window (Figure 28) from the Tools menu will give
an insight about the amount of data in each queue and whether it is filled
constantly or occasionally.
Some general rules apply for reducing overflow situations. A simple rule
of thumb is that an overflow can never occur if the speed of an output is
equal to or higher than the combined speeds of all inputs that are routed
to that output. For example: if the multiplexer is in its default
configuration and all four inputs are set to 4800 Baud, the minimum
output speed equals 4 x 4800 = 19200 Baud. This rule is only a hard rule
when the input bandwidth is fully utilized i.e. an instrument is sending
data continuously. This is hardly ever the case. As mentioned earlier,
NMEA data is often sent in bursts, resulting in a much lower overall
bandwidth. It could be perfectly feasible to have a system with four
instruments connected to the multiplexer, while running all in- and
outputs on 4800 Baud without a single overflow.
There are several ways to resolve overflow situations:
1.
Configure the instruments on the listener ports to send less data or with greater intervals. GPS
receivers can sometimes be configured for this.
2.
Use the sentence filter of the multiplexer to block unwanted sentences. Unwanted sentences are
discarded immediately and do not occupy queue space or bandwidth.
3.
For sentences that should not be blocked, setting a divisor in the sentence filter may lower their
rate. A gyro may be throttled down to 10 sentences per second or even less. From the GPS
output, the rate of the sentences containing satellite information could be lowered to once every
10 seconds instead of being output every time a position is output by the GPS.
4.
Use the routing options to select which input is routed to an output or use the routing options in
the sentence filter to selectively route NMEA sentences to an output.
5.
Increase the speed of the NMEA output that causes the bottleneck. This will only work when the
connected equipment also supports higher communication speeds.
Figure 28
