Comfort  Automation/ Security System Forums Home
Home Search search Menu menu Not logged in - Login | Register

Low-Latency Interface
 Moderated by: admin
 New Topic   Reply   Printer Friendly 
 Rate Topic 
AuthorPost
 Posted: Monday Oct 14th, 2013 03:46 pm
   PM  Quote  Reply 
1st Post
Tas
Member
 

Joined: Monday Feb 11th, 2008
Location: London, United Kingdom
Posts: 39
Status: 
Offline

  back to top

Hi,

I'd like to determine the means of interfacing with comfort that will have the least latency in communicating sensor and alarm state to an external controller.

I've experimented with the Eht02 interface but there is a noticeable lag between a sensor triggering and a message being sent. I have an RS-232 interface but haven't got round to measuring it yet. Is it likely to be any faster?

I was wondering if the UCMs themselves introduce latency and if there was a way of using the native RS-485 bus directly?

Thanks,
Tas



 Posted: Tuesday Oct 15th, 2013 01:00 am
   PM  Quote  Reply 
2nd Post
ident
Administrator


Joined: Wednesday Aug 9th, 2006
Location: Singapore
Posts: 3493
Status: 
Offline

  back to top

RS232 may be faster only because ETH02 has to go through the network
The UCM directly sends all messages from the bus. There is very little latency
However sensors have a sensitivity setting in the zones settings eg 500 ms to prevent false alarms so the "latency " may not be due to the UCM

You cannot access the RS485 bus direct as that may affect the communications
You can see what is on the bus using the Bus Monitor tool in Comfigurator



 Posted: Tuesday Oct 22nd, 2013 03:58 pm
   PM  Quote  Reply 
3rd Post
Tas
Member
 

Joined: Monday Feb 11th, 2008
Location: London, United Kingdom
Posts: 39
Status: 
Offline

  back to top

Ok. So I've now compared the two and I can see more latency on the ETH02.

When you say "The UCM directly sends all messages from the bus" do you mean on the ETH02?

Ethernet can be much faster than RS232 so I'm suspecting either a slow ethernet interface or whatever translates from RS485 to ethernet.



 Posted: Tuesday Oct 22nd, 2013 09:21 pm
   PM  Quote  Reply 
4th Post
ident
Administrator


Joined: Wednesday Aug 9th, 2006
Location: Singapore
Posts: 3493
Status: 
Offline

  back to top

The ETH02 is a serial to ethernet convertor
It translates the messages from the Comfort bus into a format which can be used by Comfigurator and other applications
So while it is true that ethernet can be much faster than RS485 the data rate for Comfort messages is still 9600 bits per second, the same as the Comfort bus, so it cannot become 100 MBps or 100 MBps. Sending messages on the network does not speed up the comfort messages

However the network itself can introduce latency or delays due to other traffic on the network eg streaming video




 Posted: Wednesday Oct 23rd, 2013 09:00 am
   PM  Quote  Reply 
5th Post
Tas
Member
 

Joined: Monday Feb 11th, 2008
Location: London, United Kingdom
Posts: 39
Status: 
Offline

  back to top

I think you've partly answered my question but I don't quite see how some of what you say is relevant.

Latency and bandwidth are two independent properties of a communication channel. My question is about the latency, not the bandwidth. You are stating bandwidth figures. Of course we aren't going improve the bandwidth or latency.

In this case there is no other traffic on the network. and I'm suspecting that the translation between RS485 and ethernet is introducing latency. I guess I can measure this by timing the difference in receiving over ethernet vs serial port but I was hoping someone might already know if this is where the latency is coming from.

Last edited on Wednesday Oct 23rd, 2013 09:01 am by Tas



 Posted: Wednesday Oct 23rd, 2013 09:49 am
   PM  Quote  Reply 
6th Post
ident
Administrator


Joined: Wednesday Aug 9th, 2006
Location: Singapore
Posts: 3493
Status: 
Offline

  back to top

The UCM will see data from the Internal  RS485 bus and convert to serial data. The Ethernet module converts that to ethernet packets
There may be accumulated delays but they should not be significant. If you can provide any latency infomation let us know



 Posted: Wednesday Oct 23rd, 2013 04:53 pm
   PM  Quote  Reply 
7th Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 557
Status: 
Offline

  back to top

Perhaps I can add something to the formula.

If we consider that there is no congestion on any of the interfaces then the RS232 interface will be the quickest.

As Ident explained, the RS485 bus message is translated to RS232 at 9600bps, if I remember correctly, at this point it is ready for sending on the wire. Because things are hardcoded you have a few variables. Some of these are internal chip buffering and then most importantly you have the delay associated with clocking each of the bits out on the line at 9600. Add all these up and you get the absolute minimum delay that can be achieved from an output.

If you look at the Ethernet module you have the added delay of converting the RS232 signal again to Ethernet and then add it's own transmit delays.

In all honesty, all these combined should be fairly insignificant. The biggest contributor to perceived 'slow response' is the sensor itself - if it's a PIR device then it has to properly 'see' movement before it sends a command on the bus. Then you have your response latency, by this I mean your PIR trigger a response, the response does something and set's <something>.

I give you an example on Cbus. I have a Comfort PIR, first it takes some time to 'see' movement, once movement is detected there is something called 'debounce' delay to make sure there isn't multiple triggers for one event. Next, Comfort detects this and fires a Response. More processing is done to execute the response. Inside my response is a Cbus command that is fired over to the UCM/Cbus. Now we start the whole process again, the Cbus network is also waiting for the complete command to be clocked out on it's network, it then has to activate either a relay or dimmer depending on the command sent. All this takes time and doesn't happen instantaneously.

If you explain what you want to achieve perhaps we can help but to answer your question on which is faster? RS232 or Ethernet? Then the answer is RS232.

The quickest test you can do is to connect a door switch to an input and a relay to an output. Note the debouce time of the input zone type and then write a response to switch the Output On|Off as you press the button. You will find the response close to immediate once you subtract the debounce delay, which you can set to a different value at your own risk of false triggers.

Ingo



 Posted: Monday Oct 28th, 2013 03:53 pm
   PM  Quote  Reply 
8th Post
Tas
Member
 

Joined: Monday Feb 11th, 2008
Location: London, United Kingdom
Posts: 39
Status: 
Offline

  back to top

Thanks for for taking the time to answer my questions.

I believe I've eliminated what's introduced by the sensors but still see a delay which is human observable. I will attempt a more objective test based on comparing rs232 and ethernet on comfort.

What am I trying to achieve. On the design of my next system I am considering maintaining home-automation logic outside of comfort while still leveraging the sensors that are connected to it. I'm trying to determine if any latency will be introduced and what the best interface is to use.



 Current time is 12:51 pm
Top




UltraBB 1.172 Copyright © 2007-2014 Data 1 Systems