AU2009222508A1

AU2009222508A1 - A method, apparatus and system for alerting traffic

Info

Publication number: AU2009222508A1
Application number: AU2009222508A
Authority: AU
Inventors: Conrad Robert Marder; Joel Stephen Murray; Robert Graham Priestley
Original assignee: Inventis Tech Pty Ltd
Current assignee: INVENTIS TECHNOLOGY Pty Ltd
Priority date: 2007-03-12
Filing date: 2009-10-01
Publication date: 2009-10-22

Description

S&F Ref: 799400AUD1 AUSTRALIA PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT Name and Address Inventis Technology Pty Limited, of Applicant: an Australian Company, ACN 002 877 312, of Block A, Unit 40, 1-3 Endeavour Road, Caringbah, New South Wales, 2229, Australia Actual Inventor(s): Joel Stephen Murray Conrad Robert Marder Robert Graham Priestley Address for Service: Spruson & Ferguson St Martins Tower Level 35 31 Market Street Sydney NSW 2000 (CCN 3710000177) Invention Title: A method, apparatus and system for alerting traffic The following statement is a full description of this invention, including the best method of performing it known to me/us: 5845c(232201 11) -1 A METHOD, APPARATUS AND SYSTEM FOR ALERTING TRAFFIC Copyright Notice This patent specification contains material that is subject to copyright 5 protection. The copyright owner has no objection to the reproduction of this patent specification or related materials from associated patent office files for the purposes of review, but otherwise reserves all copyright whatsoever. Field of the Invention The present invention relates generally to traffic control and, in 10 particular, to a method, apparatus and system for visually alerting traffic. The present invention also relates to a computer readable medium having recorded thereon a computer program for providing traffic with a visual alert. Background The use of passive reflectors, particularly retro-reflectors, as traffic 15 visual alert devices, is well known. Such devices have been used, for example, for marking lanes, central dividers, pedestrian crossings, aircraft runways and motorway exit lanes. Passive reflectors have also been used to mark utilities such as fire hydrants, for example, to enable easy location by emergency services. 20 Passive signs and indicators quickly become familiar and are easily ignored. Further, passive indicators of day- and/or time-based zone activations can be confusing or non-obvious to drivers. More recently traffic visual alert devices have become active. Active traffic alert devices typically comprise a power source or sources, electronic 25 circuitry and an active alert indicator. The active alert indicator is typically, but not exclusively visual, such as Light Emitting Diodes (LEDs). Traffic visual alert devices are typically mounted on top of, or into a road or pavement surface to provide some form of alert information to traffic. Traffic visual alert devices, either passive reflective types, active light- -2 emitting type or mixed types, are often referred to as in-road or in-pavement alert devices, road markers, traffic indicators or road studs. Hereinafter, the devices discussed above will be referred to in a general sense as "traffic visual alert devices", or "visual alert devices", while devices incorporating other 5 forms of information transfer, for example audible alerting, are implicitly considered as being included within these terms. Some known traffic visual alert devices comprise LEDs and other visual light emitters. Some known in-road traffic visual alert devices also include a microprocessor or similar component for executing firmware 10 instructions, for monitoring sensors and for the logging of local data. The physical construction of conventional in-road traffic visual alert devices involves a reflector and/or active circuitry embedded within a potting compound filling the entirety of a typically plastic shell. This form of construction, involving filling with a potting compound, is done to provide 15 adequate physical strength to the in-road traffic visual alert device. The in road traffic visual alert device is then either bonded to a road surface using a special adhesive, or mounted into a road surface that has been prepared using core-drilling or other excavation technique. A combination of such bonding and mounting methods is also known. 20 Active traffic visual alert devices are likely to require maintenance, albeit at long intervals of several years, for example, to replace the internal battery, where such components have a lifetime shorter than the required lifetime of the alert device. Conventionally constructed traffic visual alert devices, particularly those involving a potted construction, suffer from the 25 disadvantage of difficulty in accessing internal components within the in-road traffic visual alert device for repair, replacement or regular maintenance. Therefore, the potted construction method significantly increases the likelihood of in-road traffic visual alert devices being disposed of and replaced rather than being maintained, thereby creating a cost disadvantage. 30 Some conventional in-road traffic visual alert devices comprise a unique identifier (ID) or address by which the device can be controlled or monitored by, for instance, a remote controller. A mapping of physical location to unique ID is typically provided to either or both of the remote -3 controller or a central management facility. However, installation and commissioning of a system incorporating a large number of such in-road traffic visual alert devices at a single site, each device incorporating a unique ID, involves some problems and inefficiencies. Where a large number of in 5 road traffic visual alert devices are to be installed and commissioned, the installation and commissioning operation is time-consuming and costly and has the risk of re-work if a device is later discovered to be faulty. The identification of an in-road traffic visual alert device ID, or of mapping between an ID of an in-road traffic visual alert device and the 10 physical location of the device can be prepared in advance of an installation and commissioning process. However, such advance planning methods for installation and commissioning are sensitive to disruptions of failure of devices and their need for replacement, and accidental changes to the selection order of devices. 15 There can be difficulties and costs involved in individually identifying and verifying the in-system operation of each installed in-road traffic visual alert device. Since an installation and commissioning process could extend over several days, one problem is the potential risk of shortening the lifetime of installed in-road traffic visual alert devices whilst trying to verify their 20 operation and/or ID-location mapping. Such risks must be avoided or the long-term efficacy of the in-road traffic visual alert system will be at risk. One known in-road traffic visual alert device contains a preset unique ID or address via a printed circuit board (PCB) setting that allows the device to be identified, selected and reconfigured remotely by an operator via a 25 laptop, software configuration tool and a controller station. Another known active traffic visual alert device has embedded within it a firmware set that can be reconfigured under external control. However, conventional methods of reconfiguring such in-road traffic visual alert devices is disadvantaged if a feature or configuration was not previously anticipated at 30 production time for the firmware installed in the in-road traffic visual alert device. Conventional methods of reducing energy consumption are not appropriate for in-road traffic visual alert devices powered by non- -4 rechargeable batteries. Energy consumption occurring during the periods of normal operation of such devices cannot be replenished from another source and would therefore shorten the life expectancy or the maintenance period of the future installed in-road device. 5 Another known in-road traffic visual alert device incorporates active power management through the selection of an appropriate operating mode. A microprocessor-firmware combination selects an operating mode based on sensed and preset parameters such as available energy level(s), known energy source characteristics, and known target power consumption for each mode. 10 Each mode involves combinations of activated and deactivated device functions dependent on the known power consumption and the target total power consumption for the relevant mode. Another known in-road traffic visual alert device is configured to discover when other in-road traffic visual alert devices become active and 15 jump into an active mode, apparently synchronizing with the other in-road traffic visual alert devices. Such a device is disadvantaged by the extra cost of having in-road traffic visual alert devices communicate with or monitoring each other. The additional cost is recognized in either or both the addition of extra sensors or the additional communications bandwidth or time and power 20 consumption required for in-road traffic visual alert devices to communicate with or monitor each other as well as communicate with or monitor the remote controller or repeater stations. Furthermore, vagaries of local topology, weather and traffic or other obstructions affect or nullify the communications consistency behaviour of such devices. 25 Brief Summary of the Invention It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements. There is increased recognition of the need and advantages of improving the signalling of information to road, pedestrian, emergency vehicle 30 and runway traffic. An in-road traffic visual alert system for providing precise information and simple indication of an activation state of a school safety zone is -5 described. By flashing indicators directly in the path of oncoming traffic and in the direct line of sight of drivers a high degree of conscious driver-attention for an active school safety zone is gained. Consequently, drivers are directly informed of which of the alternative zone states are currently active or 5 applicable. The in-road traffic visual alert system comprises in-road traffic visual alert devices typically installed into the lane markings within a stretch of roadway in a school zone. The in-road traffic visual alert devices are controlled and monitored by a remote controller station and possibly a number 10 of repeaters, also forming part of the in-road traffic visual alert system. Although the described in-road traffic visual alert system has application within a school zone, the traffic visual alert system may be used in many other application and situations. For example, the traffic visual alert system may be used for pedestrian warnings, for railway crossing warnings, 15 for indicating emergency vehicle access, for animal (e.g., cattle) crossing warnings, for fog warning and for lane delineation. According to one aspect of the present invention there is provided an apparatus for communicating with a traffic alert device, said apparatus comprising: 20 interface means for selecting information on the apparatus; and transmission means for transmitting the selected information to said traffic alert device, via wireless communication, in order to modify the behaviour of said traffic alert device. According to another aspect of the present invention there is provided 25 a method of programming a traffic alert device, said local method comprising the steps of: selecting information on a local programming tool; and transmitting the selected information to said traffic alert device, via wireless communication, in order to modify the behaviour of said traffic alert 30 device. According to another aspect of the present invention there is provided an apparatus for mounting on or into a road or pavement surface, said apparatus comprising: -6 a base housing configured to be mounted on or into the road or pavement surface; and an assembly configured to be fixed to the base housing, the assembly comprising: 5 at least one indicator for producing illumination providing a visual alert to traffic; a receiver for receiving commands and/or data, via wireless communication, from another device within a traffic visual alert system; and 10 a processor for processing said commands and/or data from said other device to control the illumination produced by the indicator, wherein the assembly is configured to be removable from the base housing while the base housing remains mounted on or into the road or pavement surface. 15 According to still another aspect of the present invention there is provided a method of operating a traffic visual alert device within a traffic visual alert system, said device being installed into or onto a road or pavement surface, said method comprising the steps of: controlling power to at least one power-consuming subsystem within 20 the device based on time, to establish alternative modes of operation and power consumption; communicating commands and/or data between the traffic visual alert device and the traffic visual alert system based on said modes of operation and power consumption using a time-based communications frame; and 25 switching between said power-consumption modes at least once during said time-based communications frame. According to still another aspect of the present invention there is provided a computer readable medium, having a program recorded thereon, where the program is configured to make a processor execute a procedure to 30 program a traffic alert device, said program comprising: code for selecting information on a local programming tool; and code for transmitting the selected information to said traffic alert -7 device, via wireless communication, in order to modify the behaviour of said traffic alert device. According to still another aspect of the present invention a computer readable medium, having a program recorded thereon, where the program is 5 configured to make a processor execute a procedure to operate a traffic visual alert device within a traffic visual alert system, said device being installed into or onto a road or pavement surface, said program comprising: code for controlling power to at least one power-consuming subsystem within the device based on time, to establish alternative modes of operation 10 and power consumption; code for communicating commands and/or data between the traffic visual alert device and the traffic visual alert system based on said modes of operation and power consumption using a time-based communications frame; and 15 code for switching between said power-consumption modes at least once during said time-based communications frame. Additional aspects and advantages will be apparent upon consideration of the ensuing drawings and description. Brief Description of the Drawings 20 Fig 1 A shows an isometric view of a traffic visual alert device for mounting in-road; Fig I B shows a side elevation view of the traffic visual alert device of Fig IA; Fig I C shows an end elevation view of the traffic visual alert device of 25 Fig IA; Fig 1 D shows a plan (top) view of the traffic visual alert device of Fig IA; Fig 1E shows a plan (bottom) view of a base housing of the in-road traffic visual alert device of Fig IA; 30 Fig IF shows a cross-section side elevation view of the in-road traffic visual alert device of Fig IA; -8 Fig I G shows a partially exploded view of the in-road traffic visual alert device of Fig IA showing replaceable, functional sub-assembly; Fig 1 H shows an exploded view of the in-road traffic visual alert device of Fig lA; 5 Fig. I I shows an isometric view of another traffic visual alert device for mounting in-road; Fig. I J shows a side elevation view of the traffic visual alert device of Fig 11; Fig I K shows an end elevation view of the traffic visual alert device of 10 Fig 11; Fig IL shows a plan (top) view of the traffic visual alert device of Fig 1I; Fig I M shows a partially exploded view of the in-road traffic visual alert device of Fig 1I showing replaceable, functional sub-assembly; 15 Fig IN shows a partially exploded view of another in-road traffic visual alert device; Fig 2 is a schematic drawing of an example traffic visual alert system incorporating the in-road traffic visual alert device according to either of Figs. IA or 11; 20 Fig 3 is a schematic drawing the traffic visual alert system of Fig 2 in more detail; Fig 4A shows a typical waking zone communications event sequence within the traffic visual alert system of Fig 2; Fig 4B shows an 'all devices addressing frame': a typical 25 communications and synchronization frame within the traffic visual alert system of Fig 2; Fig 4C shows an RF Communications timeslot detail within an 'All devices addressing frame'; Fig 5 is a block diagram representation of the in-road traffic visual 30 alert device of Figs IA or 1I; Fig 6A is a detailed schematic drawing of an in-road traffic visual alert device CPU block, for use in the in-road traffic visual alert devices of either of Figs IA or 11; -9 Fig 6B is a detailed schematic drawing of an in-road traffic visual alert device LED driver block, for use in the in-road traffic visual alert device of either of Figs 1 A or II; Fig 6C is a detailed schematic drawing of an in-road traffic visual alert 5 device watchdog timer and inductive reset blocks, for use in the in-road traffic visual alert device of either of Figs IA or 11; Fig 6D is a detailed schematic drawing of in-road traffic visual alert device RF transmitter and receiver block, for use in the in-road traffic visual alert device of either of Figs IA or 1I; 10 Fig 7A is a flow diagram showing a first method of commissioning the in-road traffic visual alert device of Fig IA into the traffic visual alert system of Fig 2; Fig 7B is a flow diagram showing a second method of commissioning the in-road traffic visual alert device of Fig IA into the traffic visual alert 15 system of Fig 2; Fig 8A is a flow diagram showing a method for selecting and transmitting information to the in-road traffic visual alert device of either of Fig IA or II; Fig 8B is a flow diagram showing a method of waking-up the in-road 20 traffic visual alert device of Figs. IA or 11 and then transmitting information to the in-road traffic visual alert device; Fig 9A is a flow diagram showing a method of installing and verifying a series of the in-road traffic visual alert devices of Figs. IA or 11; Fig 9B is a flow diagram showing a method of completing installation 25 of a series of the in-road traffic visual alert devices of Figs. I A or 1I; Fig 1OA is a flow diagram showing a MAIN_BOOT method as executed by the in-road traffic visual alert device of Figs IA or 1I; Fig 1OB is a flow diagram showing a MAIN LOOP method as executed by the in-road traffic visual alert device of Fig. IA or 1I; 30 Fig I OC is a flow diagram showing a background method as executed by the in-road traffic visual alert device of Figs IA or 1I; Fig. 1OD is a flow diagram showing a method executed by the in-road traffic visual alert device of Fig. IA or II when the device boots up after reset; -10 Fig I OE is a flow diagram showing a TOGGLELEDS method for toggling LED orientation of the in-road traffic visual alert device of Figs IA or II; Fig 1 OF is a flow diagram showing a DEACTIVATION method as 5 executed by the in-road traffic visual alert device of Figs IA or 1I; Fig I1 shows a local programming tool (or "wand") for use with the in-road traffic visual alert device of Figs 1 A or 1I; Fig 12 is a block diagram representation of the local programming tool (or "wand") of Fig 11; 10 Fig 13 is a block diagram representation of the traffic visual alert repeater of Fig. 3; Fig 14 is a block diagram representation of the traffic visual alert controller of Fig. 3; Fig 15A is a detailed schematic of a traffic visual alert repeater or local 15 programming device CPU block; Fig 15B is a detailed schematic of a traffic visual alert repeater or local programming device power supply block; Fig 15C is a detailed schematic of a traffic visual alert repeater or local programming device watchdog timer and reset block; 20 Fig 15D is a detailed schematic of a local programming device inductive wake-up transmitter block; Fig 15E is a detailed schematic of a traffic visual alert repeater or local programming device receiver block; Fig 15F is a detailed schematic of a traffic visual alert repeater or local 25 programming device transmitter block; and Fig 16 is a flow diagram showing a method of operating the in-road traffic visual alert device of Figs. IA or 11. Detailed Description of the Invention It is to be noted that the discussions contained in the "Background" 30 section and that above relating to prior art arrangements relate to discussions of documents or devices which form public knowledge through their respective publication and/or use. Such should not be interpreted as a -11 representation by the present inventor(s) or patent applicant that such documents or devices in any way form part of the common general knowledge in the art. In the following description, certain specific details are set forth in 5 order to provide a thorough understanding of various disclosed embodiments. However, one skilled in the relevant art will recognize that embodiments may be practised without one or more of these specific details, or with other methods, components, materials, etc. Reference throughout this specification to "one embodiment" or "an 10 embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one of the described embodiments. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. 15 Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. Elements appearing in more than one figure and with the same reference number are intended to represent the identical type or instance, depending on context, unless otherwise noted in the text. 20 Visual alert devices and systems have been described below. However, audible alerting may also be used. As discussed above, audible alerting is implicitly considered as being included within the terms "traffic visual alert devices", or "visual alert devices". Fig. I A shows an isometric view of an in-road traffic visual alert 25 device 199A. Fig. I B shows a side elevation of the in-road traffic visual alert device 199A. Fig. 1C shows an end elevation view of the in-road traffic visual alert device 199A. Fig. ID shows a plan, top view, of the in-road traffic visual alert 30 device 199A. As seen in Figs. IC and ID, the in-road traffic visual alert device 199A comprises indicators in the form of two sets of LEDs I1 OA and 110C. The LEDs 11 OA and 11 OC are configured for producing illumination providing a visual alert to traffic.

