Not your usual line noise problems

[rowland]

I've recently had problems with my Insteon network that I've managed to fix. During the course of diagnosing, experimenting, and measuring I've developed a theory that explains the root cause of the problems I've had. Basically, this theory is that my network had a line noise source that caused erratic behavior in devices not because packets were blocked by the noise as quite often happens. Instead, this line noise enters a device through the components that convert 120 volt AC line power to low voltage DC power used to run the processor inside the device. The processor then behaves erratically because it's power supply is noisy.

 

The following is a description of the experiments and observations in support of this theory. If valid, it means that in some situations insteon network problems may not be caused by insteon packets being blocked. In these situations diagnosing and fixing what are perceived to be communication problems should be approached in a different way. For example, using FilterLincs may have limited, or no effect. There could be another more compelling theory that explains what I've seen. Others may have observed phenomena that support , or reject, the theory.

 

My network includes 14 KPLs, 24 togglelinc relays, 48 toggelinc dimmers, 1 OutletLinc, and a pair of RF repeaters. I have an ISY 26 and an ISY 99 that I've used interchangeably. I also have 3 PLMs that have been used interchangeably. The system behavior is invariant under different combinations of ISY controller and PLM. The ISYs have been run with 2.6, 2.6.1, and 2.6.2. Currently, the configuration is a version 2.75 2000 link PLM, ISY 99 running 2.6.2, Currently, there are no programs within the ISY. Although the house lighting is mostly fluorescent, both tube, and compact, I've not seen any behavior that would suggest noise problems due to noisy fluorescent fixtures.

 

There were several problems that were eliminated by replacing a PC. In addition, I was seeing lots of device communication errors that were drastically reduced by replacing the PC.

 

By accessing the ISY through the telnet interface and entering the command SCAN ZZ the entire link database of the PLM is listed. With the noisy PC in the system the link database listing would terminate before listing all links. No error message, it would just quit after listing a random number of links. I ran an experiment where all the breakers in the house where turned off with the exception of one breaker that had the PLM (the ISY was powered via its connection to the PLM), router, and the noisy PC plugged in. In this configuration there are NO connected insteon devices and, thus, no insteon network traffic to be blocked. The only information flow is via the serial cable between the ISY and the PLM. Replacing the noisy PC completely eliminated the SCAN ZZ partial listing problem.

 

Devices would turn on at random without being commanded to. There are no programs in the ISY. The ISY log shows no entries associated with these devices being turned on. This is a house under construction with no one there at night. Upon arrival in the morning I would sometimes find one or two lights on. There is a vague pattern that may have some significance. There were two lights that were often on, and 3 or 4 others that were affected to a lesser degree. These 5 or 6 lights are part of a larger group of about 20 lights that are responders in a scene with 14 KPL buttons being controllers. It's an "All Outside Lights On" scene. Replacing the noisy PC completely eliminated this problem.

 

Devices would go dark, i.e. simply stop working with the led being off. Airgapping the device would bring it back online. Replacing the noisy PC completely eliminated this problem.

 

After the noisy PC was replaced and the system had been working smoothly for about a week I tried an experiment where the noisy PC was plugged in at different locations within the house. In addition, I tried using none, one, and two FilterLincs with the noisy PC plugged in at a particular location. Each configuration would be tested by running the SCAN ZZ test (described above) a couple of times. The result of a trial was my subjective perception of how far (on average) the SCAN ZZs got before quitting. The number of FilterLincs used made some difference, but, the location within the house made more difference. It wasn't so much the distance (i.e. the length of the Romex) from the noisy PC to the PLM, but, locating the noisy PC on some circuits seemed to have more of an effect than others. All I can really say is that the location had some effect, but I can't really explain the effects.

 

I'm interested to know if others have observed behavior that could be explained by power line noise affecting the device processor.

[IndyMike]

Rowland,

 

Thank you for taking the time to post what is obviously a lot of troubleshooting work on your part.

 

While I have seen evidence of noise/transients directly affecting the processors in some of the old X10 products, I haven't seen or heard of the same problem with the Insteon units.

 

