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.