Page 9
wastes resources and in some cases can actually cause the microDAQ to hang and require a
power cycle.
The data rate over TCP is vulnerable to low level operating system considerations, in particular any
‘delayed acknowledgement’ algorithm. Windows ® attempts to suppress too many
acknowledgments for small data packets swamping a network by inserting a 200ms (default) delay
in the generation of a second acknowledgement to a communicating device. Since the microDAQ’s
communication consists of many small packets at a high repeat rate, this algorithm has a
catastrophic effect on the microDAQ’s delivered bandwidth (effectively limiting it to tens of Hz).
The bottleneck can be removed by altering/adding a value of the registry key:
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\
{adapter GUID}
(HKLM = HKEY_LOCAL_MACHINE;
{adapter GUID =
the network adapter being used by the
Windows PC), though this should be done only in consultation with the network administrator.
In Windows 2000, the DWORD value TcpDelAckTicks should be set to 0 in the registry key.
In Windows XP (must have SP1 or later installed), the DWORD value TcpAckFrequency should be
set to 1 in the registry key.
Also note that the TCP channel of the microDAQ is subject to buffering both within the unit itself
(the size of the buffer depending on number of channels and data rate), and within Windows ®
itself. At low data rates, it is possible to receive single complete data packets, however as the data
rate increases Windows ® is more likely to deliver chunks of data 2k to 4k bytes in length, with
arbitrary boundaries with respect to microDAQ’s data packets. User software should take this into
account to avoid losing data.
Please note that if streaming at high data rates it is essential that a good network infrastructure is
used. It is recommended that any streaming is performed over a ‘private’ network (i.e.
disconnected from any corporate network structure) to reduce the number of packets flying around
the network. It is also highly recommended that a high speed managed network switch with a large
store and forward buffer is used between the microDAQ and client PC, particularly if several
microDAQs are being used together to acquire data.
4.2.5 Control Via TCP.
User commands are handled in a similar way as the RS232 commands above, however it should
be noted that the acknowledgement bytes are doubled for the purposes of the internal workings of
the TCP software, so a positive acknowledgement is returned as ‘**’ and a negative
acknowledgement as ‘!!’.
The argument regarding loss of acknowledgements in the data stream holds good for the TCP
channel, and it is recommended that a ‘Stream Off’ or ‘Standby’ is sent before any other
command.
4.3 CAN
4.3.1 Overview.
The CAN channel is somewhat different to the above channels, in that it is not a simple serial
communications channel, the data being sent in discrete chunks on specified message identifiers.
4.3.2 CAN Baudrate.
The microDAQ offers a single ‘standard’ CAN bus connection running at a selectable baudrate, the
user having access to the values used for the microDAQ’s microcontroller CAN timing registers to
enable customising of sample point and jump width. Default values for a number of common
baudrates (1M, 500k, 250k, 125k, 100k, 50k (Hz)) are available from the microDAQSetup program.
The values are calculated based on the microcontroller CAN peripheral clock of 60MHz. Users
should bear this in mind when calculating suitable values for BRP, TSEG1, TSEG2 and SJW for
their own physical network implementation.
