Extended Message exchange - fails in Icon Relay -why?

[ELA]

I am currently installing (2) new Icon relay switches. In an attempt to be thorough I ran some communications reliability tests to each of these devices before attempting to link to my home system PLM. Using a test PLM I sent standard direct commands (PING command) repeatedly using 1 hop from the same location as my house PLM (within 3 feet, same circuit).

I ran over 400 attempts with a success rate of 99 -100% ( multiple trials over a 2 hours period) to each switch.

 

(( I will qualify that I have a known signal sucker in the area of these switches. I purposely was running these tests without a filterlinc on that device. This as an attempt to determine if I could forgo installing the filter or if it was a must.))

 

With a success rate of 99%-100% I thought it might be good enough without the filter and so then proceeded to attempt to link the first unit to the home PLM via the ISY99. I was somewhat surprised that it failed to link. Failed to write the highwater mark.

 

The second ICon Relay did link ok.

 

I retried to link the 1st device several times and did a factory reset along the way with no success. I then added the filterlinc to the known signal sucker and the 1st unit now linked. (These two switches are on the same circuit and about 20 ft from each other.)

 

Not a terrible surprise if I need the filterlinc in that location , but I am perplexed by why my earlier tests seemed to indicate very good communications without the filter and then it failed so miserably when attempting to link to the ISY PLM. The only difference I am aware of is that I was using a standard direct "PING" message vs. the message that failed on the 1st units link attempts to the ISY, is a standard direct "Get Engine" message.

 

I took several logs and reviewed them to the best of my ability. What I saw on the failure was:

1) ISY sends "Gets Engine" msg.

2) No response, and the ISY retries 3 times ( 9 seconds between) and gives up.

 

I found this strange and thought could it be the message content, or just a very marginal condition?

 

I then left the filterlinc installed and removed and re-installed both relay switches. In both of those logs I can see something like this:

1) ISY sends "Get Engine"

2) devices each return an i2.

3) ISY sends an extended message "Write all-link data base"

4) devices return standard length response. (0x02, 0x50)

5) devices also send a extended response (0x20, 0x51)

6) ISY ignored the additional response (unexpected response (i.e. DB range):ignored

7) ISY then reverts to i1 and everything completes fine.

 

sorry for the long post but this presents two questions:

1) Why did the get engine message fail so miserably when PING messages worked very well with only 1 hop

2) What is happening with the dual responses both standard and extended?

 

I intend to test again tonight with the test PLM using a Get Engine Message as a follow up.

 

My best guess is that the house PLM is slightly less powerful or sensitive than the test PLM. But I would have expected the test PLM to get more failures since it was only allowed 1 hop. If this is the case it was a very marginal condition that the filterlinc corrected.

 

I had hopes to use message reliability testing to help me avoid adding filters to all known suckers. Maybe I will just have to filter all known suckers after all

 

Just wanted to add: I also installed a dual band Keypadlinc that is about 2 feet from the Icon that failed to install, yet it also installed fine.

I had hoped that the dual band aspect of this unit would help to overcome the local signal sucker as well.

 

I will include the log from a successful install (up until it reverts to i1):

Mon 08/29/2011 08:37:37 PM : ---- Initializing the linked devices ----

Mon 08/29/2011 08:37:37 PM : ---- All Linked Devices are now initialized ----

Mon 08/29/2011 08:37:37 PM : ---- Add remaining devices ----

Mon 08/29/2011 08:37:37 PM : [  1A 2E C0 1] Removing all links

Mon 08/29/2011 08:37:37 PM : [1A 2E C0 1  ] Querying engine version			Main Bath

Mon 08/29/2011 08:37:37 PM : [iNST-ACK    ] 02 62    1A.2E.C0    0F 0D     00 06                 (00)

Mon 08/29/2011 08:37:37 PM : [iNST-SRX    ] 02 50    1A.2E.C0    0F.9E.56  2B    0D 01           (01)

