I have an emonPi and two emonTx’s. The emonTx’s came pre-set with node IDs 15 and 16. The emonTx with node ID 15 is consistently “dropping out” (its feeds are not updated for several minutes), before eventually remedying itself. The other emonTx is has no such issue and its feeds are updated every few seconds. Both emonTx’s have the same number of things connected (5), being a mix of CTs and temp sensors. All equipment is in the same room. I have tried buying an aerial with a long extension from Amazon and putting right next to the emonPi. That brought the RSSI down from 50s/60s into the 30s but didn’t solve the dropouts, so I don’t think it’s a question of poor signal
The emonhub log does not show any frames being bad/rejected (they just don’t show up)
What do you mean here? Does the data feed just reappear but with a gap? (If it’s graphed, tick “Show missing data”.)
Is the logging level set to maximum - debug?
Looking at the emonHub log, what is the interval between the messages from the two emonTx’s? Each should be sending a packet of data at intervals of a fraction under 10 s - but are the trains of packets nicely interleaved, or is the gap between a packet from one and a packet from the other gradually closing?
If the “first” (in time) emonTx is transmitting its data packet and the second one starts sending its data before the first one has finished transmitting, the emonPi’s radio department has finished processing it and sent it onwards into the RPi and emonHub, then the second data packet will be corrupted and lost.
But if that’s happening, I’d expect to see first data loss from the emonTx that’s catching up, then data loss from the one that’s been passed - unless there’s a big disparity in the RSSIs, and that’s likely in a room if there are standing waves.
It could also be that the data rate of the second emonTx is out of spec, so it’s simply being rejected because the data isn’t decoded correctly and the checksum is failing.
Yes, the log level is ‘Debug’. Good question about the ‘interleaving’ of the timing of frame receipts. If I look at a random few minutes of the log, I see each emonTx signal is being received at approx same time (tenths of a second apart), until the one with Node ID 15 finally gives up for several minutes, before packet reception resumes.
Both emonTx’s are plugged into the same 4-way power strip, which I would’ve switched on from a single socket, so in theory they powered up at precisely the same time; would that be an issue?!
Is quiet = True set in the RFM2Pi interfacer section of emonhub.conf?
Maybe, if the 2 emontx are constantly clashing without cycling through the 10 sec interval then most definitely yes. If however sometimes the emontx are at 5 sec intervals to each other then that would suggest that staggering when you plug in won’t change the fact they are gonna clash sooner or later.
Plus if you have a power outage, no matter how brief, they will of course start together when the power comes back. I have suggested adding a line where the start-up is delayed by a factor determined by the node id e.g. I use nodes 1,2 and 3 and the delay is nodeid x 1000 mill is, this tends to work very well but has not been used by OEM FW.
Also, how old are the emontx? Or more specifically what FW are they running? If they are the same FW you stand a better chance of them synchronizing by chance rather than clashing. The downside of very close but not exactly the same intervals is that not only do they take longer to clash, they clash longer due to the very slow movement, ie longer outages.
Some have suggested adding a small random element to the interval as a fix, but that wouldn’t play nicely with the fixed interval data storage.
All I can add here is that “sniffing” the radio channel before transmitting, to check for traffic, seems to be able to help in this regard. It can never be foolproof due to the delay in turning round from listening to transmitting - because you can have two nodes listening for each other, and then deciding the channel is clear and still both transmitting together.
If it’s possible for you to change the reporting period of one by 10 ms say, that should mean that the collision (and it does look as if that’s what is happening) should only affect one message at a time - albeit more frequently.
Thanks Brian and Bill for the Pi Zero recommendations, I’m reading some of the monster threads on those now…
Paul, yes quiet = true is set in the emonhub.conf
The emonTx’s are new (this month) although I can’t see an obvious place to look for a FW version
I suspect I’m at the point where I just live with it (or maybe plug them in a few seconds apart, although you’re right about a power outage…), I’m just pleased we have, I think, found what the issue is
This quite recent trend to use a serially connected Pi Zero is in in place of a emonesp wifi adapter that have proved to be troublesome in some instances. Using a PiZ in place of a emonesp is a great idea when your devices are spread out. However, you mentioned these devices are in the same room and you have tried a long antenna extn. If either (or both) emonTx’s is close enough to run a usb lead to then you can connect 1 or both to the emonPi using a usb serial adapter really quite easily and whilst having both serially connected is most robust, just connecting one this way will solve any clashing as you can turn off the rfm in the latest FW (If you have a sub to serial adapter).
If you have a programmer and connect it to the FTDI (serial) port, you get a message at power-up/restart.
But knowing they are only a few weeks old means it should be emonTxV3CM, V2.0.0
When I look, that does indeed have the r.f. code that checks if the radio is busy (and holds off for 15 ms if it is), so I guess the two get so close that neither hears the other’s transmission and both start at the same instant. If that is indeed what’s happening, then if you have a programmer, you can change the “datalogging period” on-line without recompiling. It’s 9.96 s by default, so I’d suggest reducing one of them to 9.94 s. That should minimise if not remove the problem.
The maximum message length that we use is about 10 ms, 15 ms is actually the maximum, if the band hasn’t become clear by then, it transmits anyway.
The problem we face is the interfering transmitter might not be heard at the receiver, alternatively it might be heard at the receiver but not at the first transmitter. There’s no means of knowing the conditions at the receiver, which is what’s really required.
Thanks Paul, I’m thinking the ‘wired’ approach is probably the way to go, since I only need about 3m of wire between the emonTx’s and the emonPi. I see you’ve written in some detail on other threads about how to separately identify the two emonTx’s in case of a reboot (I assume they still don’t include a Node ID in the payload, saving me a headache?), so I think I can have a go at that bit.
But I’m not sure exactly what cable to get so would you mind taking a look at the one linked below, and letting me know if (two of them) will do the trick, i.e. 2x USB ends straight into the emonPi and wire the other ends into each emonTx’s UART header?
I’m not sure that would work, it looks like a rs485 device unless it does both. You would need a rs232 device.
It also seems a tad pricey, although that might be due to the rs485 model. There is a rs232 model, here’s a link to one from thepihut. However it’s less than a meter long.
Rs does do longer ones but there are several different specs. You need 3.3v safe TTL and 5v power (If you want to power the emontx via the ftdi conn, but it isn’t mandatory).
As long as you get a genuine FTDI ft232rl equipped device (regardless of it being a FTDI branded device or not) you will be able to address the devices by serial number and get around the node id and dynamic addressing issues no problem as the eeprom is writable using a free FTDI tool from their website.
If the receiver doesn’t hear the “interfering” transmitter, then that transmitter isn’t actually causing a problem. IOW if only one signal is heard, there’s no interference. The fact the other station’s signal is
present is a non-issue if the receiver in question can’t “hear” it.
That’s where the problem lies. If all transmitters can’t monitor the “channel” collisions will occur.
This is the exact problem that beset amateur radio’s APRS for the first several years of its existence.
The APRS “network” consists of dozens or even hundreds of stations broadcasting packets on
a single frequency in the same general vicinity, (typically a radius of 1 to 15 miles) at power levels ranging from a few milliWatts to 50 Watts. (or more) In addition to that, almost all of those signals
originate from mobile transmitters and get routed through digipeaters (literally, a digital repeater)
that extend the range of said signals to 50 miles or more. The APRS community calls it
an aloha circle.
Part of the solution was to build carrier detection into the transmitter’s packet encoder to enable checking for the presence of a signal and inhibit the transmitter if a signal is detected.
(part of the solution dealt with the digipeaters. as that’s not relevant, I’ve not elaborated on it)
To get an idea of how busy a channel can be yet still function, here’s a 30 second audio sample of the APRS traffic in Los Angeles, California, during the afternoon rush hour at about 5:00 PM when the channel is totally saturated to several hundred percent of the Aloha threshold. It’s not uncommon
for this level of activity to last 30 minutes or more. The packets are make a raucous braaap, braaap sound, (sounds like an old modem) the hissing between packets is squelch tails.
Except that the transmitter that’s waiting for it to cease will hold off unnecessarily. That is the problem - albeit not a major one.
Note that the transmitter that’s waiting for the channel to clear only holds off that one data packet, the next one is sent on schedule (unless it too needs to hold off - but that’s a separate decision).
And unfortunately, it might not even be on our user’s network - it could be someone else’s, a long way away in the opposite direction to the receiver, far enough for our receiver not to hear it but close enough for our transmitter to.
While that’s certainly a possibility, given the restrictions on transmitter power, channel usage
limits, and the vast majority of devices in the ISM bands are not connected to well-placed,
efficient antennas, the odds of that happening are fairly low.
Unfortunately, the Law of Natural Perversity doesn’t obey odds. If it’s possible for it to happen, it’s going to appear here as a problem, sooner or later.