-12 Fig. I E shows a plan, bottom view of a base housing 1I1A portion of the in-road traffic visual alert device 199A. The base housing 1I1A is configured to be mounted on or into a road or pavement surface. Also shown are eight screw-bosses (e.g., 11 2A) in the base housing 111 A for fixing a 5 remaining, replaceable sub-assembly portion (the sub-assembly portion 190A in Fig. IG) of the in-road traffic visual alert device 199A. The base housing I 1IA may be formed of die cast zinc and is designed to remain installed on or into the road or pavement surface, providing a long-life mounting platform onto which replacement or repaired sub-assemblies 190A may be mounted. 10 Fig. IF shows a side elevation cross-section of the in-road traffic visual alert device 199A. The position of the LEDs IOA and IOC is indicated. The LEDs 11 OA and II OC are placed in two sets, potentially facing oncoming traffic in two opposing directions. The circuitry on PCB sub-assembly 130A receives control and data signals from an antenna 122A and controls the LEDs 15 11 OA and II OC accordingly. The in-road traffic visual alert device 199A is powered by batteries held in a battery compartment 120A which recesses into a buried stalk and upper fluted portion comprising the base housing IIIA. An outer shell 140A is moulded from glass-filled nylon or similarly strong material and provides protection to the inner components from weight and 20 momentum of incident traffic and also provides a weather seal with the base housing IilA. The outer shell 140A is heat-staked 121 A to the battery compartment 120A, thereby forming the replaceable sub-assembly 190A comprising all components, including the active circuitry and LEDs 11 OA and 1 IOB, excluding the base housing I IIA. Thus, the in-road traffic visual alert 25 device 199A is configured for the efficient repair or replacement of the active portion of the in-road traffic visual alert device 199A without requiring removal and possible destruction or re-mounting of the base housing 11 IA. The outer shell 140A provides an air-gap between its underside and antenna 122A and other components within the PCB assembly 130A. The 30 outer shell 140A is formed of strong enough construction to support required loads without the need for potting support and with adequate clearance for flexion as shown in Fig. IF. Therefore, the in-road traffic visual alert device -13 199A is provided with easy access to internal components allowing low cost diagnosis, maintenance and potentially re-use of sub-systems or components. Fig. IG shows a partially-exploded isometric view of the in-road traffic visual alert device 199A, comprising the base housing I 11A into which 5 is inserted and affixed the replaceable sub-assembly 190A by screws 144A through the outer shell 140A and battery compartment 120A into screw bosses 112A. Screw covers 142A are fitted over the screws 144A to complete the domed shape of the device 199A. Fig. 1H shows an exploded view of the in-road traffic visual alert 10 device 199A. The device 199A comprises the major components of the base housing 1I1A, battery compartment 120A, outer shell 140A and Printed Circuit Board (PCB) assembly 130A. Other components include clear lenses 148A fitted into the outer shell moulding 140A, LED support brackets 150A, screws 144A, screw covers 142A, mounting plates 146A, gasket 152A, battery 15 compartment cap 158A, Lithium-Ion non-rechargeable battery set 160A and battery boot 162A. The lenses 148A may be of any colour suitable for providing the visual alert to traffic. The in-road traffic alert device 199A may be built in shapes other than that shown in Figs. 1A to IH. For example, a circular shape suitable for 20 mounting the in-road traffic alert device 199A into the road or pavement surface through core-drilling methods may be used. Also, a 'submerged' in road traffic visual alert device may have a longer lifetime due to the traffic alert device receiving less structural distress than anticipated. Furthermore, a submerged traffic alert device may be more suitable for areas operating snow 25 ploughs in winter. Fig. 1I shows an isometric view of an in-road traffic alert device 199B. Fig. IJ shows a side elevation of the in-road traffic visual alert device 199B. Fig. I K shows an end elevation view of the in-road traffic visual alert 30 device 199B. Fig. IL shows a plan, top view, of the in-road traffic visual alert device 199B. As seen in Figs. 1K and IL, the in-road traffic visual alert device 199B comprises one set of LEDs 1 10B as opposed to the two sets of LEDs II OA and 11 OC of the device 199A of Fig. IA. The set of LEDs 11B -14 may be formed from fourteen (14) LEDs. The set of LEDs 1 IOB potentially faces oncoming traffic. The in-road traffic visual alert device 199B is therefore mono-directional. The in-road traffic visual alert device 199B comprises an outer shell 5 140B (or "lens") which may also be moulded from glass-filled nylon or similarly strong material and provides protection to the inner components (i.e., active portion) from weight and momentum of incident traffic and also provides a weather seal with a base housing I 1lB. The outer shell 140B may be of any suitable colour to provide the visual alert to traffic. The base 10 housing 111 B is configured to be mounted on or into a road or pavement surface. The in-road traffic visual alert device 199B is configured for the efficient repair or replacement of the active portion of the in-road traffic visual alert device 199B without requiring removal and possible destruction or re mounting of the base housing 111 B on or in the road or pavement surface. 15 The outer shell 140B is formed of strong enough construction to support required loads without the need for potting support and with adequate clearance for flexion. Therefore, the in-road traffic visual alert device 199B is provided with easy access to internal components allowing low cost diagnosis, maintenance and potentially re-use of sub-systems or components. 20 Fig. IM shows a partially-exploded isometric view of the in-road traffic visual alert device 199B, comprising the base housing I 1B into which is inserted and affixed a replaceable sub-assembly 190B. The sub-assembly 190B is affixed by screws (not shown) through the outer shell 140B and an inner shell 141B into screw bosses 112B. The sub-assembly 190B comprises 25 all components, including the active circuitry and LEDs 11 OB and substantially forms the active portion of the in-road traffic visual alert device 199B. As with the base housing 1I1A, the base housing 111 B may be formed of die cast zinc and is designed to remain installed. The base housing 11 B 30 provides a long-life mounting platform onto which replacement or repaired sub-assemblies 190B may be mounted. As described above, the base housing I IB may remain installed on or in the road or pavement surface, while the sub-assembly 190B is being replaced.

-15 Fig. IN shows a partially-exploded isometric view of an in-road traffic alert device 199C. The in-road traffic visual alert device 199C of Fig. IN comprises one set of LEDs (not shown) as opposed to the two sets of LEDs 11 OA and 11 OC of the device 199C of Fig. IA. In one example, the set of 5 LEDs of the device 199C may be formed from fourteen (14) LEDs as with the device 199B. The set of LEDs of the in-road traffic visual alert device 199C potentially faces oncoming traffic. The in-road traffic visual alert device 199C is therefore mono-directional. The in-road traffic visual alert device 199C comprises an outer shell 10 140C (or "lens") which may also be moulded from glass-filled nylon or similarly strong material. The outer shell 140C may be of any suitable colour to provide the visual alert to traffic. The outer shell 140C provides protection to inner components (i.e., an active portion including active circuitry and the LEDs) from weight and momentum of incident traffic and also provides a 15 weather seal with a base housing 111C. The base housing 111 C is configured to be mounted on or into a road or pavement surface. The in-road traffic visual alert device 199C is configured for efficient repair or replacement of the active portion of the in-road traffic visual alert device 199C, without requiring removal and possible destruction or re-mounting of the base housing 111 C on 20 or in the road or pavement surface. The outer shell 140C is formed of strong enough construction to support required loads without the need for potting support and with adequate clearance for flexion. Therefore, the in-road traffic visual alert device 199C is provided with easy access to internal components allowing low cost diagnosis, 25 maintenance and potentially re-use of sub-systems or components. The in-road traffic visual alert device 199C comprises a replaceable sub-assembly 190C which is inserted and affixed into the base housing 111C. The sub-assembly 190C is affixed by four (4) screws 195C through the outer shell 140C into screw bosses (e.g., 112C). The sub-assembly 190C comprises 30 all components, including the active circuitry and LEDs, and substantially forms the active portion of the in-road traffic visual alert device 199C. As with the base housing 1I1A, the base housing 111 C may be formed of die cast zinc and is designed to remain installed. The base housing 111 C -16 provides a long-life mounting platform into which replacement or repaired sub-assemblies 190C may be mounted. As described above, the base housing 111 C may remain installed on or in the road or pavement surface, while the sub-assembly 190C is being replaced. 5 The traffic visual alert device 199A of Figs. IA to I H, the traffic visual alert device 199B of Figs. 11 to IM and the traffic visual alert device 199C will be generally referred to below as the traffic visual alert device 199, unless specifically referred to, with the description being applicable to either the device 199A of Fig. IA to IH, the device 199B of Figs. II to IM or the device 10 199C of Fig. IN. Similarly, the base housings 1I1A, 11 B and II IC will be generically referred to below as the base housing 111, unless specifically referred to. The outer shells 140A, 140B and 140C will be generically referred to below as the outer shell 140, unless specifically referred to. The sub-assemblies 190A, 190B and 190C will be generically referred to below as 15 the sub-assembly 190, unless specifically referred to. Further, the two sets of LEDs 11 OA and 11 OC of the device 199A, the set of LEDs 11 OB of the device 199B and the set of LEDs of the device 199C, will be generically referred to below as the LEDs 110, unless specifically referred to. As described above, the traffic visual alert device 199 is modular in 20 nature allowing service to be performed on the device 199 while the base housing 11I remains installed on or in a road or pavement surface. The various parts of the traffic visual alert device 199, such as the outer shell 140 and sub-assembly 190, may be easily replaced, while the base housing 111 remains installed on or in the road or pavement surface. For example, a 25 scratched and damaged outer shell 140 may be replaced without removing the base housing 111 from the road or pavement surface. As described above, the LEDs 110 are configured to produce illumination in order to provide a visual alert to traffic. The LEDs 110 can be of any suitable colour in order to provide that visual alert. As the LEDs 110 30 may be replaced together with the sub-assembly 190, the colour of the LEDs 110 may be changed as required in order to provide the visual alert. The outer shells (or lenses) 140A, 140B and 140C of the in-road traffic alert devices 199A, 199B and 199C, respectively, may be replaced in each -17 case by different types of lenses depending on the use and installation of the devices 199A, 199B and 199C. For example, the outer shells (or lenses) 140A, 140B and 140C may be flat lens that direct the light up. Alternatively, the outer shells 140A, 140B and 140C may be configured to provide radial 5 light distribution. Fig. 2 shows a traffic visual alert system 200 installed in a section of roadway including a school safety zone. The school safety zone is signposted at entry with a conditional speed sign 208 in both traffic directions 216 and is also signposted with exit-speed signs 210 in both traffic directions. The traffic 10 visual alert system 200 is shown comprising multiple in-road traffic visual alert devices 199 installed in the lane divider or markings at regular intervals along the length of the school zone. The in-road traffic visual alert devices 199 are typically installed at between two (2) metres and six (6) metres spacing and along a line of travel of oncoming traffic and ideally emitting visual 15 warnings directed into the line of sight of drivers. The traffic visual alert system 200 also comprises a controller station 202 (or controller) and one or more repeaters 204. The function of the controller station 202 is to manage the traffic visual alert system 200 through intra-system radio frequency (RF) communications. 20 The controller station 202 also provides an interface between the traffic visual alert system 200 and a central management controller (not shown) which controls a number of such sites and systems. The controller station 202 uses proprietary low power radio communications, as described in more detail below, to communicate with the 25 in-road traffic visual alert devices 199 and repeaters 204. The controller station 202 receives commands and communicates with the central management controller via a Wide Area Network (WAN), such as the Global System for Mobile Communications (GSM). A repeater 204 is used to increase RF communications coverage area 30 of the controller station 202. The number of repeaters 204 per school zone will depend on environmental conditions such as the length of the school zone, road and surrounding topology, line of site, building structures etc. Further, all of the RF communications between the controller station 202, the in-road -18 traffic visual alert devices 199 and repeaters 204, is preferably performed at low frequency (e.g., 433MHz) in order to maximise ground performance and balance. The low frequency communication increases the range of the RF communications coverage area over conventional traffic visual alert systems. 5 Any suitable RF frequency, including the industrial, scientific and medical (ISM) radio bands (e.g, 315MHz, 433MHz and 810MHz), may be used for the RF communications, with the lower bands (e.g., 433MHz) being found to maximise the RF communications coverage area. The inventors have found that a communication range between the controller station 202 and the in-road 10 traffic visual alert devices 199 of greater than one hundred and fifty (150) meters may be achieved using the lower RF communications frequencies (e.g., 433MHz). On entering a school zone as shown in Fig. 2, a driver of a vehicle will be able to immediately determine if a modified speed limit is in force, i.e. if 15 the school safety zone is active, by observing if the in-road traffic visual alert devices 199 pointing towards her vehicle are flashing. The in-road traffic visual alert system 200 informs a driver of the active school safety zone without requiring the driver to take her eyes from the road to, for instance, view a roadside sign or indicator. Furthermore, the time-controlled nature of 20 the in-road traffic visual alert system 200 means that a driver need not perform a mental calculation on entry to the school zone to determine whether she has arrived within an active period for the zone. Although the described in-road traffic visual alert devices 199A, 199B and the system 200, have application within a school zone, the traffic visual 25 alert devices 199A, 199B and system 200 may be used in many other application and situations. For example, the in-road traffic visual alert devices 199A, 199B and the traffic visual alert system 200 may be used for pedestrian warnings, for railway crossing warnings, for indicating emergency vehicle access, for animal (e.g., cattle) crossing warnings, for fog warning and for lane 30 delineation. Referring to Fig. 3, the traffic visual alert system 200 has a scalable architecture with a configuration that can be selected for the characteristics of any particular locale. A minimum configuration of the traffic visual alert -19 system 200 for any locale comprises one controller station 202, at least one (and typically multiple) in-road traffic alert device 199 and possibly one or more repeaters 204. Two repeaters 204 are shown as present in the traffic visual alert system 200 of Figs. 2 and 3. 5 The controller station 202 receives commands from a central management controller (CMC) 344 via GSM radio links 342 and 328 in WAN 326, part of the wider management and network facility 320. Other management centres 340 and alert systems 200 may also be linked into the WAN 326. The controller station 202 also reports system status and fault 10 information back to the CMC 344 via the same network 326 and paths 328 and 342. The controller station 202 translates and relays a command or data to the local traffic visual alert system 200 via RF communications link 380. All in road traffic alert devices 199 and repeaters 204 within range of the controller station 202 receive the transmissions and act on them or relay them. 15 The repeaters 204 relay commands and data from the controller station 202 or other repeaters 204 and the repeaters 204 also relay responses from other repeaters 204 and in-road traffic visual alert devices 199. The repeaters 204 may be positioned to ensure reliable communications between in-road traffic alert devices 199 and the rest of the traffic visual alert system 200. In 20 any particular installation site, some in-road traffic visual alert devices 199 may be in range of multiple repeaters 204, for example via 384 and 386 to 382 or 388, and possibly also including the controller 202 via 380. Thus in-road traffic visual alert devices 199 receive at least one copy of a command transmission from either a controller station 202 or a repeater 204 or some 25 combination of the controller station 202 or the repeater 204. The alert system 200 is configured to communicate so that multiple receipts of a command or data may still result in correct operation of a recipient in-road traffic visual alert device 199. Similarly, the duplication or multiplication of in-road traffic visual alert device responses by several repeaters 204 back to the controller 30 station 202 may still result in correct operation of the in-road traffic visual alert devices 199 within the system 200, because the controller station 202 will overwrite earlier copies of the received response with later copies.

