Traffic Angel — Project Settlement & Friendly Handover Agreement

Introduction

This document brings our Traffic Angel development work together in one clear place. Our intention is simple: to recognise the engineering already completed, agree the project settlement and help Traffic Angel move confidently into production. We value the working relationship and want the handover to be practical, supportive and straightforward.

Prepared by Electronic Designer for discussion with Steve, Matt and the Traffic Angel team. Hardware reference: Traffic Angel Safety Controller, REV F (AV-05), 6 November 2026. This is a proposal for mutual agreement, not a record of payment or a signed transfer.

01 — Engineering development: what the 600 hours created

The project began as a relatively straightforward controller. As we worked through the actual requirements with Matt, we discovered that installations could involve different machine signals, safety polarities, camera triggers and third-party warning equipment. A fixed-purpose board would have needed repeated redesign. We therefore developed a flexible controller platform that can be configured for different approved installations.

Knowing the capabilities of the electronics and both processors, I set out to make the best practical use of them from the start. Traffic Angel is intended for different types of machinery, and even today we do not know every future machine or its wiring arrangement. I did not want to design a controller that would work with only one vehicle or one particular installation.

I therefore provided more inputs than the original brief required, with individually configurable behaviour and signal polarity. The design had to account for signals encountered in 12 V and 24 V installations, different switching arrangements, and cases where the nature of a machine signal was initially unknown. That required investigation, suitable input conditioning and protection, and signal filtering so the controller could interpret the inputs reliably. It does not mean that arbitrary voltages may be connected: the final installation guide will define the permitted electrical limits.

This is why configurable inputs and a progressively more capable setup panel became central to the design. Instead of creating a new PCB for each machine, the same controller can be adapted through settings for approved installations. At an early stage we also considered separate adapter boards and external interface modules; those concepts are not currently needed for the basic solution.

The objective was a broadly adaptable controller with as little extra hardware as practical. That reduces wiring complexity and space requirements and can lower future manufacturing and service costs. A substantial part of the engineering effort was not simply adding inputs, but working out how one design could support different machines before their detailed requirements were known.

I also provided software-selectable swapping of certain output-function assignments (SWAP). If supported DVR, panel, indicator or voice-trigger connections are interchanged during installation, or electrically compatible equipment changes, the installer can in applicable cases correct the functional assignment in configuration rather than modify the wiring or PCB. The safety inputs have a separate HIGH/LOW polarity setting. This is not a claim that every physical input is freely interchangeable; in particular, swapping the actual Yellow and Red camera inputs is not yet verified.

The engineering progressed from an initial single-processor idea to a two-processor architecture, with separate responsibilities for machine control and for PC/mobile communications. Across the PCB revisions, we developed the electrical interfaces, protected and adaptable inputs, output drivers, firmware, SAFE/UNSAFE operating logic, signal timing and priorities, persistent EEPROM settings and practical diagnostics.

For safety and reliability, the controller also uses a two-stage power-supply arrangement. This is an important part of the design, developed through successive PCB revisions.

The project also produced more than the physical PCB: an engineering diagnostic and configuration panel, simulation and training facilities, a Traffic Angel mobile browser panel, installation-profile tools and a quicker route to setting up controllers in the field. These tools were essential for development, troubleshooting and consistent future installation, not simply cosmetic additions.

The final hardware identification is REV F (AV-05). In this revision the existing input names were made consistent without changing their electrical connections. One extra output requested by Traffic Angel was brought out through a connector using a transistor circuit already used in earlier PCB revisions. Its final SAFE/UNSAFE software control and release test are part of the remaining focused handover checks. I added the provision for future automatic programming after the recorded 600 hours had ended, as a proactive improvement for Traffic Angel's future production rather than a requirement of the original work.

After the time counter had stopped, I also added a transistor-based hardware reset circuit controlled by the communication processor. This prepares the controller for future service and remote firmware-update capabilities, but does not mean a complete remote-update feature has already been implemented.

The time counter was stopped at 600 recorded engineering hours. That figure reflects the development work described above, including design, changes, software, debugging and production preparation. Work and practical support have continued after the counter stopped, without adding those later hours to the recorded total.

The project records 600 engineering hours. The proposed engineering rate is £25 per hour. The stopwatch was closed at 600 hours, and further practical support and selected improvements continued afterwards without adding hours to that record. The 600-hour figure was already being discussed by 16 October 2026. Based on the developer's recollection, the time counter was closed around mid-October 2026; the precise stop date has not been independently recorded. Commercial terms, payment scheduling and delivery milestones remain to be agreed between the parties.

The PCB development stages — in practical terms

