Dual Band PLM Communicating Poorly with Older (I1) Devices

[ELA]

IndyMike,

 

Since you say it failed in the test environment as well, do you have so many i1 devices such that replacement is not an option?

In my network the single i1 device I had was a problem. I identified definitively that it was the cause of the problem.

 

Once replaced I have not had any cause to look back.

 

While it would be great if you could definitively identify why the device fails, what would that get you? I considered spending more time on my i1 device but it did not seem a worth while effort.

Do you believe that Smartlabs would replace all older i1 units?

It seemed like an exercise in frustration to me.

 

That being said, if you should go that route I would be very interested to read about your findings.

[LeeG]

ELA

 

With the 2412 working with the I1 devices and the 2413 not I think the solution lies with the 2413 PLM firmware rather than replacing every I1 device in the field. I have a house full of I1 devices since I moved to Insteon shortly after the technology became available. I don't want to wholesale replace some 20+ devices. I would purchase a few more PLMs if I knew the I1 issue had been resolved with a firmware update.

 

Lee

[ELA]

Hi LeeG,

I agree that if the problem is in the 2413 that it would make more sense to fix it. Do you believe that Smartlabs would be any more likely to replace everyones 2413s?

I do not. That is whey I question spending the time to identify whether it is i1 devices or the 2413.

Just curious, have you duplicated IM's results?

 

This is from one of IM's earlier posts:

"I'm happy to see that they are continuously improving their product. In this particular instance, they may have improved the dual band communications with newer I2 modules and unknowingly sacrificed reliability with the older I1 units under certain conditions.

Assuming that Smartlabs has improved communications with newer I2 devices I would think they would be more interested in moving forward and leaving the i1 devices behind.

 

But then we will most likely never know will we?

If I had any faith whatsoever that Smartlabs would make things right I would be more interested in attempting to identify the issues. As you said earlier it would be a lot easier if we had access to more information and firmware.

 

I personally believe that one big issue is with simulcasting (ability of units to sync with one another) in general. I also believe that devices "try to hard" by reaching into the noise floor and end up producing bogus messages. I also question the CRC used.

[ELA]

IndyMike,

I apologize for mucking up your thread with my comments. I am eager to hear how you progress and will try to refrain from any further such comments.

[LeeG]

ELA

 

I'm not expecting or asking SmartLabs to replace anything. I would like them to evaluate IM data and conclude there is an issue and update the PLM firmware. I'd pay for new PLMs if they would insure the users the problem is resolved by a firmware fix. I was hoping the v.99 would help but the results are not that much better with the v.99. The only company that provides firmware updates is Simplehomenet. SmartLabs does not offer that service. It is just one of those things one accepts working with SmartLabs devices.

 

Lee

[IndyMike]

Gents,

 

As I said in my opening post, I felt I needed to get this information out because I had read a number of posts which I felt could be attributed to this problem. Posts that caught my attention were related to difficulties in upgrading from the 2412S to the 2413S PLM. If I were to try to restore a 2413 PLM during a "problem period" I would wind up with over 22 I1 modules failing to respond. No one needs that type of frustration - I'm attempting to generate an understanding of the problem so forum members don't have to deal with this.

 

My other reason for posting was that I do not know how widespread this problem is. Some type of stimulus is required to initiate the faults. I'm soliciting forum members to provide their observations on 2413 PLM/I1 device performance. It's possible there are very few people that have experienced this. If that is the case, I will focus on the power quality aspect.

 

I do not expect SH to replace my I1 units. I would hope they would look into the problem and determine whether a PLM fix is viable (there may be hardware aspects to this as well). Like Lee, I would not consider purchasing new I2 units to replace my old hardware. It's simply not economically viable for me.

 

IM

[ELA]

Hello IndyMike,

 

I was able to spend some alone time with my girl Insteon this morning.

You know the type ... she is very high maintenance !

 

I had thought that I no longer had any i1 devices but I found that I did still have one i1 device installed. It is a 2476D (v.27) It is the #11 device in this testing I performed a while back:

 

