The problem of several data-gathering sensor nodes transmitting at the same instant comes up moderately frequently. It happens because at present there’s no mechanism to do it any other way – each node transmits as and when it wants to, and in general relies on chance to avoid clashing with any other.
The limited “hold-off” period in the latest rfmTxLib code can alleviate the issue, but it’s not a solution.
I’ve been pondering whether it would be possible to work mains-powered emonTx’s using a “polled” method of getting the data, i.e. the base (emonBase or emonPi) transmits a request and the sensor node responds with the data. The big problem is that’s likely to be too power-hungry to be feasible for the battery-powered emonTH or a battery-powered emonTx, because the receiver must be turned on in anticipation to hear the request, so would it be possible to have the two co-existing on the same band? I think, given that the emonTH only transmits every minute, it should be possible given the processing power of the Pi, to schedule the transmissions – leaving the sampling and averaging period on the regular clock tick as now – of emonTx’s so that they are polled and respond in between the transmissions of the autonomous emonTH’s.
It’s clear this principle can’t be extended to battery-powered emonTHs, so the expectation is that an emonTH can still jam other emonTHs, but emonTx’s won’t be jammed by each other nor by emonTHs.
It does mean a massive shift in the OEM data-gathering philosophy. We do it this way because it’s always been like this: the original concept was a simple battery-powered sensor sending its data to an equally simple graphical display, and optionally to a Base (NanodeRF) for onward transmission to emoncms.org.
I’d welcome thoughts on all aspects.