I have seen evidence posted (D Houston) that Insteon devices can respond to "out of band" noise and can effectively lock up as a result. Mr. Houston was using a failing PC Monitor as a noise source and could effectively lock up different devices. This was interpreted as direct powerline noise influence, not noise making it to the low voltage side of the processor.

 

I have never seen documented evidence that noise produce an un-commanded ON in Insteon devices. This should not happen due to the error checking in the Insteon protocol. In short, if your devices are activating in response to the noise, you may be on to something with your theory that the noise is directly affecting the PIC power input.

 

If I could impose upon you a bit more? Would it be possible for you to use an Oscilloscope to characterize the noise being generated by the PC? The scope would need to have FFT capability so you could quantify the frequency and amplitude content of the noise. If we could get this info we might be able to reproduce some of your results and explain why Filterlincs don't work for some installations.

[MikeB]

I have never seen documented evidence that noise produce an un-commanded ON in Insteon devices.

 

What if the Insteon device has an inadvertent X10 address assigned to it?

[rowland]

Rowland,

 

If I could impose upon you a bit more? Would it be possible for you to use an Oscilloscope to characterize the noise being generated by the PC? The scope would need to have FFT capability so you could quantify the frequency and amplitude content of the noise. If we could get this info we might be able to reproduce some of your results and explain why Filterlincs don't work for some installations.

 

Unfortunately, my scope doesn't have an FFT capability, and I've retired from my job where I could borrow one. But the noisy PC isn't going anywhere, and sooner or later, I'll be presented with the opportunity to connect it to a spectrum analyzer of some sort.

 

I'm suspecting, without any real data, that it is a noise source somewhere between 60 hZ and 131.5 kHz (carrier signal for insteon). About 6 months ago I dissected a FilterLinc to find that it is a single stage low-pass pi-network filter. This wouldn't provide much rejection of noise towards the lower end. A spectrum analyzer would be just I need

[IndyMike]

Unfortunately, my scope doesn't have an FFT capability, and I've retired from my job where I could borrow one. But the noisy PC isn't going anywhere, and sooner or later, I'll be presented with the opportunity to connect it to a spectrum analyzer of some sort.

 

I'm suspecting, without any real data, that it is a noise source somewhere between 60 hZ and 131.5 kHz (carrier signal for insteon). About 6 months ago I dissected a FilterLinc to find that it is a single stage low-pass pi-network filter. This wouldn't provide much rejection of noise towards the lower end. A spectrum analyzer would be just I need

 

Yep, we're thinking along the same lines here. In order for this to work, the frequency must make it past the Filterlinc 1st order filter and make it's way into the low voltage section of the Insteon device. Not necessarily an easy thing to accomplish.

 

To MikeB's point, have you performed a "factory reset" on your devices to ensure there are no stray X10 codes leftover from the factory?

 

Having asked that, I have never seen a valid X10 transmission "spontaneously generated" by noise alone. I have seen valid X10 transmissions that become "morphed" in the presence of noise (Ex - address or house code changes due to noise bursts during the transmission).

 

IM

[rowland]

 

 

To MikeB's point, have you performed a "factory reset" on your devices to ensure there are no stray X10 codes leftover from the factory?

 

IM

 

I didn't get around to doing that because I figured out that the noisy PC was causing the PLM SCAN ZZ problem. The problem with lights coming on being fixed came as a "bonus". But I can try the factory reset as an experiment with the noisy PC being plugged in as noise source. The experiment will be a little different than what I had. Just this morning I have removed those lights for about a month to deal with a stucco problem. But I'll be able to tell if its on by looking at the admin console. The only difference will be that the device doesn't have a load, but, that shouldn't matter.

 

My network will become ugly during the experiment, but that's OK since we're not living here yet. And, I'll know it can be restored to working order.

[rowland]

I have not quite managed to confirm that a factory reset won't affect the behavior where devices get turned on without being commanded to.

 