-20 In the system 200 described above, a non-volatile memory card, such as a Secure Digital (SD) card, is preferably used for storing historical data. For example, each of the controller stations 202 and repeaters 204, may include a non-volatile memory card such an SD card or the like for storing 5 commands, data, system status and fault information. Accordingly, if the system 200 fails, historical commands, data and information are still accessible. Further, duplicate copies of commands, data and responses of the in-road traffic visual alert devices 199, may be stored in such SD cards various in a plurality of the repeaters 204, improving the reliability of the system 200. 10 The in-road traffic visual alert devices 199, controller station 202 and repeaters 204 may be battery operated and configured for high performance whilst maintaining extremely long-term battery life, as will be described below. This is particularly a requirement for the in-road traffic visual alert device 199 which is expected to perform for several years from a non 15 rechargeable battery set (1 60A in Fig. IH). The battery set (e.g., 160A) of all of the in-road traffic visual alert devices 199A, 199B and 199C, are replaceable, together with the corresponding sub-assembly, increasing the operational life of installed devices 199. A time-multiplexed packet signalling method may be used to obtain 20 the benefits of scalability, fast response, auto-synchronisation, robust response to RF communications noise, and maximised battery lifetime. Figs. 4A and 4B shows two schedules 401 and 402 for illustrating a packet signalling method at two time-scales. Fig 4A shows a twenty four (24) hour schedule 401 over a period of twenty four hours 410 with a resolution of five (5) minutes. Fig. 4B 25 shows a magnified five (5) minute schedule 402 over a period of five (5) minutes 424 with resolution of a few seconds. Referring to Figures 4A and 4B, the packet signalling method and its advantages over conventional methods will be explained in detail. The controller station 202 regularly broadcasts, to the in-road traffic 30 visual alert devices 199, a local system time reference and current system 200 configuration parameters, sleeping and waking times, etc. The repeaters 202 receive and relay such broadcasts. The in-road traffic visual alert device 199 receives at least one such broadcast intended for the device 199 in an -21 addressing cycle period 424. The devices 199 and the repeaters 204 utilise the broadcast information to synchronise their internal clocks, and optionally calendars, and resultant behaviour to the controller station 202. While the in-road traffic visual alert devices 199 are not in the alerting 5 (indicating or flashing) state they conserve battery power by powering down all of the internal circuits with the exception of a microprocessor low-power real time clock. The in-road traffic visual alert device 199 comprises an internal clock which is synchronised to the broadcast system time reference. The 10 combination of the internal clock and the system parameters indicate to the in road traffic visual alert device 199 when to power-up parts of its internal functionality in synchronism with other parts of the system 200 and to exchange information. Such a synchronised communications and power management method provides significant advantages in terms of fast 15 responsiveness and considerable power savings, providing for a long battery lifetime and therefore a very infrequent maintenance requirement. The in-road traffic visual alert device 199 internal synchronisation supports the following modes of operation: 0 Dead Zone 414: The in-road traffic visual alert device 199 deactivates 20 outside of alert zone activation times (typically at night). Active and Passive check-in are reduced in frequency to reduce power consumption; * Waking Zone 412: The in-road traffic visual alert device 199 is maintaining frequent communication with the system 200, switching through a sequence of modes to maximise battery life; 25 e Passive Mode: The in-road traffic visual alert device 199 will frequently power-up in Passive Mode, with its receiver active, ready to receive incoming commands from the controller station 202 or repeater 204. Passive Mode occurs twice every minute during the in-road traffic visual alert device 199 Waking Zone. 30 e Active Mode: Once every five (5) minutes in the Waking Zone, the in-road traffic visual alert device 199 will power-up in Active Mode, during which the device 199 sends status information to the controller station 202.

-22 " Sleep Mode 478 and 498: The in-road traffic visual alert device 199 powers-down most internal circuitry as frequently as possible to conserve battery life and this is called Sleep Mode. " Deep Sleep Mode: The in-road traffic visual alert device 199 powers-down 5 all internal circuitry for maximum power conservation suitable for storage or transit. The controller station 202 within the traffic visual alert system 200 communicates with the in-road traffic visual alert devices 199 in a carefully arranged periodic cycle to minimise power consumption in all the in-road 10 traffic visual alert devices 199 and to reduce chances of RF communications overlaps. This periodic cycle has several variables that may be factory-set to prioritise particular requirements for any or all target sites. The following description of timing operations is for one example. Many variations are possible on this description, and may be performed by varying many of the 15 parameters described below. The described traffic visual alert system 200 has the advantages of scalability to very large numbers of in-road traffic visual alert devices 199, scalability to long or complex sections of roadway, fast and synchronised responsiveness, very low power consumption and infrequent maintenance requirements, low RF transmission power requirements and high 20 flexibility in configuration and functionality. Figs. 4A and 4B illustrates typical communications operations periodicity at two levels of timing. The schedule 401 of Fig. 4A represents a typical 24-hour period 410 including a normal school day in which the school safety zone activation 428 occurs for two periods. The schedule 402 of Fig 4B 25 shows an exploded view of a five (5)-minute period 424 of the Waking Zone 412 in the 24 hour cycle 410. The 'Dead Zone' 414 is a period of very low power consumption that occurs outside of the expected school safety zone activation time 428. The Dead Zone 414 is typically factory-set into the controller station 202, repeaters 30 204 and in-road traffic visual alert devices 199 to reduce power consumption and increase lifetime of the controller station 202, repeaters 204 and traffic alert devices 199. During the Dead Zone 414, as shown, communication occurs rarely 416 and only for the purposes of maintaining device -23 synchronisation and to allow programming flexibility for the activation periods 428. Note that a Dead Zone 414 is not duplicated by ceasing transmissions during a Waking Zone 412. If this is attempted, the controller station 202, 5 repeaters 204 and traffic alert devices 199 will begin hunting for synchronisation signals and consequently may draw excessive power from their batteries. The Dead Zone period 414 specifically reduces the synchronisation hunting behaviour of the controller station 202, repeaters 204 and in-road traffic visual alert devices 199 to conserve power. 10 As illustrated in Fig. 4A, the Dead Zone 414 is pre-set to end some time 418 (typically at least 30 minutes) before the expected first school safety zone activation time (shown as the left-hand item 428 in Fig. 4A). The Waking Zone 412 is complementary to the Dead Zone 414 in a general 24 hour period 410. During the Waking Zone 412, the controller station 202, 15 repeaters 204 and in-road traffic visual alert devices 199 enter regular communications and synchronisation cycles 424 in preparation for the school safety zone activation 420 and deactivation 422 commands. During the Waking Zone period 412, but prior to the school safety zone activation period 428, the controller station 202 sends in-road traffic visual alert device visual 20 warning 'Off commands, 418. At the beginning of the first school safety zone activation period 428 of a particular day, the controller station 202 begins to transmit visual alert 'On' signals 420 to the in-road traffic visual alert devices 199. This transmission 420 occurs repeatedly at a set interval during the school safety zone activation 25 period 428 and the in-road traffic visual alert devices 199 respond by flashing the appropriate forward 11 OA (or 1101B) and/or backward I1 OC visual warning LEDs. The pre-set command repetition rate is five (5) minutes 424, as shown in Fig. 4A. This repetition period 424 is called the 'All devices addressing cycle.' This 'All devices addressing cycle' (5 minute) period 424 is configured 30 to ensure that all system devices, including the controller station 202, repeaters 204 and in-road traffic visual alert devices 199 are each addressed at least twice for command transmissions (for example, in periods 470 and 476 or in periods 490 and 496, etc) and each controller station 202, repeater 204 and -24 traffic visual alert device 199 is addressed at least once (for example in period 472, or in another period such as 492) to allow collection of response transmissions including device status and fault information. It can be seen in Fig. 4A that the 'All devices addressing cycle' 424 5 repeats for the entire school safety zone activation period 428, in which the 'On' signals 420 are repeatedly sent until the end of the period. At the end of the first school safety zone activation period 428 of the day, the system 200 begins repeated transmission of an 'Off' signal 422. Like the 'On' signal 420, this 'Off signal 422 is repeated within every five-minute 'All devices 10 addressing cycle' 424 to ensure that the LEDs 110 for all in-road traffic visual alert devices 199 are switched off. At the start of the second school safety zone period 428 of the day (shown as the right-hand item 428 in Fig. 4A) the controller station 202 begins another activation period of repeated transmission 420 of 'On' commands in 15 the same manner as occurred in the first period activation period 428 of the day. After this second activation period 428, in the last portion of the Waking Zone 412, a series of 'Off' commands (i.e., represented by down arrows in Fig. 4A) are sent, in a similar method to those in period 418 at the commencement of the Waking Zone 412. Subsequently (after a preset period), 20 the Waking Zone 412 will end and the Dead Zone 414 will begin for each controller station 202, repeater 204 and traffic visual alert device 199. The in-road traffic visual alert devices 199 may be pre-set with a timeout period at least equalling the 'All devices addressing cycle' 424 period. So, if no signal is received by the in-road traffic visual alert devices 199 25 during a Waking Zone 412 then the in-road traffic visual alert devices 199 timeout and tum off their LEDs 110. In this circumstance, the in-road traffic visual alert devices 199 will begin to hunt for synchronising transmissions 454. The in-road traffic visual alert device 199 preset method of hunting for 30 synchronisation signals involves several stages of operation which are stepped through if and as the period without establishing synchronisation increases. Firstly, an in-road traffic visual alert device 199 allows some tolerance on receiver activation period when searching for synchronisation signals and its -25 own preset communications timeslot. Such tolerance allows for clock drift between various controller stations 202, repeaters 204 and traffic visual alert devices 199 in the alert system 200. If several 'All devices addressing cycles' 424 occur without receipt of a synchronisation signal 454 then the in-road 5 traffic visual alert device 199 begins to hunt for synchronisation signals. The in-road traffic visual alert device 199 synchronisation hunt initially involves the device 199 enabling its receiver (534 see Fig. 5) for 50ms periods every 200ms, listening for a synchronisation signal 454. This behaviour persists for ten minutes, during which the in-road traffic visual alert device 199 may have 10 encountered many opportunities to re-establish synchronisation. If this initial hunt failed then the in-road traffic visual alert device 199 will deactivate its receiver 534 and wait for fifty (50) minutes before repeating the ten (10) minute hunt, and so on until 24 hours is reached without synchronisation, after which the hunt rate will decrease to listening for ten minutes every eight 15 hours, repeating indefinitely. This synchronisation hunting method is designed to provide rapid synchronisation or re-synchronisation of an in-road traffic visual alert device 199, in typically milliseconds or seconds, to a controller station 202 or repeater 204. This is most likely to be relevant to an in-road traffic visual alert 20 device 199 being installed and commissioned and connecting to the system 200 for the first time, or if an in-road traffic visual alert device 199 temporarily loses synchronisation through an external event such as RF interference or maintenance being undertaken to part of a system 200. The decreasing hunt rate method, in which synchronisation hunting occurs at 25 increasingly longer intervals, is designed to reduce battery consumption within the in-road traffic visual alert device 199 in exchange for a less rapid resumption of synchronisation. An example of the advantages of such a hunting method is of a system 200 in which the controller station 202 is temporarily taken out of commission 30 for maintenance. If the controller station 202 is out of commission for a few minutes or hours then the in-road traffic visual alert devices 199 at the same site will re-establish synchronisation and normal operations within seconds or minutes after the controller station 202 is returned to normal functioning.

-26 However, if the controller station 202 is out of commission for several days then the in-road traffic visual alert devices 199 actively reduce their synchronisation hunting rates to minimise impact on their battery power consumption. However, once the controller station 202 is returned to normal 5 operation, the system 200 will be fully synchronised and operational within eight (8) to twenty four (24) hours. Synchronisation hunting is typically disabled during the Dead Zone 414. At the commencement of the Dead Zone 414, the controllers 202, repeaters 204 and in-road traffic visual alert devices 199 enter a power-saving 10 Sleep mode until the preset start time of the next Waking Zone period 412. During Dead Zone 414, the controllers 202, repeaters 204 and traffic visual alert devices 199 may be preset to wake-up and temporarily enter Passive Mode to synchronise and exchange commands on an infrequent basis 416. The purposes of this infrequent communication are to maintain synchronisation 15 and potentially receive prior-notice commands regarding changes to the next Waking Zone 412 period and operation parameters whilst maintaining minimal power consumption. During the major portion of the Dead Zone 414 each of the controllers 202, repeaters 204 and traffic visual alert devices 199 are in Sleep mode in which substantially all, or as much as possible, of the 20 internal functionality is suspended except for the processor's low-power clock-timer. For example, if an in-road traffic visual alert device 199 has been instructed to flash its LEDs 110 then in Sleep Mode the in-road traffic visual alert device 199 will power down as much circuitry as the in-road traffic visual alert device 199 can, but will correctly maintain the flashing LED 25 operation. The ratio of system device operating time spent in various modes, for example time spent in Passive Mode compared to time spent in Sleep Mode during the Dead Zone 414, provides significant advantages to the traffic alert system 200 and in-road traffic visual alert devices 199, as previously 30 described. This ratio of time spend in differing operating modes is configurable and differing configurations will provide differing trade-offs, for example, between minimising power consumption and maximising system responsiveness.