http://forum.universal-devices.com/viewtopic.php?f=28&t=5923&start=105

Near bottom of the page is the room map. Later in the thread were results of all devices in that room.

 

To provide a better data comparison for you I tried to run 2000 trials.

 

I ran that same device for a total of 1785 trials this morning (then I got company and had to stop the test, too much activity in the house). That one test took nearly 2 hours.

 

The results were 3 missed messages for a >99% success rate (when sent using 3 hops). (5 second time between sends)

This one i1 device appears to do as well as all the I2 devices around it. At least during these two tests. I tested using a 2413U (V.92) PLM.

 

Performing this extended length test gave me a real appreciation for the amount of time you have spent. It also prompted me to ask how you prevented "normal house Insteon traffic" from interfering with your test results? That is a long time to keep other traffic from interfering with results.

I was the only one home and I found myself refraining from using lights, curtains etc. I know that I caused one of the missed messages by activating a lighting scene.

[IndyMike]

Hello ELA,

 

Thank you for taking the time to run those tests. Three failures out of 2000 could easily be explained by transient noise - not at all what I am seeing.

 

In regard to "other Insteon Traffic", I do disable my polling programs on the ISY while I am testing. Aside from that, I allow normal traffic on the system. I can't speak for the HL2 software, but the ISY and My code "tolerate" traffic from other devices. If a response is received from a different device than addressed, my code attempts to wait for a valid response. If the timeout is reached, the command is retried without counting it as a failure.

 

I do keep track of the unexpected responses - they are typically below 10 for a 6000 comm run.

[IndyMike]

IM

 

One of the things that happens when max hops 2 or 3 is specified in the outbound command, the responder must wait longer to send the ACK even if it receives the command on the first try. Do you have the ability to accurately determine the AC cycle that starts the ACK message. I'm wondering if the I1 and I2 devices send the ACK at a slightly different point (start on a different AC cycle). That should not matter but the required delay in sending the ACK when max hop 2/3 is the only thing I can think of that max hops 2/3 is affecting.

 

Lee

 

Hello Lee,

 

I believe I can now say that the failures are not due to the I1 devices "slipping" an AC crossing. I tested this by using an Isolated circuit with my 2413UH PLM and a V.2D KPL. I separated the two devices with 250' of Romex so I could monitor individual responses (voltage differences).

 

1 - 2413S by Itself (KPL not installed)

Obviously this failed since the KPL was not installed. It's very interesting that the PLM participated in all 3 of the outgoing transmission Hops.

 

 

2 - 2413S with KPL: Comm failure

Here I did manage to trigger on a communication response failure. The KPL did respond with a very respectable 1.6V p-p level. HL2 tagged this as a timeout failure - the PLM apparently rejected this response.

 

 

3 - 2413S with KPL: Comm pass

This one still has me scratching my head. The PLM apparently "heard" the KPL response on the initial Hop. The following transmissions that follow appear to be from the PLM itself. After receiving the response, the PLM appears to be participating in the KPL simulcasting. This is very different from what I have seen on the 2412S. It may be different than my V.92 2413S as well (need to check).

 

 

Still looking,

IM

[Teken]

IM,

 

