Getting Serious - When Comm issues strike

[ELA]

Hi IndyMike,

 

Thanks for the reply.

I agree that other activity on the network can result in additional hops being used. I try to do most testing when the house is relatively inactive.

Mostly what I see when other activity is going on is that I receive "extra messages" from those devices without effects on the hop count of the message I am monitoring.

But there is no doubt that reliability testing intended for one particular device is better done in the absence of other network traffic.

 

With my test device I am able to access things that external devices cannot.

 

As Michel alluded to the ISY retries only occur after the PLM itself has given up retrying. So if you are recording ISY retries then you have some very real issues that need to be addressed at the PLM level (either signal attenuation, noise, or defective or inferior devices ??)

 

I am really interested in both your LCD and your refrigerator. I am going to try to roll out my refrigerator one day for a test but not sure when.

 

I posted a comment on the XPF filter that I had intended to use on the refrigerator if it needed one at the Smarthome forum.

Very interesting. I would not recommend that filter (based on my sample test size of one) as an Isolator.

 

I did however make one simple modification to this filter that greatly improves it performance in terms of line isolation. May compromise the noise attenuation, if noise is the issue, but all my filter installs to date have been to isolate a signal sucker.

[ELA]

 

Can you please explain why you are trying to minimize filter use? Is it simply due to the cost or is there some drawback to using too many?

 

Thanks

Rob

 

Hi Rob,

I think I may have posted that it is these things; cost, wall wart effect and a general distaste for the fact that there are so many things that can attenuate the Insteon signal ( as it was in X-10). Of course Insteon is much better once you make the effort to make it that way, and filters are often part of the effort.

 

In general I am not aware of an issue with adding too many "good Insteon Signal Quality" filters (within reason).

It was a philosophical question to others if they felt there was such a thing as too many, for whatever reason.

I think that if you do not mind the added cost, or the appearance/inconvenience of the filter placement, that they should be added to known signal suckers or noise generators above a certain level. Of course it can be debated what that level is and it may vary from Installation to Installation.

 

My attempts have been to establish a useful tool to be able to quantify signal suckers so that an educated decision can be made as to when to add filters or not.

 

Each Filter is a signal sucker of a certain amount. Usually pretty much not of concern when compared to the added gain they will provide.

 

In my early efforts I have decided to use a comparative method between devices as opposed to absolute values for ease of discussion. I think of a single Insteon device as "1 Standard Insteon Load". Each device actually varies from one another so I use an average value as the standard load.

 

If you add an actual Insteon device to a network this load is not very important because the device repeats Insteon signals (simulcasts). This point becomes a signal source.

 

Now if you add a "non Insteon appliance" that is a signal sucker , all it does is suck or attenuate the signal value.

 

We would hope that the filter device itself would not present itself as too high of a signal load, since in some cases (appliance isolation), that is exactly what we wanted the filter to prevent.

 

Would you add a filter to a "surge strip" that you believe to be a signal sucker? I would not. I would strive to pick a surge strip without an internal capacitor.

[Rob]

Hi ELA

 

Thanks as always for the details response. I don't always fully understand some of your more technical posts so I thought perhaps I missed something about the potential for too many filters. I have about a half-dozen filtering tv's, pc's, etc. and plan on adding a few more when I upgrade the last 2 rooms to Insteon. Lacking any good diagnostic tools I found it easier to simply filter potential noisemakers/signal suckers.

 

Now I won't feel compelled to start removing them to see if I can improve on the 99% reliability I already have

 

Rob

[wrj0]

I think we all need one of ELA's "Signal Sucker" detectors so we can identify and isolate/eliminate the cause.

[ELA]

Thanks Rob and wrj0,

 

Rob,

I agree with your approach when no good diagnostic tools are available to you.

 

Sometimes the trick can be knowing who all the offenders are. Since I built this tool I now at least understand who all the signal suckers are. I have identified eight total signal suckers in my home network (fairly significant ones, not just a surge strip). I have elected to leave 4 unfiltered and I am using 4 filters on the others. I have been tempted to simply filter all of them, I bought a few spare filters so that I could.

I am using my house network as a real world test platform for the tester development and so having some potential issues remain can be helpful to the development effort.

 