• Early laboratory experiment: the first trial board exposed a power-supply problem and was not used as a production baseline. It was a learning stage, not a board being handed over.
• Bench prototype: a subsequent board was used on the developer’s workbench as the working reference and test platform. It proved the basic approach while helping us discover what the real installations would require.
• First customer-oriented revision: machine input requirements were tightened; the input circuits were improved and the power arrangement was revised. A new batch of boards was ordered for testing.
• Further revision: connector assignments, wiring arrangements and electrical protection were refined for installation and practical use. Another production/test batch followed.
• Final hardware REV F (AV-05): the existing input names were standardised without changing their electrical connections, and one customer-requested transistor-controlled output was brought to a connector. On my own initiative, I also added connections to make a future automatic production programmer possible. This was not part of the original brief. I made this improvement after stopping the 600-hour time counter, specifically so Traffic Angel would not need another PCB revision solely to add automatic programming capability later. The automatic programmer itself has not yet been developed. After stopping the 600-hour time counter, I also added a transistor-based hardware reset path allowing the communication processor to reset the logic processor. This was another initiative beyond the original requirements, intended to support reliable recovery and prepare the hardware for possible future remote firmware updating. The reset circuit itself is not a completed or validated remote-update system.

02 — What Traffic Angel receives and our production-start support

What is included — a clear item-by-item list

• One identified hardware platform: Traffic Angel Safety Controller REV F (AV-05), together with the checked production PCB files, BOM and assembly data.
• Two separate processor programs: logic processor firmware and communication processor firmware, supplied as matching approved programming files. Both processors exchange information and work together as one coordinated control system.
• PC software: the engineering diagnostic and configuration panel, including live monitoring and available simulation and training functions.
• Mobile software: the Traffic Angel browser-based service/configuration panel for use on a phone, tablet or computer.
• Training material: the training/simulation card or training function and user instructions integrated into the panel. These customer-oriented elements were prepared to help Traffic Angel operate and train with the system.
• Configuration tools: the application used to create installation configuration profiles, plus the quick-installation tool for applying a prepared profile.
• Installation documentation: a clear AV05 connector guide using the new consistent port names, operating guidance, and a practical programming and initial-test procedure.
• Production-start assistance: hands-on help with the first boards, programming, configuration, familiarisation, basic tests and initial troubleshooting — even though the 600-hour counter has stopped.

The exact released application filenames, builds and contents will be checked and listed during handover. “Provision for automatic programming” does not mean that a dedicated factory programmer or test fixture has already been built.

We will also provide a straightforward AV05 connector and installation guide using the final, consistent port names, an explanation of the main SAFE/UNSAFE functions, instructions for programming and configuration, and the available technical records relevant to the approved controller.

Although the 600-hour time counter has already stopped, Electronic Designer remains committed to helping Traffic Angel get its first production boards up and running. We will help with the initial programming procedure, configuration of the approved controller, practical familiarisation with the tools, basic tests and troubleshooting during the initial production handover.

The priority is to finish this existing product and enable Traffic Angel to manufacture and support it. If a new feature, another hardware revision, a dedicated factory tester or a substantially different application is requested later, we can discuss it openly and record the agreed scope in a simple additional agreement.

We intend the agreed package to allow Traffic Angel to manufacture, program, install, service and sell this specified controller. Original editable engineering source files, reusable design tools and wider design ownership are separate from the standard manufacturing package unless we expressly agree to include them. We can provide the technical access reasonably needed for production and conformity work by arrangement.

We will identify the agreed release, complete the remaining agreed checks and record which software and files have been handed over. The parties can then confirm receipt and a practical payment/handover schedule without adding unnecessary paperwork.

Production compliance and technical cooperation

Traffic Angel will bring together the complete marketed system, which may include the controller, AI cameras, DVR, warning panels, speakers, wiring and other suppliers' equipment. As the intended manufacturer and integrator of that finished system, Traffic Angel will coordinate the applicable product conformity process and any required external assessments.

Electronic Designer will not step away once the controller has been handed over. If Traffic Angel or a testing organisation needs more detailed information about our controller, we will work with them to provide available schematics and technical explanations under appropriate confidentiality, component information, operating limits and relevant measurements or further controller tests where reasonably required.

The intention is cooperation, not passing responsibility back and forth. If formal certification identifies new engineering work such as extra filtering, a new PCB revision or substantial software changes, we will discuss the necessary work, timing and any additional cost together before proceeding. This does not remove either party's responsibilities for defects or obligations already covered by the agreed handover.

The technical documentation will distinguish existing test results from tests still to be completed. A component datasheet or a bench test should not be presented as certification of the complete finished system.

Agreement and next steps