Please excuse the random Q. But, when you have noted a failure with the i1 communications. Have you ever once heard from the PLM (doesn't matter which one) a buzzing sound?

 

Also, one thing to listen for is to place your ear right on any and all switches especially the KPL units. As I have been able to hear comm traffic coming and going while performing diagnostic tests!

 

Teken . . .

[ELA]

Hi IndyMIke,

I noted the same behavior of the newest PLM :

 

http://forum.universal-devices.com/viewtopic.php?f=28&t=5923&p=53174#p53174

 

In my longer duration testing I find most of the time that normal (non test related Insteon traffic) will be tolerated but only to a point.

My firmware will also tolerate unexpected messages(within the limit of PLM level retries). If a scene is activated involving a few devices, and the communications is less than perfect, these communications can interfere with communications timeouts at the PLM level.

 

I have found that testing for 100-200 or so trials provides a pretty good indication of what to expect (unless of course issues are related to a time of day occurrence).

 

I ran the same test again on the one i1 device I have for 500 trials, but from an alternate PLM location and go the same 99% success rate.

In my experience there may not be a lot of difference between a 99% result and a 96% result if the communications path is marginal. An additional load being on (such as a signal sucker) can be all that it takes to make the difference.

[IndyMike]

Hello Tekken,

 

I'm sorry, but I'm not a good person to ask this question. My hearing is only slightly better than my eyesight - poor at best. I can't say that have ever heard anything from a device while it was transmitting.

[IndyMike]

This is a continuation of the isolated circuit testing using the 2413S PLM and the V.2D KPL. In my previous post I was able to demonstrate that the KPL would reliably respond to the PLM Ping command, but the PLM would sometimes reject the response (even though the level was 1.6 V p-p).

 

After finding I could reliably trigger on failed communications on an isolated circuit, I began to measure the device response timing relative to the AC zero crossing. The Insteon white paper specifies a transmission start 800 us prior to the AC zero crossing.

 

The table below shows cursory data I obtained while monitoring 3 devices. The I1 devices would consistently run in the 630 us range while they were communicating properly. When the timing dove below 600 us the PLM would reject the transmission. The I2 APL consistently ran in the 850 us range and did not exhibit failures.

 

 

This may be the "phenomena" that I was searching for. If there is something on my 60 Hz power that causes the I1 devices to communicate "late" it would explain why I see multiple devices fail at the same time.

 

On the flip side, the 2412S PLM does not reject these communications. Not sure if this is due to firmware or revisions in the zero cross detection circuit.

 

IM

[ELA]

Hi IndyMike,

 

I have questioned these devices ability to synchronize properly pretty much from the beginning of my efforts here:

http://forum.universal-devices.com/viewtopic.php?f=28&t=5923&start=23.

 

I question this both with i1 and some i2 devices. Did you also note how the newest PLM appears to "sync" very well with the previous rev PLM ( In my last reference)?

 

Best of luck should you continue your effort to identify just why it happens whether it be hardware,firmware or a combination of both.

[Brian H]

Very interesting findings. Thanks to all for the data so far and I look forward to future findings.

Doesn't help that from time to time Smartlabs changes things communications or hardware wise.

[IndyMike]

I am continuing to experiment and learn about the differences between I1 and I2 devices. This has forced me to start looking at bit level transmission timing and how this differs between new and old devices.

 

Per the Insteon white paper, devices initiate their transmission 800us prior to the 60Hz AC zero crossing as shown below. The 60 Hz AC crossing serves as a clock that all devices use for synchronization.

 

 

In order for devices to simulcast without interfering with one another, the synchronization to the 60Hz zero crossing must be very tight. Each bit consists of 10 cycles at 131.65 Khz or 76 us period. A 180 degree phase shift at 131.65 Khz (1/131.65K/2 = 3.8us) would result in signal cancellation between two devices. In a perfect word, devices would be synchronized to less than 180 degrees of the 131.65 Khz carrier (less than 3.8 us shift). This isn't realistic given the simple zero cross detectors that I've seen on older I1 devices. The white paper indicates that device crossing detectors should be accurate within 1 or 2 carrier periods ( 7.6 to 15.2 us).

 

Plot Data

The following plots show relative zero cross synchronization of my 2413UH PLM, 2456S ApplianceLinc (I2), and 2486D KPL (I1). The yellow traces are the 131.65 carrier. Blue is the 60 Hz AC. Green is a math divide function which blows up (divide by 0) when the 60Hz signal crosses zero. Timing is presented for each plot between the zero crossing and the start of the Insteon transmission.

 

I am not attempting to verify the synchronization at the 131.65 KHz level. I am using a "yardstick" to measure relative timing between the various devices. The I1 KPL does exhibit significant variation.

 

Observations

• [*:202qngmn]The I2 PLM and ApplianceLinc both communicate around 800us prior to the zero crossing. There is some variation, but this can be attributed to my crossing detection.
  [*:202qngmn]When responding to a direct command, the I1 KPL initiates communication at times that vary depending on the max hop level (0 to 3 Hops). In all cases, it is responding later than the I2 devices.
  [*:202qngmn]When responding to a 3 Hop command, the I1 KPL exhibits significant variation. When the response occurs at the bit 8 time frame it is rejected by the 2413UH PLM
  [*:202qngmn]When the KPL is not addressed as a responder (simulcast) it responds in the bit 11 timeframe and is insensitive to the max hop specified.

 

I believe the above explains why my I1 devices perform much better when addressed with a max hop of 0 or 1. It does not explain why they perform differently when using the 2412S modem. That's next up...

 

[IndyMike]

I patched together a zero cross detector similar to the circuit used in the 2412S PLM and re-ran the tests from my previous post. I've pretty much convinced myself of the following as it relates to my system.

 

1) My problems with the I1 devices are due to Insteon response phase shift/incorrect zero crossing detection.