I feel I am nearing completion of the design effort for what I would consider to be a very helpful diagnostic tool. I hope that via some avenue I will be able to make it available to anyone who would like to have one. I would very much like to be able to compare notes with others using the same diagnostic tool.

[IndyMike]

Hello ELA and Michel,

 

Thank you both both the confirming the PLM retries being separate from ISY retries. In hindsight, I should have recognized this as I have seen the PLM perform retries with my scope (probably posted the traces as well). I just didn't realize that the ISY was not informed when they were occurring.

 

ELA - some additional answers to your questions:

 

 

Room Setup

• 
  [*:1pkexvte] Master bedroom on dedicated breaker ~ 60' from panel.
  [*:1pkexvte] Insteon devices - 1 V.2C KPL dimmer; 1 V.8E KPL dimmer; 1 V.28 Icon Switch
  [*:1pkexvte] Loads: Panasonic 32" LCD, DVD, VCR, Motorolla Phone, 2 Clock Radios - no filters, no accesspoints.

 

 

IndyMike,

I have read your post several times now. I am curious where the LCD TV is in relation to the two keypadlincs?

I have a Panasonic 32" LCD in my master bedroom. It was one of three substantial signal suckers in the room.

I measured it at 3.5 Standard Insteon Loads. Depending upon its relative location it may be a good candidate for a filterlinc!

 

This is exactly why I picked this location. All of my loads are between the two KPL's. The newer KPL that responds well is on the opposite side of the loads (further from the panel). Both the older devices (KPL and Icon relay) are on the panel side of the load. Both of the older devices have problems when the noisemaker is active. Both are at or near 100% when the noisemaker is not active. The newer KPL is consistently good throughout.

 

