DT800 v4 FIRMWARE RELEASE NOTES =============================== This document describes the changes and bugs fixed since v3.16. IMPORTANT: PLEASE READ ALL THE INFORMATION BELOW to ensure a trouble free upgrade occurs. Documentation ------------- The features present in this release of the DT800 firmware are described in the following documents: - DT800 User's Manual (revised edition, version UM0068-A2). This revision of the User's Manual is applicable to version 4.00 of the DT800 firmware. It is strongly recommended that you obtain this latest version of the manual, if you have not done so already. It is available in PDF format for free download from the Support area of the of the dataTaker website, www.datataker.com.au, or a printed copy may be ordered. - DT800 User's Manual Errata. This contains corrections and clarifications to the above version (UM0068-A3) of the User's Manual. This file is included in this firmware package. - Version 4.10 release notes (this text). Any functional changes between Version 4.00 (the version documented in the user manual and errata) and the current release are described here (see "Changes" sections below). In addition, the known issues list (included in this firmware package) describes issues or problems that have been identified with the operation of the current release, along with work-arounds where possible. Preparation for upgrade ----------------------- The following procedure should be used before upgrading the firmware to ensure that no compatibility problems occur. This procedure will return the logger to a completely unprogrammed state. Once the upgrade is complete you will have to restore any settings and programs. 1. Connect to the DT800 and perform the following operations, most of which can be done from the text window interface in DeLogger or from DeTransfer or other terminal application. BEWARE: if you are using DeLogger it may ask if you want to upgrade the logger when you connect to the logger; you must say no so that you can perform the following steps before the upgrade occurs. 2. Save any previously logged data from both internal memory and any PC card to be used with the new version of firmware. 3. In DeLogger select the 'Profile...' option from the 'dataTaker' menu and note any important profile settings, such as Ethernet IP Address. You must re-enter them once the upgrade is complete. If you are using DeTransfer or other terminal application then you can issue the PROFILE command to return the current profile settings. 4. Delete all data for all jobs on the DT800 using the DELDATA command. 5. Delete all jobs on the DT800 using the DELJOB command. 6. Delete any ONRESET job stored in flash memory using the DELFLASHONRESET command. 7. Delete any USER.INI stored in flash memory using the DELFLASHUSERINI command. 8. Format any cards to be used with the logger using the FORMAT"A:" command. 9. Format the internal RAM disk using the FORMAT"B:" command. Upgrading from firmware version 3.99 (or later) ----------------------------------------------- Follow the normal firmware upgrade procedure as described in the DT800 User's Manual. Upgrading from firmware version 3.16 (or earlier) ------------------------------------------------- Upgrading from firmware version 3.16, or earlier, to version 4.00, or later, is a two-stage process that involves upgrading to an intermediate version before upgrading to the final version. DeLogger Version 2 Release 16 or later knows this and will perform the intermediate upgrade automatically as part of the upgrade process if required. At the time of writing these notes, DeTransfer cannot do this automatically so you must do the intermediate upgrade manually. The name of the intermediate firmware file to use is "316v4bs.dxf". Should you need to revert back to an old version the same two-stage process is required however the name of the intermediate file in this case is "399v3bs.dxf". Both of these intermediate files are distributed within the new firmware release zip file. If you are using DeLogger to upgrade a DT800 you must copy all of the .dxf files in the upgrade zip file into the DeLogger firmware directory. The name of the directory is typically C:\Program Files\DeLogger\Firmware\mt This ensures that DeLogger can locate any intermediate upgrade files necessary to perform a two stage upgrade, if required. Also note before you begin that during this two-stage upgrade the internal RAM disk on the DT800 will be cleared. So retrieve any valuable data from your internal drive before you begin. BEWARE: If you try to upgrade directly to version 4.00 (or later), without going via the intermediate version, the upgrade will not succeed. The logger must be restarted after the failure. The logger will still contain the old firmware version. You can then upgrade to the intermediate version. IMPORTANT: You can only upgrade from version 3.16, or earlier, to version 4.00, or later, via the Host RS-232 port. The other methods, via PC card or FTP, cannot be used. Verifying the upgrade --------------------- After the upgrade has completed, reconnect to the DT800 using DeLogger or DeTransfer. If using DeLogger, select Status... from the dataTaker menu. The "Version" field should read "800 4.10.0001". If using DeTransfer, type STATUS. The first line should read: "dataTaker 800 Version 4.10.0001 Flash 2006/01/18 11:32:09" You will now need to restore the ONRESET job (if any) and any PROFILE settings that may be required, then issue a firm reset. DT800 Firmware Change History ----------------------------- Version 4.10, 18 January 2006 (this release) ============================================= Bugs Fixed (since version 4.08) ------------------------------- * When auto-ranging was enabled, measurements of low level signals near gain range boundaries (eg close to +/- 10mV, +/- 20mV) could sometimes be inaccurate. This has been fixed. (#40738) * If the logger was returning real time data using TCP/IP, and the TCP/IP connection was broken, the logger would stall and not log new data for about 5 minutes. This behaviour has been corrected. A disruption to a TCP/IP connection will not cause any interruption to logging. (#40249) * The excitation voltage for LM35 series, and AD590 series temperature sensors was found to be about 10% below what it should be. This has been corrected. (#40373). Changes (since version 4.08) ---------------------------- * All output text (including messages, real time data, etc) is now sent to all current TCP/IP connections, as well as the currently active connection (ie the one on which the last command was received). This allows multiple workstations to connect to the logger (using TCP/IP) and passively monitor the returned real-time data. * Excitation can now be specified for V, VNC, AS and F channel types: - If Pnnn, Innn, N or no excitation option is specified, no excitation is generated. - If V option is specified, 5.0V voltage excitation is generated on * terminal. - If Vnnn option is specified, nnn mV voltage excitation is generated on * terminal (max 14000mV). - If any load is placed on the excitation output the voltage will drop; output impedance is approx 500 ohms. Version 4.08, 21 December 2004 ============================== Bugs Fixed (since version 4.06) ------------------------------- * U(from)(to) where "from" and "to" are the same didn't work as documented in the user's manual. For example, U(13)(13) is supposed to be a short cut for U(13:00:00.0)(13:59:59.999999). This shortcut feature now works as documented in the user's manual. (#40329) * Spurious timeout errors sometimes occurred when operating the serial sensor port in half duplex mode. This has been corrected. (#40224) * A bug was discovered which caused the following behaviour in a schedule containing more than one ALARM statement:- When the first alarm is triggered, the actions for the second alarm may also be executed (although the second alarm's alarm text is not output). This has been corrected. (#40345) * Setting the modem initialisation string to be empty (ie. PROFILE"HOST_MODEM","INIT"="") caused the logger to reset when a modem was connected. This has been fixed. (#40299) * It was found that the following command sequence could cause the logger to reset: 1..2CV 1CV STATUS14 The cause of the problem was discovered and corrected. (#40342) Changes (since version 4.06) ---------------------------- * If carrier detect is active then the logger will no longer try to initialise an attached modem. (#40318) * Polynomials, spans, thermistors, intrinsic functions, manipulation and digital manipulation channel options can now be applied to analog channels in burst schedules. Version 4.06, 07 September 2004 =============================== Bugs Fixed (since version 4.04) ------------------------------- * Fixed bug where internal command buffer could become corrupted. This schedule: RA IF(1CV<1){[20CV=9]} was used to reproduce the bug. It will cause an "illegal characters" error message to be output approx. once per minute. The problem that caused this has been corrected. (#40301) * The (N) channel option could not be applied to BGV type channels. Applying it would result in a "channel list error" message being returned. This no longer happens, and the N option will have the desired effect of causing the DT800 to not excite the BGV channel. (#40304) * When an RTD device was the first thing measured in a schedule, it was sometimes receiving excessive excitation, causing self-heating and noisy measurements. There was also the potential for slight variations in the way channels (particularly those involving excitation, eg. resistance, RTDs, bridges) were measured, depending on their position in the schedule. This has been fixed. (#40291) * Analog voltage outputs (Ao, Sp and Ac terminals, controlled by VO, P47 and P49 respectively) did not actually appear until the next analog measurement was made. These outputs now appear as soon as the associated channel or parameter is set. (#40142) * Loopback operation on the serial sensor did not work when RS485 or SDI-12 mode was selected. This has been fixed. Note that RS485 and SDI-12 are normally half-duplex protocols. For loopback testing, it is necessary to force the port into full-duplex mode by including the TXON channel option. For example, to test the operation of RS485 mode in loopback mode you would connect T+ to R+ and T- to R-, then issue the following command: 1SERIAL(RS485,TXON,"{abc\\013}%S[1$]") 1$ which should set 1$ to "abc". (#40164) * Improved the detection of errors in the serial sensor control string (#40164) * The \m[text] construct in a serial sensor control string (skip incoming characters until "text" is found) now works correctly. (#40222) * The logger will now recover properly after a failed PPP connection attempt (eg. if the wrong username or password is entered). (#40226) * The serial sensor transmit buffer was not being displayed properly when P56=4 was used. This has been fixed. (#40234) * Overrange readings (99999.9) were sometimes being returned on the AS (analog state) channel type when the input voltage was increased suddenly. This has been fixed. (#40260) * The logger would reset when 17SV was accessed. This has been fixed. (#40261) * Entering a n$ string longer than 80 characters caused the next string to be corrupted. Long strings are now truncated to 80 characters. (#40262) * Entering a PROFILE string longer that 30 characters caused the next string to be corrupted. Long strings are now truncated to 80 characters. (#40268) * The serial sensor port was defaulting to being powered and the transmitter was enabled, causing increased power consumption and possibly disrupting a connected RS485 network. The port is now disabled until a serial channel or trigger is defined. (#40269) * Delay option for DSO channel type, eg 1DSO(5000) did not work unless the R option was also specified. This has been fixed. (#40186) * DSO(delay,R) did not generate an output pulse if the specified delay option was less than about 10ms. Now, if the delay option is set to a value less than 10 (or omitted) then a 10ms pulse will be produced. (#40187) * Bitmask channel factor for DNO and DBO did not work. This has been fixed. (#40188) * After changing a counter's wrap value, it could not then be reset back to the default value (no wrap). This has been fixed, eg. 4C(0) will remove the counter's wrap value. (#40171) * A spurious count was being recorded on counter channels 9C-16C, ie. their initial value was 1 rather than 0. This has been fixed. (#40179) * Counter channel count values are now reset to zero when the RESET command is issued. (#40134) * When counter and other non-hardware channel types (C,$,CV,IV,SV,ST) are set, the value returned now always reflects the actual value (which may sometimes be different from the value you set it to). For example, previously if you entered "19SV=7" then "19SV 7.0" would be returned, while subsequent reads of 19SV would return the correct value, which is 1.0 (for 19SV only the least significant bit is relevant). * System timers (1ST, 2ST, 3ST, 4ST) now wrap correctly when a non-default wrap value is specified; see also "Changes" below. (#40109) * "While" conditions on continuous schedules, eg BEGIN RA:1~W 1V END now work correctly. (#40021) * System timer updates are now synchronised with schedule execution. Previously they were not, which led to results such as: BEGIN RA1S /u T 1ST END Time 12:45:15.012 1ST 15.0 Time 12:45:16.001 1ST 15.0 Time 12:45:17.006 1ST 17.0 Time 12:45:18.011 1ST 18.0 Time 12:45:19.000 1ST 19.0 Time 12:45:20.005 1ST 19.0 Time 12:45:21.010 1ST 21.0 (#40116) * Fixed problem with unreliable host port communications following repeated sleep-wake cycles (this problem was only noticable with some types of host PC motherboard) (#40184) * When the event log overflows, its contents are copied into a file EVENT.BAK and EVENT.LOG is cleared. However, when UEVTLOG was entered, only the contents of EVENT.LOG were being displayed, which could be misleading. UERRLOG will now display both files, so you always get the last up to 1000 events displayed. * Current directory is now set to B:\ when a user logs into the DT800's FTP server. (#40228) * If a schedule was specified as continuous then any alphabetically later schedules would not run, eg. BEGIN RA 1V RB1S 2V END would never execute schedule B. This has been fixed; see also "Changes" below. (#40024, #40041) * If a schedule was specified with a short time interval (eg. 1T) then a maximum of two schedules would run, eg BEGIN RA1T 1V RB1T 2V RC1S 3V END would never execute schedule C. This has been fixed; see also "Changes" below. (#40024) * Using H or G commands with no current job no longer generates a spurious error message. (#40137) * Incorrect operation (logger "hangs" or returns overrange data values) when the required reading count for a burst mode measurement is close to the maximum value, eg. BEGIN RA1-E;BURST(16384) 1V END or BEGIN RA1-E;BURST(16383) 1V END. This has been fixed; see also "Changes" below. (#40131) * It is now possible to cancel a burst while it is waiting for the burst trigger by sending any command, as documented in the manual. Note that the burst will only be cancelled if it is configured to have an INFINITE timeout (ie. the timeout is specified as 0S). Thus If you do NOT want the burst to be cancelled by the arrival of a command, specify a very long (eg 10000H) timeout, rather than an infinite one. (#40192) * Under some circumstances, large blocks of the returned burst data would be invalid (typically overrange, ie. 99999.9). This has been fixed. (#40251) * If overrange values occur during a burst, this should force the channel's gain setting to be reset to the minimum value for the next burst, but this was not happening. This has been fixed. (#40256) NOTE: Using automatic gain adjustment is NOT RECOMMENDED for burst measurements. All channels should be gain-locked to a suitable range, eg. 1V(GL2V). Changes (since version 4.04) ---------------------------- * If you just enter VO (ie. don't set it to anything), it will return the currently set voltage for the Ao terminal. Previously this was an error. * Removed the serial channel options SSPWRON & SSPWROFF. Equivalent functionality is already provided by the SSPWR channel. (#40136) * The character used for negating a serial sensor scanset is now "~" rather than "^", eg. to match characters other than digits you would use "%[~0123456789][1$]" * Digital output channel types (DSO, DNO, DBO, WARN) now work in a more consistent way: 1) If =Expression is present (it is no longer mandatory) then the physical output is set to the specified value. 2) Then, if the delay channel factor is specified, we delay for the specified time or 10ms, whichever is greater. Note: If =Expression and R are both specified - ie. we are setting the output to a value then resetting it - then we always delay for at least 10ms, even if the delay channel factor is not specified. 3) The return value is then set to the actual current value (eg 2WARN returns 1 if the LED is currently ON) 4) Finally, if the R option is specified (it is now valid for all channel types) then the output is inverted. For example: 1DSO no change to output, return current state 1DSO=1 set output high, return 1 1DSO(50) delay 50ms, return current state 1DSO(50)=1 set output high, delay 50ms, return 1 1DSO(R) invert output, return previous state 1DSO(R)=1 set output high, delay 10ms, set output low, return 1 1DSO(R,50) delay 50ms, invert output, return previous state 1DSO(R,5)=1 set output high, delay 10ms, set output low, return 1 1WARN(R)=1 beep for 10ms, return 1 3DNO(7)=254 set D5:3=110, all other outputs unchanged, return x110 (x=state of D6) 1DBO(170,R) invert state of D2,4,6,8, return previous value of D8:1 (note that for DNO/DBO the channel factor is a bitmask, not a delay) * If a counter is preset to a value outside its current range then it now gets the specified value modulo the range, eg. 1C(5)=7 will result in 1C being set to 7 mod 5 = 2. (Previously the counter would return 99999.9, next time it would return the previous value.) * 1C(R)=3 will now return the value 3, next time it will return 0. (Previously the R option would be ignored if the counter was preset.) * Counter wrap schedule triggers, eg. RA3C(10) (trigger when counter 3C reaches the value 10), are no longer limited to a maximum 30Hz counter input frequency. This form of triggering now works over the full range of allowable input frequencies for the particular channel. * The LED flashing sequence following a firm or hard reset is now slightly different. (If there is a serious hardware fault in the logger, the unit may "hang" indefinitely during startup. If this occurs, you should note which LEDs are illuminated and report this to dataTaker support.) * Software failures and other critical errors are now handled differently. In addition to the event log, there is now a second file, the "error log". This contains detailed diagnostic information which can assist dataTaker engineers in fixing the problem. Two new commands have been added: UERRLOG - display the contents of the error log (if any) CERRLOG - clear the error log If a critical error occurs, the logger will immediately perform a firm reset. Following the restart, a a warning message is displayed: "Warning: abnormal firmware reset - type UERRLOG for details" If the logger ever unexpectedly restarts and you see this message, type UERRLOG and report the results to dataTaker support. * System timer (1..4ST) operation has been made more consistent and predictable. nST(range) will now immediately set the ST's range and reset its value to the current number of ST time units since midnight (1..3ST) or Sunday (4ST), modulo the specified range. So now you can type eg. 1ST(60) at any time to return an ST to its default behaviour; something that was previously not that easy to do. For example, if the time is 12:34:56: 2ST returns 34.0 (default wrap value for 2ST is 60) 2ST(0) returns 754.0 (754 minutes since midnight) 2ST(22) returns 6.0 (754 mod 22) 2ST=23 returns 1.0 (23 mod 22) 2ST returns 1.0 2ST(22) returns 6.0 (changing wrap value resynchronises ST to current time) 2ST will now increment every minute, resetting back to 0 each time it reaches 22. When midnight comes around, it will again be reset to 0. Note also that in order for the STs to always be synchronised to midnight/Sunday, the range values are limited to 86400 (1ST), 1440 (2ST), 24 (3ST) and 7 (4ST). If the range is set outside these limits then the value used will be the specified range modulo the range limit, eg. 3ST(25) is equivalent to 3ST(1). (#40204) * The way in which schedules are executed has been made "fairer". If multiple schedules are due to execute at a particular time then they will all be executed, one after another, in the order: *,S,A..K,X. This is similar to the way the DT500 series loggers operate. * The deprecated LOADPROFILE command has been removed. * Burst mode has been improved. During execution of a burst schedule, the analog sampling system passes through four distinct states: 1. Filling pre-trigger: collect required number of pre-trigger samples. During this time the burst trigger is NOT sampled. This state is skipped if 0% pre-trigger samples are required. 2. Waiting for trigger: repeatedly sample the burst trigger condition. This state is skipped if there is no burst trigger defined. 3. Acquiring: collect required number of post-trigger samples. 4. Idle: required number of post-trigger samples have been collected, or we timed out waiting for the trigger. When in normal (non-formatted) output mode, messages are now output to indicate the current state of the burst, eg: BEGIN LOGON /u RA1-E;BURST(10,50,LEVEL,50,0S) 1VNC(LEVEL>500,GL2V) 1V(GL2V) END (trigger the schedule by setting digital input 1 low...) Burst Schedule A: Filling pre-trigger Burst Schedule A: Waiting for trigger (trigger the burst by raising 1VNC above 500mV...) Burst Schedule A: Acquiring 1VNC 675.0 1V 672.6 1VNC 670.2 1V 673.2 1VNC 674.1 1V 674.8 1VNC 670.9 1V 675.1 1VNC 674.4 1V 671.0 1VNC 674.1 1V 673.2 1VNC 677.4 1V 672.9 1VNC 673.7 1V 673.5 1VNC 670.1 1V 673.5 1VNC 676.5 1V 672.3 Burst Schedule A: Complete Note the following caveat. At at high sample rates, there may be some "jitter" in the indicated indicated trigger position. For example, BEGIN RA1-E;BURST(100,100000,1-E,50) 1VNC END will always return exactly 100 readings, but you will generally get fewer pre-trigger and more post-trigger samples than you asked for - in this case the actual number of pre-trigger samples will typically be between 45 and 50. So for high sample rates, the pre-trigger percentage should be thought of as a MAXIMUM value. The above example is the worst case. If you sample at a lower clock speed, or sample a larger number of channels, then the actual number of pre-trigger samples will more closely match the percentage you specify. * On startup, if a hardware fault in the analog measurement system is detected then the following message will be displayed: "Warning: Analog measurement fault - housekeeping measurements disabled" Previously this would cause an endless sequence of restarts. If you see this message, contact dataTaker support. Version 4.04, 29 April 2004 =========================== Bugs Fixed (since version 4.02) ------------------------------- * Fixed problem where inaccurate and/or overrange analog measurements would occur following recovery from sleeps that occur due to battery failure. * Fixed bug where logger would fail to process a large job if it was sent as a file or run as an "on reset" job. This problem could affect any large job, but jobs containing long, mathematical expressions were most prone. * Fixed the LOADPROFILE command. It works again. It should be noted that this command will not be supported in future versions of our firmware so its use should be avoided. * Fixed bug where profile settings would disappear if the user issued a FORMAT"B:" command prior to the logger going to sleep. When the logger awoke the user's profile settings would not be restored. This has been fixed. * Fixed minor problems with host post initialisation where DT800 may not have been awakened upon receipt of chars on host port. * Fixed bug where entering a new job of the same name as a locked current job would cause the logger to crash. * Related to the abovementioned bug fix, was a problem where, if a locked job was re-entered, the current job would be deleted. This behaviour has been corrected. * Entering a job with /F set caused the logger to crash. This has been fixed. * Serial sensor control string error messages are now suppressed or output according to the state of the /m switch. This brings serial sensor error message output in line with the other error messages in the system. * We found that receiving a lot of packets at high frequency via the DT800's ethernet port could cause the DT800 to "lock up". The cause of this "lock up" has been identified and fixed and, as a result, our ethernet support is now more reliable. * Alarm polling (syntax: ?n where n is an alarm number) has been repaired and now works properly. * $ strings could not be assigned strings with spaces or lower case letters. This has been fixed. Dollar strings can now be assigned any string surrounded by double quotes. * After a cold restart the logger would go straight to sleep if it could, instead of waiting the number of seconds specified by P17. This has been fixed. * Data and alarms can now be unloaded with sub second resolution. An unload between time constraints used to disregard the subsecond portion of the time constraints. Now it does not. Changes (since version 4.02) ---------------------------- * Alarm text can now be sent exclusively and unconditionally via the host port. Simply enclose the alarm text in single quotes (') instead of double quotes ("). This feature enables the logger to send commands to a modem at any time. One application is that SMS modems can be commanded by the DT800 to send messages as a result of alarm conditions being met. * The modem INIT string can now contain embedded "^M" substrings. These substrings are used to delimit separate commands within the INIT string. Each subcommand is sent separately and with a COMMAND_PROCESSING_TIME delay following it. * Increased the size of the channel table from 500 entries to 800 entries. * Removed the AT&F0 modem command from the default HOST_MODEM INIT string. Version 4.02, 23 January 2004 ============================= Bugs Fixed (since version 4.00) ------------------------------- * Fixed the bootstrap loader to support early revisions (CB0055A1) of the DT800 kernel circuit board (These were shipped prior to February 2001). The old loader would make the DT800 appear dead once the upgrade was completed - requiring factory reprogramming to recover. This bug was introduced in beta version 3.99 Build 14. Version 4.00, 9 January 2004 ============================ Bugs Fixed (since version 3.16) ------------------------------- * Improved reset & wakeup handling. The reason for a reset is now recorded in the event log. * Fixed generation of "On Insert" messages in the event log. * Assignment of strings to $ string variables inside {[]} now works. * Serial sensor error messages are now returned when logger is in /H (formatted mode). * Fixed bug where using a span number greater than 20 could cause undefined problems. * Fixed bugs with ATA flash card insertion and removal. Sometimes a logger would not detect the insertion or removal of a PC card. * Problems with opening and closing a PPP session have now been fixed. 10 TCP/IP sessions can be established via a PPP link. Actually, 10 TCP/IP connections can be established over either Ethernet or PPP or a mixture of both. * User units are now propagated properly to statistical channels. * Logger incorrectly reporting running out of expression text space as a channel option error. * In formatted mode (/H) the PH command used to return :- S,000000,2003/09/08,18:11:55,0.119506,22;57600,N,8,1,SWFC;0058;A597 The status number (22) is wrong. It should be 21. This has been fixed. * Fixed numerous bugs with serial sensor support. * Serial channel should receive floating point numbers correctly. * RS485 support has been fixed and now works correctly. Effort has been expended to correct timing and signalling issues with RS485 communications. * Ethernet should now be more reliable. It should no longer lock up unexpectedly. * Logger should no longer crash while waking up and processing digital events. * SHOWPROG"jobname" and SHOWJOB"jobname" will now work for any job, not just the current job. Changes (since version 3.16) ---------------------------- * Changed default value for P5 from 1 minute to 60 minutes. This means that, in the absence of a schedule to execute, the logger will sleep for 60 minutes. * !START_PPP command has been removed. PPP clients initiating a PPP session with the DT800 must send the word 'CLIENT' to the DT800 via the RS232 host port. The logger will respond with 'CLIENTSERVER' and then it will expect PPP packets. MS Windows PPP client software issues 'CLIENT' and expects the 'CLIENTSERVER' response by default. * General optimisations have been made to increase the DT800's performance. * Minor changes have been made to the bootstrap and firmware loader to improve the reliability and speed of the firmware upgrade process. * The caches on the main processor have been enabled. This allows any CPU intensive activities to complete more quickly. For example the maximum speed at which analogue channels can be measured and written to the internal RAM disk has improved by up to 120%. * The communications support has been improved so that communications over Ethernet is up to 600% faster. * Support for modems has been completely changed. Please see the latest version of the DT800 users manual that explains the new operation. * MODEM SUPPORT: Added profile HOST_MODEM SEND_BANNER_CONNECT. If it is set to "YES" ("YES" is default) then a string like "dataTaker 800 Version 4.00" is transmitted whenever CD (carrier detect) goes from inactive to active. * Removed the following profile settings from the HOST_MODEM section: HANGUP, ANSWER, RESET, RESPONSE, ATTENTION, END_DATA_MODE, RING, CONNECT, COMMAND_DELAY, INIT_REPETITION_PERIOD, COMMAND_ANSWER_TIMEOUT, DIAL_TIMEOUT, ANSWER_TIMEOUT, ESCAPE_BEFORE_HANGUP, MODEM_INSTALLED. These profiles were associated with the modem management system that exists in the version 3.16 firmware. Modem management in version 4.00 firmware is a completely new design and implementation and as such, does not require the above-mentioned profile settings. * Increased size of expression text and alarm text areas from 4Kbytes to 16KBytes each to allow for more complex programs to be defined. * Serial sensor now supports reading binary data. The %b conversion type enables the serial sensor to read numbers represented in binary (not ASCII) to be received via the serial sensor. %b by itself will read 1 byte. A width may be specified. e.g. %4b will cause 4 bytes to be read and treated as an unsigned 32bit number. * New feature: serial sensor now supports a scanset conversion type: %[abc][1$]. This tells the serial sensor to receive a string containing the letters 'a', 'b', and 'c only, and place the received string into 1$. In the example [abc] is the scanset. It can be any set of characters. The scanset can also be negated if the first character in the scanset is a '^'. For example, [^1234567890] will cause the serial sensor to receive a string that contains characters other than digits. * New feature: string enumeration. 1SERIAL("%s['abc','123','qwer','vwed','765',1CV=-1]") This tells the serial sensor to read in a string. If the string matches abc (the first enumeration element) then 0 will be assigned to 1CV. If the string matches 123 then 1 will be assigned to 1CV. If qwer then 2 and so on and so forth. If the received string matches none of the strings in the enumeration list then an optional default value is assigned to 1CV (if the optional default value is present). The enumeration list assignment can be applied to %s, %S, and %[] input conversion types. * Reading and writing to PC card ATA flash devices have been sped up significantly. Writes are now about 15 time quicker than in the previous version. * Pressing the reset button while the logger is asleep now causes the logger to do a full hardware reset. It used to just wake up. * Alarm action text has some new options designed to help with SMS messaging, but will also be of general interest. A new replacement text option has been provided to allow the current value of any channel variable to be substituted into the alarm action text. The new substitution characters are ?n, where n is a number from 1-500 such that the ?n will be replaced by the value of the referenced Channel Variable (CV) specified by n. There are modifiers for this notation that allow you to specify the number format. You can specify any of F, E or M to indicate Fixed, Exponential or Mixed format respectively after the channel variable index. You can also specify another number after the format type to indicate the number of decimal places. For example ?2F1 will output the value of channel variable 2 in fixed format with one decimal place. In addition you can now specify !!, @@ or ## to return !, @ or # respectively. This allows you to define alarm action text that includes the substitution characters without them being substituted, which is especially helpful if the device that the text is being sent to requires any of these characters for particular operations (eg. SMS modems). --End--