Mon 08/29/2011 08:37:37 PM : [standard-Direct Ack][1A.2E.C0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Mon 08/29/2011 08:37:37 PM : [1A 2E C0 1  ] Retrieved engine version is i2

Mon 08/29/2011 08:37:37 PM : [1A 2E C0 1  ] Calibrating engine version ensuring support for i2

Mon 08/29/2011 08:37:38 PM : [iNST-ACK    ] 02 62   1A.2E.C0    1F   2F 00    00   00    0F FF    01     00 00 00 00 00 00 00 00    00   06        (00)   // write all-link data base
																					address   nu	        8-byte record

Mon 08/29/2011 08:37:38 PM : [iNST-SRX    ] 02 50    1A.2E.C0   0F.   9E.56 2B    2F 00           (00)

Mon 08/29/2011 08:37:38 PM : [standard-Direct Ack][1A.2E.C0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Mon 08/29/2011 08:37:38 PM : [iNST-ERX    ] 02 51    1A 2E C0     0F 9E 56     11    2F 00    01 01    00 FF 01 A2 00   0F 9E 56   FF 1F 00 00 

Mon 08/29/2011 08:37:38 PM : [Extended-Direct][1A.2E.C0-->ISY/PLM Group=0] Max Hops=1, Hops Left=0

Mon 08/29/2011 08:37:38 PM : [Ext. Msg. Handler] Unexpected Response (i.e. DB range): ignored

Mon 08/29/2011 08:37:47 PM : [iNST-ACK    ] 02 62    1A.2E.C0    1F   2F 00    00 00    0F FF    01     00 00 00 00 00 00 00 00    00 06        (00)

Mon 08/29/2011 08:37:48 PM : [iNST-SRX    ] 02 50    1A.2E.C0    0F.9E.56    2B    2F 00           (00)

Mon 08/29/2011 08:37:48 PM : [standard-Direct Ack][1A.2E.C0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Mon 08/29/2011 08:37:48 PM : [iNST-ERX    ] 02 51 1A 2E C0 0F 9E 56 11 2F 00 01 01 00 FF 01 A2 00 0F 9E 56 FF 1F 00 00    // device is sending extended responses and ISY does not like them

Mon 08/29/2011 08:37:48 PM : [Extended-Direct][1A.2E.C0-->ISY/PLM Group=0] Max Hops=1, Hops Left=0

Mon 08/29/2011 08:37:48 PM : [Ext. Msg. Handler] Unexpected Response (i.e. DB range): ignored

Mon 08/29/2011 08:37:57 PM : [iNST-ACK    ] 02 62 1A.2E.C0 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06        (00)

Mon 08/29/2011 08:37:58 PM : [iNST-SRX    ] 02 50 1A.2E.C0 0F.9E.56 2B 2F 00           (00)

Mon 08/29/2011 08:37:58 PM : [standard-Direct Ack][1A.2E.C0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Mon 08/29/2011 08:37:58 PM : [iNST-ERX    ] 02 51 1A 2E C0 0F 9E 56 11 2F 00 01 01 00 FF 01 A2 00 0F 9E 56 FF 1F 00 00 

Mon 08/29/2011 08:37:58 PM : [Extended-Direct][1A.2E.C0-->ISY/PLM Group=0] Max Hops=1, Hops Left=0

Mon 08/29/2011 08:37:58 PM : [Ext. Msg. Handler] Unexpected Response (i.e. DB range): ignored

Mon 08/29/2011 08:38:02 PM : [1A 2E C0 1  ] i2 data transfer commands do not work. Reverting to i1




Mon 08/29/2011 08:38:02 PM : [1A 2E C0 1  ] Using engine version i1

Mon 08/29/2011 08:38:02 PM : [iNST-ACK    ] 02 62 1A.2E.C0 0F 28 0F 06          SET-MSB(0F)

Mon 08/29/2011 08:38:02 PM : [iNST-SRX    ] 02 50 1A.2E.C0 0F.9E.56 2B 28 0F    SET-MSB(0F)

Mon 08/29/2011 08:38:02 PM : [standard-Direct Ack][1A.2E.C0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Mon 08/29/2011 08:38:02 PM : [iNST-ACK    ] 02 62 1A.2E.C0 0F 2B F8 06          PEEK   (F8)

Mon 08/29/2011 08:38:03 PM : [iNST-SRX    ] 02 50 1A.2E.C0 0F.9E.56 2B 2B A2    PEEK   (A2)

Mon 08/29/2011 08:38:03 PM : [standard-Direct Ack][1A.2E.C0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Mon 08/29/2011 08:38:03 PM : [iNST-ACK    ] 02 62 1A.2E.C0 0F 29 00 06          POKE   (00)

Mon 08/29/2011 08:38:03 PM : [iNST-SRX    ] 02 50 1A.2E.C0 0F.9E.56 2B 29 00    POKE   (00)

[LeeG]

ELA

 

The 0250 followed by an 0251 is the normal response to an Extended 2F ALDB command. The ICON has always been spec'ed to support 30 link records only. For years the device was shipped with a memory configuration that actually supported 417 link records. The difference between the two is where the first link record starts, 00F8 for 30 link records and 0FF8 for 417 link records. The Extended 0251 message returns with the true 00FF (always ending address with an ALDB command) address reflecting the fact that the latest ICONs now actually support only 30 link records as the spec's have always said. The ISY is expecting 0FFF in that first response so indicates it is out of range. Does not matter as the ISY will not use I2 linking anyway when running the Automatic option.

 

This was looked at before 3.1.6 was released and UDI decided not to make a change to accept the 00FF as a valid address over concern for impact on other devices. The ISY will configure the ICON using Extended commands for things like Local On Level and Local Ramp Rate so a power cycle is no longer needed when these values are changed.

 

I have no explanation why one command gets a response and one does not.

 

Lee

[ELA]

Thank you Lee for the benefit of your experience and knowledge.

 

I had just upgraded to 3.1.6 to get support for my new 2487S.

 

I will experiment further on the lack of response, or marginal signal level.

I have just changed my test PLM code to support the Get Engine message and I will try that while monitoring signal strengths compared to the ISY99 connected PLM.

 

I also just reviewed my development notes. I had previously compared the ISY connected 2413S with my test PLM: 2413U and indeed the test PLM is slightly stronger.

 

In an isolated network test with only a switchlinc and the PLM under test:

2413S xmit was 4.0V p-p

2413U xmit was 4.6V p-p

 

I will confirm if this small difference may have produced the results I experienced.

[IndyMike]

Edit:

 

ELA,

 

In my original response I focused on the ISY rejection of the extended message response and totally missed the fact that you were getting response "timeouts" on one of your devices (Thank you LeeG for pointing this out). My apology for not reading thoroughly.

 

Extremely interesting that one of your devices would link without the filter while the other would not while they were both in close proximity. Are both of the Icons the same revision and firmware?

 

I have run with only a passive coupler and one Accesspoint for years now. The signal level on the opposite phase (passively coupled) is well below the spec 3.2V - I have not see an issue with this. The signal gets repeated "down the line" and things work well.

 

What was the offending device and how many "insteon loads" was it presenting?

 

IM

[ELA]

Hi IndyMike,

 

The area of the home I was expanding into is the master bedroom that I talked about here:

http://forum.universal-devices.com/viewtopic.php?f=28&t=5923&start=45 ->2nd post down.

 

It was 3.5 Insteon Loads (Satellite receiver and power supply).

I consider this a substantial signal sucker and was committed to filtering it. I did however want to be thorough and prove the need, prior to just blanket adding filters.

 

The sucker load was near the end of the home run from the service so it made sense to me to filter it. One of the Icons was slightly upsteam of this sucker by about 20ft (one that did link). But the Keypadlinc was in the same location as the failed Icon (that did not link) with (3 ft pigtail between the two) and it linked fine. Both Icons are same revision.

 

I have tested enough devices now to know that all transmitters are not created equal. The 2413s I have been using for prototypes in my testers are very powerful. Nearly twice the output (with a single Insteon load), of the 2412 that I made my very first prototype with. I have also noticed other devices being weaker when compared to others.

When a very marginal condition exists, such as this one, small differences can make all the difference.

 

I retested last night and realized that when I used my test PLM (ELAM) I did not unplug the home based PLM, so it was helping the test PLM out (not a fair comparison). Whereas when I was trying to link via the ISY99 my ELAM was not in the circuit to help (retransmit).

In addition there was about 20ft difference in wiring between the two PLMs in the original test. In the new test I used the very same outlet.

 

In my retesting with the ELAM I removed the home based PLM (and used the very same outlet) and now I started getting failures in the reliability testing.

I could see that the ELAM did appear to fair better than the house PLM though.

 

This is an example of a very marginal communications situation where small changes can have a large impact on the reliability. There is no doubt in my mind now that the filter is a must. As I mentioned earlier I had hopes that the two icons and the (dual band) keypadlinc would help each other out enough that I might avoid adding a filter but that did not happen.

 

When I first developed the ELAM I was focused on ability to identify and quantify signal suckers. The device does this very well.

Then I decided to expand its capabilities to test communications reliability as a bonus. This is still a work in progress as I learn more from this type of testing.

 

In my first reliability test using the ELAM I was only watching the LCD display that simply indicated that 99-100% of the messages were getting through. This device also connects to a pc for expanded data since the LCD space is so limited. In the second test I used the PC connection an thus could see that the messages were just barely getting through. I now could view the return message -number of hops- was often 3 allowed and 0 remaining.

 

In addition I was viewing using the oscope and a lot of retries were occurring as well.

 

With the filter installed I was getting a consistent 3 hops allowed and 2 remaining on return messages.

 

I am now going to change the LCD display to include a "quality factor" indicating -if MARGINAL (when all the hops are being used).

 

I found no difference between the newly added "Get Engine" message and the "Ping" I was using previously (of course .... but I wanted to assure a direct comparison).

 

Now it is on to my original Keypadlinc ( one of 3 I now have). It is very old and I occasionally get failed responses from it. Last night I tested an outletlinc device very near to it and it was very reliable. The same test on the keypadlinc showed it has big issues.

Only speculating (with limited testing to back it up) at this point but I think I may need to replace that device.

[Michel Kohanim]

Hello ELA,

 

Sorry for disrupting the conversation.

 

Just wanted to let you know that we have very many requests for just such device especially by installers who do large installations. Do you have any plans for commercialization?

 

With kind regards,

Michel

[ELA]

Hi Michel,

It is both good and bad to know that there is a demand for additional Insteon tools.

I do hope to be able to share this tool with others some day after I have completed my development.

 

Thank you for your comments.

 

I have been able to purposely create a variable, and marginal, communications test environment that is now allowing me to learn more and to improve this tools ability to assist in detecting a marginal communications issue.

[Michel Kohanim]

Hi ELA,

 

Thanks so very much for your contribution and please do let us know if there's anything we can do to help.

 

With kind regards,

Michel

[IndyMike]

Hello ELA,

 

My apologies for taking so long to respond. I have been struggling to match the behavior of this circuit with that of a signal sucker. I simply don't understand how a heavy signal load alone can produce the symptoms that you are seeing. I would expect that a heavy load at the end of the line would prevent the responder from hearing the transmission. Your description is somewhat opposite - the responder is hearing the transmission, but the return hop count is marginal.

 

I envision your configuration as follows (circuit below):

1) PLM some distance from the bedroom and the 1st Icon (I've modeled as 100' below).

2) Icon2 and the KPL 20' from Icon1

3) The Satellite load another 20' down the line. 3.5 Insteon loads equivalent to 3.5 ohms at 130 kHz.

 

Assumptions:

1) "1 Insteon load" equivalent to a 0.1uF cap (~12 ohms at 130kHz).

2) PLM is able to drive the line at rated 3.2 Vp-p (rated into 5 oms).

3) Responding devices are able to drive at 3.2 Vp-p. This may not be valid due to the high loading near Icon2.

 

