K22/Decabit Signalling Schedule Analysis

Earlier, I discovered the annoyance of mains ripple based signalling and developed a means of decoding and logging the transmissions. While I performed some preliminary analysis, further collection was underway.

After collecting a little more than a week’s worth of data, I was able to look at the data as a whole. The preliminary analysis posted seemed to show transmissions starting at xx:25:15 and xx:55:15 with the exception of two transmissions a day for street lighting control. This was found to hold true throughout the week. No anomalous “non K22” transmissions were noted, and about 95% of the transmissions decoded successfully with no error.

It was found that the majority of scheduled messages correlated identically with the same scheduled message transmitted the next day, however, some differences were also observed.

I have compiled the normally scheduled transmissions into a table. Transmission times are listed across the top row, with each row representing either a K22 channel, prefixed by K22-, or a Decabit command number, prefixed by DCO-. Seemingly redundant commands in the Decabit system are denoted by being surrounded by parenthesis. Commands which are not always sent in that state (i.e. we have 1-3 samples in this state, rest in the other) are marked with an asterisk. The highlighting has been adapted to reflect this – for the K22 system, green indicates power always available in this slot, whereas beige represents power sometimes available in this slot and white indicates power never available in this slot. For the Decabit system, this is denoted by pink, purple and white respectively.


It may be counter-intuitive that the only commands on Decabit command 50 are marked as redundant – this is because it is always preceded by a unscheduled transmission which varies in time each day. Decabit command 50 and K22 channel 8 are both in-step and are used for street lighting from what I can tell. Maybe it’s used by the Nightwatch lighting products (maybe they have no photocell).

The morning peak can be seen to be less severe than the evening peak. Services are progressively re-enabled after a mass shutdown at 6:55:15 in the morning, and 15:55:15, 16:55:15 in the evening. The timing of the Decabit system to the K22 system is not exactly in step – many of the Decabit command channels show much more flexibility in their commanding state, resulting in many “uncertain” periods of supply indicating that they are taking maximum advantage of the load control abilities of the ripple signalling scheme.

The K22 distribution can be seen to “gradually” restore service after each peak – channels 4, 6, 15, 16, 19, 20, 21 seem to be well suited for storage hot water heaters as they are on for most of the time, except for a few hours each peak period. Decabit command 2, 4, 6, 8, 10, 18 seem to be similar in timing. K22 channel 15 and Decabit command 18 especially seems to take significant priority over the other channels, suggesting it may be business oriented (as it restores service fastest after each peak).

K22 channels 12, 13 and 14 seem to be powered on during the early hours and into the afternoon only. This may be useful for environmental control – thermal mass storage systems possibly? Decabit Command 3, 11, 12 seems to follow similarly.

Decabit command 24, 25, 100, 103, 110 are all very short-term activated channels. I’m not sure what they’re for, but they may be company internal channels for their own use.

Redundant Decabit commands seem to be sent – in some cases, this is many hours after the last status update which may serve to reset a watchdog timer against being “permanently on”. In other cases, it may be a desperate attempt to reconfirm that the loads are turned off in an upcoming peak (as receivers may miss messages when the signal amplitude is low or there is lots of harmonic interference). Decabit commands are sent in K22 slots in reverse command order. If a command needs to be issued for channels 2, 3, 4, 5 hypothetically, they will be sent with command 5 in the first available non-K22 signalling slot, followed by command 4 in the next non-K22 slot, etc.

For a more fair and easy comparison, I’ve produced these “equal time” graphs where each cell is a half-hour interval. As with K22, the receiver keeps the state from the last transmission until it receives a new one, whereas Decabit must be explicitly commanded on or off with its command in order to react.



I have yet to see an out-of-cycle transmission except around dawn and dusk – I suppose that’s a good thing because otherwise, we might be having a network event or a grid emergency. For now, I’ve stopped monitoring the ripple signalling, as it’s costly to run a computer for this purpose, but I might investigate making a more “low power” solution using one of my embedded platforms in the near future for continuous signal logging.

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Electronics and tagged , , , . Bookmark the permalink.

2 Responses to K22/Decabit Signalling Schedule Analysis

  1. Perry Stephenson says:

    Depending on where you live, the “unscheduled” transmissions may be street-lighting commands. Most of the older lights on the network operate off separated “street light circuits” rather than being connected directly to LV mains, and these circuits can be switched either by a nearby photo-electric cell or by a ripple command sent from the zone substation, sometimes on a schedule and sometimes triggered by a PE cell at the zone substation.

    I can fairly confidently say that the load-control functionality would not be used in “network emergencies” – as you say its a very slow form of communication. If a large amount of load needs to be dropped quickly – for example in response to a “loss of reserve” condition in the market or due to an unexpected overload, it would be done by opening circuit breakers back at the zone substation.

    I’m not sure what you mean with the redundant transmissions… Most transmissions are repeated 1-2 hours later as the signal levels measured at the relay in your switchboard vary throughout the day. A missed transmission means no hot water, so they repeat it to give the relay a second chance.

    Not sure where you got 1042Hz from – the first units used motor-generator sets to create the carrier signal and these were fixed gear ratios supplied by a 50Hz mains motor. This means all carrier signals are multiples of 50Hz, and in Sydney they are normally 750Hz (15th harmonic) or 1050Hz (21st harmonic).

    • lui_gough says:

      Hi Perry!

      Nice to hear from you – the unscheduled are street lighting from what I can see, good to have a confirm on that. And yes, I would expect that under severe pressures, the stability and security of the whole network is primary, so load shedding would happen in a matter of seconds rather than minutes, making K22 unsuitable for that sort of reaction.

      Signal levels with the ripple injection are always an issue – too high, or too low, they cause issues. No hot water? Yeah, I can see that happening, thus making sense to make some redundant transmissions.

      I know the K22 sequence is sent out at the times I’ve seen them to (mostly xx:25:15 and xx:55:15, not all times) and the redundant commands are not in regards to K22 (as it seems likely they update their state on every initiation of a 3-minute transmit cycle). The redundant transmissions are within the Decabit command channels where an ON channel (which I’ve seen to always be set to ON at a given time) is recommanded to ON at a later time (mostly many hours later, thus probably resetting a watchdog rather than as an “insurance” command). Or an OFF channel is recommanded to OFF in the next transmission cycle.

      However, in the case of street lighting (Channel 50/Decabit 8), I can see the redundant commands being “insurance” safety there – a light sensor command followed by a scheduled time command will ensure the lights come on, or are forced off.

      As for 1042Hz – it seems that there’s a bit of slip. Originally Zellweger plant were rotational plant, and there would be some slip in it due to loading. A spectrogram of the transmission can be seen in my previous post at http://goughlui.com/?p=5759 – the 21st harmonic is clearly seen above the 1042Hz carrier ( http://goughlui.com/wp-content/uploads/2014/02/Mostly-Decabit-Transmissions.jpg ). Likewise, it is noted by RODALCO2007’s videos, that his Zellweger test sees the ripple signal “travel” along the 50Hz fundamental, indicating a non-fixed harmonic relationship.

      As a result, the Zellweger ripple signal causes additional harmonics to be generated, rather than just riding along the harmonics of the 50Hz powerline frequency (to my understanding at least).

      Thanks very much for the info though :).

      – Gough

Error: Comment is Missing!