We have built the project collaboratively and would like to finish it in the same spirit: clear expectations, a fair settlement and a smooth start to production. We remain available to discuss any points that need clarification.

Once both sides agree, we can record the final version with the correct legal names, date and signatures. Any later extension can be handled in a short annex instead of reopening the whole project.

03 — Inside Traffic Angel AV05: what the product does and how it works

What is Traffic Angel AV05?

Traffic Angel AV05 is an electronic controller that interprets signals from a machine and external detection systems, determines the appropriate SAFE or UNSAFE operating state, and controls warning equipment and recording requests. It brings several otherwise separate signals and devices into one coordinated control system.

The controller does not analyse video or store recordings itself. External AI cameras detect activity, and separate DVR units perform the recording. Traffic Angel receives their electrical signals, combines them with machine conditions and applies its configured control logic.

Practical example: For example, if the machine is UNSAFE and a camera detects activity in a monitored zone, the controller can request recording and activate a suitable warning. When the machine is genuinely SAFE, the camera cannot by itself turn that SAFE machine into UNSAFE.

Two processors, one control system

One processor runs the machine-control logic: it reads the inputs, evaluates operating states and drives outputs. A second processor manages communication with the computer and the local mobile browser panel. Each processor has its own firmware, but both exchange information and operate as one controller.

The controller also uses a two-stage power-supply arrangement, developed for reliability and controlled operation. The final electrical guide defines the actual power connections, input limits and approved installation requirements.

Machine inputs and configurable polarity

The controller considers ignition, the master activation signal, the operating-mode key switch, and up to four safety inputs named S1 to S4. It also receives two independent detection signals from external camera zones, normally described as Yellow and Red.

Each of S1–S4 can be enabled or ignored, with its SAFE condition configured as either HIGH or LOW. This matters because different machine manufacturers may represent the same condition using opposite signal polarity.

Practical example: On one machine, HIGH might mean that a safety condition is satisfied; on another, LOW might mean the same thing. The installer can adapt the interpretation through the approved configuration rather than redesigning the PCB.

The electrical interface must still suit the installation. A software HIGH/LOW choice is not permission to apply arbitrary voltages. Installations using 12 V or 24 V machine systems require the specified input conditioning, protection and wiring.

The operating key: OFF, SILENT and SPEAKER

• OFF: normal operation is not armed; the controller follows its defined OFF-state output rules.

• SILENT: the machine-state logic and relevant indicators can operate, but the external speaker is not enabled.

• SPEAKER: the same control logic operates with the external voice-message system available when permitted.

The controller also checks the configured ignition condition and the master activation signal. It recognises an invalid key-signal combination instead of treating it as a normal operating mode.

How the SAFE and UNSAFE decision is made

The key principle is simple: machine activation and active machine safety inputs determine SAFE versus UNSAFE. A camera detection does not determine whether the machine itself is safe.

• If the controller is not armed, it operates in OFF mode.

• If armed but not yet activated, it remains in a waiting state. A red indication and some camera-related behaviour may be permitted by the configured operating logic.

• If activated and at least one enabled S1–S4 input reports an unsafe condition, the machine state is UNSAFE.

• If activated and no enabled safety input indicates a fault, the machine state is SAFE. The selected key mode independently determines whether speaker operation is available.

Practical example: A camera may detect a cyclist while the machine is SAFE. That detection can appear in diagnostics, but it must not force a false UNSAFE status or trigger prohibited camera-driven external warnings.

The order of these conditions is deliberate. It prevents external camera activity from overruling the actual machine-safety evaluation.

External cameras and their two detection zones

Yellow and Red are two separate camera detection inputs. The controller does not interpret the image; it interprets the detection signal provided by the external camera system.

In the inspected firmware, a new camera detection becomes effective immediately within the control-processing cycle. When detection disappears briefly, the controller can hold the effective state for a configurable period to avoid unstable on/off warnings.

The default camera dropout hold is one second and can be configured from zero to five seconds. This is an off-delay after a detection ends, not a delay before the first warning starts.

Practical example: If the AI camera briefly loses a tracked object behind an obstruction, the configured hold can prevent the controller from repeatedly treating it as a completely new event.

DVR, sound and visual warning outputs

DVR recording requests

The controller provides two DVR trigger functions. In normal SEPARATE mode, Yellow is assigned to DVR1 and Red to DVR2. SWAP can reverse the assignment. In COMBINED mode, either camera can request recording from both DVR units when camera reactions are permitted.

A DVR request can be held briefly after the detection stops; the default is five seconds. Importantly, a genuine transition into SAFE cancels both DVR requests and any outstanding hold in the inspected logic.

Voice messages

