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.
Hi Robert, i have several emonTH like sensors running my own firmware and the trick i used to prevent most collisions is to listen for RF level before transmitting and use acknowledge of message received by the gateway. I went further and reply to the units the RX level on the gateway, so that each unit adjusts to only transmit with enough power to reach the gateway.
The logic goes like there:
If there is ‘noise’ on the channel, wait a random time and try again
If no ack received, assume there was a collision, increase power level, wait random time and try again
if ack is received, reduce a notch on the TX level (down to -80dBm at the gateway side that i discover to be safe)
for the next data set transmission.
It works great and the two AA batteries get me almost 4 years posting every 2 minutes.
That’s exactly what the “hold-off” in rfmTxLib does, but even turning on the radio to listen significantly increases the energy demand. Of course, transmitting every 2 minutes will counteract that.
What I seek is something that will principally work with mains-powered emonTx’s and work around the emonTH.
If the receiving pi is scheduling transmissions then perhaps it could include some correction number in the ack, telling an autonomous emonTH the ideal correction to the time of its next broadcast. Sort of like an NTP nudge to keep things synchronised?
That’s a suggestion that’s well worth detailed consideration.
My initial thoughts were that, with the emonTH transmitting for around 3.4 ms every minute, the chances of emonTH blocking emonTH are quite slim, so the concept was to manage the emonTx’s around the emonTHs. By avoiding the need for the emonTH to listen, there’s no effect on the battery life.
This should really be implemented. Reading Chaveiro’s post, it does appear that it could be done with the emonTH too while maintaining an acceptable level of performance. But maybe a good starting point is to leave them as being autonomous and work on the rest of the system.
Assuming the emonTx is powered by the AC-AC adapter, will the need to listen compromise the monitoring in any (meaningful) way?
That was my concern. It is impossible to have no impact on battery life. In my testing, turning on the radio to receive simply to check for traffic on the band would reduce the battery life by around 25% - it’s not for me to decide if that’s acceptable - I suspect many users would be disappointed.
From my work in getting the emonPiCM working, it’s feasible only if the RFM69 works in ‘Native’ mode. Reliable reception is impossible when running continuous monitoring - the numbers I got indicated around 20 - 25% of messages were getting through, 75 - 80% failed; it’s because JeeLib places a heavy demand on the processor to handle each character as it arrives, whereas Native mode allows the RFM itself to handle that task, and the processor only sees the complete message.
I believe few emonTx’s (Gwil will know the numbers) are now sold with battery holders, and those are loaded with the DS sketch, not the CM one - again with the aim of extending battery life. I wrote “mains power” - meaning power derived from the public electricity supply or a private and continuously available source of generation - because of the additional demand to have the receiver on for rather longer than when transmitting simply because you don’t know exactly when the message will arrive.