-27 Fig. 4B shows detail of an exploded view 402 of a five (5)-minute 'All devices addressing cycle' 424. This cycle contains five identical one (I) minute periods 456 in which RF communications cycle through a specific sequence of send and listen operations. 5 At the commencement of each of two Send frames, SendO.A 470 and SendO.B 476 within a sixty (60)-second cycle 460, the controller station 202 broadcasts commands to all other devices, including repeaters 204 and in-road traffic visual alert devices 199. The command transmission portions of the Send frames 470 and 476 also include clock (and optionally calendar) 10 synchronisation information. Such information assists repeaters 204 and traffic visual alert devices 199 to maintain the synchronised, multiplexed RF communications cycles shown in Figs. 4B and 4C. Fig 4C shows a detailed timeslot allocation view 430 for the 'All devices addressing cycle' 424. As seen in Fig, 4C, the controller station 202 15 broadcasting occurs in periods 431. The synchronisation information is important for keeping the controller stations 202 repeaters 204 and traffic visual alert devices 199 synchronised to the same cycles and also for maintaining reduced power consumption and RF communications collisions. The repeaters 204 operate in the same manner in their own timeslots 440 20 within the same Send frames 470 and 476. The Send Frames 470 and 476 involve bi-directional communications between the controller 202 and all repeaters 204, including between repeaters 204 themselves. The Send Frames 470 and 476 are named as such to indicate when the controller 202 and repeaters 204 are sending information to the traffic visual alert devices 199. 25 In Fig. 4C the Send.OA 470 and Send.0B 476 frames are shown in greater detail 430. Send.OA 470 and Send.0B 476 each comprise two major portions, the controller broadcast and synchronisation portion 431 and the repeater communications portion 440. The purpose of Send.0 repeater portion 440 is to allow the repeaters 204 to relay transmissions from the controller 202 30 and other upstream repeaters 204 down the system pathway and eventually to the in-road traffic visual alert devices 199. Repeaters 204 may also use this Send.0 repeater portion 440 to relay messages upstream, eventually to the controller 202, if any such messages are pending. Send.OA and Send.0B -28 repeater portions 440 comprise low 432, medium 433 and high 434 message priority timeslots to allow adequate bandwidth to messages of all priority types. Additionally, the Send.OB repeater portion 440 includes a critical priority timeslot 435. This timeslot 435 is positioned to allow the quick 5 relaying of a critical-priority message received from an in-road traffic visual alert device by a repeater in the prior Listen.0 period 472 of the same addressing cycle 460. The repeater portions 432, 433, 434, 435 within the Send portion 470 of an address cycle 456 include further division into timeslots for individual 10 repeaters to transmit. The repeaters 204 access the further timeslots based on their individual addresses, thereby avoiding RF communications clashes. Each individual in-road traffic visual alert device 199 is pre-set to listen and respond within a particular one (1)-minute period within the 'All devices addressing cycle' 424. That is, each individual in-road traffic visual 15 alert device 199 is pre-set to listen in only one of the cycles, either in 460, in 464 or in one of the three intervening cycles within 424. This pre-set 'address grouping' may be set by a manufacturer and may be based on the unique ID of each in-road traffic visual alert device 199. The purpose of pre-setting a particular one (1)-minute period 'address grouping' 460, 464, etc for an in 20 road traffic visual alert device's communication is two-fold. Firstly, the power consumption of the traffic visual alert devices 199 is reduced because the traffic visual alert device 199 needs only power-up and listen or respond in one (1) of five (5) addressing cycles. Secondly, communications with the in road traffic visual alert devices 199 will be apportioned across the five 1 25 minute addressing cycles 460, 464, etc, thereby reducing RF congestion and crosstalk between in-road traffic visual alert devices 199, allowing scalable support for a large number of in-road traffic visual alert devices 199 per installation site. The use of device addresses to allocate one of the one (1) minute 30 cycles 456 of an 'All devices addressing cycle' 424 to an in-road traffic visual alert device 199 is a convenience. If the allocation of unique addresses to devices 199 is simply sequential then it provides a method of evenly -29 distributing device communications allocations between the one (1) minute cycles 456 within the 'All devices addressing cycle' 424. During the Listen frame 472 of one (1)-minute cycle 460, the controller station 202 and all repeaters 204 cease transmissions and listen for 5 transmissions from in-road traffic visual alert devices 199. Any received in road traffic visual alert device 199 transmissions are logged, and then forwarded during the next or subsequent Send frames up the communications pathway via any number of repeaters 204 to the controller 202. The Listen Frames are defined to absolutely disable all controller station 202 and repeater 10 204 transmissions so as to allow the relatively low-power transmissions of the in-road traffic visual alert devices 199 to be detected. In-road Traffic visual alert devices 199 enter their Active mode during the appropriate Listen.0 472, Listen. 1 482.. .Listen.4 492 period, enabling their transmitter to send status and fault information to the controller station 202 or a repeater 204. The Listen 15 period is further segmented into slots for individual or small groups of in-road traffic visual alert devices 199 to make their transmissions, again based on unique device address information. Therefore, the Listen period has in-road traffic visual alert device communications spread through it, avoiding RF communications traffic clashes. 20 In any particular cycle's Listen period (472, 482, 492 or other) in which an in-road traffic visual alert device 199 is not due to transmit status & fault information, that traffic visual alert device 199 enters Sleep mode for the duration of the Listen portion of the cycle 456. In Sleep mode, all internal circuitry, excluding the processor clock-timer and any currently necessary 25 circuitry (depending on current state), is inactive and drawing minimal or no power. All devices, including the controller 202, repeaters 204 and in-road traffic visual alert devices 199 enter Sleep mode during portions 474, 494, etc and 478, 498, etc of the addressing cycles 456. The purpose of this behaviour 30 is again, to reduce power consumption by reducing the proportion of time spent by devices using power. The described behaviour of the controller stations 202, repeaters 204 and traffic visual alert devices 199 for the address cycle period 460 is repeated -30 identically for subsequent address cycles within the 'All devices addressing cycle' 424 period. The number of address cycles 456 within an 'All devices addressing cycle' 424 is a configuration parameter, which can be set to an optimal value for the number of in-road traffic visual alert devices 199 present 5 within a particular site installation. In the described examples, five addressing cycles 460, 464, etc within an 'All devices addressing cycle' 424 have been used. The fewer traffic visual alert devices 199 present in a site installation, the more likely that fewer addressing cycles 456 need be configured in one 'All devices addressing 10 cycle' 424 to allow all devices 199 to communicate. Conversely, larger site installations with many (practically hundreds or thousands) of in-road traffic visual alert devices 199 will require more addressing cycles 456 to be included within an 'All devices addressing cycle' 424 to ensure that all traffic visual alert devices 199 have adequate communications opportunities. 15 The communications cycles described in Figs. 4A, 4B and 4C are configurable within the alert system 200. In a typical situation all controller stations 202, repeaters 204 and in-road traffic visual alert devices 199 intended for a particular target installation will be pre-set with a default communications configuration. Once installed and commissioned, a traffic 20 alert system 200 will support dynamic reconfiguration of the communications cycles. In every addressing cycle broadcast portion 431, a controller station 202 sends communications configuration data to all in-road traffic visual alert devices 199. This facility allows the convenience of site-customisation of an alert system 200 through reconfiguration of only the controller station's 25 parameter set, which will then be automatically broadcast to and adopted by the entire traffic alert system 200. Such customisation could be undertaken locally at the site using a laptop connected to the controller station 202, for example, to perform the reconfiguration. Alternatively, the central management controller may remotely reconfigure the controller station 202 30 parameter set. Fig. 5 shows, in block diagram form, the in-road traffic visual alert device 199. The in-road traffic visual alert device 199 comprises a processor block 511 that includes a CPU core with functions such as a timer, and Flash -31 and RAM memories. The processor block 511 is preferred to be a low power component with the ability to disable portions of its functionality to conserve power and yet maintain state. Processor block 511 communicates with RF transmitter and receiver 5 block 534 via control and data path 516. The processor block 511 also enables and controls the power consumption of the RF transmitter and receiver block 534 via control line 512. The RF transmitter and receiver block 534 connects to the antenna 122A for effective transmission and reception of RF signals comprising commands and/or data. 10 Processor block 511 controls LED driver block 536, via control and data path 514. Processor block 511 also controls power consumption of the LED driver 536 and LEDs 110 via control line 510. Watchdog timer block 532 is regularly sent a pulse by the processor block 511 to avoid the Watchdog timer block 532 sending a reset signal 530 to 15 the processor block 511. Inductive reset block 518 detects a specific transmission signal generated by a local programming tool (referred to as a 'wand') 1170 (see Fig. 11) and if the inductive signal is present, causes a reset 530 to be sent to the Processor block 511. 20 Power supply block 540 adapts and feeds the non-rechargeable battery power to the sub-systems of the in-road traffic visual alert device 199. Several functional blocks of the in-road traffic visual alert device 199 may be independently enabled or disabled depending on device state. Thus, the in-road traffic visual alert device 199 and system 200 are advantaged by 25 this flexibility to dynamically rotate and adjust power consumption and functionality according to device state. For example, if an in-road traffic visual alert device 199 is entering Sleep mode and its LED state is 'Off then the device 199 will power down both the LED driver block 536 and RF transmitter and receiver block 534. However, if the in-road traffic visual alert 30 device 199 is entering Sleep mode with a state of 'On' for its LEDs 110 then the device 199 will power down the Transmitter & receiver block 534 without disabling the LED driver block 536. A further example of the flexibility of independent power control is the comparison between Passive mode and -32 Active mode. In Passive mode, the receiver is enabled for detection of incoming commands, while the transmitter is disabled. Whereas, in the Active mode, the transmitter is enabled for the sending of a status response to the alert system 200, while the receiver is disabled. 5 Fig. 6A shows a detailed schematic diagram of the Processor block 511, including microcontroller device 610 (i.e., Texas InstrumentsTM MSP430F135 Microcontroller) of the traffic visual alert device 199. Fig. 6B shows a detailed schematic diagram of the LED driver block 536 and LEDs 110, including LED voltage amplifier component 620 (i.e., 10 Linear TechnologyTM LT1932 Led Driver), of the traffic visual alert device 199. Fig. 6C shows a detailed schematic diagram of the Watchdog timer block 532 and Inductive reset block 518 of the traffic visual alert device 199. An exemplary detailed implementation of the Watchdog timer is indicated by 15 532. This exemplary Watchdog timer circuit 532 generates a reset under the previously described conditions which is logical ORed at 632 with the output state of the exemplary detailed implementation of an inductive reset circuit 518. The exemplary inductive reset circuit includes a tuned inductor-capacitor circuit with downstream rectification, causing a reset signal to be generated at 20 632, if an appropriate input inductive signal is detected. Any positive reset signal appearing at 632 is converted to a negative logic reset signal at 530. Fig. 6D shows a detailed schematic diagram of the Transmitter and Receiver block 534 connecting to antenna 122A of the traffic visual alert device 199. The block 534 comprises component 640 (i.e., Nordic 25 SemiconductorTm NRF905, RF Tranceiver) which includes RF transmitter and receiver circuits that can be enabled or disabled via control lines 512. The described examples reduce the costs of installation and commissioning of a large quantity of in-road traffic visual alert devices 199. Fig. 9A is a flow diagram showing a method 900 of installation and 30 commissioning of a quantity of in-road traffic visual alert devices 199 within the system 200. The method 900 begins at step 902 from which an installation location of a first device 199 is determined 904. At a next step 906, an appropriate -33 modification, such as core-drilling, is made to the road or pavement surface in order for the road or pavement to receive the first in-road traffic visual alert device 199. Then at the next step 908 an in-road traffic visual alert device 199 is selected from available stock and operation of the selected device 199 is 5 verified and the device 199 is installed at the next step 910 into the roadway or pavement. A method 800 of verifying the in-road traffic visual alert device 199 will be described in detail below with reference to Fig. 8A. At a next step 912, a check is made to determine if the device 199 installed was the last one, and if not, the method 900 returns to step 904, 10 determining the next installation location. Otherwise, the installation method 900 concludes. Step 910 will typically include insertion and/or bonding of the in-road traffic visual alert device 199 to the road or similar operation. Some equivalent variations of the method 900 are possible, including, for example, performing steps 906, 908 and 910 in differing orders. 15 A potential disadvantage of the method 900, as shown, is that the in road traffic visual alert devices 199 remains active and possibly in a LEDs ON state at the completion of the method 900. This could be a disadvantage if there is a significant number of in-road traffic visual alert device installations to complete and if it could take a considerable time. The disadvantage is one 20 of loss of battery energy in the in-road traffic visual alert devices 199 if they remain flashing, for example, for many hours or even several days during the system installation process. This situation could be particularly a problem if the devices 199 are powered by non-rechargeable batteries, for example. A method of removing this disadvantage in the method 900 is to 25 deactivate the in-road traffic visual alert device 199 prior to completing the method 900, as shown by optional in-road traffic visual alert device deactivation step 915. This deactivation step 915 may be undertaken by an operator with the wand 1170 of Fig. 11, for example. This step 915 provides significant advantage to the method 900 of allowing a sequence of devices 199 30 to be installed, including identification and verification and then deactivation to conserve battery and operating life and to be reactivated later in a commissioning method, for example.