2) The max hop setting multiplies the timing error. If the device has a base zero cross timing error of 50 us, it will be 4x greater with 3 hops (200 us error). This is why my devices consistently pass when using 1 hop.

3) When not addressed, I1 devices simulcast using what is effectively 0 Hop timing.

4) The 2412S PLM is "more tolerant" of communication phase shift. This tolerance is not unlimited. I did note consecutive failures with the 2412S when the timing slipped 500 us (bit 7 position).

5) I2 device synchronization is greatly improved.

 

I have only seen one partial schematic of a I1 Icon relay unit (efundies). That schematic showed the zero cross detector as being transformer coupled to the AC line. If that is correct, it could explain my current problems.

 

I believe I am suffering of incoming power quality issues. Specifically, I believe I have powerline harmonics (or unbalanced loading) that are fooling the transformer coupled I1 devices into mis-interpreting the AC zero cross. The PLM's and older accesspoints, being DC coupled, are able to correctly discern the zero crossing.

 

Time to call the power co. for a "survey".

 

 

 

[Teken]

I patched together a zero cross detector similar to the circuit used in the 2412S PLM and re-ran the tests from my previous post. I've pretty much convinced myself of the following as it relates to my system.

 

1) My problems with the I1 devices are due to Insteon response phase shift/incorrect zero crossing detection.

2) The max hop setting multiplies the timing error. If the device has a base zero cross timing error of 50 us, it will be 4x greater with 3 hops (200 us error). This is why my devices consistently pass when using 1 hop.

3) When not addressed, I1 devices simulcast using what is effectively 0 Hop timing.

4) The 2412S PLM is "more tolerant" of communication phase shift. This tolerance is not unlimited. I did note consecutive failures with the 2412S when the timing slipped 500 us (bit 7 position).

5) I2 device synchronization is greatly improved.

 

I have only seen one partial schematic of a I1 Icon relay unit (efundies). That schematic showed the zero cross detector as being transformer coupled to the AC line. If that is correct, it could explain my current problems.

 

I believe I am suffering of incoming power quality issues. Specifically, I believe I have powerline harmonics (or unbalanced loading) that are fooling the transformer coupled I1 devices into mis-interpreting the AC zero cross. The PLM's and older accesspoints, being DC coupled, are able to correctly discern the zero crossing.

 

Time to call the power co. for a "survey".

 

[attachment=0]Zero_Cross_Comparison2_Table.png[/attachment]

 

[attachment=1]Zero_Cross_Comparison2.png[/attachment]

 

 

Are you saying that you're not receiving 60 hrz cycles at the mains? If so what does the scope measure as the incoming frequency?

 

Teken . . .

[Brian H]

Interesting message thread over on the X10 Forums. Seem that there maybe a one year experiment to allow the power grid to drift further off the 60Hz normal, before corrections are done.