I re-connected the noisy PC, but in the garage instead of it's original location. The garage is detached and has it's own branch circuit with receptacles being on the same breaker as insteon switches. I was hoping to have the house insulated some from the problems caused by the noisy PC. In addition, those insteon switches in the garage are much closer, in terms of wiring length, to the noisy PC. Initially, the only problems apparent were the usual device communication problems. In fact, the SCAN Z diagnostic that I use beacuse it is reliable and quick indicated no problems.

 

Then, I had to move the noisy PC about 6 inches and the problems started again. I'm assuming the power supply has mechanical problem that causes intermittent problems. Since then I see an insteon device turn on every 2 days, or so. This is less than before. I'll factory reset it and wait to see if it turns on again. So far, no repeats but the test needs to go a bit longer before concluding that the factory reset has an effect.

 

As I understand it, the X10 address is located at 0x30, 0x31, 0x32. In each case, the contents of these locations is 2000FE both before AND after the factory reset. I would expect to see 000000 after a factory reset. Am I missing something here?

 

The behavior that hasn't changed is the SCAN Z test which indicates problems with the PLM. Does the PLM have an X10 address?

[Michel Kohanim]

Rowland,

 

After factory reset, those locations should all have 0000s unless we are not reading the right memory locations.

 

I don't think the PLM has an X10 address.

 

With kind regards,

Michel

I have not quite managed to confirm that a factory reset won't affect the behavior where devices get turned on without being commanded to.

 

I re-connected the noisy PC, but in the garage instead of it's original location. The garage is detached and has it's own branch circuit with receptacles being on the same breaker as insteon switches. I was hoping to have the house insulated some from the problems caused by the noisy PC. In addition, those insteon switches in the garage are much closer, in terms of wiring length, to the noisy PC. Initially, the only problems apparent were the usual device communication problems. In fact, the SCAN Z diagnostic that I use beacuse it is reliable and quick indicated no problems.

 

Then, I had to move the noisy PC about 6 inches and the problems started again. I'm assuming the power supply has mechanical problem that causes intermittent problems. Since then I see an insteon device turn on every 2 days, or so. This is less than before. I'll factory reset it and wait to see if it turns on again. So far, no repeats but the test needs to go a bit longer before concluding that the factory reset has an effect.

 

As I understand it, the X10 address is located at 0x30, 0x31, 0x32. In each case, the contents of these locations is 2000FE both before AND after the factory reset. I would expect to see 000000 after a factory reset. Am I missing something here?

 

The behavior that hasn't changed is the SCAN Z test which indicates problems with the PLM. Does the PLM have an X10 address?

[rowland]

Seems like there might be a problem with SCAN. I ran these two SCANs about 5 minutes apart. The first shows 0x00 in 0x30 and the second shows 0x20 in 0x30. I tend to believe the former since I had done a factory reset. This is the only time I've seen 0x00 in 0x30; all the other SCANs I've done shows 0x20 in 0x30.

http://192.168.1.26>SCAN 83C2A 490 520
Device info for:  8 3C 2A 1
--- Device Links - Start ---
00A8 : 490 : FF FF FF FF FF FF FF FF
00A0 : 491 : FF FF FF FF FF FF FF FF
0098 : 492 : FF FF FF FF FF FF FF FF
0090 : 493 : FF FF FF FF FF FF FF FF
0088 : 494 : FF FF FF FF FF FF FF FF
0080 : 495 : FF FF FF FF FF FF FF FF
0078 : 496 : FF FF FF FF FF FF FF FF
0070 : 497 : FF FF FF FF FF FF FF FF
0068 : 498 : FF FF FF FF FF FF FF FF
0060 : 499 : FF FF FF FF FF FF FF FF
0058 : 500 : FF FF FF FF FF FF FF FF
0050 : 501 : FF FF FF FF FF FF FF FF
0048 : 502 : FF FF FF FF FF FF FF FF
0040 : 503 : FF FF FF FF FF FF FF FF
0038 : 504 : 00 00 00 00 00 00 00 00
0030 : 505 : 00 00 FE 00 00 00 00 00
0028 : 506 : 00 00 00 00 00 00 00 00
0020 : 507 : 00 1F 80 00 00 00 00 00
0018 : 508 : 00 00 00 00 00 00 00 00
0010 : 509 : 00 00 00 00 00 00 00 00
0008 : 510 : 00 00 00 00 00 00 00 00
0000 : 511 : 50 10 27 00 00 00 00 00
--- Device Links - End   ---