Using the above, the predicted levels for the PLM to responder transmission (1st hop) are shown below. I've cheated and used the capacitive reactance in the the model to keep resonances out of the picture.

 

 

PLM to responder communication -

1) Given the levels noted, I would expect your Icon2 to be able to "hear" the PLM on the original transmission in the absence of noise.

2) If noise is present on the line (preventing Icon2 from hearing the original transmission), Icon1 may hear it and repeat on the the next hop. This should certainly be should be heard due to the close proximity (low powerline impedance).

3) If all else fails, the DualBand KPL should hear the 1st transmission (RF) and repeat on Hop1.

 

From your description, one of the above appears to be working since you do get responses. What confuses me is that you have poor reliability on the responses (low hop counts). That would seem to imply one of the following:

1) Icon2 is unable to drive the powerline due to the local loading. None of the neighboring devices can hear and repeat the signal. This seems unlikely since the Dual band KPL is in close proximity and should repeat on the next HOP. It's possible that the RF communication from the KPL to the PLM can't be heard.

2) Icon2 is driving the powerline at a reduced level (and repeaters are operating), but the loading at your PLM is high and the signal is being attenuated. This assumes that your KPL RF is out of range of the PLM.

3) Icon2 is driving the powerline at a reduced level (and repeaters are operating) but you have noise at the PLM and it's activating it's AGC. It can't hear the inbound communication until multiple repeaters sum their transmissions together.

 