http://forums.x10.com/index.php?PHPSESS ... ic=24051.0

[IndyMike]

Hello Tekken,

 

My service is 60 Hz as verified by a number of instruments. It is not, however, anywhere close to a pure sine (few power drops are). The incoming waveform appears to have "soft" clamping at the voltage extremes and significant harmonics. I do not have equipment to measure and log the low frequency harmonics.

 

My concern is that the quality of the incoming service changes with loading. I have noted that my system tends to run better during times of higher loading. Again, it's not something that I can capture on the scope - requires low frequency equipment.

[Brian H]

OK. Maybe what you are seeing on the AC could be what causes my intermittent total Query Failures with the whole system playing dumb. All but one of my devices is i1.

 

I may try and look at my power. Maybe I will see something.

[ELA]

I believe I am suffering of incoming power quality issues. Specifically, I believe I have powerline harmonics (or unbalanced loading) that are fooling the transformer coupled I1 devices into mis-interpreting the AC zero cross. The PLM's and older accesspoints, being DC coupled, are able to correctly discern the zero crossing.

 

Time to call the power co. for a "survey".

 

IndyMike,

 

What do you think POCO will be able to identify that you did not? How will you phrase your request?

 

Something like, " Two thirds of my home automation system works but one third has issues. It must be harmonics on your incoming supply"?

You might have better luck asking Smartlabs why they cannot seem to simulcast properly.

 

I read your posts with interest but do not follow your reasoning.

 

When loading of the system changes so do circuit impedances. I suspect that is why you see the change.

Have you ever focused on 240volt devices being on/off when you have more issues?

 

Forgive me if I remember incorrectly but I thought you posted that you can duplicate the issues in an isolated network? If so then you believe that harmonics pass through the isolation devices?

[ergodic]

Your testing has made me think again about something I've always wondered: why Insteon seems so much more susceptible to impulse and amplitude noise than it really ought be. The PLL sync really should perform much better in such an environment.

 

But that requirement for tight zero-crossing synchronization suggests the possibility it isn't just simple AM interference fouling the transmissions as we usually assume. But instead high impulse noise creating localized, anomolous jitter of the zero-crossing, then causing either the transmissions to be mistimed relative to the PLM or the reception at the PLM to be ignored.

 

Are you able to tell if the harmonics are being back-fed from your own residence or coming in off the pole?

[ELA]

 

I have only seen one partial schematic of a I1 Icon relay unit (efundies). That schematic showed the zero cross detector as being transformer coupled to the AC line. If that is correct, it could explain my current problems.

 

I believe I am suffering of incoming power quality issues. Specifically, I believe I have powerline harmonics (or unbalanced loading) that are fooling the transformer coupled I1 devices into mis-interpreting the AC zero cross. The PLM's and older accesspoints, being DC coupled, are able to correctly discern the zero crossing.

 

IndyMike,

I went to efundies and did not see the transformer coupling you talk about? Maybe I looked in the wrong spot but the coil there was a relay coil.

 

 

I took my old 2486D keypadlinc apart (i1 device, R1.4 hardware) and traced some of the circuit. This is the i1 device I removed a while back as it was causing me issues.

 

There is no transformer coupling of the zero cross.

[IndyMike]

Forgive me if I remember incorrectly but I thought you posted that you can duplicate the issues in an isolated network? If so then you believe that harmonics pass through the isolation devices?

 

For the record, all of the data I have presented has been performed using a low pass filtered network. The filter will do nothing to eliminate low frequency harmonics or common mode signals.

 

I did try an Isolation transformer at one point and did see failures. That was some time back and prior to disabling the RF on the PLM (may have been a contributing factor). Regardless, it was prior to beginning testing of the zero crossing.

 

To answer your second question, I do not believe a transformer would pass common mode signals (be they AC or DC). I do see 3rd, 5th, 7th, etc. harmonics on the line. These pass through a step down transformer rather nicely.

 

Aside from that, could we limit the snide comments and questions? They are getting a bit old.