-34 An example of such a commissioning method 950 is shown in Fig. 9B. The method 950 is started either after the method 900 is completed, or can be started during the execution of the method 900 after a suitable delay (i.e. in a process pipelining arrangement), whichever is appropriate to the requirements 5 and situation of the installation. The method 950 begins at step 952 and proceeds to step 954 at which the next in-road traffic visual alert device 199 is located. At step 956 the wand 1170, for example, is juxtaposed with the in road traffic visual alert device 199 and is used to activate the in-road traffic visual alert device 199 in the manner described. At step 952 there is a check to 10 determine if the last in-road traffic visual alert device 199 has been activated and if not, then execution of the method 950 back to step 954. Otherwise the execution proceeds to and ends at step 954. Fig. 8A is a flow diagram showing the method 800 of verifying the in road traffic visual alert device 199, as executed at step 910 of Fig. 9A. The 15 method 800 in Fig. 8A may be accomplished before or after the in-road traffic visual alert device installation portion of step 910 in Fig. 9A. The method 800 in Fig. 8A begins at step 804 at which the previously selected in-road traffic visual alert device (from step 908 in Fig. 9A) is juxtaposed with the local programming tool 1170, also referred to as a 'wand'. 20 Fig. 11 shows an example of the juxtaposition of an in-road traffic visual alert device 199A and a local programming tool (i.e., wand) 1170. Fig. 11 shows the in-road traffic visual alert device 199A already installed into the road surface while the wand 1170 is juxtaposed with the device 199. However, the wand 1170 and in-road traffic visual alert device 199 may also be 25 juxtaposed prior to the installation of the device 199 into the road surface. The wand 1170 may be similarly used for the devices 199B and 199C. The method 800 of Fig. 8A continues from step 804 to step 806 at which an operator selects information, such as a command, data, or firmware executable file, or a combination thereof, for transmission by the wand 199 to 30 the in-road traffic visual alert device 199. At subsequent step 808, the operator causes the wand 1170 to transmit the information selected in step 806 to the in-road traffic visual alert device 199, via wireless communication (preferably an RF communication). A method 850 of transmitting information to a traffic -35 visual alert device, as executed by the wand 1170 at step 808, will be described in detail below with reference to Fig. 8B. At step 810 a decision is made as to whether the information transmission from the wand 1170 to the in-road traffic visual alert device 199 5 was successful. Typically, this decision is made by the wand 1170 attempting to detect an RF response packet sent to the wand 1170 by the in-road traffic visual alert device 199 on completion of the transmission by the wand 1170. If the response of the in-road traffic visual alert device 199 is correct and indicates success then the method 800 proceeds to completion at step 814, 10 otherwise remedial action is required and the method 800 proceeds to and stops at step 812. Remedial action might include, for example, repeating the method 800, or replacing the previously-selected in-road traffic visual alert device 199 and repeating the method 900 from step 908. Fig. 8B shows the method 850 of transmitting information to an in 15 road traffic visual alert device 199, as executed by the wand 1170 at step 808 in method 800 of Fig. 8A. The method 850 may be implemented as software resident within a memory (e.g., Flash memory as seen in Fig. 12) and being controlled in its execution by a processor (e.g., CPU core as seen in Fig. 12). The method 850 begins at step 854 when the wand 1170 detects the 20 pressing of a button on the local programming tool, or wand 1170. The wand then, at step 856, sends a wake-up signal to the juxtaposed in-road traffic visual alert device 199 (e.g., the device 199A as seen in Fig. 11). The wake-up signal is a pre-arranged signal that the in-road traffic visual alert device 199 is configured to detect, despite the device 199 being in any state, including a 25 deep sleep for transit or storage. And, therefore the in-road traffic visual alert device 199 is not required to actively monitor the wake-up signal, thereby avoiding the disadvantage of incurring additional power consumption inherent in the active monitoring method. The wake-up signal is designed to operate locally, to be unlikely for external sources to mimic and must be reliable over 30 the lifetime of the in-road traffic visual alert device 199. A mechanical signal, such as might be generated by an externally accessible switch, or an electrical signal such as might be applied to externally-projecting contacts, are not considered to be reliable methods of -36 providing a local wake-up signal with reliability for the lifetime of the in-road traffic visual alert device 199. Similarly, a magnetic signal as might be detected by a reed switch or Hall effect probe is unlikely to provide the lifetime reliability required for an in-road traffic visual alert device 199. These 5 assertions will be understood by a person skilled in the art when considering the target environment in which an in-road traffic visual alert device 199 might be installed. To overcome the difficulties and shortcomings of mechanical, electrical and magnetic wake-up signals and/or their detectors for an in-road 10 traffic visual alert device 199, alternative wake-up signals may be utilised, with consequent advantages of high reliability and long lifetimes for the appropriate detection circuitry. Two exemplary methods of providing a local wake-up signal are: a short-range inductive signal tuned to a specific frequency; and an encoded electromagnetic signal, such as InfraRed (IR) or 15 visual light, carrying a specific code and being received in a highly directional or short-range way to reduce the chances of false activation and to increase device specificity in the installation site. The in-road traffic visual alert device 199, both in Fig. 5 and in the detailed schematic of Fig. 6C, utilise an inductive local wake-up signal 20 detector. So, in the method 850 of Fig. 8B, being executed by the wand 1170, the in-road traffic visual alert device 199 detects an inductive signal of the appropriate frequency, amplitude and duration sent by the wand 1170 in step 856 and the device 199 performs an internal reset and respond with an appropriate wake-up signal to the wand 1170. On detecting, at step 858, the 25 appropriate wake-up signal response from the juxtaposed in-road traffic visual alert device 199, the wand 1170 proceeds to execute step 860 and sends (or transmits) the pre-selected information to the juxtaposed in-road traffic visual alert device 199. The method 800 of Fig. 8B may be split into two parallel methods, 30 being steps 854 through 856 and separately steps 858 through 860. As may be seen in a block diagram of the wand 1170 of Fig. 12, a local wake-up signal transmitter block 1218 may be operated independently of firmware execution within processor block 1211. The previously-described splitting of the method -37 850 into two methods, each beginning at steps 854 and 858 is compatible with the block diagram of the wand 1170. Thus the local wake-up transmitter block 1218 may commence at step 852 and wait for a button 1224 to be pressed at step 854 before sending the wake-up signal at step 856 and ending, or looping 5 back to step 854. Whereas, independently, the wand processor block 1211 may be executing the loop at step 858, asynchronously awaiting a response from a juxtaposed in-road traffic visual alert device 199 and when such response is received, proceeding to step 860 to transmit the preset or pre-selected information, thence proceeding to either end at step 862 or to alternatively 10 loop back to step 858. A variety of information may be sent from the wand 1170 to the in road traffic visual alert device 199 using the method 850 or a modified version of the method 850. Examples of information that may be sent to an in-road traffic visual alert device 199 from a wand 1170 include activate and 15 deactivate commands and data. Other example information includes factory test selection and activation commands and data, configuration or setup parameters or commands, including a physical orientation change command such as the TOGGLELEDS command which is explained later. Still other example information includes re-programming commands, which might 20 include many variations of possibilities such as partial or complete executable firmware updates, unique serial number or ID changes and so forth. Fig. I OD is a flow diagram showing a method 1100 executed by the in road traffic visual alert device 199 when the device 199 boots up after reset and possibly detects a transmission from the wand 1170. The method 1100 25 may be implemented as software resident within memory (e.g., Flash memory) of the processor block 511 of the traffic visual alert device 199 and being executed by the processor block 511. At reset 1102 of the in-road traffic visual alert device processor 511, which includes a locally-induced reset by the wand 1170 such as using an 30 inductive reset method or other method, execution proceeds to 1104. At step 1104, the processor block 511 initialises itself and the in-road traffic visual alert device 199 and checksums or otherwise satisfies itself of the integrity of firmware (typically in Flash memory or equivalent) stored within the device -38 199. At the next step 1106, the processor block 511 then causes the in-road traffic visual alert device 199 to transmit a packet 1106 indicating that the device 199 has woken up and is ready to receive any wand transmissions. Then at step 1108, the in-road traffic visual alert device 199 waits with 5 its receiver enabled for a transmission from the wand 1170. If a wand transmission is not forthcoming in a period, such as I OOms, for example, then at step 1110 the in-road traffic visual alert device 199 proceeds via the No branch to MAIN_BOOT step 1112. The RF communications at steps 1106 and 1108 may utilise a maintenance RF channel or network identifier (ID) 10 differing from the system 200 RF channel and or network ID and matching the RF channel and/or network ID expected of the wand 1170. The optional method utilising maintenance RF communications at steps 1106 and 1108 is for the purpose of temporarily isolating the awakening in-road traffic visual alert device 199 from the system 200 RF communications, thereby removing 15 possible interferences between system 200 RF communications and wand 1170 RF communications and/or commands or data carried by those communications. A MAIN_BOOT method 1010 as executed at step 1112, will be described in detail below with reference to Fig. I OA If the in-road traffic visual alert device 199 did receive a wand 20 transmission at step 1108 then at step 1110 the Yes branch is taken and an operation is selected based on the command type received. The exemplary options for selectable operations shown in step 1110 include the following: * Deactivate 1114: This step sets a flag which later causes the processor block 511 to shut down all controllable power consumption in the in-road 25 traffic visual alert device 199 and to stall itself. The Deactivate operational mode provides the lowest power consumption case for the in-road traffic visual alert device 199 and is suitable for long-term storage and transit. The power consumption in this mode is typically less than the leakage current of a battery. Therefore when the in-road traffic visual alert device 199 is in this 30 mode the remaining shelf-life of such a battery is an appropriate estimate of the remaining battery lifetime. 0 Activate 1116: The Activate command is essentially a null command since the method 1100 effectively activates the in-road traffic visual alert -39 device 199, and if no action is taken at step 1116 then the in-road traffic visual alert device 199 proceeds to MainBoot 1112 anyway. The functionality at step 1116 may be included as desired or required. * FactoryTest 1118: This step is convenient for providing self-test or 5 similar facilities within the in-road traffic visual alert device 199 to verify its function. The types of tests executed in step 1118 may be further selected by a command parameter, for example. * Setup 1120: This step allows setting or modification of configuration parameters such as clock and calendar information, communications cycles 10 information for any of the parameters already described in Figs. 4A, 4B, or 4C and other in-road traffic visual alert device 199 parameters may be modified by the method 1100. Typically the parameters may be kept in non-volatile Flash memory or optionally in RAM memory, or in both types of memory within the in-road traffic visual alert device 199, allowing various options and 15 flexibilities that are well-known in the art for use of these parameters in an embedded system. e TOGGLELEDS 1122: This step modifies the physical to logical mapping of the LEDs 110 within the in-road traffic visual alert device 199. The example given is that the two sets of LEDs 1 IOA and I IOC on pointing 20 from opposite ends of the in-road traffic visual alert device 199A are caused to swap their mappings in step 1122. This operation is very useful if the in-road traffic visual alert device 199 has been found to have been installed in the opposite (180 degrees) orientation from that expected, or if the device 199A was assembled or labelled incorrectly as to its forward vs. reverse LED 25 orientation. Other types of physical to logical mapping may be altered by this command and step 1122 or by similar commands and steps not shown or by a parameter provided with the TOGGLELED command. * REPROGRAM 1124: This step provides the facility to revise or rewrite in-road traffic visual alert device 199 executable software code and or 30 data, typically in Flash memory, as seen in Fig. 12, down to any level. The feature of step 1124 allows the in-road traffic visual alert device 199 to have its usefulness appended, extended or replaced/renewed depending on how the wand 1170 is used to modify the executable software and data code within the -40 in-road traffic visual alert device 199. Included within the wide range of data that may be modified is a unique address/serial number/ID (these concepts potentially being interchangeable or alternatives) corresponding to the device 199. Step 1124 enables advantageous operations such as adding new features 5 to installed in-road traffic visual alert devices 199; causing a new in-road traffic visual alert device 199 to be programmed with the unique ID of a another in-road traffic visual alert device that the device 199 is replacing (such as at first installation or later during maintenance); causing in-road traffic visual alert device operational features or functionality to be removed or 10 replaced, which may be used to fix software or hardware bugs, update or upgrade feature sets, or completely alter the in-road traffic visual alert device 199 operation to satisfy a change in purpose or requirement. The REPROGRAM 1124 step will allow considerable scope and the step 1124 may be viewed as a generic facility that includes all of the other more specific 15 steps 1114, 1116, 1118, 1120 and 1122. After execution of any of the steps 1114, 1116, 1118, 1120 and 1122, the execution of the method 1100 proceeds to MAIN_BOOT at step 1112. A confirmatory response indicating successful receipt and implementation or execution of the transmission by the wand 1170 may be 20 sent by the in-road traffic visual alert device 199 to a nearby operator through the built-in LEDs 110 used for visual warnings, or other suitable signalling method. For example, a brief flash of both forward and reverse LEDs 11 0A and I 1C may be actioned by the in-road traffic visual alert device 199 at step 1112, or at another appropriate step such as at step 1032 in a MAIN_LOOP 25 method 1030 which will be described in detail below with reference to Fig. 10B. Furthermore, additional or alternative confirmatory response mechanisms or methods may be supported, including confirmation of success being reported by the wand 1170 (local programming tool) to the operator, after the wand 1170 receives a confirmatory message directly (e.g., an RF 30 communications packet or equivalent) from the juxtaposed in-road traffic visual alert device 199. A further example of an additional or alternative confirmatory response method is for the alert system controller station 202 to recognise the -41 successful receipt and execution of the transmission from the wand 1170 by the juxtaposed in-road traffic visual alert device 199. In this example, the in road traffic visual alert device 199 may transmit a message of success to the controller station 202 (possibly not uniquely to the controller station 202). 5 Alternatively, the in-road traffic visual alert device 199 may, for instance, be interrogated by the controller station 202 as part of the regular traffic visual alert system 200 communications cycle. The controller station 202 may recognise the changes to the in-road traffic visual alert device 199 from the response of the device 199. The controller station 202 may then provide the 10 confirmatory response to the operator itself through any of a number of direct or indirect means, either immediately or later. For example, the controller station 202 may provide a log report containing relevant information and identity or chronology concerning installed in-road traffic visual alert devices 199. Alternatively, the controller station 202 may directly signal the operator 15 through the in-road traffic visual alert device 199 (or traffic visual alert devices) by causing a visual alert switching event, such as a specific number and duration of LED ON & OFF pulses, and so forth. Fig. 10A is flow diagram showing an exemplary MAINBOOT method 1010 as executed at step 1112 of the method 1100. The method 1010 20 may be implemented as software resident within the processor block 511 of the traffic visual alert device 199 and being executed by the processor block 511. The in-road traffic visual alert device processor block 511 enters the method 1010 at step 1012 and proceeds to test whether the processor block 511 should enter DEACTIVATE mode at the next step 1014. Typically, the 25 processor block 511 tests a flag at step 1014, where that flag may have been set in another method such as in step 1114 in the method 1100. If the test at step 1014 is successful then execution proceeds to step 1016 where the DEACTIVATE mode is entered and all controllable power consumption is disabled and the processor 511 is stalled. 30 If, at step 1014, DEACTIVATE mode is not required to be entered and the test at step 1014 is false then execution continues to step 1018 where the executable code in non-volatile memory of the device 199, such as Flash or ROM, for example, is tested for integrity by a checksum method or similar.

-42 This integrity check at step 1018 caters for the case where an in-road traffic visual alert device 199 may have recently been re-programmed in some form or had its data set or parameters, etc modified. Such wand re-programming or modification as shown in Fig. IOD may include a checksum or similar check 5 information that can be verified by the in-road traffic visual alert device 199 processor block 511 performing a repeat of the same check method at step 1018 and comparing the result. The result of the integrity check is tested at step 1020 and if found to be incorrect, execution proceeds to step 1022 where DEACTIVATE mode is 10 entered. If the integrity check succeeded then execution next proceeds to MAINLOOP method 1030 at step 1024. An exemplary in-road traffic visual alert device MAINLOOP method 1030 is shown in Fig. 10B. Equivalent methods may be used for implementing a MAINLOOP method 1030, including utilising any of a 15 variety of schedulers, task managers, multi-thread or multi-process, semaphore or other types of operating system or base-level software methods to support the MAINLOOP method 1030. The traffic visual alert device MAINLOOP method 1030 may be implemented as software resident within the processor block 511 of the traffic 20 visual alert device 199 and being executed by the processor block 511. The MAINLOOP method 1030 begins at step 1032 and proceeds to step 1034 at which a check is made to determine if the in-road traffic visual alert device 199 is synchronised to the system 200, which means that the in-road traffic visual alert device 199 is performing correctly in synchronism with the 25 communications cycles shown in Fig. 4B or Fig. 4C. Step 1034 may check a flag or similar that indicates the recent synchronisation status. If the in-road traffic visual alert device 199 is not synchronised to the system 200 communications cycles then execution proceeds to step 1036 and the previously-explained reducing-rate re 30 synchronisation method is entered, involving steps 1038, 1040, 1042, 1044, 1046 and 1048. The Broadcast_0 test indicated in the diagram in steps 1038 and 1044 refers to the detection of a synchronisation command and information broadcast by the controller station 202 or relayed by a repeater -43 204. The Broadcast_0 test is the same as or equivalent to the information 454 in Fig. 4B which is typically included in a Send portion 431 in Fig. 4C. Other equivalent methods are possible for detecting synchronisation information or information supporting re-synchronisation in the communications cycles of 5 Fig.4. Step 1048 includes a similar process to that shown for the steps 1038 and 1040 but occurring at a less frequent rate and if synchronisation is successful in step 1048 then execution proceeds to step 1050. Alternatively, step 1048 may include a nested version of the method 1030 operating at a 10 lesser re-synchronisation rate until step 1050 is reached. When and if step 1050 is reached, meaning that the in-road traffic visual alert device 199 is satisfied that the device 199 is synchronised to the system 200 communications cycles, the processor block 511 performs a passive check-in at step 1050. Step 1050 is for the purpose of obtaining 15 command and data information from the controller station 202 or repeater 204 that is to receive the information in a Send transmission 470, 480, etc as described in and in relation to communications cycles in Figs. 4A, 4B and 4C. During the passive check-in, the in-road traffic visual alert device 199 maintains a low power consumption, such as remaining in Sleep mode, except 20 at calculated intervals during the appropriate Send portion of the communications cycle during which the processor block 511 enters passive mode in which the processor block 511 enables the receiver 534 to accept the expected incoming information from the controller station 202 or repeater 204. Next, at step 1052, the in-road traffic visual alert device 199 may perform an 25 active check-in if the appropriate timing window is reached. As previously explained in relation to Figs. 4A to 4C, an active check-in is typically performed at less frequent intervals than a passive check-in and the rate of both is configurable. During an active check-in, if such an active check-in is selected to occur in step 1052, the processor 511 of the in-road traffic visual 30 alert device 199 enables the transmitter 534 at the calculated intervals during an appropriate Listen portion of a 472 communications cycle, as previously described.