http://192.168.1.26>SCAN 83C2A 490 520
Device info for:  8 3C 2A 1
--- Device Links - Start ---
00A8 : 490 : FF FF FF FF FF FF FF FF
00A0 : 491 : FF FF FF FF FF FF FF FF
0098 : 492 : FF FF FF FF FF FF FF FF
0090 : 493 : FF FF FF FF FF FF FF FF
0088 : 494 : FF FF FF FF FF FF FF FF
0080 : 495 : FF FF FF FF FF FF FF FF
0078 : 496 : FF FF FF FF FF FF FF FF
0070 : 497 : FF FF FF FF FF FF FF FF
0068 : 498 : FF FF FF FF FF FF FF FF
0060 : 499 : FF FF FF FF FF FF FF FF
0058 : 500 : FF FF FF FF FF FF FF FF
0050 : 501 : FF FF FF FF FF FF FF FF
0048 : 502 : FF FF FF FF FF FF FF FF
0040 : 503 : FF FF FF FF FF FF FF FF
0038 : 504 : 00 00 00 00 00 00 00 00
0030 : 505 : 20 00 FE 00 00 00 00 00
0028 : 506 : 00 00 00 00 00 00 00 00
0020 : 507 : 00 1F 80 00 00 00 00 00
0018 : 508 : 00 00 00 00 00 00 00 00
0010 : 509 : 00 00 00 00 00 00 00 00
0008 : 510 : 00 00 00 00 00 00 00 00
0000 : 511 : 50 10 27 00 00 00 00 00
--- Device Links - End   ---

 

The noisy PC is not on and connected

[Algorithm]

Hello Rowland,

 

First of all, thanks so much for the great deal of testing which you have done, and for sharing your results!

 

I've recently had problems with my Insteon network that I've managed to fix. During the course of diagnosing, experimenting, and measuring I've developed a theory that explains the root cause of the problems I've had. Basically, this theory is that my network had a line noise source that caused erratic behavior in devices not because packets were blocked by the noise as quite often happens. Instead, this line noise enters a device through the components that convert 120 volt AC line power to low voltage DC power used to run the processor inside the device. The processor then behaves erratically because it's power supply is noisy.

 

...

 

I'm interested to know if others have observed behavior that could be explained by power line noise affecting the device processor.

Here is some anecdotal evidence which, though involving X-10 devices rather than INSTEON, does I believe support your theory of erratic behavior due to noise entering the power supply.

 

A few years ago before moving to INSTEON, I had a reasonably solid X-10 installation. But there was one switch (an X-10 Pro relay switch) in the kitchen controlling the counter light. This switch would, at random times of the day, rapidly turn itself on and off. The duration of the on portion and off portion of the cycle would vary from perhaps three seconds, down to seemingly less than a second. This on/off cycle would repeat anywhere from one time to 20 times or more, and then stop as mysteriously as it had started. When not in this cycling mode, the switch would operate completely normally, both locally and via remote commands. This would happen one, twice, or several times in a day, but there would be periods of one to many days where it would not happen at all. I never did discern a pattern to it.

 

However, this behavior completely stopped when the family next door sold that house and moved. Now, my kitchen is the part of my house closest to the neighboring house, but my service panel is at the opposite corner of my house, at the point farthest from the neighboring house. This strange phenomenon did briefly manifest itself one time only on a few other switches in the house, all of which were near the service panel and distant from the other house. So the fact of the switch being physically near the other house may be pure coincidence. But it is no coincidence that the behavior stopped completely when the other people left.

 

After reading your initial post, it seems quite possible to me that those people used something that generated [electrical] noise which got into this switch's power supply.

 

One other datum which has nothing to do with home automation devices: I have a cordless phone and base in my kitchen as well. This phone used to occasionally ring as though there were an incoming call, but none of the other phones in the house would ring. If I picked up the phone, I would hear dial tone--no incoming call. This behavior, too, ceased immediately when the people next door left.

 

