smithtek-mako-rf 3.3.4 → 3.4.1

package/MAKO-RF.md

@@ -0,0 +1,607 @@
+# Original Mako RF · basic Modbus
+
+This guide covers the original RF node included in **smithtek-mako-rf**. For Smithtek’s proprietary PassPort Connect link between PassPort, Mako and Solaris, use the separate [PassPort Connect guide](PASSPORT-CONNECT.md). Both nodes are installed by the same package.
+
+## Installation
+Install using the `NodeRED palette manager`
+
+
+## Smithtek Mako RF node
+
+The Smithtek Mako RF nodes are designed specifically for the Mako PLC, while remaining fully compatible with other Modbus RTU devices connected over RS485.
+
+They support communication to one or multiple devices across hard-wired RS485 channels or long-range RF, all from a single, unified node. Whether you’re polling a single PLC or managing a full remote site, the node handles device sequencing and bus control automatically.
+
+Built for industrial environments, the node includes integrated queue management, retry handling, timeout control, gap spacing, and automatic reconnection logic. These features provide stable, predictable polling without requiring complex flow logic.
+
+The Smithtek Mako RF node effectively replaces the traditional Modbus contrib nodes and the separate Mako decoder node, combining communication and decoding into a single streamlined tool.
+
+One node. One inject. Full control.
+
+
+
+![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/Smithtek%20Mako%20RF%20Nodes%20page%201.png?raw=true)
+
+The Smithtek Mako RF node operates in two modes:
+Read Mode – Poll slave devices and retrieve data from registers.
+Write Mode – Send commands or values to slave devices.
+The PassPort Gateway provides three communication channels:
+RS485-1
+RS485-2
+Long Range RF
+You can assign any node to any bus channel, allowing wired and RF devices to operate independently while the node manages sequencing and communication control in the background.
+
+![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/Smithtek%20Mako%20RF%20Nodes%20page%202.png?raw=true)
+---
+
+## Bus Configuration
+
+Select the communication channel:
+- **RS485-1** → PassPort RS485-1  
+- **RS485-2** → PassPort RS485-2  
+- **RF** → Long range LoRa radio link  
+When RF is selected, serial parameters are automatically managed.
+Timeout, Retries and Gap are configured in **seconds**.
+
+---
+
+## Mode
+
+### Read
+Polls registers from the remote Mako and outputs structured JSON.
+
+![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/Smithtek%20Mako%20RF%20Nodes%20page%203.png?raw=true)
+---
+
+
+
+
+### Write
+Sends values to the remote device using:
+
+- FC5 – Write Single Coil  
+- FC6 – Write Single Register  
+- FC15 – Write Multiple Coils  
+- FC16 – Write Multiple Registers  
+
+Values can come from `msg.payload` or be fixed in the node configuration.
+
+Polls registers from the remote Mako and outputs structured JSON.
+![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/Smithtek%20Mako%20RF%20Nodes%20page%204.png?raw=true)
+
+
+---
+
+## Device ID
+
+The Modbus Unit ID of the remote Mako (1–247).  
+Must match the ID configured in the target device.
+
+---
+
+## Function Code
+
+Must match the table type configured in your V-NET program:
+
+- Read Coils  
+- Read Digital Inputs  
+- Read Holding Registers  
+- Read Input Registers  
+
+---
+
+## Address
+
+Starting Modbus register address.  
+Must align exactly with the Modbus table built in your Mako V-NET program.
+
+---
+
+## Quantity
+
+Total number of registers to read.
+
+- 16 bit value = 1 register  
+- 32 bit value = 2 registers  
+
+**Example:**  
+3 × 32 bit floats = Quantity 6  
+
+Quantity must cover all registers defined in your decoder map.
+
+---
+
+## Decoder Map
+
+Build the register table in the exact same order as your Mako V-NET Modbus table.
+Each row defines how raw Modbus data is converted into structured JSON.
+
+### Name
+Becomes the output key in `msg.payload`.  The name could be your sensor name like "level sensor" or " thermal trip" " pump control" choose a name that suits your SCADA scheme.
+
+### Prefix
+
+The Prefix field applies to every name in the decoder table. Enter `b1` and a row named `Pressure` becomes `b1 Pressure` in `msg.payload`, with a space between the prefix and name.
+
+Copy the node and change only the prefix to reuse the same table for another asset. Leave it blank to use the table names as entered.
+
+### Register Data Type
+
+- 16 bit integer  
+- 16 bit unsigned  
+- 32 bit integer  
+- 32 bit unsigned  
+- 32 bit float  
+- Digital to unsigned binary encoder  
+
+### Offset (regs)
+
+Offset is configured in registers.
+Automatic stepping behaviour:
+- 16 bit types increase by 1 register  
+- 32 bit types increase by 2 registers  
+- Digital encoder increases bit number from 0–15 before moving to the next register  
+
+Offsets must match your V-NET Modbus table layout exactly.
+
+---
+
+## Digital to Unsigned Binary Encoder
+
+Used when one 16 bit register contains multiple digital states.
+The Bit column becomes active.  
+Bit automatically increments when adding rows.  
+After Bit 15, the next row moves to the next register.
+
+---
+
+## Scale
+
+Optional value transformation applied after the Modbus register is read.
+
+Decoded numeric readings are rounded to a maximum of six decimal places after Math or Range scaling. Values remain numbers, without added trailing zeros. Very small values may round to zero. Raw data in `msg.modbus.raw` is unchanged.
+The Scale field lets you adjust raw register data into meaningful engineering values without needing extra function nodes. Think of it as lightweight post-processing built directly into the driver.
+
+Choose a scaling mode for each row:
+
+- **None** leaves the value unchanged.
+- **Math** applies an operator and number, such as `/100` or `+5`.
+- **Range** maps input low/high values to output low/high values.
+
+All controls stay on the same row. Selecting None disables the calculation while keeping the entered settings for reuse.
+
+### Math
+
+You can apply the following operators:
+
+- Addition +
+Adds a number to the value.
+Example:
++10 → adds 10 to the parsed value
+
+- Subtraction -
+Subtracts a number from the value.
+Example:
+-5 → subtracts 5 from the parsed value
+
+- Multiply *
+Multiplies the value by a number.
+Example:
+*10 → multiplies the parsed value by 10
+
+- Divide /
+Divides the value by a number.
+Example:
+/100 → divides the parsed value by 100
+
+- Modulus %
+Returns the remainder after division.
+Example:
+%10 → returns remainder when value is divided by 10
+
+If you want to multiple your modbus value by 10 you would put "* 10"   without the quotes and use a space between the number and the match function.
+
+### Range — 4–20 mA Scaling
+
+Select **Range** and enter **In low**, **In high**, **Out low** and **Out high**. This converts a sensor reading into engineering units in the Passport without a separate Function node or a calculation in the Mako.
+
+For a 4–20 mA signal representing 0–100%:
+
+| In low | In high | Out low | Out high |
+|---|---|---|---|
+| 4 | 20 | 0 | 100 |
+
+A reading of 4 becomes 0, 12 becomes 50, and 20 becomes 100.
+
+Use the values actually reported by the register. If it reports 4000–20000, enter 4000 and 20000 as the input limits instead of 4 and 20.
+
+Tick **Clamp** to keep the result within the output limits. Otherwise, values outside the input limits continue scaling beyond the output range. Input low and high must differ. Negative, decimal and reversed ranges are supported. Range applies to numeric values and replaces the Math calculation for that row.
+
+This allows you to convert raw Modbus numbers into readable, usable data straight from the node — reducing additional processing and keeping flows clean and simple.
+
+---
+
+## Output Behaviour
+
+### Output Pins
+
+- **Top pin — Data / alarm:** sends parsed Modbus readings or write confirmations. If a request fails, it sends a readable fault message instead.
+- **Bottom pin — Debug:** sends technical error details for a local Debug node. Leave it disconnected if these details are not needed. Successful requests send nothing from this pin.
+
+### Fault Messages
+
+Example payload from the top pin:
+
+```json
+{"b1 RF ID1 Not communicating — check power/RF; disable if out of service":1}
+```
+
+The fault name identifies the prefix, bus and device ID, followed by an operator message. If the prefix is blank, the node Name is used. Other problems, such as an unsupported register or invalid settings, receive a message appropriate to that fault.
+
+A timeout fault is sent after one poll exhausts its retries: retries set to 0 means one failed attempt; retries set to 2 means three failed attempts. A successful retry sends normal data only. An unsupported-register error is reported immediately because retrying cannot correct the address. Each failed poll sends a fault; a redeploy cancellation does not.
+
+The bottom pin carries `msg.payload.ok`, `msg.payload.error`, `msg.payload.code` and `msg.payload.req` for troubleshooting. Technical details are also available in `msg.modbus`. Node-RED error logs and Catch handling remain available.
+
+When communication succeeds again, the top pin resumes normal readings. No automatic zero/clear alarm is sent.
+
+### Successful Read
+
+- `msg.payload` → Decoded structured JSON  
+- `msg.modbus.raw` → Raw Modbus response  
+- `msg.modbus.req` → Request metadata  
+
+### Successful Write
+
+- `msg.payload` → Device confirmation response  
+- `msg.modbus.raw` → Raw Modbus confirmation  
+
+The write response is the actual Modbus confirmation returned by the remote device.
+
+---
+
+## Industrial Behaviour
+
+- Single shared bus queue per channel  
+- One request processed at a time  
+- Timeout handled in seconds  
+- Configurable retry attempts  
+- Optional inter-request gap  
+
+Designed for stable Modbus RTU polling over RS485 or long-range RF links.
+
+---
+## Decoder Mapping V-NET v NodeRED
+
+
+The Decoder Map in the Mako RF node must match your V-NET Modbus table exactly.
+Every register must appear in the same order in both tools.
+If the order does not match, the decoded values will be incorrect.
+Think of it as a mirror:
+V-NET defines the Modbus table.
+The Node-RED Decoder reads it back in the exact same sequence.
+Register type, size (16-bit or 32-bit), and position must align between both.
+Digital to Unsigned Binary Encoder
+When using Digital to Unsigned Binary Encoder in V-NET:
+A single 16-bit register holds up to 16 digital values
+Each digital output occupies one bit (0–15)
+In the Node-RED Decoder Map, you select the same register type
+Then assign the correct bit number for each digital
+
+Example:
+
+Bit 0 = Digital 1
+Bit 1 = Digital 2
+Up to Bit 15
+This allows one register to represent 16 individual digital states.
+
+Best Practice
+It is recommended to place Digital to Unsigned registers at the end of your Modbus table.
+This gives you flexibility to:
+Add new digital points later
+Adjust bit assignments
+Expand without shifting existing analog register positions
+Keeping digitals grouped at the end prevents breaking your existing register structure in future revisions.
+
+Correct mapping ensures clean decoding, predictable data, and stable long-term expansion.
+
+## Example Configuration reading registers ##
+![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/Decoder%20Map.png?raw=true)
+
+
+
+In the screen shot example above is a typical reading the Mako map/\ ,
+
+The V-NET screenshot shows on the left shows.
+
+Device ID: 1
+Start register: 0
+Modbus table type: Input Registers
+2 × 32-bit floats
+2 × 16-bit unsigned registers
+
+The second 16-bit unsigned register is used as a Digital to Unsigned Binary Encoder, allowing up to 16 digital values to be packed into a single register.
+On the Node-RED Mako RF node properties, you can see these settings match exactly:
+Device ID is set to 1
+Function Code matches Input Registers
+Start address is 0
+Quantity shows 16, this is higher than needed but a good habbit to do as it ensurs you dont miss a register. If we wanted to match it completely we would have this set to 6 length!
+
+Decoder Map mirrors the exact register order and types from V-NET
+In this example, RF is used as the communication interface on both the Mako PLC and the PassPort Gateway.
+Once deployed, each poll from the PassPort will correctly read the Mako Modbus table.
+The decoded data will then be output from the node, ready for use in dashboards, logic, or cloud transmission.
+
+---
+## Example Configuration writing a single coil register ##
+![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/decoder%20write%20to%20a%20coil.png?raw=true)
+
+In this example, an additional coil has been added to the V-NET Modbus map.
+The Node-RED Mako RF node is now set to Write mode, and the settings match the V-NET configuration:
+Device ID matches the Mako
+Function Code matches the coil type
+Address matches the coil register in V-NET
+Communication channel remains the same (RF or RS485)
+When triggered with an inject node:
+If using msg.payload, the value (true/false) will be written directly to the selected coil.
+If using Fixed, the configured value will be sent on every inject.
+Once deployed, each trigger will send a write command to the Mako, updating the coil state in real time.
+
+---
+## Example Configuration writing a single holding register ##
+![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/Decoder%20writing%20a%20single%20register.png?raw=true)
+
+In this example, a Holding Register has been added in the V-NET Modbus map at address 0.
+The Node-RED Mako RF node is set to Write mode, configured as:
+Device ID matches the Mako
+Function Code set to Write Single Register (FC6)
+Address set to 0 to match V-NET
+Communication channel matches the system (RF or RS485)
+When triggered:
+From msg.payload – the numeric value in the payload is written directly to the holding register.
+Fixed mode – the configured value is written on every inject.
+Once deployed, each inject sends the write command to the Mako, updating the holding register immediately. The value is then available inside the V-NET program just like any other mapped register.
+
+
+---
+## Node Status ##
+
+Each Mako RF node shows a live status under the node so you can see what it’s doing without opening debug panels. This is especially useful when polling multiple devices, troubleshooting timeouts, or confirming that queues are being processed correctly.
+
+What you’ll see
+
+`Idle / waiting`
+No active request is being processed. The node is ready for the next poll.
+
+`Polling (in progress)`
+Blue dot status while a request is being sent and a reply is expected.
+Typical text includes the bus name, function code, unit id, and address, for example:
+RF: fc4 uid1 @0 (try 1/3)
+
+`Success (response received)`
+Green dot status when the device responded correctly.
+Example:
+RF: ok fc4 uid1
+
+`Failure / timeout / comms fault`
+Red ring status when a request fails after retries or times out.
+Example:
+RF: fail fc4 uid1
+The reason will also be available in msg.modbus.error on the output message.
+
+`Queue activity (multiple devices)`
+When multiple polls are triggered together, the status will “walk” through each device one at a time as the queue processes. This is normal and confirms the node is sequencing requests rather than blasting the bus.
+
+``Notes``
+
+The (try x/y) indicator shows retry behaviour. For example try 2/3 means the first attempt failed and it is retrying.
+
+If you see repeated red failures on a single device, it usually points to ID/address mismatch, wiring/RF link quality, or the poll rate being too aggressive for the link.
+
+
+---
+## RSSI (RF Signal Strength Diagnostic) ##
+
+RSSI (Received Signal Strength Indicator) provides a live measurement of the RF signal strength between the PassPort and the remote Mako device when using the RF channel.
+
+When enabled, the node performs an additional request to the LoRa module after each successful Modbus read. The returned signal strength (in dBm) is then appended to the output payload.
+
+This allows you to:
+- Verify RF link quality during installation
+- Diagnose weak or marginal radio paths
+- Confirm antenna alignment and placement
+- Monitor signal health during maintenance
+How to Enable
+- Open the Bus configuration node (smithtek-mako-rf-bus).
+- Select the RF channel.
+- Tick the RSSI checkbox.
+- Deploy.
+- To disable RSSI, simply untick the checkbox and deploy again.
+
+
+## RSSI Output Behaviour (msg.payload) ##
+
+When enabled:
+RSSI is appended to the normal decoded payload (msg.payload).
+It is added to the same JSON object generated by the Decoder map.
+The property name is automatically derived from the node block name.
+
+`RSSI Guard & Timeout Settings`
+
+The RSSI feature includes two adjustable timing parameters to fine-tune how the LoRa module is queried after a Modbus poll.
+In most installations.
+`The default values (10ms guard / 100ms timeout) are ideal and do not require adjustment.
+
+`RSSI Guard (ms)`
+
+The RSSI Guard is the delay between the completed Modbus response and the RSSI request being sent to the LoRa module.
+- This short pause ensures:
+- The Modbus transaction has fully completed
+- The UART buffer has settled
+- The RF module is ready to respond cleanly
+
+Typical range: 5–10ms
+Default: 10ms
+
+Lower values may work, but 10ms provides stable behaviour across most installations.
+
+`RSSI Timeout (ms)`
+
+The RSSI Timeout defines how long the system will wait for the LoRa module to respond with the RSSI value before aborting the request.
+Default: 100ms
+
+This is usually more than sufficient. Increasing the timeout:
+Does not improve signal strength
+Only increases the wait time if the module does not respond
+The timeout should only be increased if diagnosing unusual behaviour on a slow or noisy link.
+
+## RSSI Practical Guidance ##
+
+- Leave both values at default unless diagnosing an issue.
+- Use RSSI primarily during install or maintenance.
+- If RSSI is enabled permanently, keep guard low and timeout reasonable to avoid unnecessary bus slowdown.
+
+In short, the defaults are tuned for real-world PassPort + Mako RF deployments and will suit almost every scenario.
+
+![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/RSSI%20switch.png?raw=true)
+
+
+---
+## Polling Tips – Long Range RF ##
+
+RF polling is different to hard-wired RS485. Even though it still looks like Modbus, the request and reply must travel through the radio link and be processed at both ends. That adds “time of flight” and a bit of overhead, so the fastest possible poll rate is always slower than RS485.
+
+On the PassPort, the RF channel hides baud/parity/stop settings because the radio link is handled internally. What you control instead is the pacing: timeout, retries, gap, and your inject interval.
+
+``What slows RF down``
+
+- Air link latency (packetising + radio turnaround)
+- Retries when the link is marginal
+- Bigger register reads (more bytes to move)
+- Polling too frequently, causing requests to stack up
+- Best practice for multiple Makos
+- Polling should be treated as a “cycle”: each device gets a turn, one at a time.
+
+Choose an inject interval that allows the whole device list to complete without building a backlog.
+If you trigger multiple devices at once (single inject feeding multiple RF nodes), the queue will serialize them.
+
+Cycle time rule (use this in your markdown)
+
+`Cycle time ≈ (N × (typical RF transaction time + gap_s)), plus a bit of margin.`
+
+``Where:``
+- N = number of RF devices
+- typical RF transaction time = how long one poll normally takes (including reply)
+- gap_s = the deliberate spacing you set between requests
+
+## Practical tuning tips ##
+
+- Start conservative: increase speed only after you’ve proven stability.
+
+- If you see timeouts, the first fix is usually: slow the cycle down (longer inject interval), not bigger timeouts.
+
+- Keep read sizes sensible. Large reads are fine, but they raise transaction time, so the cycle must be longer.
+- For RF, it’s usually better to have one inject per site (simple) but set the inject interval long enough that the queue clears every cycle.
+
+- If you want “no backlog ever”, do not inject faster than the cycle time, otherwise requests will pile up behind the queue and devices will start timing out.
+---
+
+## RF Polling Guide (≈100 Bytes Per Device) ##
+
+| RF Devices | Typical Per-Device Time (s) | Recommended Gap (s) | Safe Cycle Time (s) | Recommended Inject Interval |
+|------------|----------------------------|---------------------|---------------------|-----------------------------|
+| 1          | 1.5                        | 0.5–1.0             | ~2–3                | 3 seconds                   |
+| 2          | 1.5                        | 0.5–1.0             | ~4–5                | 6 seconds                   |
+| 3          | 1.5                        | 0.5–1.0             | ~6–7                | 8–10 seconds                |
+| 4          | 1.5                        | 0.5–1.0             | ~8–10               | 12 seconds                  |
+| 5          | 1.5                        | 0.5–1.0             | ~10–12              | 15 seconds                  |
+| 6          | 1.5                        | 0.5–1.0             | ~12–15              | 18 seconds                  |
+| 7          | 1.5                        | 0.5–1.0             | ~15–18              | 20 seconds                  |
+| 8          | 1.5                        | 0.5–1.0             | ~18–21              | 25 seconds                  |
+| 9          | 1.5                        | 0.5–1.0             | ~20–24              | 30 seconds                  |
+| 10         | 1.5                        | 0.5–1.0             | ~22–26              | 30–35 seconds               |
+
+`Important notes read below `
+
+## RF Spreading Factor Note ##
+
+The above table is based on the default spreading factor of 1024.
+
+At this setting, the transaction times shown are realistic for stable industrial polling with approximately 100 bytes per device.
+If you increase the spreading factor for longer range transmission, the air time increases significantly.
+As a simple rule:
+Add at least 2 seconds per spreading step increase
+
+Maximum spreading factor supported is 4096
+
+Example:
+
+- 1024 → use table values
+
+- 2048 → add ~2 seconds to the recommended inject interval
+
+- 4096 → add ~4 seconds to the recommended inject interval
+
+Increasing spreading improves range and link robustness, but it reduces throughput. Always adjust your inject interval to suit the radio configuration to avoid queue build-up and timeouts.
+
+In RF systems, range and stability always win over speed.
+
+---
+# Troubleshooting Guide – Smithtek Mako RF Node
+
+| Issue / Symptom | Possible Cause | Recommended Action |
+|-----------------|---------------|--------------------|
+| Red status: `fail fcX uidY` | Device ID mismatch | Confirm Device ID in Node-RED matches V-NET configuration |
+| Red status: timeout | Polling too fast | Increase inject interval (slow the cycle time) |
+| Red status: timeout | RF link marginal | Increase spreading factor or improve antenna alignment |
+| Red status: timeout | Inject interval shorter than cycle time | Ensure inject interval is longer than full device cycle |
+| Red status: timeout after working normally | Bus overloaded | Reduce number of devices per cycle or increase interval |
+| Only first and last device polling | Queue dropping logic enabled | Disable aggressive queue dropping or increase maxQueue |
+| Devices poll intermittently | Retries too high | Reduce retries to prevent blocking the queue |
+| Devices stop polling after deploy | Serial port locked | Restart Node-RED or power cycle PassPort |
+| Data values incorrect | Register order mismatch | Ensure V-NET Modbus table matches Node-RED decoder map exactly |
+| 32-bit values incorrect | Wrong word order | Confirm correct 32-bit interpretation (float / unsigned / integer) |
+| Digital bits incorrect | Bit index mismatch | Ensure correct bit number (0–15) selected in decoder |
+| Write command not working | Wrong function code | Confirm FC5 for coil, FC6 for single register, FC15/16 for multiples |
+| Write works but value wrong | Payload type mismatch | Ensure msg.payload is correct type (bool or number) |
+| Write command appears successful but nothing changes | Writing to wrong register type | Confirm coil vs holding register mapping in V-NET |
+| Queue growing continuously | Inject too fast | Increase inject interval |
+| Random comms drops on RF | Spreading factor too low for range | Increase spreading factor (add time to cycle) |
+| RF very slow but stable | High spreading factor | Increase inject interval accordingly |
+| Works on RS485 but not RF | Wrong Bus selected | Confirm correct Bus channel assigned |
+| RS485 unstable | Wiring issue | Check termination resistors and polarity (A/B swapped) |
+| All devices fail at once | Bus configuration changed | Confirm baud rate, parity, stop bits match |
+| Node shows “bus config missing” | Config node deleted | Reassign or recreate the Bus config |
+| Node invisible / unknown type | HTML/JS syntax error | Check node installtion, reinstall or contact smithtek support |
+
+## Golden Rule
+
+Always make your inject interval longer than your full device cycle time.
+
+Cycle time ≈ (Number of devices × transaction time + gap).
+
+If the inject interval is shorter than the cycle time, the queue will grow, timeouts will occur, and stability will suffer.
+
+Slow and stable always beats fast and failing.
+
+
+
+
+
+
+
+---
+# License
+Copyright (c) 2023 www.smithtek.com.au Licenced under the terms of the GPLv3
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED. IN NO EVENT SHALL DAMIEN CLARK BE LIABLE FOR ANY DIRECT,
+INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
+OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+www.smithtek.com.au
+