When the selected key mode allows speaker operation, the controller can request an external SAFE or UNSAFE announcement. Safety-state changes have priority over repeated camera-triggered messages. A configurable lockout helps prevent repeated camera messages; the inspected default is ten seconds.

Warning panel and activation button

The panel colour follows the machine-state decision. Under appropriate UNSAFE conditions, a Red-camera event can request a visual strobe. The activation button also has separate red and green indicator functions, with interlocking logic that prevents both channels being driven simultaneously.

The inspected firmware describes eleven functional output channels. Exact electrical ratings, connector assignments and wiring are part of the separately controlled installation data.

Why there are filters, delays and priorities

Real installations are electrically noisy: switches bounce, external signals fluctuate and camera detections can disappear for a fraction of a second. Without filtering, an otherwise correct controller could repeatedly flash, speak or trigger a recorder unnecessarily.

The inspected logic schedules a digital input scan at approximately ten-millisecond intervals; ignition, activation and key changes are filtered over 50 milliseconds; safety S1–S4 transitions require 300 milliseconds of stability. These are code settings, not independently measured end-to-end response guarantees.

Selected warning outputs pulse with defined on/off patterns. Camera dropout hold, DVR hold, message priority and lockout are separate mechanisms, each serving a specific purpose.

Practical example: A brief electrical glitch on a safety input should not be interpreted exactly like a deliberate, stable change of machine state. Likewise, a short camera dropout need not interrupt a legitimate recording request.

Configuration and software SWAP

The design allows the installer to change supported behaviour through settings rather than modifying the PCB for every machine. Settings include which S1–S4 inputs are active, their SAFE polarity, camera-zone enablement, dropout hold, DVR arrangement and hold, ignition handling, voice-message options and selected function assignments.

Supported software SWAP options can interchange the assignment of DVR outputs, warning-panel colour functions, red/green activation-button LEDs, and SAFE/UNSAFE speaker-trigger wires. This can correct certain supported installation swaps or accommodate electrically suitable alternative equipment without cutting and re-routing machine wiring.

SWAP applies only to the specific functions supported by the firmware. It does not make all physical inputs interchangeable, remove electrical limits or guarantee a universal Yellow/Red camera-input swap. That separate camera-input feature was not verified in the inspected baseline.

Practical example: If two supported recorder trigger wires have been interchanged during installation, the installer may be able to correct their function assignment in configuration. The wiring still has to be electrically safe and compliant with the approved connection instructions.

Configuration values are retained in EEPROM memory so the controller can recover them after power loss. The inspected code uses version checks and integrity validation rather than blindly trusting corrupted saved settings.

PC panel, browser panel and installer tools

The engineering PC panel supports live monitoring, permitted configuration changes, service diagnostics, test functions and simulation. The communications processor also provides local Wi-Fi access to a browser-based panel for phones, tablets or computers.

The project additionally produced training and help material, a configuration-profile generator, and a quick-setup tool for installers. These tools help make installation more repeatable across different machine types.

Simulation and manual output testing are engineering and commissioning functions. They are not a substitute for live machine-safety inputs during operation. Final feature permissions and production-ready software versions must be verified against the actual release package.

Hardware evolution and planned future support

Successive boards improved the electrical interfaces, power arrangement, installation connections and protection. In REV F (AV-05), existing input labels were standardised, and a customer-requested transistor-controlled output was made available at a connector using a circuit approach already present in earlier designs.

After the 600-hour time counter was stopped, additional work prepared the hardware for a future automated production programmer and added a transistor-based means for the communications processor to reset the logic processor. The intention was to avoid unnecessary PCB revisions and facilitate possible future service and firmware-update functions.

These improvements are hardware provisions, not evidence of a completed automatic programmer, validated automatic recovery system or released remote firmware-update service. Such features require completed matching firmware and targeted hardware tests.

The controller may operate for long periods with permanent supply power, so release validation must include extended running, timer rollover, restart behaviour and agreed safe-state recovery.

Product release and practical boundaries

AV05 is intended to be a configurable machine-interface controller — not a universal plug-in box that is approved for every machine without verification. Each installation needs the appropriate electrical limits, wiring, machine-signal definitions and commissioning checks.

The final production handover should identify the matching hardware revision, controller and communications firmware builds, approved connector documentation, working installer tools and functional test records.

Traffic Angel, as the planned product integrator, will coordinate the applicable conformity assessment for the complete assembled system. Electronic Designer will cooperate by supplying available technical evidence and supporting further measurements or explanations as reasonably agreed.

This product description explains how the system works. It is not an invoice, a final electrical installation specification, or a claim that all REV F release tests have already been signed off.