Make of that what you will...

[Algorithm]

Hi Rowland,

 

Now on to part two...

 

As I understand it, the X10 address is located at 0x30, 0x31, 0x32. In each case, the contents of these locations is 2000FE both before AND after the factory reset. I would expect to see 000000 after a factory reset. Am I missing something here?

 

I think you may be on to something here. Over the weekend, I installed four of the new KeypadLinc Relay switches, as well as a not so new Icon dimmer switch, and of course factory reset them all. While I was able to give the dimmer an X-10 address, I could not do the same for the KPL Relays, no matter what method or how hard I tried.

 

After reading your post today, I scanned my recently installed devices. Every one of the new KPL Relays shows 0x20, 0x00, 0xFE in locations 0x30, 0x31 and 0x32, respectively! The dimmer shows 0x0A, 0x0C, 0xFE in those locations. The X-10 address of the dimmer is D1--does that translate correctly to what is shown in those locations?

[IndyMike]

rowland,

 

Thanks for the info on the scans. I'm learning here - I didn't know where the X10 codes were stored.

 

I've done some scanning on my own (using your locations as a guide) and came up with the following.

 

1) Icon Lamp dimmer: Housecode P, Unit code 16, Brightness set to 100:

Device info for:  7 AE 1D 1
--- Device Links - Start ---
0030 : 505 : 0C 18 FF 00 00 00 00 00

 

2) Icon Lamp dimmer: Housecode P, Unit code 16, Brightness set to 0:

--- Device Links - Start ---
0030 : 505 : 0C 18 01 00 00 00 00 00

 

From what I've observed, memory locations x30 is the House Code and x31 is the Unit code (conform to the X10 standard). Memory location X32 is the "on" level (x01 to xFF).

 

The following table converts the binary X10 code to the Hex code used in the memory -

 

 

 

Based on the above, a code of x20 at location x30 would be outside the valid X10 Housecode range - ignored???

 

Thanks again for the info,

IM

 

Seems like there might be a problem with SCAN. I ran these two SCANs about 5 minutes apart. The first shows 0x00 in 0x30 and the second shows 0x20 in 0x30. I tend to believe the former since I had done a factory reset. This is the only time I've seen 0x00 in 0x30; all the other SCANs I've done shows 0x20 in 0x30.

[rowland]

Darrel,

 

Was your neighbor a ham radio operator? You'd know if there were unusual antennas and the like. Also, did he have a lot of time on his hands and that far off look in his eyes? I know this because I've done some ham radio operating. Seriously, it almost sounds like there was RF energy emanating from his house that was making it's way into your X10 device. Either, as random signal data, or, as you suspect, power fluctuations.

 

On your second issue. The only Insteon devices I've inspected for X10 addresses are KPLs, and ToggleLinc Dimmers. All have shown 0x20, 0x00, 0xFE at 0x30, 0x31, 0x32; even after a factory reset. I'm suspecting that something is going wrong with SCAN; especially since two particular SCANs showed 0x30 containing 0x20 and 0x00 within 5 minutes of each other. See my previous post.

[rowland]

 

The following table converts the binary X10 code to the Hex code used in the memory -

 

 

 

Based on the above, a code of x20 at location x30 would be outside the valid X10 Housecode range - ignored???

 

Thanks again for the info,

IM

 

 

That's interesting. Just the low order 4 bits are used for the House Code. So 0x20 is the same as 0x00 as far as X10 is concerned. That is, unless the "H32" bit (following the convention of your table) has special meaning. Such as ignore this entry.

[rowland]

IndyMike,

 

I get it now. An X10 device has to have one of the 16 House Codes which includes 0000 binary (the M house code). I.e. "no address" isn't allowed. But, Insteon has to have a way of specifying that an Insteon device has no X10 address, thus requiring the use of a bit exclusive of the low order 4 bits. Is this what you were trying to tell me?

[IndyMike]

That's interesting. Just the low order 4 bits are used for the House Code. So 0x20 is the same as 0x00 as far as X10 is concerned. That is, unless the "H32" bit (following the convention of your table) has special meaning. Such as ignore this entry.

 