-44 The in-road traffic visual alert device 199 transmits previously collected status and fault information about its subsystems, including information such as battery level, LED functionality, clock and calendar accuracy. The in-road traffic visual alert device 199 may also transmit other 5 information that might be deemed appropriate including information gathered by internal or external sensors such as internal temperature sensors, for example. The in-road traffic visual alert device 199 may also transmit its unique ID in conjunction with the status and fault information if necessary. Alternatively, the unique ID for the in-road traffic visual alert device 199 may 10 be inferred from the identification of the timeslot used by the device 199 in a particular Listen period. At step 1054, the in-road traffic visual alert device 199 refreshes the LED status according to the command(s) and/or parameter(s) that the device 199 received in step 1050. For example, a MasterLEDsonflag may be 15 checked in this step 1054 to determine if the LEDs 110 should be enabled or disabled. If a timer is used to control the on time for the LEDs 110 then the timer may be consulted during this step 1054 and the status of the LEDs may be refreshed accordingly. If the Master_ LEDs on flag is disabled then the LED timer is cleared in step 1054. Execution of the method 1030 then 20 proceeds to step 1056 at which a test is made to determine if the current time and/or date is between the on and off times (or dates) previously received for controlling the LED state. If the current time is between these times then the LEDs 110 are activated 1058 by loading a short period into the LED timer, which is typically equal to or greater than the 'All devices addressing cycle' 25 424 period. Utilising a timer to operate the state of the LEDs 110 provides a short term fail-safe, continued operation of the LEDs 110 if, for example, RF communication with the system 200 is temporarily lost. Further, utilising a timer to operate the LEDs 110 provides the dual short-term advantages of 30 maintaining the state of the LEDs 110 unchanged for a short period (e.g. for one 'All devices addressing cycle' 424 period) as well as eventually turning off the LEDs 110 if further communications are lost. The timer thereby provides the dual advantages of a more stable short-term visual result from the -45 in-road traffic visual alert device 199 and also eventually protecting the battery energy level of the in-road traffic visual alert device 199. The timer also operates when the in-road traffic visual alert device 199 has a calendar contingency but is likely to be redundant in that case. If the current time is not 5 in the LED active period then execution proceeds to step 1060 where the LED start & stop times (and/or dates) are checked for validity. If the test 1060 returns an invalid result then the MasterLEDs on flag state is directly used to control the LEDs 110 at 1062. Otherwise, execution continues to 1064 where the timer for the LEDs 110 is cleared. Following steps 1058, 1062 and 10 1064, the method 1030 proceeds to step 1034. Similar methods of controlling LEDs with a timer and master control flag may replace some or all of steps 1054, 1056, 1058, 1060, 1062 or 1064. The method 1030 may be implemented as a parallel or mixed series parallel set of operations rather than the purely sequential exemplary method 15 1030 indicated in Fig. 10B. For example, steps 1032, 1034, 1036, etc through 1050, 1052, 1054, for example, need not stall the processor block 511 execution if they include or require a wait or loop operation. Alternative, similar or equivalent implementation methods may include, for example, the use of semaphores or flags to maintain state and then the method 1030 may be 20 interpreted as a state diagram rather than as a flow diagram. In this equivalent approach, execution may re-commence at step 1032 on every synchronisation signal 454 in Fig. 4B, or at the expected arrival time of such a synchronisation signal based on the count of an internal clock-timer. Thereafter the appropriate steps in the method 1030 may be executed according to the saved and current 25 state information and the method 1030 may complete in time and loop back to step 1032 to be ready for the next synchronisation signal or the expected arrival time 454 of the next synchronisation signal before proceeding to step 1034. A calendar function may be included in the in-road traffic visual alert 30 device 199 to provide contingency control of the LEDs 110 and possibly other functions. The method 1030 of Fig. I OB shows optional execution flow lines 1033 and 1035 between steps 1034 and 1036. As seen in Fig. 16, a calendar contingency model may include the execution steps 1600, between the lines -46 1033 and 1035 with line 1033 connecting to step 1633 and line 1035 connecting to step 1635. The steps 1654 through 1664 are substantially identical to those steps 1054 through 1064 previously explained, except that the LED control data is not obtained from a command input to the in-road 5 traffic visual alert device 199, but from a saved data set. The saved data set may have been a copy of the last command or commands to have been received, or the saved data set may be a default LED control configuration available to the in-road traffic alert device 199. Several alternative or equivalent implementations of the combined methods of 1030 and 1600 may 10 also provide calendar contingency support. The advantage of the calendar contingency method described above is that a loss of RF communications synchronisation between an in-road traffic visual alert device 199 and the rest of the traffic visual alert system 200 may be ameliorated by the calendar contingency feature continuing to operate the 15 in-road traffic visual alert device LEDs 110 or other features in the manner described above. In fact, the calendar contingency may be used to provide security for short-term RF communications problems or for longer-term RF communications problems. This calendar contingency feature therefore significantly increases the inherent risk management capability of an in-road 20 traffic visual alert device 199 and of a traffic visual alert system 200 in which the in-road traffic visual alert device 199 resides. The in-road traffic visual alert device 199 contains a calendar contingency as previously described, with a much lower rate of RF synchronous transmission from a controller station 202 or repeater 204 in the 25 traffic visual alert system 200. The in-road traffic visual alert device 199 with internal calendar may operate without the use of a permanent alert system controller station 202 or repeater 204. For example, a mobile controller station 202 or repeater 204 may occasionally, or at regular but infrequent intervals, pass by an in-road traffic visual alert device 199 for the purpose of 30 sending the device 199 new commands, configuration or other data, including LED on/off date and time information and also checking the status and fault report of the device 199. The in-road traffic visual alert device 199 may, for example, update its internal LED on/off control information from a recently -47 received command(s) and revert to using calendar contingency updates to maintain the correct LED on/off operations sequence and timing. Furthermore, an in-road traffic visual alert device 199 may be sent only a single command prior to installation, or even be sent no commands but contain preset calendar 5 data within memory with the required LED on/off operations sequence and timing. In these latter cases, the in-road traffic visual alert device 199 need not have an RF or other communications capability included within the device 199. In many of these example methods, the in-road traffic visual alert device 199 might only communicate with another device such as a controller station 10 202, repeater 204 or local programming tool (wand) 1170 at very long intervals such as during annual maintenance or similar. The following lists provide exemplary controller synchronisation packet structures and data content as may be broadcast by the controller station 202 to repeaters 204 and ultimately to in-road traffic visual alert 15 devices 199. A Broadcast_0 packet is typically sent in the controller's first Send portion 431 of the 456 synchronous communications frame indicated in Fig. 4B. The Broadcast_1 packet listed below is typically sent in the controller's second Send portion 431 of the 456 synchronous communications frame indicated in Fig. 4B. Both the Broadcast_0 and Broadcast_1 packets 20 provide the synchronisation signal 454 indicated in Fig. 4B through the event of their receipt by an in-road traffic visual alert device 199 or repeater 204 as well as by the clock synchronisation data content they contain. The previously-described facility for a controller to reconfigure a traffic visual alert system 200 through the broadcasting of new configuration 25 parameters to the controller station 202, repeater 204 and traffic visual alert devices 199 is supported by the fields present in both the Boradcast_0 and BroadcastI packets. It may be seen in the Broadcast_0 packet that calendar synchronisation information may be provided by the controller station 202 in fields four (4) 30 and five (5), along with clock-timer synchronisation information in fields six (6), seven (7), and eight (8). Furthermore, calendar- and/or clock-based LED on/off information may be provided in other packet fields and the Broadcast_0 example includes fields fourteen (14) through seventeen (17) for this purpose.

-48 Additional calendar-based information fields may be included in a controller packet in order to support several of the calendar contingency operational methods previously described. 5 Broadcast_0 packet from router: (and defaults that will be used if it's invalid) 0- net id 1- Ox00 - broadcast address 10 2- Ox00 3- cmdbroadcast_0 4- clockweek = 34; #time - week 5- clock_day = 3; #time - day (0 = sun, 1= mon, 6 = sat) 6- clockhr = 2; #time - hr 0-23 15 7- clock_min = 27; #time - minute 8- clocksec = OxFF; #time - sec 9- clockTARH = 0xFF; #488us count (for precise synch) 10- clockTARL = OxFF; # 20 11- config-checksumH = chksum; #checksum range from flashpattern to xun_5 12- config-checksumL = chksum; #"" 13- flashpattern = 1; #option for different patterns 14- flashstarthr = OxFF; #flash between start/stop times 25 15- flashstart_min = OxFF; #"" if OxFF its ignored 16- flash-stophr = OxFF; #"" 17- flash stop_min = OxFF; I"" 18- activecheckinperiod = 0x41; #period for IRUs to do active checkin, (bit 7=hrs, bit4=min, else sec) 30 19- passivecheckin-period = 30; #period for IRUs to wakeup and listen for broadcast (bit7= "") 20- configflags = 0; #configuration flags see description below 21- systemflags = 0; #system flags 35 22- specialmodestarthr = OxFF; 23- specialmodestart_min = OxFF; 24- specialmodeduration = OxFF; 25- un_1 = 0; 26- un_2 = 0; 40 27- un_3 = 0; 28- un_4 = 0; -49 29- un_5 = 0; 30- un_6 = 0; 31- databroadcastoffset; //not checksummed in router/iru (na to ipv) 5 Config flags: 7 6 10 5 4 3 2 1 15 0- if set, send temperature instead of battery in active checkins System flags: 7 20 6 5 4 3 2- Leds Direction B enabled (reverse). set = enabled. if 25 no direction enabled no leds will flash. 1- Leds Direction A enabled (forward) . set = enabled. both directions can be enabled at once 0- master on/off. set = leds on, reloads timer for 5 min 1- every time IRU recieves, leds will flash until timeout 30 or flag=0 (note - start/stop time will override OFF setting) (but both directions off will override on if needed) 35 Broadcast_1 packet from router: (and defaults that will be used if it's invalid) 0- net id 1- Ox00 - broadcast address 40 2- Ox00 3- cmd broadcast_1 4- exchecksumH = 0x43; #checksum high byte range from rflistentimeout to xun_15 5- exchecksumL = 0x53; 6- rflistentimeout = 50;//50ms #Router wait for reply timeout, count = 488us 7- flp_8_1 = 20; //10ms on #flash pattern times, count 5 = 488us 8- flp_16_2_H = OxlO; //2000ms #"" 9- flp_16_2_L = 0x02; 10- flp_8_3 = 40; //20ms on 11- flp_16_4_H = OxOl; //200ms 10 12- flp_16_4_L = 0x99; #"" 13- flp_8_5 = 0; #"" 14- flp_8_6 = 0; #"" 15- battery-test-period = OxFF; //ignored #always 0xFF because im not using 15 16- led test-period = OxFF; //ignored #" 17- failed_comstimeout = 2; //2 mins #time IRU fails to receive broadcast before it starts to try harder. count = 1 min 18- failedcomscritical = 3; //4 mins #"" until 20 there's a serious problem and it starts trying very hard (battery intensive) 19- activecheckinwindow = 204; //looms #size of window for each IRU to get its active checkin done within. count = 488us 25 20- deadzonestarthr = 22; #deadzone, IRUs and routers will not try to recieve anything, saves battery power in night. 21- deadzoneendhr = 02; #"" 22- activecheckinlistentimeout = 100; #how long IRU 30 listen for active checking reply /x 488us 23- passive-checkinlisten timeout = 50; #how long IRU to wakeup to listen for passive checkin /x 488us 24- exun_4 = 0; 25- exqun_5 = 0; 35 26- ex-qun_6 = 0; 27- ex-qun_7 = 0; 28- qun_8 = 0; 29- qun_9 = 0; 30- qun_10 0; 40 31- xun_11 = 0; //not checksummed in router/iru (na to ipv) -51 Fig. 1 OC shows an exemplary background method 1070 executed in the in-road traffic visual alert device 199 by the processor block 511 to, for example, obtain fault information about the operation of the LEDs 110, and so 5 forth. This collected information can then be utilised by other parts of the firmware of the in-road traffic visual alert device 199, such as previously explained for the method 1030 in Fig. 10B, for example. The method 1070 may be implemented as software resident in the processor block 511 and being controlled in its execution by the processor block 511. 10 The method 1070 begins at step 1072, in which the configuration of the in-road traffic visual alert device 199 is verified by the processor block 511 performing a checksum. If the current configuration is invalid, then at step 1074 the default, factory-set configuration parameters typically stored in Flash memory within the processor block 511 of the device 199 are used to replace 15 the current configuration which may be stored in RAM or Flash memory of the processor block 511. For instance, the factory-set configuration parameters may be used to overwrite the current configuration parameters. Execution proceeds to step 1076 at which a watchdog function is maintained, such as a pulse being sent to a hardware watchdog timer to delay 20 the hardware watchdog timer 532 performing a hard reset, or a software accessible timer is modified to avoid the hardware watchdog timer 532 causing a software or hardware reset, or another equivalent watchdog maintenance function is performed. At step 1080, if a new twenty four (24) hour period has been entered 25 (e.g., if the date has progressed since last execution of step 1084) then step 1082 is executed, which loops waiting for the LEDs 110 to be enabled. If the LEDs 110 are enabled then execution proceeds to step 1084 at which point a battery test is performed while the LEDs 110 are On, allowing a more accurate test of remaining battery lifetime (through performance of a voltage 30 measurement under load or equivalent). At step 1086, if a new 24 hour period has been entered (e.g., if the date has progressed since last execution of step 1090) then step 1088 is executed, which loops waiting for the LEDs 110 to be enabled. If the LEDs 110 are enabled then execution proceeds to step 1090 at which point the forward and -52 reverse LEDs 110 are tested to check that they are operating correctly. This test may perform a check of LED current, for example, by measuring any of a number of related parameters in relation to the LEDs 110 or the LED driver such as voltage across the active LEDs, or voltage across a resistor in series 5 with the LEDs 110, or other equivalent test. The method 1070 may be implemented as a parallel or mixed series parallel set of operations rather than the purely sequential exemplary method 1070 indicated in Fig. 10C. For example, steps 1080, 1082, 1084, 1086, 1088 and 1090 need not stall the processor block 511 execution if the steps include 10 or require a wait or loop operation. Alternative, similar or equivalent implementation methods may also be used. For example, the use of semaphores or flags to maintain state and then the method 1070 could be interpreted as a state diagram rather than as a flow diagram. Fig. 1OE shows a TOGGLELEDS method 1130. Again, the method 15 1130 may be implemented as software resident in the processor block 511 and being controlled in its execution by the processor block 511. The method 1130 begins at 1132 where the physical mapping to logical mapping of forward and reverse LEDs 11 OA and 11 OC, respectively, in the in-road traffic visual alert device 199A is swapped. This swapped state is saved in Flash memory of the 20 processor block 511 in step 1132 and will affect all subsequent LED control within the in-road traffic visual alert device 199A if and until the swapped state is modified by another TOGGLELEDS command or is erased by a reconfiguration or reprogramming or similar event. Following step 1132, execution proceeds to the MAINBOOT method 1010 at step 1134. 25 Fig. I OF shows a DEACTIVATION method 1140 as executed by the in-road traffic visual alert device 199. Again, the method 1130 may be implemented as software resident in the processor block 511 and being controlled in its execution by the processor block 511. The method 1040 begins at step 1142 and proceeds to step 1144 at which the in-road traffic 30 visual alert device 199 writes a flag or state value or similar into memory (preferably Flash memory) of the device 199 to indicate that the device 199 is in the DEACTIVATE mode. This flag or state value will be checked in the -53 future, if the in-road traffic visual alert device 199 is ever reset, for example in the MAIN_BOOT method 1010 at step 1014. Following step 1144, step 1146 is executed during which the processor block 511 shuts down all controllable sub-systems and then the processor 5 block 511 itself halts. The in-road traffic visual alert device 199 is now in sleep mode with the processor block 511 halted at step 1148. The power consumption in this mode is negligible and the in-road traffic visual alert device 199 may only be reactivated by a local reset command such as may be issued by the wand 1170 (or local programming tool), as previously described. 10 Fig. 11 shows a juxtaposed wand 1170 (local programming tool) and an in-road traffic visual alert device 199A. The wand 1170 may be similarly juxtaposed with the in-road traffic visual alert devices 199B and 199C. The juxtaposition orientation, relative positioning and details are exemplary. However, the example of Fig. 11 is a practical scenario that conveys 15 advantages to a number of processes or operations in relation to the in-road traffic visual alert device 199A. Some examples of these processes or operations involving the in-road traffic visual alert device 199A that would be advantaged by the juxtaposition and use of the wand 1170 with the in-road traffic visual alert device 199A include installation and commissioning, de 20 commissioning, replacement or repair and other operations that may conceivably be undertaken on the in-road traffic visual alert device 199, particularly when or after the device 199A is deployed in the field. Fig. 11 also shows an in-road traffic visual alert device 199A already placed into or installed in the road or pavement surface 1154 and 1156. A 25 core-drilling operation has created core-hole 1156 into which the in-road traffic visual alert device stalk or stub 1158 has been inserted. In the case of the in-road traffic visual alert device 199B, the base housing 11 B would be inserted into such a core-hole. The remainder of the in-road traffic visual alert device 199A is shown 30 sitting atop the road or pavement surface 1154. However, other options are equally viable and practical including the top portion of the in-road traffic visual alert device 199A being submerged partially or wholly into a cavity in the road or pavement surface 1154.