I'm really interested in whether you've been able to isolate this further.

 

IM

[ELA]

Hi IndyMike and thank you for the detailed analysis,

 

I had composed a detailed response and thought I hit send, by it appears it did not post for some reason? I find that so frustrating when that happens, and thus I am going to be more brief this time.

 

The associated network would be much more complex. Sorry for not providing all the details required for analysis in the earlier post.

 

I was sending from the ISY/PLM area on a different phase #2 cir. That has to go about 100ft back to the panel with 3 or so actual Insteon loads along the way. Then out to what you detailed on the Masterbed Phase #2 cir. In addition there would be several parallel branches midway between the two (from the panel). Including a known (as of yet unfiltered)signal sucker on one of those parallel circuits near the panel.

 

Of course there are also variables associated with not knowing the exact routing of romex in the circuits without tracing them all.

 

I have spent my time recently creating a "bench test- marginal communications test environment" that I am now using to improve my testers ability to report marginal communications. I intend to use the tester when done to diagnose my original keypadlinc issue next.

 

I am content with the filter as the required fix for the master bedroom. I may revisit it in the future for test purposes but that requires unplugging the satellite power supply and all tvs in the house go down. My wife does not appreciate that much.

 

I want to address each signal sucker issue one at a time and use them as a real world development environment. While I think I feel comfortable with blanket filtering any signal sucker over, say 3 standard Insteon loads, I want to back that with test results. I know many people have good success with just a few filters and may question the need for more than (x # of filters). It is for that reason as well that I want to proceed slowly and test prior to and after each filter install.

[ELA]

A follow up to this post with very marginal communications to one of three newly installed Insteon devices.

 

While waiting on a replacement Keypadlinc for another comm issue I have run extended reliability testing on the new Icon Switch that was very marginally communicating at 99-100% message completion (but with using hops & lots of retries involved).

 

With the filterlinc that was added the communications is now 100% completion, two hops remaining on all message exchanges and no retries required. Confirming the value of the filterlinc added ( at satellite receiver) , one of the three identified signal suckers in the room. I have been able to leave the other two suckers unfiltered since they are downstream of the new Insteon devices and I do not have any plans to add more Insteon devices in those locations.

[Brian H]

ELA; I have had the forum software time out {I think}. While composing a long on line message. When I hit the submit button it said I was not logged in and the message was lost.