Correct,

 

It's interesting to not that my Icon Lamp dimmer does not have the 0x20 code set with the X10 disabled. Many of my other units do have this code.

 

The table above is simply a hex conversion of the X10 protocol document located here:

 

http://www.x10pro.com/pro/pdf/technote.pdf

 

Enjoy,

IM

[Algorithm]

Was your neighbor a ham radio operator?

 

Not that I know of. Perhaps he had some heavy duty equipment in the basement?

[Algorithm]

The following table converts the binary X10 code to the Hex code used in the memory -

 

Indy,

 

Thanks so much for the X-10 table!

 

I've scanned a few more devices. Some Icon appliance modules which have never been given X-10 addresses, show 0x20, 0x00, 0xFE. Some in-wall switches with X-10 addresses show the correct house/unit codes in 0x30, 0x31 according to the table, with 0x32 being 0xFE.

 

I believe that Rowland is correct in that 0x20 in the housecode position must indicate no X-10 address assigned, since 0x00 is a valid housecode.

 

But if position 0x32 holds the on-level (and I'm sure you're correct that it does, and I presume this means the on-level the switch should go to when the X-10 code is received, not the current level), I wonder why is it 0xFE rather than 0xFF for full on--both for assigned X-10 addresses (mine are set to full on) and for no X-10 address--even in relay devices which have no 'on-level'?

[IndyMike]

 

I believe that Rowland is correct in that 0x20 in the housecode position must indicate no X-10 address assigned, since 0x00 is a valid housecode.

 

 

I agree. Rowland has given us a very handy piece of information here. Being able to scan the X10 address status beats the heck out of randomly resetting the device and wondering if that was the problem.

 

But if position 0x32 holds the on-level (and I'm sure you're correct that it does, and I presume this means the on-level the switch should go to when the X-10 code is received, not the current level), I wonder why is it 0xFE rather than 0xFF for full on--both for assigned X-10 addresses (mine are set to full on) and for no X-10 address--even in relay devices which have no 'on-level'?

 

I found the same entry on devices that I had not assigned addresses to. It appears to be a default, but I'm not sure why they chose "FE". I was able to verify a working range from "0x01 to 0xFF" using the lamplinc.

 

Incidentally, location 0x02 (line 511) contains the device revision.

 

IM

[Algorithm]

Hi Indy,

 

But if position 0x32 holds the on-level (and I'm sure you're correct that it does, and I presume this means the on-level the switch should go to when the X-10 code is received, not the current level), I wonder why is it 0xFE rather than 0xFF for full on--both for assigned X-10 addresses (mine are set to full on) and for no X-10 address--even in relay devices which have no 'on-level'?

 

I found the same entry on devices that I had not assigned addresses to. It appears to be a default, but I'm not sure why they chose "FE". I was able to verify a working range from "0x01 to 0xFF" using the lamplinc.

Yes, you are correct. In an Icon lamp module set to 100%, I see 0xFF in 0x32. But in every in-wall device I scanned, switch or KPL, dimmer set to 100% or relay, I saw 0xFE in that location. Strange!

 

Incidentally, location 0x02 (line 511) contains the device revision.

And you are correct again. Each device I scanned showed the same revision as reported by ISY.

 

Thanks so much, Indy

[rowland]

I was finally able to get back to testing in regards to the lline noise issue. Doing a factory reset does not make the problem go away. That is, I still get devices turning on without being commanded to and doing a factory reset doesn't help.

[Cartwrig]

I was finally able to get back to testing in regards to the lline noise issue. Doing a factory reset does not make the problem go away. That is, I still get devices turning on without being commanded to and doing a factory reset doesn't help.

 

Just coming across this thread....here's my input......

 

-----------INSTEON EMBEDDED CONTROLLER - POWER SUPPLY NOISE:

 

I've seen some of the same erratic behaviors, I believe related to the power supply for the embedded micros in Insteon devices, where high noise generating appliances exist in homes. Most notably: VFD Motors (variable frequence drive; i.e., variable speed) ....such as:

 

- wellpumps,

- hvac circulation fans, and/or