-54 As seen in Fig. 11, the local programming tool, or wand 1170 is positioned a short distance from and essentially overlapping much of the upper portion of the in-road traffic visual alert device 199. The precise details of the juxtaposition are not provided. However, a local reset method and 5 communication transmissions between wand 1170 and in-road traffic visual alert devices 199 work over a short distance that is considered desirable or practical for normal local operations with the wand 1170. The local reset method and transmissions are preferably not effective over longer distances, such as the distance between installed in-road traffic visual alert devices 199A, 10 so as to provide some selectivity providing locality and confidence as to which in-road traffic visual alert device 199A is being operated on by the wand 1170. The wand 1170 need not make contact with the in-road traffic visual alert device 199A in order for the device 199A to provide effective operational control of the in-road traffic visual alert device 199A. 15 The wand 1170 comprises a 'skirt' or 'plunger base' 1160 which holds an inductive means in the form of an inductor or other component that serves to create the local reset in the in-road traffic visual alert device 199A juxtaposed with the wand 1170. Also likely in the vicinity of the plunger base 1160 of the wand 1170 will be the transmitter 1221 and receiver 1219 and/or 20 their antennas in order to facilitate effective short-range communication between the wand 1170 and the juxtaposed in-road traffic visual alert device 199A. The wand 1170 includes a handle 1162 of sufficient length to provide convenient and comfortable use of the wand 1170 in the field by an operator in 25 a vertical stance standing over an installed in-road traffic visual alert device 199. Therefore, in one example, the handle 1162 is of a length of approximately one (1) to one point five (1.5) metres for this purpose. The wand 1170, as seen in Fig. 11, includes a control means in the form of a control unit 1168, at least one selection means in the form of a 30 switch 1164 and optionally a display means in the form of a display 1166. The control unit 1168 may include the wand active circuitry and battery and possibly transmission means in the form of a transmitter 1221 (see Fig. 12) and receiver means in the form of a receiver 1219 (see Fig. 12) unless any of -55 these are fitted elsewhere to the wand 1170. The switch 1164 provides the operator with an interface means for creating an inductive reset signal that activates (or triggers) the in-road traffic visual alert device processor block 511 to awaken from its halt state as previously described. Other interface 5 means in the form of switches 1164, for example, might exist to allow operator selection of wand commands and data, for example. Further, an optional display 1166 may form part of the interface means for use in reviewing the wand 1170 command selection, or to view the wand report after an attempted command transmission to a juxtaposed in-road traffic visual alert 10 device 199. The display 1166 may also display other, related information. Several practical alternatives exist to the use of the display 1166. For example, the interface means may be in the form of a simple wand interface (e.g., one or more switches, buttons and indicator LEDs) allowing easy and confident pre-selection of a wand command and data and therefore which does 15 not require confirmatory feedback from the display 1166. In this instance, the display 1166 may not be needed. Another example of replacement of the display 1166 might be the use of a laptop or other portable computer connected to the wand 1170 by serial cable. The laptop display may provide a facility for verification of the wand command transmission results, as well as 20 also providing a way of pre-selecting the command and data to be transmitted by the wand 1170. A further example involving replacement or omission of the display 1166 is for the wand 1170 to be pre-programmed with one or more specific command or data sets which can be selected by a simple user interface such as 25 a bank of switches and not requiring a display 1166 for confirmation. In one example, a pre-programmed command or data set single operation which does not require any switches or confirmatory display to support selection of a pre programmed command and/or data to be sent to an in-road traffic visual alert device 199, may be used. 30 The local programming tool or wand 1170 is shown in exemplary block diagram form in Fig. 12. The wand 1170 contains a processor block 1211 that includes functions of a CPU core, Flash and RAM memory or equivalent, and an optional RS232 communications interface capability or -56 equivalent. The RS232 communications functionality in processor block 1211 provides bi-directional serial communications capability via lines 1227 and 1228 to a connector 1230, to which may be connected any suitable terminal, laptop or other suitable input/output device for controlling and reviewing at 5 least one operation of the wand 1170. Alternatively, as previously described, the wand 1170 may include an integral user interface capability (not shown in Fig. 12) in which case the RS232 capability may be totally internal or not required. Fig. 12 also shows a watchdog timer and reset block 1217 connected to 10 the processor block 1211 for the purposes of providing an appropriate resetting facility for the processor block 1211 and monitoring of processor block 1211 activity and application of a reset if the watchdog so determines that it is necessary. Fig. 12 also shows an RF transmitter block 1221 connected to the 15 processor block 1211 via command and data lines 1214 and via power control/enable line 1210. There is also shown an RF receiver block 1219 that is connected to the processor block 1211 via command and data lines 1216 and power control/enable line 1212. The control of power to transmitter and receiver is optional in the wand 1170, except where the transmitter 1221 needs 20 to be disabled to avoid interfering with wand reception of signal transmitted by the juxtaposed in-road traffic visual alert device 199. Power control of the transmitter 1221 and receiver 1219 in the wand 1170 may convey the advantage of longer battery life. The wand 1170 may utilise differing RF channel and/or network ID 25 from those typically used by an installed system 200. Therefore, the wand 1170 transmitter 1221 and receiver 1219 may be tuned or selected by processor block 1211, or by fixed preset or pre-configuration, to operate on a maintenance RF channel and/or network ID, the same RF channel and/or network ID to which an in-road traffic visual alert device 199 device may 30 temporarily switch on or after wake-up at steps 1106 and 1108 by the processor block 511 to check for a maintenance operation request. The wand 1170 also includes, as shown in Fig. 12, a power supply block 1223 and a switch or button 1224 for activating a local wake-up -57 transmitter 1218. As previously described, the local wake-up transmitter 1218 may be an inductive local reset generator, for example, with an inductive means in the form of an inductor mounted in the plunger base 1160 of the wand 1170. The inductive means may be configured for generating an 5 inductive reset signal for activating the traffic visual alert device 199. Thus, there is interaction between wand 1170 and in-road traffic visual alert device 199 in that the wand 1170 initiates an inductive or other local reset event in an in-road traffic visual alert device 199, initiating a wake-up and maintenance mode check in the in-road traffic visual alert device 199. The in 10 road traffic' visual alert device 199 temporarily awaits a maintenance RF transmission by the wand 1170 containing information, which, if receipted by the in-road traffic visual alert device 199, is thereupon operated on by the in road traffic visual alert device 199. Following such an operation, the in-road traffic visual alert device 199 proceeds to MAINBOOT 1012 and thence into 15 normal operation and interaction with the alert system 200. Fig. 13 shows an exemplary block diagram of a repeater 204. The repeater 204 contains a processor block 1311 that includes functions of a CPU core and Flash and RAM memory or equivalent. As described above, each of the repeater 204 may include a non-volatile memory card such an SD card or 20 the like for storing commands, data, system status and fault information. Accordingly, if the system 200 fails, historical commands, data and information are still accessible. Fig. 13 also shows a watchdog timer and reset block 1317 connected to the processor block 1311 for the purposes of providing an appropriate resetting facility for the processor and monitoring of 25 processor activity and application of a reset if the watchdog so determines that it is necessary. As seen in Fig. 13, the repeater 204 also comprises an RF transmitter block 1321 connected to the processor block 1311 via command and data lines 1314 and via power control/enable line 1310. Optional additional transmitter 30 blocks are also shown as 1322 and these are also interconnected with the processor block via lines 1314 and 1310. The repeater 204 also comprises an RF receiver block 1319 that is connected to the processor block 1311 via command and data lines 1316 and power control/enable line 1312. Optional -58 additional receiver blocks are also shown as 1320 and these are also interconnected with the processor block via lines 1316 and 1312. The control of power to transmitter(s) and receiver(s) is advantageous in a battery-operated repeater 204 to increase the operating lifetime of the solar-rechargeable 5 battery, for example. Furthermore, the power control/enable line 1310 is useful where the transmitter needs to be disabled to avoid interfering with reception of a signal transmitted to the repeater 204 by another device in the traffic alert system 200. The repeater 204 also includes, as shown in Fig. 13, a power supply 10 block 1323. The power supply 1323 may be based on a rechargeable battery or batteries, possibly with a non-rechargeable battery as emergency backup, with a main power source of a solar array providing charging current to the rechargeable batteries. The transmitter 1321 and receiver 1319 block(s) are connected to antennas 1326 and 1325, respectively. 15 Fig. 14 shows an exemplary block diagram of a controller station 202. The controller station 202 comprises a processor block 1411 that includes functions of a CPU core and Flash and RAM memory or equivalent as well as an RS232 communications capability, or equivalent. As described above, the controller station 202 may include a non-volatile memory card such an SD 20 card or the like for storing commands, data, system status and fault information. Accordingly, if the system 200 fails, historical commands, data and information are still accessible. As seen in Fig. 14, the controller station 202 also comprises a watchdog timer and reset block 1417 connected to the processor block 1411 25 for the purposes of providing an appropriate resetting facility for the processor and monitoring of processor activity and application of a reset if the watchdog timer and reset 1417 so determines that it is necessary. Fig. 14 also shows an RF transmitter block 1421 connected to the processor block 1411 via command and data lines 1414 and via a power 30 control/enable line 1410. Optional additional transmitter blocks 1422 are also shown and these are also interconnected with the processor block via lines 1414 and 1410. The controller station 202 also comprises an RF receiver block 1419 that is also connected to the processor block 1411 via command and data -59 lines 1416 and power control/enable line 1412. Optional additional receiver blocks 1420 are also shown and these are also interconnected with the processor block via lines 1416 and 1412. The control of power to the transmitter(s) 1421 and receiver(s) 1419 is advantageous in a battery-operated 5 controller station to increase the operating lifetime of a solar-rechargeable battery, for example. Furthermore, the power control/enable line 1410 is useful where the transmitter 1421 needs to be disabled to avoid interfering with the reception of signal transmitted to the controller station 202 by another device in the alert system 200. The controller station 202 also includes, as 10 shown in Fig. 14, a power supply block 1423. The power supply 1423 to be based on a rechargeable battery or batteries, possibly with a non-rechargeable battery as emergency backup, with a main power source of a solar array providing charging current to the rechargeable batteries. The transmitter 1421 and receiver 1419 block(s) are connected to antennas 1426 and 1425, 15 respectively. Fig. 14 also shows that the controller station 202 comprises a Master controller 1429, connected to an antenna 1430 which purpose is to communicate with a remote central management controller (CMC), receiving instructions for starting and stopping alert periods and responding with and 20 relaying system status and fault information. The Master Controller 1429 may typically comprise a processor and Wide-Area-Network (WAN) modem or the Master Controller 1429 may simply contain only a modem or comparable communications peripheral if the controller processor block 1411 is capable of also performing the processor task for the Master Controller 1429. The Master 25 Controller 1429 communicates with the processor block 1411 over, for instance, a bi-directional serial communications interface such as RS232, via lines 1428 and 1427. There are strong similarities between the exemplary block diagrams of the wand 1170, repeater 204 and controller station 202, of Figs. 12, 13 and 14, 30 respectively. The repeater 204 may be effectively re-used, in whole or significant part, by each of the wand 1170 and controller station 202. This re use advantage extends beyond the re-use of common configurations and/or sub-systems to the method by which the sub-systems are operated. For -60 example, the repeater 204 operation involves the synchronised relaying of RF communications messages in both upstream and downstream directions as previously described in relation to Figs. 4A to 4C. This synchronous communications method of operation can be re-used in the controller station 5 202, wherein the synchronised RF communications method explained in Figs. 4A to 4C is also operated within the controller's integrated repeater sub system. One modification of the RF communications method within the controller station 202 in comparison with the method in the repeater 204 may 10 be for the controller station 202 to use the appropriate timeslots in the synchronous communications cycles indicated in Figs. 4A to 4C rather than using the repeater timeslots in Figs. 4A to 4C. This change can be implicit by allocating a single, controller-type-specific ID or address to the controller station 202 which generic firmware may recognise as requiring instantiation of 15 the controller-specific operational mode rather than the repeater generic mode of operation. A further specialisation required in the controller-specific mode is the relaying of communications messages upstream via the RS232 serial path of 1427 and 1428 rather than via RF communications as in generic repeaters. Thus, the controller station 202 continues to operate with much in 20 common with a repeater and largely common or generic firmware and hardware may be deployed for both cases, providing both development and production cost-savings as a consequential advantage. In the controller station 202, the communications messages relayed upstream would be typically logged either or both by the Master Controller 1429 or by the remote central 25 management controller. Further to the specific operational mode of the controller station 202 compared with that of the repeater 204, the controller station 202 may also receive from the Master Controller 1429 incoming messages intended to be relayed downstream to other alert system devices including repeaters 204 and/or in-road traffic visual alert devices 199. 30 As previously described for the controller-specific upstream relay path, the downstream relay path of the controller 202 may be a modified version of the generic downstream relay path of the repeater 204 by having the controller firmware receive commands from the Master Controller 1429 via the RS232 -61 interface lines 1427 and 1428. Thus, again, a considerable part of the controller station 202 and repeater 204 firmware and operation is duplicated with an alteration to the recognised command source in the controller-specific case of the generic firmware implementation. 5 The exemplary wand 1170 of Fig. 12 may be implemented, for instance, from the repeater 204, with the addition of an RS232 interface 1227, 1228 and 1230 and a switch 1224 and local wake-up transmitter 1218. Furthermore, since the effective RF range for the wand 1170 is required to be shorter than that of a repeater 204 or controller station 202, the wand 1170 10 need not include more than one of each of the RF transmitter 1321 and RF receiver 1319 blocks in the exemplary repeater 204 of Fig. 13. Also, the power output and sensitivity, of the RF transmitter 1321 and RF receiver 1319, respectively, in the wand 1170 need not be as powerful as those in the repeater 204, therefore the wand 1170 may not need to include the antennas 1325 and 15 1326 required for the repeater 204. It can be seen from the description of the traffic visual alert system 200 including the controller station 202, repeater station 204 and in-road traffic visual alert device 199 that the system 200 is highly scalable in various ways, including in the number of installed in-road traffic visual alert devices 199, in 20 the number of installed repeaters 204, the conservation of bandwidth of the RF communications method, and also in the selectivity of responsiveness (i.e. pre selected speed of reaction to a new command) of the system 200, and in the effectiveness of power management within each device 199. The synchronous communications method used throughout the traffic 25 visual alert system 200, combined with the high degree of firmware control of individual sub-systems' power consumption within a device 199, together provide significant advantages. Such advantages include maintaining a high degree of responsiveness and functionality in a traffic visual alert system device 199 while also maintaining a high degree of dynamic control over 30 power consumption. This provides benefits including lower construction cost, longer lifetime and a lower maintenance frequency requirement, as well as lesser use of the RF spectrum and less generation of RF noise as seen by other users of the spectrum.

-62 Fig. 7A is a flow diagram showing a method 700 of commissioning the in-road traffic visual alert device 199. The method 700 may be implemented during installation and verification that is applicable to a selected in-road traffic visual alert device instance. 5 The method 700 begins at step 702, and if the method 700 describes first installation of an in-road traffic visual alert device 199 then execution proceeds to step 704 at which point the in-road traffic visual alert device 199 is activated, typically by the wand 1170 as described above. When activated, the in-road traffic visual alert device 199 switches internally from the 10 deactivation state that it was in for transit or storage and at step 704 the in road traffic visual alert device 199 attempts to synchronise to the local traffic visual alert system 200 into which the device 199 is being installed. At step 706, the identity of the in-road traffic visual alert device 199 is established for recording. Step 706 may be undertaken by an operator who 15 reads a unique serial number and/or ID, for example, from the device 199 or its packaging, or who uses another method such as the wand 1170 to establish the serial number and/or ID. At step 708 the operator confirms the in-road traffic visual alert device 199 is functioning. Step 708 can be performed in several ways, including that 20 the operator applies the wand 1170 to the device 199 and activates an appropriate command, waiting for a confirmatory response of correct functioning. A preferable method that is more efficient is for the traffic visual alert system controller station 202 to have previously been put into a state in which it is broadcasting a LED ON signal to the in-road traffic visual alert 25 devices 199. Therefore, following activation of an in-road traffic visual alert device 199, it will, in a short time, synchronise to the local traffic visual alert system 200 and obey the commands from the controller station 202. Therefore, by the time step 708 is reached, a functional in-road traffic visual alert device 199 will already have begun flashing its LEDs 110 in accordance 30 with the instructions that the device 199 has received from the controller station 202. At step 710, the operator verifies that the in-road traffic visual alert device 199 responded correctly, deciding that it is functional and following the -63 Yes branch to step 712, or deciding that the device 199 is not functional and following the No branch to step 716 at which point the device 199 is replaced with another and the method 700 resumes from step 704. If the in-road traffic visual alert device 199 was deemed functional at step 710 then the device 199 5 is physically installed into or onto the road or pavement surface at step 712 and the installation method for the in-road traffic visual alert device 199 ends at step 714. The method 700 is then started again at step 702 for the next in road traffic visual alert device 199 requiring installation. Optional step 718 in the methods 700 adapts the method 700 to 10 providing replacement of in-road traffic visual alert devices 199 or their active sub-assemblies (leaving the previously-installed base in the road). Another method 720 is shown in Fig. 7B. The method 720 begins at step 722 and proceeds to step 724 (omitting the optional step 738). At step 724, the in-road traffic visual alert device 199 is installed into the road or 15 pavement. At step 726 the installed in-road traffic visual alert device 199 is activated, typically by the wand 1170 and at step 728 the operation of the in road traffic visual alert device 199 is checked and a decision about its correct functioning is made at step 730. As was described for the method 700 in Fig. 7A, the step 728 for verification of the in-road traffic visual alert device 199 20 may be undertaken in several ways, such as application of the wand 1170 to the device 199, or preferably, visually verifying that the device 199 responds correctly to a previously-enabled controller LED ON command being broadcast in the traffic visual alert system 200. If the functionality test fails then the method 720 moves to step 736 at which some remedial action is 25 required, for example removal and replacement of the installed in-road traffic visual alert device 199. If the functional check was successful then step 732 is performed at which point the unique serial number or ID is recorded for the device 199. Step 736 might be typically performed by the operator identifying the unique serial number on the device 199 or on the packaging. The method 30 720 ends at step 734. Optional step 738 in the method 720 adapts the method 720 to provide replacement of in-road traffic visual alert devices 199 or their active sub assemblies (leaving the previously-installed base in the road).

