slow comms

For more advanced meter data users. Learn from others and ask questions about how to read meters, how to use the EKM Push Data, and how to display the meter data in useful ways.
Post Reply
nielo
Posts: 10
Joined: Wed Aug 27, 2014 7:45 pm

slow comms

Post by nielo »

I have 2 of your meters running (a v4 and a v3) on the same RS485 network and they work fine as far as accurately reading electrical flow, but I need faster communications. If the point is simply to collect kWh usage then collecting data every few minutes, maybe even every few hours, is adequate. But, if a person wants to see relatively fast changes he needs a faster system. I realize you don't build oscillographs, you build watt hour meters with extra bells and whistles, but still I think many of your customers would like faster systems.

Your meters run at 9600, even parity, 1 stop bit so the total transmission time for a 257 byte data frame calculates to be about 0.24 seconds plus latency (time required to start sending data after a data request is received). When I actually run data requests and receive responses the v4 meter averages about 0.518 seconds for a complete transaction (from the beginning of the request to the end of the response) and the v3 meter averages about 0.493 seconds. So, in round numbers, regardless of which version meter is used, it takes about a half second for one of your meters to respond to a data request. Unfortunately, if I expand the network as planned a 1/2 second (actually more than that) is too slow. Ideally I want a 1 second update both for relatively fine granularity and so all the meters are synchronized, and I can't get that with just 2 of your meters much less 4 or 5. There are a couple of possibilities I can think of for speeding things up but the most reasonable would be a selective response rather than the meter dumping everything in response to a data request, and/or a higher baud rate. So, my question is, are there any plans to increase the baud rate or the ability to be a little more selective in what data is requested?
Jameson
Posts: 860
Joined: Fri Nov 04, 2011 7:42 pm
Location: Santa Cruz, CA
Contact:

Re: slow comms

Post by Jameson »

Hello nielo, welcome to the forum and thanks for your questions!!

I can envision having the option of changing the baud rate of a meter somewhere far off in the future. But for now about 3/4 of a second to once per second is about the fastest read time we can expect from a meter. 9600 baud works well for us as you do sacrifice max distance of the RS485 wire at the higher baud rates.

We do not have a way to request only certain metered parameters as you suggest.

The only way that I can see getting what you want now would be to use either multiple iSerials (with 1 meter connected to each), or an 8 port device like this (not sure that this is an option): http://www.negustore.com/products/Netwo ... ports.html

But you would have to write your own software to be able to interpret all of your meters in parallel. It would request, get the responses from, and parse all of your meter data from all of the ports (virtual or otherwise) at the same moment. I would imagine this is quite doable, it is just not how our EKM Dash software is setup to work (we read 1 at a time in your meter list). Once you have the software written, at that point you would have all of your meter data, from all of your meters streaming in at once per second.

If you are thinking of writing your own software the best place to start is here: http://www.ekmmetering.com/developer-portal

Hope this helps,
Jameson
EKM METERING
http://www.ekmmetering.com
831.425.7371
nielo
Posts: 10
Joined: Wed Aug 27, 2014 7:45 pm

Re: slow comms

Post by nielo »

Nope, a star configuration like your data concentrator doohickey provides won't work to increase network throughput.

In any network topology be it star or bus or mesh or whatever, without some sort of collision avoidance/bus arbitration, data will collide and be useless. The implication of that is, given the same bit rate, all network topologies are roughly equivalent in throughput. As an aside, port virtualization won't help because the problem is physical collision.

Actually, there are only two solutions with one variation to this problem.

The first, albeit most expensive, is to not use a bus but instead dedicate a separate, interrupt driven, I/O to each device. This approach eliminates the possibility of collision but takes the term "bus" out "RS485 bus".

The second, and easiest solution, and the one used most often, is a higher bit rate. The RS485 spec calls out a minimum suggested allowable speed of about 100kbps at 4,000 feet and at 1,000 feet it's a little over 300kbps. My experience is these speeds and higher are easily attainable with a reasonably low capacitance twisted pair cable such as Belden 3105A and proper termination. So, unless something really weird is going on, a baud rate of 115200 (12 times faster than 9600) is pretty easily doable at the maximum distance of 4,000 ft. that the spec allows. Throw in repeaters and you can go as far and as fast as you want. Actually, for "normal" distances of a few hundred feet with just a few devices on a network, probably typical of what your users need, I've used general purpose twisted pair cable at speeds higher than 115200 successfully, even in industrial environments.

A third possibility that is actually a variation of the higher baud rate solution is to provide a data buffer for each device that retransmits to the bus and receives from the bus at a higher baud rate. Send a "Collect Data" command that could be as short as 3 or 4 bytes, and whoever you told to collect data, including everybody if that's what you chose, collects data at 9600 baud and then retransmits the data, or part of it, at the higher baud rate. The first half second would be lost while your meters collect and transmits data to its buffer but, at a higher baud rate, you could transmit what everybody collected to the Master in the remaining half a second. And, everything would be synchronized as perfectly as possible to boot! I might pursue that because if I go to that much trouble it would be relatively easy to include things like selective response. The only difficulty would be I'd have to detect a busy bus, but that shouldn't be too difficult.