I would not call the 3.5 Insteon load presented by the Panasonic LCD high absorption - at least not for this length of line. I have far higher signal loading in my family room (42" Panasonic Plasma, Audio amp, DVD, Playstation, Wii, Cable box, and assorted chargers) and do not have issues - unless the noisemaker is active.

 

This is really nothing more than signal/noise ratio. It's perfectly OK to have loading as long at the noise floor is low. I choose to search out the noisy devices rather than the signal absorbers. Much of this is due to the fact that I'm still operating X10 devices as well.

 

I have also exonerated the new refrigerator as the source of my problems. I switched it off during a "problem" period and there was no significant difference in communications. I had singled the fridge out since it was the most obvious "new" item and it operated asynchronously.

 

I'm sure I could fix this problem with a couple of well placed accesspoints. Unfortunately, I'm thickheaded and stubborn - I want to find the noise source and kill it.

[LeeG]

IndyMike

 

Did you unplug the refrigerator or turn it Off. Like many devices now days just turning if Off often does not eliminate the source of the interference.

 

Lee

[IndyMike]

Lee,

 

I actually tried both. Turned the refrigerator off and tried a couple of KPL scans. Threw the breaker and tried a couple more scans. Had degraded communications in both cases.

 

2 hours later (refrigerator operating) things were back to 100%.

 

Thanks for the thought,

IM

[ELA]

Hello IndyMike,

 

This is exactly why I picked this location. All of my loads are between the two KPL's. The newer KPL that responds well is on the opposite side of the loads (further from the panel). Both the older devices (KPL and Icon relay) are on the panel side of the load. Both of the older devices have problems when the noisemaker is active. Both are at or near 100% when the noisemaker is not active. The newer KPL is consistently good throughout.

 

I would not call the 3.5 Insteon load presented by the Panasonic LCD high absorption - at least not for this length of line. I have far higher signal loading in my family room (42" Panasonic Plasma, Audio amp, DVD, Playstation, Wii, Cable box, and assorted chargers) and do not have issues - unless the noisemaker is active.

A 3.5 Non-Insteon Device Load is a considerable absorber no matter where it is located. Only testing can confirm whether or not it is severe enough at a particular location to know whether or not it is an issue for your installation. How difficult would it be for you to take some Oscope measurements to compare signal levels at the two devices? Can you also collect data with and without any suspect signal suckers (or noise makers) connected in the room?

I know it may not be an easy task but I think you would agree that data is always preferred to speculation.

 

I am a little confused at this point by your assertions of a noise maker? I understood that you had a previous issue with a photocell noise maker. I thought I read that you eliminated that source? I thought I also read that you have yet to capture any noise in this case?

Why do you know assume it is a noise maker in this instance?

 

Of course it could be noise, but I missed why you would assume noise in this instance?

 

This is really nothing more than signal/noise ratio. It's perfectly OK to have loading as long at the noise floor is low. I choose to search out the noisy devices rather than the signal absorbers. Much of this is due to the fact that I'm still operating X10 devices as well.

I can appreciate that you will search for noise first. Please also consider signal suckers as well. Comparative Oscope measurements can demonstrate the signal reduction and reliability testing can then confirm whether or not that signal reduction was significant or not.

 

Unfortunately, I'm thickheaded and stubborn - I want to find the noise source and kill it.

Good luck finding the issue. I will look forward to hearing more when you have had time to collect some data. Speak softly and carry a big hammer my friend.

[IndyMike]

Hello IndyMike,

 

This is exactly why I picked this location. All of my loads are between the two KPL's. The newer KPL that responds well is on the opposite side of the loads (further from the panel). Both the older devices (KPL and Icon relay) are on the panel side of the load. Both of the older devices have problems when the noisemaker is active. Both are at or near 100% when the noisemaker is not active. The newer KPL is consistently good throughout.

 

I would not call the 3.5 Insteon load presented by the Panasonic LCD high absorption - at least not for this length of line. I have far higher signal loading in my family room (42" Panasonic Plasma, Audio amp, DVD, Playstation, Wii, Cable box, and assorted chargers) and do not have issues - unless the noisemaker is active.

A 3.5 Non-Insteon Device Load is a considerable absorber no matter where it is located. Only testing can confirm whether or not it is severe enough at a particular location to know whether or not it is an issue for your installation. How difficult would it be for you to take some Oscope measurements to compare signal levels at the two devices? Can you also collect data with and without any suspect signal suckers (or noise makers) connected in the room?

I know it may not be an easy task but I think you would agree that data is always preferred to speculation.

 

I respectfully disagree that a 3.5 Non-Insteon Load is a problem no matter where it is located. I've performed many simulations and measurements for exactly this situation. Years ago I became concerned when I realized that Insteon devices were themselves a significant load to communications. My specific concern was that a "bundled" Insteon load (multiple devices) at the end of a long branch might present enough absorption to prevent receptions. Per your assertion, 4 Insteon devices installed in a J-box would present a problem regardless of their distance from the transmitter. This I cannot accept.

 

My concerns led me to perform testing using a 250' length of 12-2 Romex using varying loads (isolated line). Using 5 "real" Insteon loads, I was able to demonstrate 100% command/response efficiency with a 200 mv receive signal level at the load devices. This was in the absence of noise (<10 mv).

 

If we accept the fact that the transmitter can drive the local load to full level (assumption that I have confirmed for my installation), I have to reject the fact that a 3.5 Insteon load could be a factor in the installation that I have cited - less than 1/4 the distance - unless noise was a contributing factor (it always is).

 

I am a little confused at this point by your assertions of a noise maker? I understood that you had a previous issue with a photocell noise maker. I thought I read that you eliminated that source? I thought I also read that you have yet to capture any noise in this case?

Why do you know assume it is a noise maker in this instance?

 

Of course it could be noise, but I missed why you would assume noise in this instance?

 

My apologies - this has been a rather long thread and I have sometimes posted "observations" rather than hard data (time constaints and all that).

 

• 
  [*:1chh2qyf]I stumbled across the photocell issue back in July while performing testing with another forum member. I say "stumbled" because the communication issues occurred over a narrow time window (dusk). Prior to and after the "problem" time there were not issues. Once the photocell was disabled, there were no issues.
  [*:1chh2qyf]Around the time that we installed the new refrigerator I began to notice communication "dropouts". These were intermittent and only detected during long duration device link reads ( 5 minute communication duration). I incorrectly pointed at the refrigerator as the culprit as it was the "new device" in the house.
  [*:1chh2qyf]On Friday (11 PM), my Son's PC power supply nosed over and began producing continuous noise at 57 kHz. This took down my network on phase A (phase B still operative). At 3:00 AM I isolated things to my Son's PC when I threw the breaker and the noise subsided.
   
  Unfortunately this was accompanied by a my Son's scream/yell/un-mentionable words - he had been running a simulation since 6:00 PM the previous day. If I understand things correctly, I now owe him a new power supply, and gas money until long after I am dead an gone - so saith the "high" family court.

 

"We" (I) have filtered the computer and communications are "nearly" normal. Filtering is not completely effective since the noise is "out of band"."We" (I) have ordered a new power supply for the computer. After it's replacement it will serve as a useful "noise maker" test device in the house.

 

I have gained a lot of data and plots from the last 3 days of testing. Some of the most interesting data is "time" based, looking for retries within the ISY command/response protocol. Your post on the PLM retry events being "invisible" to the ISY was instrumental in this.

 

I haven't posted any data here - only my conclusions. I didn't want to dilute your thread further. If you would like details - PM me or post.

 

IM

[ELA]

A follow-up to my previous Kitchen/Dinette readings. I was able to remove a rather large refrigerator that was in a very tight space today for testing.

There is no longer any doubt that the Refrigerator is a substantial signal sucker at 3.9 Standard Insteon loads!

 

I monitored the Dinette outlet on the same circuit that was reading as an abnormally high signal suck location (even though there were not loads present there). It was reading 8.1 Standard Insteon loads. When I unplugged the refrigerator the reading when down to 4.5 Insteon loads.

 

I then isolated the refrigerator using my modified XPF isolator and found the refrigerator to register at 3.9 Standard Insteon loads.

 

While a person may not tend to think of a refrigerator as a signal sucker these new units that have electronics controls may be.

I have elected not to add a filter to it at this point due to time constraints. I think I may order an AF120 for it when and if I do.

[ELA]

Hi IndyMike,

Looks like you posted while I was writing my other post.

 

Thanks for your reply. If you reread my post you will see that I said, " A 3.5 Non-Insteon Device Load is a considerable absorber no matter where it is located."

I also qualified, " Only testing can confirm whether or not it is severe enough at a particular location to know whether or not it is an issue for your installation." I did not assume it would be a problem.

 

In the post to Rob I stated this , " If you add an actual Insteon device to a network this load is not very important because the device repeats Insteon signals (simulcasts). This point becomes a signal source.

 

Now if you add a "non Insteon appliance" that is a signal sucker , all it does is suck or attenuate the signal value. "

 

 

I respect your efforts at testing and wish you the best of luck in your installation.

[IndyMike]

Hello ELA,

 

Just to clarify - my testing was performed both with X10 and with Insteon with 0 Hops. As such, the Insteon devices could be considered as simple loads (non-repeating). Using your words - "all it does is suck or attenuate the signal value".

 

In both instances:

• 
  [*:3efj4e2h] The X10 devices responded to commands.
  [*:3efj4e2h] The Insteon devices responded to commands and ack'd direct commands.
  [*:3efj4e2h] Signal levels at the devices were at or above 200 mv p-p (considered 2x more than acceptable to X10)

 

This was not a statistical test. I did not monitor command/response hops as I did in the previous tests. Nonetheless, 200 mv at 250' is considered "good" for x10 using a "0" hop protocol and no HOPs. I would expect Insteon to do far better using the device repeating, and retries.

 

I am not trying to be a PITA - these are my measurements and my experiences with Insteon. As we have discussed, I am trying to understand the differences between our systems.

 

IM

 

Hi IndyMike,

Looks like you posted while I was writing my other post.

 

Thanks for your reply. If you reread my post you will see that I said, " A 3.5 Non-Insteon Device Load is a considerable absorber no matter where it is located."

I also qualified, " Only testing can confirm whether or not it is severe enough at a particular location to know whether or not it is an issue for your installation." I did not assume it would be a problem.

 

In the post to Rob I stated this , " If you add an actual Insteon device to a network this load is not very important because the device repeats Insteon signals (simulcasts). This point becomes a signal source.

 

Now if you add a "non Insteon appliance" that is a signal sucker , all it does is suck or attenuate the signal value. "

 

 

I respect your efforts at testing and wish you the best of luck in your installation.

[ELA]

IndyMike,

I have never considered your posts as being a PITA. I respect your knowledge and your opinions.

 

I too have communicated over long lengths of Romex as well as through Filterlincs with great success. I have posted some of those where I got 100% message responses (however there have often been many retries ((at the PLM level)) involved).

 

We seem to have different approaches to solving communications issues. This may stem from our individual experiences in our home networks.

Back in my X-10 days I tended to look more for noise sources.

 

I still have one filter on an electric lawn mower battery charger that I believed to be a noise source. It would upset my X-10 repeater ( CR234). It was a very obvious offender in that I could see the error LEDS erratically blinking without the filter installed.

I still have that filter in place. Yesterday I tested that power supply to see if it qualified as a signal sucker and it does not. That makes sense to me as manufacturers often add capacitors across the line specifically to filter noise ( which I know you are very aware of as an EMI knowledgeable fellow).

 

That filter is the only filter that I have installed for noise specifically. All the others have been to reduce signal attenuation. I did have a TV that was an obvious noise source in the X-10 days that also upset my CR234. I ended up installing an isolation transformer on it as the normal filters did not work on the ~55Khz offending signal. That TV is long gone now.

 

We have discussed the concept that you put out there of AGC ( in the Leviton X-10 devices I think it was?) and its possible effects on a devices ability to receive a valid signal in the presence of noise. Since we do not have any good info on whether or not the Insteon devices have AGC or some other form of noise detection (false start bit detection, or ???) it is difficult to discuss what levels/frequencies of noise are really significant and those that may not be.

I have looked at the 2412 schematic and pin 1 (PLC RX Ref) looks as if it may be detecting when a continuous noise source is present? What do you think?

 

Without knowing more about the internal workings of the Insteon devices and their noise rejection capabilities I am choosing to go for the best signal strength I can get. Thus I look for significant signal suckers and then reliability test to see if they may be having an impact on reliability. If the testing shows they are, I filter and the retest to confirm the improvement.

 

I would never discount the possible negative effects of noise as I know they are very real. When I had my keypadlinc issue I did specifically test for noise (as we discussed) and did not find any. I later posted that I tested that same keypadlinc in an isolated test setup after I had replaced it with a new one.

It failed miserably in an isolated test environment as well. I think that pretty well excluded noise in that case.

 

I think we agree that both signal attenuators and noise sources may be present in individuals home networks. You and I as engineers want to know for sure which is the offender.

For the average Insteon user the easiest approach is probably to just add a filter to any suspects. If the filter does not help then it is more likely to be an "out of band" noise source and a more involved filtering scheme may be needed.

 

p.s. What brand is your French Door Refrigerator?

[ELA]

A problem arose in my living room where a “mood light†failed to turn off as part of a scene. This is not used often and it was not noticed previously.

 

Step 1) To begin diagnosing this issue I first tested for signal suckers in the room. While I had done this once previously I apparently missed a rather large one. My recliner is a signal sucker measuring a rather large 3.5 Standard Insteon loads! (this recliner has an electric assist, the power supply must have an across the line cap).

 

- I left the recliner unplugged throughout the testing process . –

 

Step #2) I ran repeated communications reliability testing between a Test PLM as the message originator and the Device #9 (mood light that failed) as shown in the diagram below.

 

 

 

This testing would consistently show that messaging between these two was marginal. All tests were performed with a standard direct message type and 3 max hops. A consistent result would be 2 hops being used (1 hop remaining). When run for a long enough duration retries would occur and and occasionally a complete fail of the msg exchange.

 

Referring to the diagram above:

 

Tests to devices 1 -5 showed only 0-1 hop being used (3:2 response) and results were 100% (no retries) to these devices from the PLM.

 

Same tests to devices 8 -11 were all marginal, typically requiring 2-3 hops (3:1, 3:0 responses) and retries required.

 

 

 

Step #3) Tests were performed removing one or more devices (on the 6 -11 side). Communications would then sometimes get slightly better when two devices were removed. (less local loading).

 

Step #4) RF coupling was confirmed to be good, direct from the test PLM to the Living Room dual band device . In addition there are also several other dual band devices in the house, more than one on each Leg /Phase.

 

Below are some power line Oscilloscope captures recorded at the locations indicated at this point in the testing:

 

In the course of troubleshooting I could see that the Originators primary transmit was weakly coupling from Phase #2 to Phase #1, without having a hardware coupler. I could also note that communications to devices 8 -11 would improve by removing a few devices (the originators primary transmit got slightly stronger with less local loading).

It was appearing as if devices 1-5, had a strong enough primary signal and that was what was making them more reliable. (further tests sending zero hops messages will be done to confirm this).

 

Step #5) At this point I installed a hardware coupler directly at the service. I had bought a 2406H a few years back but never installed it. I had elected to reply on access points and dual band devices for my phase coupling. I never realized that I was getting a minimal indirect coupling before. I decided to make it intentional just in case this unintentional coupling was intermittent in nature.

 

This did not provide any improvement. My hopes were that the initiators primary transmit would be more effectively coupled between phases. However due to the heavy loading present at the service cabinet, on each phase, there was no real gain. While Ph#1 may have increased slightly Ph#2 amplitude dropped a little (primary signals small and difficult to measure).

 

 

As stated I was seeing that devices 1 -4 were receiving a large enough signal from the primary transmit whereas the devices 8 -11 were not. This made sense as to why the devices 1-4 would only require the first hop ( or zero hops?) whereas devices 8 -11 were reliant on additional simulcast hops.

 

The strange and unexplained thing was that even though all hops have a very strong signal strength, at devices 8-11, they still were not reliably communicating. Isn’t that what having a lot of devices is supposed to help improve? Look at how strong the hops are in the scope images. They were consistently a large amplitude, even when retries occurred.

 

Step #6) In an attempt to have the absolute best RF coupling I added a spare access point at the service cabinet on Ph#1. This would complement an access point already very close to the service cabinet on ph#2. These two would provide both line and RF coupling direct at the service cabinet. My thought were that the two access points served to provide a good solid hops line signal going out from this point.

 

This did increase reliability at devices 8 -11, just enough to be acceptable. It was still taking 2 hops to complete but it was no longer using retries and no outright failures.

 

When looking at the diagram of this test scenario I would think this is a great example of the Insteon concept of: adding devices to strengthen a network! There are 11 insteon devices in this one room. Hop signal strength is outstanding. Yet the devices that have the best reliability are the ones that can actually “see†the primary transmission.

Once devices in the room start to become reliant on additional hops the reliability drops off.

Are these devices not simulcasting properly? Is there a phase shift and even though the signal strength is very strong the data is not valid?

 

I spent way too many hours on this one. I am happy with the slight improvement and will live with it as is unless I notice a degradation. I had entertained the idea of dedicating a line direct to the PLM or moving the PLM and ISY close the service cabinet (via a long Ethernet cable). This seems a bit extreme and should not be required if one could rely upon the simulcast concept and strong hops.

 

This scenario has me wondering and questioning Insteon simulcasting and synchronization. Does it work well but only under certain conditions?

 

After all was done I reconnected the recliner (big signal sucker) that was between devices 10 and 11 and it had no measurable detrimental effects. At least this part of the claim seems to work. The signal strength in this area is so strong, with so many devices , that they are able to overcome a fairly substantial local signal sucker.

[Illusion]

I do not have the testing capabilities you have, ELA, but I can tell you this:

 

I have noticed a distinct correlation between adding Insteon devices and having worse communication problems since I started installing Insteon at my house in 2006.

 

I used to be surprised by this, but I think I am finally coming to accept that the marketing put forth regarding more is better to be just that, marketing. Clearly from your scope traces it seems like it should be helping, but it is not. I did some really isolated network testing that showed results that seem similar to what you are experiencing. viewtopic.php?p=23139#p23139

[ELA]

Hi Illusion,

I have read many of your test experimentation's. What a time hog Insteon can become if you let it be.

I am just happy that this most recent issue was very minor and now is what I would consider acceptable.

 

I did have enough time to run just a few tests with zero hop sends (0:0). In an attempt to learn which devices are actually communicating on the Primary signal vs 1st hop. A quick test showed only devices 3 & 4 were consistently receiving the primary send. I will do more testing but from this early data it would appear the other more reliable devices #1 & 2 & 5 from earlier tests must be requiring the 1st hop. There do appear to be some variables affecting how well various hops synchronize (simulcast) with one another. I now wonder if the 1st hop is the gem or can any one of the three be the golden boy, given a certain set of circumstances.

 

I agree that it is not as simple as adding more devices.

 

I am going to do some more testing just to learn more.

 

Can you please tell me, what is the largest number of Insteon devices you have grouped together in one room (on the same circuit?). I am curious to learn if my 11 devices might be considered normal or not.

[Illusion]

I have a circuit that has 13 - 15 devices on it (variable throughout the year). I do have some comm issues on occasion and no work I do with filters or access points ever has seemed to improve it. Adding more devices to this circuit sometimes helps with comms, sometimes it hurts. Unknown why.

[LeeG]

As one example I currently have 29 devices on my test bed circuit. It varies depending on what is being tested at the time. The devices are a few inches to 6 wire feet apart. This is of course a contrived environment for ease of testing. Not likely any actual installation would have that many devices on the same circuit.

[ELA]

Thank you both for that input.

 

LeeG,

I am jealous of your test bed!

I would like to ask a series of questions about your test bed it you would not mind.

 

Assuming you have a test PLM on your test bed ... If so have you determined how far the Primary send (hop 0) makes it from the PLM out to the devices on the bed?

 

Are devices connected in a linear (daisy chain) or in a star configuration?

 

I am guessing that testing communications reliability is probably not the intended purpose of your test bed.

Have you ever considered inserting various lengths of cable between devices in the range of 30 -50ft to stir it up a bit?

[LeeG]

The test bed is not for checking communications reliability. Have done that on occasion to evaluate a specific issue but nothing of a general nature. Power distribution is a combination of linear and star. It was what was easiest to get power to the various wired power strips rather than consideration for the factors you are looking at.

 

There are multiple PLMs, one for Powerhome/HouseLinc/SHN Utility testing, one for the ISY, one on a EZIO8SA, one on an EZBridge (like the ISY with a separate PLM), one EZSrve, a 2413S and 2413U that come and go depending on what is being tested at the time. There is an old 2414 PLC that is added from time to time but not normally powered.

 

I was going to run some Hops 0 tests using HouseLinc which has a good comm check function that allows the Max Hops to be selected. Unfortunately HouseLinc is abending on startup ever since installing 2.7.17 and 2.7.18 which I hoped would fix the abend but did not.

 

Have not tried extending the power runs. Each metal power strip has 6 outlets and an attached power cable that is approx 6' in length. As you mentioned this was established to test function, providing a means of testing a cross section of devices without having to use the main house Insteon devices. I have used the house and garage Insteon devices at times where a large configuration was necessary but I try and stay away from that as much as possible. I like the house to work no matter what fun and games are being played here.

If I can get HouseLinc running again I will do some Hop 0 tests.

[ELA]

After recent discussions and early tests performed at 0:0 hop setting I altered the code in my test PLM to track a number of statistics so I could better evaluate why messaging within a room can have such a strong signal strength in its hops, yet many devices in the room at not quite up to par. Far from what one would think considering the number of repeaters in the room.

 

While testing the code in an isolated test environment I spent a lot of time tracking a bug in my code that then lead me to a very interesting Insteon message finding.

 

I was making an assumption, while incrementing one counter, that the msg was valid if received. For a second counter I was actually validating the message, and these two counters became out of sync sometimes.

Shouldn't the received message ( 0x50 response) be a valid message if passed to the host? Isn't the devices CRC checking supposed to assure that?

 

In my earlier code I was checking the command 1 and command 2 bytes to see that they matched the sent commands. My early code was not counting some messages as valid. The newer counter was allowed to increment, assuming the message must be valid if passed up from the host.

 

This then lead me to what appeared as though I was receiving invalid messages. I fixed the code so the counters both checked msg content.

As a result I decided I needed to track when the code detected the command 1 and command 2 not matching and report that as a separate statistic " invalid message received".

 

I am pretty sure I have read other posts here where people have reported what appeared as invalid messages in their ISY logs?

If I recall others have also reported seeing occasional and unexpected extended msg responses to a standard length request.

 

I have seen both of these while testing in this isolated test environment.

Here was the setup:

 

 

Before I go any farther with this, here are two messages sent and the responses below.

Are there some command table responses I am unaware of that make these valid in some way?

 

Note hops here

 

I tried two different msgs to comfirm.

 

If you analyze how the bit changes from what should be, to what I got, it is very interesting.

[LeeG]

"I am pretty sure I have read other posts here where people have reported what appeared as invalid messages in their ISY logs?

If I recall others have also reported seeing occasional and unexpected extended msg responses to a standard length request."

 

I have seen both circumstances in forum posts and locally on my network. Some look like messages issued by actual devices, some look like bit shift as a possible explanation while others looks like a valid Extended message but unexpected at the point at which they occur. There was speculation on another forum that some of these might be diagnostic in nature, left over from device hardware/firmware testing. For sure there are things on the powerline that cannot be explained with current documentation, at least not with the documentation available to the public.

 

From the perspective of most Insteon installations these are harmless events that do not cause any visual effects. Unless one has automation with the ability to look at PLM message traffic their presence would go unnoticed. They sure do peek ones curiosity though.

[ELA]

Thanks LeeG,

As always I appreciate your well informed responses. I do worry when I get unexpected results such as this whether it could be attributable to my instrumentation and thus I hedge my speculation a bit. In addition, from the first isolated test, I wondered if it could be my test Switchlinc device itself having issues.

 

From running tons if "good network" tests the tester does not appear as it would contribute in any way to false reports but I cannot eliminate it 100%.

 

What concerns me most is the CRC check appearing to fail, or pass an invalid msg. Does anyone here know exactly which CRC algorithm is used? I am curious, do these invalid msgs match in CRC values by some chance?

 

The PLM should not pass a msg to the host that does not match its CRC should it? Since it did pass the invalid msg to the host doesn't that subtract from system reliability?

In some cases the PLM did not retry beyond the first extended hop attempt since it had gotten a reply. If it had recognized that response as invalid then it would have retried into the 2:2, 3:3 extended hop ranges. Not that I think those would have helped but isn't that the theory behind retries with extended hopping?

 

I understand that normally these invalid msgs may not cause an actual miss-fire in the system network. Especially if it is only an ack msg. Since this seems to be very duplicate-able I may try some status msgs to see if they ever get corrupted.

 

 

Now that I had new code that trapped for invalid msgs I ran 100 test msgs to each device in my living room.

Please reference my earlier post showing the living room layout with device identifiers.

 

Here are the statistics collected from that. As you can see I am getting corrupted msgs here as well. These corrupted were the unexpected extended msg type. In several cases the extended msg was valid as an extended response but comd1 and 2 were not correct. In a couple of instances the was not valid. No such address exists in the network. Note that in these statistics the invalid responses are not counted as a msg completion.

 

 

I find these very interesting and leads me to further question simulcasting reliability. Is there a fix to be had in new devices -with better hop participation?

How would we know if there was?

As I pointed out in another post my newest PLM has a very different hop participation from older devices. Note this PLM is not part of an ELAM as of yet and so not involved in these test results.

[IndyMike]

Hello ELA,

 

I had a very long post in the making - lost it and am extremely frustrated at the moment.

 

To make a long story short, we've been working along the same lines but from different angles. I've been investigating "unexplained" extended message transmissions during standard message communications and found something that surprised me. I'd call this "extended message interference".

 

Rather than go into theories of how and why this is happening, I'll simply present the plots.

 

Baseline setup -

1) V.2B I1 KPL target device on phase B. Roughly 120' run.

2) 3 V5.x I2 SWL (repeaters) on same circuit

3) V1.0 dual band PLM on phase B.

4) Passive coupler at the PLM with V1.1 Icon LL on phase A (non I2 repeater).

 

Symptoms -

1) Communications 99.9% reliable, occasional retries.

2) Occasional extended message responses during standard message communications.

 

Plots - All communications monitored at the PLM. Scope set to 20 mv level to "catch" return transmission from the target KPL.

 

Baseline - Standard 3 hop "direct On" command with 3 hop response.

 

Test 4 - ISY logged 0 hops remaining in event viewer. Evidence of Insteon activity in what should be a no-transmission period for a standard message (Accesspoints should be communicating via RF at these points). I'm inferring that a module somewhere in my system is corrupting the standard message response with an I2 response.

 

Test 6 - ISY logged 3 hops remaining. Again Evidence of Insteon activity during the no-transmission AC crossing but at a much lower level. Infer that a remote device is responding with I2 message format, but the level is low enough that the standard message arrives intact.

 

I previously promised that I would not further speculate on these results - so there it is. As a disclaimer, my system is different than most. I use passive coupling with only 1 Accesspoint. This could play into the results since I effectively have a "point" source for transmissions.

 

Hope this sparks further dialog,

 

IM