- hvac outdoor airconditioning compressors (Carrier for example).

 

When I get a chance, I'm going to take apart an Insteon device and use my o-scope to read the low voltage DC-supply pins of the PIC. Then, turn on the VFD (variable frequency drive) wellpump in my customer's home; and see if the power feeding the embedded controller becomes erratic.

 

------FILTERING TESTS UNDERTAKEN:

 

I have a customer's home that I've recently done $450 worth of filtering on the 220VAC feeding the wellpump controller (a Franklin SubDrive 300, VFD-type controller). I've been successful in reducing (but not completely removing) much of the noise generated by that pump controller. I got it down to a consistent 0.1V.

 

Note: For the $450 filtering test, I used a "tuned" Insteon Notch Filter (FilterConcepts Model: 2132). I had been seeing 0.3V to 0.5V+ of noise, before installing the 2132. After installation of this filter, I'm seeing only 0.1V of rock solid noise, while the pump is running.

 

I also tried an $850 Dongan Isolation Transformer (Model 85-1065, 10KVA 240VAC, 40A); which, I was able to get used on ebay for $250. The Dongan Iso-Xfmr reduced the noise seen by the (4) AP's mounted below the two Main Electrical Panels, from the 0.3-0.5V, down to "under" 0.1V, as metered on an ELK ESM1 X10 Signal Meter.

 

----------FILTERING EXPERIENCES - RESULTS:

 

Generally I don't see the noise from the wellpump much at all on the ELK ESM1, with the Iso-Xfmr installed; except that, I get little blips of viewable noise on the ESM1. So, I think the noise is just below the 0.1V lowest LED Bar on the bar graph. However, the noise jumps in signal strength just enough to randomly light the lowest 0.1V LED.

 

Main Electrical Panel AP's: Of course, in either case, with the 2132 Notch Filter, or the 85-1065 Iso-Xfmr, the noise was reduced; but also in either filtering case, the AP's at the Main Electrical Panels still blinked randomly whenever the wellpump was running...just as if no filtering had been installed at all.

 

House-wide AP's/Other Devices: However, with either filtering solution, the incessant LED flickering throughout the house (on the LampLincs, IR-Linc, AP's, and EZIO devices spread throughout the rest of the house) COMPLETELY went away. So, I think I've reduced the noise enough for the rest of the house; and, I'm just contending presently with 0.1V noise levels right near the wellpump controller, which of course is right next to the Main Electrical Panels.

 

----------SMARTHOME INFO ON "BACK-OFF" and "RETRY":

 

SmartHome confirmed that flickering AP LED's will not keep the AP's from still transmitting/retransmitting when they receive strong Insteon PLC transmissions. In other words, stray noise on the line, at small signal strengths should not cause AP's to "back off" and wait to "retry" when the powerline becomes clean. However, Smarthome did comment that some other devices will back-off; but, they didn't itemize which ones, exactly. So, beware of KPL's and SWL's, etc. throughout any home that has incessant noise...especially where VFD equipment is running.

 

---------TESTING CAVEAT:

 

Do note that the ELK ESM1 is designed for ~121KHz X10 signals; so, I don't know if there is some dB roll-off in the metering capability as it reads Insteon Powerline Carrier Frequencies at 131.65KHz.

 

---------NEXT STEPS:

 

If anyone else gets to testing the DC supply-voltage feeding PIC controllers inside Insteon devices with an o-scope, before I do; please post your results. It may be a while before I get it done. [Obviously, if you have a scope, I'm assuming you know how to use it; but, just as a caution......There are high voltages inside Insteon Circuits as well...if you go testing in there, be careful!!] And, if you do test, be sure you have some "high noise generating appliance/equipment" to assure that you're generating lots of noise and harmonics on the 120VAC supply wires!!!!

 

--------SMARTHOME INFO ON POWERSUPPLY UPGRADES:

 

Likewise, Smarthome did confirm, as I've seen elsewhere in these forums that they have some new KPL Relay devices that have already released with far less susceptable internal power supplies. Other devices will havre beefed up power supplies as well....as time goes on.

 

- Rob