You guys implementing a higher baud rate would be so much easier.
Jameson
Posts: 860
Joined: Fri Nov 04, 2011 7:42 pm
Location: Santa Cruz, CA
Contact:

Re: slow comms

Post by Jameson »

Thanks, for all of the information you have posted here, you are obviously quite knowledgeable on how this stuff works. Our developers are tinkering on an unrelated device (not a meter) that does have selective data outputs and selectable baud rates. I can see learning from that project how we would want to improve our meter communications in the future.
Nope, a star configuration like your data concentrator doohickey provides won't work to increase network throughput.
I think it might, you would have to essentially create 8 separate RS485 networks per USB spider (unless there is some sort of limitation to the USB spider I am not aware of). You would have to use 8 of these: http://www.ekmmetering.com/ekm-metering ... erter.html

I also think you could have 8 separate iSerials (essentially create 8 separate RS485 networks) and get what you want.
In any network topology be it star or bus or mesh or whatever, without some sort of collision avoidance/bus arbitration, data will collide and be useless. The implication of that is, given the same bit rate, all network topologies are roughly equivalent in throughput. As an aside, port virtualization won't help because the problem is physical collision.
Yes agreed.
You guys implementing a higher baud rate would be so much easier.
Yes, I also agree with this. Being able to change the baud rate as a setting in the meter would be awesome. Or like you say, having a default meter response like we do now and selective meter responses to get only the dat you really need.

We really appreciate all of this feedback, keep it coming :D
Jameson
EKM METERING
http://www.ekmmetering.com
831.425.7371
pvanroos
Posts: 11
Joined: Wed May 28, 2014 8:52 am

Re: slow comms

Post by pvanroos »

I'd like to second nielo's request for faster transfer rates. For my home with a single water, power, and gas line, the current implementation is working great. However, there are some commercial use cases that we are testing that would require faster communications.
Jameson
Posts: 860
Joined: Fri Nov 04, 2011 7:42 pm
Location: Santa Cruz, CA
Contact:

Re: slow comms

Post by Jameson »

Thanks for letting us know! We really appreciate hearing what our customers want so that we can steer in that direction.

One thing that has come up is that the opto-isolators (physical hardware) we use are only rated to 10KHz These are on the UART side of the RS485 transceiver, so would have to be physically jumpered over. Or I suppose a faster opto-isolator could be used.

Here is what we are using: http://www.cel.com/pdf/datasheets/ps2561.pdf

As an aside, we dont have opto-isolation on our USB converter, so it can communicate at 115200 baud. The iSerial does have opto-isolation, I am not sure of its baud limits.

Let me know your thoughts.

Thanks,
Jameson
EKM METERING
http://www.ekmmetering.com
831.425.7371
pvanroos
Posts: 11
Joined: Wed May 28, 2014 8:52 am

Re: slow comms

Post by pvanroos »

My ignorance may be exposed in this post, but I will proceed nonetheless. The iSerial serves as nice "broker" between Ethernet and RS485. Removing it from the communications stack and replacing it with the USB converter seems like it might increase complexity of my current implementation. Maybe not? I don't know.

Where is the source of the bottleneck? If this particular opto-isolator is truly the source of the bottleneck, can you run a test and determine if this is indeed true. So swap it, ratchet the speed and verify.

Either way, good luck and let us know how it goes! :-)

-Paul
nielo
Posts: 10
Joined: Wed Aug 27, 2014 7:45 pm

Re: slow comms

Post by nielo »

Jameson wrote:I think it might, you would have to essentially create 8 separate RS485 networks per USB spider (unless there is some sort of limitation to the USB spider I am not aware of). You would have to use 8 of these: http://www.ekmmetering.com/ekm-metering ... erter.html

I also think you could have 8 separate iSerials (essentially create 8 separate RS485 networks) and get what you want.
Yup, that would definitely work. But, as I mentioned earlier, a separate I/O for each device, regardless of how that I/O is implemented (Serial, USB, whatever else you can think of) takes the "Buss" out of "RS485 Buss", or if you'd rather, takes the term "Network" out of everything and puts your comms physically in the "whole lot of copper" category.

Btw, another possibility might be to use XBee's running 802.15.4 protocol. The XBee you sell runs at 900 MHz which gives outstanding range (at a mile or better line-of-sight probably much greater than your customers require) but limits throughput to 9600 Baud. On the other hand, if you use XBee's running 802.15.4 (I don't know a part number off hand but I think even the series 1 radios will work) they run at 2.4 gHz and have an advertised over the air bit rate of 250 kbps. The problem would be data buffering because as I recall the XBee's have a pretty small buffer. But, it is a possibility so maybe I should look into it a little.

Hmmm. Even if that works, radios would be over-kill for most applications and inherently are less reliable than hard-wire. The most reasonable thing to do would be to build a board that interfaces the 9600 baud you guys use to something higher. May be I'll do that. If I do I'll let you know.

Let me say again, a higher baud rate on your meters would be soooo much easier.
Post Reply