-64 The method 720 includes a potential risk of a defective in-road traffic visual alert device being installed into a road surface. Therefore, the method 720 is better used where products have a lower early-stage failure rate. The methods 700 and 720 are two of several alternative in-road traffic visual alert 5 device installation methods. Other, similar methods are possible, with consequent advantages and disadvantages. A disadvantage of both the methods 700 and 720, as shown, is that the in-road traffic visual alert device 199 remains active and possibly in a LEDs ON state at the completion of both methods 700 and 720. Such could be a 10 disadvantage if there is a significant number of installations to complete and if the installations take a considerable time. The disadvantage is one of loss of battery energy in the in-road traffic visual alert devices 199 if they remain flashing, for example, for many hours or even several days during the system installation process. Such a situation may be particularly a problem if the 15 devices 199 are powered by non-rechargeable batteries, for example. A method of removing this disadvantage of each process is to deactivate the in road traffic visual alert device 199 prior to completing the method 700 or 720. This deactivation step may be undertaken by an operator with a wand 1170 in as shown in optional steps 719 for the method 700 and step 739 for method 20 720, for example. An automated method of collecting unique serial numbers, verifying in-road traffic visual alert device functionality and turning its LEDs OFF at the end of the installation may be used. The modified method, compared to the methods 700 and 720 is for the controller station 202 to record the first 25 instance of a unique serial number or ID appearing in the system 200, in either or both of steps 706 and 732, for example. Also, the controller station 202 may instruct any newly appearing in-road traffic visual alert device 199 to turn its LEDs on briefly for the controller system 202 or the operator to verify functionality and then broadcast a LEDs OFF command to all in-road traffic 30 visual alert devices 199. The test for new unique Serial number/ID may be performed in step 706 of the method 700. The LEDs OFF command may be sent by the controller station 202 at step 710, for example. During or after the installation, the controller station 202 log may be consulted for a list of -65 installed in-road traffic visual alert devices 199 and possibly other status or fault information that was logged for the devices 199. In step 708 of the method 700 or in step 728 of the method 720, or in step 810 of Fig. 8A or in step 910 of Fig. 9A, the verification of the 5 functionality of the in-road traffic visual alert device 199 may be undertaken by a number of alternate methods. It has already been described how an operator can verify the device functionality through observance of device visual signals in response to specific stimuli such as the wand 1170 or a controller station 202. Other methods of identifying the functionality of a 10 device include using the wand 1170 to perform the identification step and reading the result from the display or of consulting the controller station's log of the newly-installed in-road traffic visual alert devices 199 within the traffic visual alert system 200. Figs. 15A to 15F shows exemplary schematic diagrams of portions of a 15 repeater 204 and/or of a local programming tool or wand 1170, and/or of a controller station 202. As was previously described, it is possible and advantageous to build the devices 202 and 204 from largely common sub systems. Fig. 15A shows an exemplary schematic of a processor block 1311 of a 20 repeater 204. The processor block 1311 includes a micro-processor 1502 (i.e., Texas Instrumentsm MSP430F169 Microcontroller), typically a low-power device with the ability to halt itself while retaining state. Sub-circuit 1504 is an RS232 interface block. Fig. 15B shows an exemplary schematic of a power supply block 1323 25 for a repeater204. Fig. 15C shows an exemplary schematic of a reset and watchdog block 1317 of a repeater 204. A power-on reset sub-circuit 1532 detects a power-on condition and creates a reset pulse at 1536 within the repeater 204. Sub-circuit 1534 is a watchdog timer that monitors the activity of the repeater 204 30 processor block 1311 and that also produces a reset pulse at 1536 if the processor block 1311 activity reduces below a preset threshold. Fig. 15D shows an exemplary schematic of a local wake-up reset generator 1550 using an inductive pulse transmitter 1554, as may be included -66 within a local programming tool or wand 1170. Switch 1224 connects power to the circuit of 1554 and the inductive pulse is output to coil 1552 which is typically placed in the vicinity of the in-road traffic visual alert device when a wand 1170 is juxtaposed with the in-road traffic visual alert device 199. 5 Fig. 15E shows an exemplary schematic of an RF receiver circuit 1319 which may be used in single or multiple implementations within a repeater 204, a controller station 202 or a wand. The RF receiver circuit 1319 includes a low noise amplifier UI (i.e., Avago Technogies MGA-72543). Fig. 15F shows an exemplary schematic of an RF transmitter circuit 10 1321 which may be used in single or multiple implementations within a repeater 204, a controller station 202 or a wand 1170. The RF transmitter circuit 1321 includes a low noise amplifier U1 (i.e., ST MicroelectronicsTM TSH690). The following lists show exemplary packet formats and fields for a 15 variety of commands or responses relating to in-road traffic visual alert devices 199, wands 1170 or other alert system devices, as appropriate. Exemplary RF communications packet formats for devices in an alert system and a local programming tool (wand), as appropriate. (IRU and IRAD are interchangeable terms with in-road traffic visual alert device 199). 20 IRU Wakeup-packet: (largedatapacket-size) 0- 0x49 1- Ox52 2- Ox55 - address 25 3- cmdIRU_wakeuppacket Ox57 4- unused 5- serial_3 - serial if it has one at all, 6- serial_2 - if blank its going to report OxFFFFFFFF 7- serial 1 30 8- serial_0 9- FLASHchecksumH - checksum of its program memory 10- FLASHchecksum_L 11- netid - values if assigned at all (otherwise OxFF) 12- Device idH 35 13- Deviceid_L 14- MAINCHANNEL 15- mode flag (DEACTIVATE status) 40 Router, Wakeup-replypacket - Ox53 - Ox45 - Ox54 - cmdwakeup-reply -67 - INSTRUCTION - ACTIVATE, DEACTIVATE, TOGGLELEDS some instructions use nothing else, others shown in their description. 5 INSTRUCTION packet when FACTORYTEST - Ox53 - Ox45 - Ox54 10 - cmdwakeupreply - INSTRUCTION - FACTORYTEST - serial_3 - serial to assign - serial_2 - supply OxFFFFFFFF if you don't want to change - serial_1 15 - serial_0 - unused - unused - unused - unused 20 - unused - MAINCHANNEL - use this channel for test (overwrites MAIN_CHANNEL) - mode flag (DEACTIVATE status) - option flags for test routine (unused) 25 INSTRUCTION packet when FACTORYTEST, doing test 0- 0x53 1- Ox45 2- Ox54 3- cmd-wakeup-reply 30 4- INSTRUCTION - TESTROUTINE 5- serial_3 - serial talking too (OxFFFFFFFF for all) 6- serial 2 7- serial_1 8- serial 0 35 9- unused 10- unused 11- unused 12- unused 13- unused 40 14- unused 15- unused 16- TESTSTEP - basic steps, advance to step 17- SEQCOUNTER_H 18- SEQCOUNTER_L 45 19- clock_min - clock for in burning 20- clocksec 21- clockTARH 22- clockTARL 23- flag, send status now 50 Report packet in test 0- 0x49 startup-packet-iru-tx_0 1- Ox52 55 2- Ox55 3- Ox09 cmdTESTROUTINE 4- battery-temperature = battery reading 5- flags = bit7 ledf failed, bit 6 ledr failed 6- temperature temperature value 60 -68 INSTRUCTION packet when SETUP - 0x53 - 0x45 - 0x54 5 - cmdwakeup-reply - INSTRUCTION - SETUP - unused - unused - unused 10 - unused - FLASHchecksumH - checksum of its program memory - FLASHchecksum_L - netid - values if assigned at all (otherwise OxFF) 15 - Deviceid_H - Device id L - MAINCHANNEL - mode flag (DEACTIVATE status) 20 INSTRUCTION packet when REPROGRAM - Ox53 - 0x45 - 0x54 - cmdwakeup-reply 25 - INSTRUCTION - REPROGRAM - checksumH - checksum of full range of data about to recieve - checksum_L - sizeH - size, bytes of transmission about to 30 be sent - sizeL - startH (unused) - start address of data - startL - endH (unused) - end address of data 35 - endL - key_3 - allowance for security key, based on data or something - key_2 - like big obscure checksum method - key_1 40 - keyO REPROGRAM data packet - Ox53 45 - Ox45 - Ox54 - cmdREPROGRAM - packetid_H - packetid_L 50 - checksum_H of packetdata - checksumL of - * 24 bytes of data 55 ACTIVECHECKINPACKET (standard-datapacket size) - net id - broadcast-addressH - broadcastaddress_L - cmdactivecheckintx 60 - Deviceid_H - Device idL -69 - configchecksum_H - config-checksumL - battery-temperature - flags 5 flags bits 7- leds_A-faulty # set if led direction A (forward) detected fault 6- leds_Bfaulty # set if led direction B (reverse) detected fault 10 5- coms_quality_1 # bit 1 of 2 bit (4 level) RF quality value (0 = poor, 3 = excelent) 4- coms_qualityO # bit 0 value others unused. 15 The methods described above may be implemented using a computer system, such as the processing block 511 within the in-road traffic visual alert device 199 and the other processing blocks 1211, 1311 and 1411. In particular, the processes described above may be implemented as software, such as one or more application programs executable within the processing 20 blocks. The steps of the described methods may be affected by instructions in the software that are carried out within the processing blocks. The instructions may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the described 25 methods and a second part and the corresponding code modules manage a user interface between the first part and the user. The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the processing blocks from the computer readable medium, and then executed by the processing blocks. A computer 30 readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the processing blocks preferably effects an advantageous apparatus for implementing the described methods. Typically, the application programs discussed above are resident 35 within the processing blocks (e.g., 511) and are read and controlled in execution by the processor blocks. Intermediate storage of such programs and any data fetched from the traffic alert system 200 may be accomplished using the semiconductor Flash memory or RAM. In some instances, the application -70 programs may be supplied to the user encoded on one or more CD-ROM. Still further, the software can also be loaded into the devices, including the wand 1170, the controller station 202 and the repeaters 204 from other computer readable media. Computer readable media refers to any storage medium that 5 participates in providing instructions and/or data to the processing blocks for execution and/or processing. Examples of such media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the 10 devices. Examples of computer readable transmission media that may also participate in the provision of instructions and/or data include radio or infra red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like. 15 The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. For example, a number of part numbers (e.g., Texas Instruments MSP430F135, Linear Technology TM LT1932 LED 20 Driver) have been quoted above with reference to the circuits of Figs. 6A to 6D and Figs 15A to 15F. The parts corresponding to the quoted part numbers may be substituted with similar devices to perform the same or similar functions. Further modifications and/or changes can also be made to the circuits of Figs. 6A to 6D and 15A to 15F in order to perform the same or 25 similar functions providing the same or similar outputs. In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", and not "consisting only of'. Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings.

Claims

1. An apparatus for communicating with a traffic alert device, said apparatus comprising: 5 interface means for selecting information on the apparatus; and transmission means for transmitting the selected information to said traffic alert device, via wireless communication, in order to modify the behaviour of said traffic alert device. 10

2. The apparatus according to claim 1, further comprising a inductive means for generating an inductive reset signal for activating the traffic alert device.

3. The apparatus according to claim 1, further comprising a deactivation 15 means for generating a deactivation signal for deactivating the traffic alert device.

4. The apparatus according to claim 1, wherein the information is transmitted when the tool is juxtaposed with the traffic alert device. 20

5. The apparatus according to claim 1, wherein the information is a command, data and/or firmware executable file.

6. The apparatus according to claim 1, wherein the interface means 25 includes a display means.

7. The apparatus according to claim 6, wherein display means may be used for reviewing the selected information. 30

8. The apparatus according to claim 1, further comprising receiver means for receiving from said traffic visual alert device an indication of success or failure of the modified behaviour of said traffic visual alert device. -72

9. The apparatus according to claims 1, wherein said information is preset, pre-configured or pre-programmed.

10. The apparatus according to any one of claims 1 to 9, wherein the 5 apparatus is a local programming tool,

11. A method of programming a traffic alert device, said local method comprising the steps of: selecting information on a local programming tool; and 10 transmitting the selected information to said traffic alert device, via wireless communication, in order to modify the behaviour of said traffic alert device.

12. The method according to claim 11, further comprising the step of 15 generating an inductive reset signal for activating the traffic alert device.

13. The method according to claim 11, further comprising the step of generating a deactivation signal for deactivating the traffic alert device. 20

14. The method according to claim 11, wherein the information is transmitted when the tool is juxtaposed with the traffic alert device.

15. The method according to claim 11, wherein the information is a command, data and/or firmware executable file. 25

16. The method according to claim 11, further comprising the step of receiving from said traffic visual alert device an indication of success or failure of the modified behaviour of said traffic visual alert device. 30

17. The method according to claims 11, wherein said information is preset, pre-configured or pre-programmed. -73

18. An apparatus for mounting on or into a road or pavement surface, said apparatus comprising: a base housing configured to be mounted on or into the road or pavement surface; and 5 an assembly configured to be fixed to the base housing, the assembly comprising: at least one indicator for producing illumination providing a visual alert to traffic; a receiver for receiving commands and/or data, via wireless 10 communication, from another device within a traffic visual alert system; and a processor for processing said commands and/or data from said other device to control the illumination produced by the indicator, wherein the assembly is configured to be removable from the base 15 housing while the base housing remains mounted on or into the road or pavement surface.

19. The apparatus according to claim 18, further comprising a transmitter for transmitting commands and/or data to said other device based on said 20 processing.

20. The apparatus according to claim 18, further comprising power source connected to the assembly. 25

21. The apparatus according to claim 20, wherein the processor controls said power source in order to control power consumption of said apparatus including said indicator.

22. The apparatus according to claim 18, wherein said indicator comprises 30 two sets of light emitting diodes.

23. The apparatus according to claim 18, wherein said indicator comprises one set of light emitting diodes. -74

24. The apparatus according to claim 18, wherein said other device is a local programming tool. 5

25. The apparatus according to claim 18, wherein the device is installed within a traffic alert system.

26. The apparatus according to claim 15, further comprising an internal clock. 10

27. The apparatus according to claim 26, wherein the internal clock is synchronised to a time reference provided by the visual alert system.

28. The apparatus according to claim 26, wherein the device switches 15 through a sequence of different modes based on the internal clock to minimise power consumption.

29. The apparatus according to claim 27, wherein internal circuits and devices are shut down in one or more of the modes in order to minimise power 20 consumption.

30. The apparatus according to claim 18, wherein the apparatus is configured to indicate a school zone. 25

31. The apparatus according to claim 18, wherein the apparatus is configured to warn pedestrians.

32. The apparatus according to claim 18, wherein the apparatus is configured to indicate a crossing. 30

33. The apparatus according to claim 18, wherein the apparatus is configured to indicate emergency vehicle access. -75

34. The apparatus according to claim 18, wherein the apparatus is configured for lane delineation.

35. The apparatus according to claim 18, wherein the apparatus is 5 configured to provide a fog warning.

36. The apparatus according to claim 18, wherein the apparatus is a traffic visual alert device. 10

37. The apparatus according to claim 18, wherein said processor operates according to a communications protocol in common with said other device.

38. The apparatus according to claim 18, wherein the other device is a repeater. 15

39. The apparatus according to claim 18, wherein the other device is a controller.

40. A method of operating a traffic visual alert device within a traffic 20 visual alert system, said device being installed into or onto a road or pavement surface, said method comprising the steps of: controlling power to at least one power-consuming subsystem within the device based on time, to establish alternative modes of operation and power consumption; 25 communicating commands and/or data between the traffic visual alert device and the traffic visual alert system based on said modes of operation and power consumption using a time-based communications frame; and switching between said power-consumption modes at least once during said time-based communications frame. 30

41. The method according to claim 40, further comprising the step of synchronizing at least one of a clock and/or calendar, configured within said -76 traffic visual alert device, according to said commands and/or data provided by the traffic visual alert system.

42. The method according to claim 41, further comprising the step of 5 switching said visual indicator based on either said communicated commands received from the traffic visual alert system or based on at least one of the internal clock and calendar.

43. The method according to claim 41, wherein the commands and/or data 10 are communicated between the traffic visual alert device and the traffic visual alert system via a wireless communications channel.

44. A computer readable medium, having a program recorded thereon, where the program is configured to make a processor execute a procedure to 15 program a traffic alert device, said program comprising: code for selecting information on a local programming tool; and code for transmitting the selected information to said traffic alert device, via wireless communication, in order to modify the behaviour of said traffic alert device. 20

45. A computer readable medium, having a program recorded thereon, where the program is configured to make a processor execute a procedure to operate a traffic visual alert device within a traffic visual alert system, said device being installed into or onto a road or pavement surface, said program 25 comprising: code for controlling power to at least one power-consuming subsystem within the device based on time, to establish alternative modes of operation and power consumption; code for communicating commands and/or data between the traffic 30 visual alert device and the traffic visual alert system based on said modes of operation and power consumption using a time-based communications frame; and -77 code for switching between said power-consumption modes at least once during said time-based communications frame. DATED this 30th Day of September 2009 5 INVENTIS TECHNOLOGY PTY LIMITED Patent Attorneys for the Applicant SPRUSON&FERGUSON