[Also see the “US split phase monitoring requirements” thread, separated from this thread to keep both linked discussions on topic - Mod]
Working on a pretty massive setup. For now I’d like to do 16 channels on one hub and 6 more with an emonTx connected to an emonPi. I’d prefer to use wired connections; am I right that there are only two radio channels for the Tx’s? Is this feasible?
Hi John,
Welcome aboard!
Sounds like you may be a little confused. emonHub is software.
Could you elaborate a little on what you mean by “16 channels on one hub?”
The radio module OEM uses (HopeRF RFM12 in early versions, RFM69 in current verions)
uses but a single channel at 433.92 MHz.
37 posts were split to a new topic: US split phase monitoring requirements
Yes!
You can easily just add 4 emonTx via usb-serial adaptors direct to the 4 accessible USB ports (more is you introduce one or more usb hubs!)
See the Does the emonTx Shield need an actual Arduino? thread for an example of 3 emonTx’s connected to a Pi via USB’s to create a 3ph monitor. There are several other threads to read as this has come up a few times.
Whilst Bill is correct that only a single channels is actually used, there are 255 different “channels” or “groups” in JeeJib speak, OEM just uses “210”. On any one group/channel you can have up to 30 unique nodes.
Each emonTx comes programmed to use one of 2 node ids dependent on the position of a small switch inside the emonTx, that maybe where the “only 2 channels” originates from. But you can actually edit and reflash the firmware with any valid node id so theoretically you could have 30 emonTx’s on the same channel.
No, not really!
Although theoretically possible, 30emonTx’s all transmitting their payloads on thier own independent “every 10s” cycle with no synchronisation between them means that many (perhaps even most) transmissions will be lost due to RF collisions. Each time the receiver starts to receive a transmission it is blind to any others that might start, in many instances (depending on location) the emonTx is unaware the reciever is busy so it sends anyway, when the receiver finishes the first payload is receives the tail end of the second and discards it as incomplete, whilst it’s doing that it misses the start of the third one etc etc Or the payloads just corrupt each other, either way the data is lost.
It would be totally possible if you were to write your own FW (both receiver and emonTX) to accommodate such traffic, but as it stands even 4 devices unsync’d would be unreliable;e at times. The very first 3ph (3x emonTx’s) I did used rf and the reliability was (IMO) unacceptable, hence the 3x USB emonTx’s in a box approach.
Me too. Even with “reliable” RFM networks, there are occasional hiccups etc, if you have the opportunity to use a direct connection you should (IMO). Plus you get the added advantage of not powering the emonTx via the AC:AC adaptor which can result in better accuracy (especially if not using the RFM).
If you decide to go the USB route there are some pointers I can give you specifically regarding running multiple usb emonTx’s that may not be obvious from the many posts on connecting or configuring a single emonTx this way.
[edit - I’ve edited the thread title to better reflect the question]
Erm…
That’s open to question. Accuracy at the top end of the scale shouldn’t be affected, provided that calibration has been carried out using that supply. This is because the analogue reference is the internal 3.3 V, and it’s derived from two different regulators depending on the power source.
But there is expected to be a difference at low or no current. The internal supply from the a.c. adapter is quieter than the USB 5 V d.c. adapter sold in our shop, so what you say will be true with a clean 5 V supply, but not with a ‘dirty’ one. The symptom of a dirty power source is a higher current is shown when there’s no real current flowing.
Not very long ago, I did a test using emonLibCM and the shop 100 A c.t. Supplied by the ITE/Ideal 5 V USB adapter or FTDI programmer from a laptop, the zero-current output was reading around 50 - 60 mA. Using the a.c. adapter internal power, it dropped to 12-14 mA. In both cases it was using a 10 s averaging time and reporting interval.
Just offering options and my own opinion.
There are so many different permutations of PSU (PSU +USB lead?), USB adapter (and lead?) that I’m sure there can be both better and worse results. I have always had good results, but that said I do not use any of the same PSUs, leads or USB adapters as the shop and always oversize the PSU (3.0A+)
It would be interesting to know how that compares to a PI (rather than laptop) and how much the Pi’s PSU (laptop chanrger?) impacts that, I know Pi put a lot of effort into both their PSU’s and the on-board regulation (at least for the 3V3 and 1V8 rails etc, not sure about the 5V rail specifically)
Was that a shop sold programmer or a “genuine FTDI” branded/cloned device?
In this specific application it might also be beneficial to only have just 1 AC:AC adaptor (per leg) feeding multiple emonTx’s to save wall sockets (and cash), I have no idea how much that might impact the results if there are 2-4 emonTx’s running off one AC:AC. I know I wouldn’t want 4 AC:AC (+ 1 AC:DC) adaptors if I could get away with 1 or 2 AC:AC (+ 1 AC:DC) adaptors.
All are Megni Shop (OEM) devices.
You meant wouldn’t want?
Provided that all the emonTx’s have a common GND, and all have the JP2 link removed, then it’s OK, and probably best, to feed a common a.c. voltage sample. The loading on the a.c. adapter/transformer is negligible. Again, there should be no problem feeding all the emonTx’s with the same 5 V USB supply.
But I do know that the Shop USB lead is (was?) a particularly high resistance specimen, I don’t know if that has changed since I measured one.
Indeed I did (now corrected to avoid confusion, thanks)
Yes, and we have discussed this and the PSU’s at great length elsewhere previously. My own advice in these instances with USB attached emonTX’s would be to use a genuine RPi PSU with an emonBase, not an emonPi (different PSU connector type) or hunt out a better 3A PSU with integral (Mini-USB) lead if you are going to use an emonPi.
Yes please.
So, my current plan is to have two emonHub devices (not emonBase, sorry @Bill.Thomson), with four emonTx devices connected to one and two to the other. (For one I could use a single emonTx and an emonPi, I think, but for Reasons I’d rather do it this way.) So I’ll need two hubs, six tx’s, and six serial-to-USB converters? Any other suggestions on what I’d need would be helpful.
What are you calling an emonHub device?
Do you just mean a raspberry pi without an emonPi or RFM2Pi add-on board? I would still regard that as an emonBase. I have several RPi’s that have USB connected emonTx’s and run emonHub (software), I still refer to them as emonBases even though they have no ability to receive RFM transmissions.
As would I.
2x RPi’s? 6x Tx’s and 6x USB adaptors, yes plus
2x good 5v AC adaptors (genuine RPi or good 3A+ with integral (micro-usb) leads)
2-6 AC:AC adapters depending on whether you “share” the AC signal (you’ll need some cable and connectors to do that and beware of the AC polarity as one side is connected to gnd (0vdc) in each emonTx so a short could be caused through the USB’s)
and of course 22 CT’s
The main pointer about multi-usb connected emontx’s is identifying each one. By default the emonTx stock FW doesn’t pass a node Id so unless you chose your USB-serial adapters very carefully so they are not all indistinguishable (from each other) devices you will need to edit the firmware of all the emonTx’s to output a node id. If you are planning on making FW changes either way, this becomes less of an issue of course.
The problem is that linux assigns device addresses on a first come first served basis at boot time, so whilst one day node 10 might be /dev/USB1 at the next boot up /dev/USB1 could get assigned to the emonTx known as node 15 (for example) which will really screw with your data (and your head!)
When the emonTx FW identifies itself within the payload you can have 4 identical interfacers set up in emonhub for /dev/ttyUSB0 thru /dev/ttyUSB3and it really doesn’t matter who gets what address, unless you unplug one and reconnect it, then that one may be given the address /dev/ttyUSB4 and not seen by emonhub.
If you use genuine FTDI usb devices (or really good clones so that eeprom is functional) you can give each of your emonTx’s a unique serial number and create udev rules so that each device is always recognised by a address defined by you eg /dev/emonTx-abcdef where “abcdef” is the serial number you have defined.
But beware there are “bad clones” out there that are sold as genuine and do not even function the same way (let alone being actually genuine). I suspect that the ones I use are just “good clones” as they are cheap, but the first thing I do when buying “FTDI” (brand) devices is check the eeprom works. If you are buying from ebay (for example) you can back them if the eeprom doesn’t function, it’s either faulty or a poor clone. Unfortunately, even the sellers are often duped, I cannot recommend a seller as even when i have found a reliable source in the past, they have had bad batches, it’s a bit of mine field or just pay the “genuine” prices if you want to avoid the hassle/risk.
Search the forum for “udev rules” for more on this. The FTDI software to program the FTDI eeprom is FoC from their website and it’s really easy to do (unless they are bad clones, then it’s impossible).
[edit]
Also if you mount all the emonTx and the Pi in a (ventilated) box you can save yourself the cost of 6 emonTx cases (and 2 Pi cases?). This makes mounting the FTDI’s simpler, neater and less prone to being knocked. Her’s 3 emonTx’s stacked in a box with a RPi from the thread previously linked and also of the flip side so you can see the FTDI “stuck on” where the battery carrier used to be.
Also note that although the emonTx’s MCU operates at 3.3v, it requires a 5v supply so set the FTDI to 5v not 3.3v.
Oh! And another consideration for USB connected emontx’s if using the default FW’s. I believe it is considered risky to operate the emontx with no antenna attached. This is not something I’ve had to consider since i have always used my own FW with the rf stuff removed/disabled.
Side note! - I really think it would be a good idea to add a “disable rf” serial command option to the emonTx FW, many users have used the emontx via serial that might want to remove the aerial and also when it comes to debugging a emonTx that won’t run, it would be of great value to be able to “switch off” the RFM initialisation code to see if it then runs. (would you agree @Robert.Wall ?)
Very easily done around here!!
Remove the RFM69Pi add-on and that is just a plain old RPi in a case. Glad to see we’re all on the same page .
A similar approach can be taken there too. Here’s a couple of pic’s of an emonTx converted to USB (removed the battery holder, stuck a FTDI adapter in it and drilled a hole for the short USB adapter)
(Ignore the lump on the side and red/yellow/black wires, I converted these ones to 5CT also)
I’m just not keen on having the adaptor poking out of the 6pin header, with the USB adater and ridged part of the USB lead that’s a good 4-6 inches of leverage on those header pins if it gets knocked etc.
Appreciate it. Not sure what I’m going to do yet, but we’ll see. Sounds like it’s just best to modify the firmware and use individual IDs, and not have to deal with specialized USB adapters at all.
I would. The danger comes if the RFM69CW (not the RFM12B) is run at “high” power - though I’ve not seen a definition of “high”. I’m pretty sure we run it at the same power as the RFM12, which is quite a way (23 dB) below maximum, so I wouldn’t normally expect a problem.
If, @TheSHAD0W, you’re modifying the sketches, simply taking out the lines that control and send data to the RFM will remove all risk of damage.
I wasn’t so much thinking about when users write or modify the FW (for high power output?), i was thinking the standard sketch has “serial output” for users that want to use emonESP ( or usb/serial-direct) but no way to disable the RFM, if for no other reason than to leave the airwaves free for other emonTx/Th’s etc, there should be an easy (no flashing involved) way to disable the RFM. Then that would also make debugging those “maybe it’s the rfm module” issues a breeze, plus it gives the user a chance to still use the emonTx (without re-flashing) if a RFM module does go belly up.
There’s a thread running now about that. If you’re thinking about it, take a look there. I’d say hang fire unless you’re very familiar with Raspberry Pi’s and you’re prepared for teething troubles.
Gwil tells me the shop White USB A to Mini-B lead has a loop resistance of 106 mΩ for the 1 m lead, So that should be OK for 4 emonTx’s.
