over-egging AFDDs?

Interesting.

Fuses >MCBs >>RCDs >>>RCBOs >>>>SPDs >>>>>AFDDs

what next for 19th ed? David Savery is imagining a computerised consumer unit ...

thanks: a nice illustration of how much is left to speculation when changes are made without an impact assessment - i.e. a something setting out just what the change is meant to achieve, with what costs and benefits, and what other options were considered but rejected.

If you've time to watch a longer video, or just leave in running for audio-only in the background (it does have added swearing) then here's a chap pointing out the new changes including the wording from the HSE (that probably ought to have been in previous versions) reminding electricians that all which is old isn't dangerous, and doesn't necessarily need replacing to comply with latest regs ... some of the youtube sparkies can't seem to cope with installations that are older than they are, so "replace it" seems to be their mantra.

AFDDs *are* computerised. There's a microcontroller in there trying to detect the signature of an arc.

Now I wonder about firmware updates...

Theo

He knows, he's fitted 9 of them to his own CU to see how they perform, I think he's envisaging the CU having one processor for all devices ...

There is *something * to be said for upgrading to what you are familiar with...

That would be a major reverse from the path of "whole house" 1 RCD > "split" CU with 2 RCDs > RCBOs. I'd expect the Committee, aided by industry experts, would mandate at least triple redundancy - i.e. 3 independent systems.

and CU hosted malware :-)

The suggestion is that you would use AFDDs that replicate and replace RCBOs in most cases. So one per (high risk) circuit.

Given the current costs of AFDDs, sharing some of the hardware over multiple circuits might make some kind of sense. Possibly having the AFDD functionality shared but individual RCBOs. You can't really run multiple circuits through a single AFDD, but maybe a device that can 'see' multiple circuits and push the trip button on each of them if an arc is detected.

I could imagine some kind of 'smart busbar' that hosts multiple plug-in RCBOs.

A central unit would likely be nicer than trying to parse the fault LED flash code on an individual module - could have a nice display or something.

Theo

My comment was aimed not at how AFDDs work now but at the idea of "the CU having one processor for all devices ..."

Won't happen.

There's no reason to put enough brains in a gadget like that to host malware - it would make it more expensive.

Your intelligent heating controls, OTOH...

Andy

we're not talking about a simple microcontroller like a PIC inside an AFDD, they have ARM CPUs in them. OK, they have no connection to anything (yet)

I was not seriously suggesting that it will.

I expect the amount of brains required for the real time signal processing that they need to do will easily cope with additional tasks.

However the limitation would be lack of external comms at the moment.

there seemed to be no reason for any electronics in fusesboxes then electronic timers got cheaper than mechanical then RCDs came along now AFDDs next it might be circuit controllers that recognise every load & spot anything abnormal going on. And that'll need lots of software updates.

Give me a bimetal stat any day.

Consider me shocked!

Oh.

Let me rephrase that.... surprised?

I'd be interested to read something on the theory, and why they need a CPU with any grunt in it at all. After all they're just signal processing a 50Hz waveform. It's not exactly RF... My google fu has failed me, and I can't see anything that says _how_ they do it.

Andy

Dunno but here's a destructive teardown, get ready with the pause button at 28s I think I can make it out as STM32F or similar?

Not got any real info, but must be looking for more complex waveforms, as many of the sparkies on youtube failed to get AFDDs to trigger with a "primitive" spark rig.

BS EN 62606 if you have access, I notice that BSI are clamping down on access to PDFs and requiring DRM plug-ins now ...

Probably because the "how" is proprietary and where the money is to be made for the early vendors (before they have been copied and commoditised at least!)

(Also the waveforms they will interested in will be up into RF - not just 50Hz)