Getting Serious - When Comm issues strike

[wrj0]

ELA,

This is not boring at all. On the contrary - it's very interesting. Please keep posting your test results as it's giving us plenty to think about in our own configurations. Thanks for your efforts!

 

It sure would be great to have a source for your monitor.

[Illusion]

Agreed. I read each new post with great interest.

[ELA]

Thank you both,

I appreciate your kind responses.

 

I bought two new "SurgeStrips" yesterday. They did not state any EMI attenuation figures so i was hopeful that they did not have a capacitor inside.

After previous purchases, and not knowing for sure without prying the unit open, it was very cool to be able to put it on my tester and confirm "No change in XMIT current" , thus no signal suck.

 

I have decided to add (2) Switchlinc Relays and (1) KeypadLinc to the room (circuit) I have been pretesting. I am purchasing three filters and possibly a dual band lamplinc.

That would allow me to test different configurations for effectiveness. I like the idea of getting some RF (redundant capability) in that room but I would rather not add a lamplinc (or access point) device just to get the RF without another purpose for the device. If there were a Black Tabletop dual band Keypadlinc that would fit my needs perfectly

[TJF1960]

If there were a Black Tabletop dual band Keypadlinc that would fit my needs perfectly

There will be a 6 button white KPL DualBand available 8/15. http://www.smarthome.com/2487S/KeypadLinc-INSTEON-6-Button-Scene-Control-Keypad-with-On-Off-Switch-Dual-Band-White/p.aspx

 

Assuming the black button change kit is still available. http://www.smarthome.com/2401BK6/6-Button-Change-Kit-for-KeypadLinc-Black/p.aspx

 

And count me as a follower of your posts as well. Love seeing the data and your findings.

 

Also, just a thought. If you find you are not able to cost effectively produce your tester you might be able to recover some money by offering the software and a parts list and assembly instructions. I know I would love to build one of these.

 

Thanks,

 

Tim

[Brian H]

I also find your data informative.

I joined the Developers Group in the early days. When they where pushing the idea of " For Those Interested In How Insteon Hardware Worked"

 

Not 100% sure if the new dual band KPL will fit in the present desktop case used by the original KPL. As it is .5" deeper and I don't remember how much extra room was in the case. I built one myself with the KPL and case purchased separately. The preambled one was not being sold yet.

 

http://www.smarthome.com/2402BK/Tableto ... ack/p.aspx

I used the ZTP2-W as I wanted white. Which I believe is the generic case that Smarthome put their stock number on.

http://www.simply-automated.com/documen ... 080527.pdf

 

I can see where your tester could be a tool in finding signal problems. I use an X10 tester and a signal source to observe changes. The tester does display a "I" if it see an Insteon signal but readings can be confused by which module was read as the signals are being passed around.

[LeeG]

ELA

 

I ditto the interest in a parts list/wiring diagram/software package to recover some of the investment. Keep up the posting of your findings. They are fascinating reading for many of us. The fact the body can interfere with the RF signal was great information.

 

Lee

[wrj0]

ELA,

If your monitor cannot economically be made available, please include this long-time-ago-Heathkit-builder on the interest list for a parts list, schematics, and software. It would seem that your monitor is potentially just too useful not to have one. Thanks.

[ELA]

Thank you all once again for the kind responses.

 

Thanks for the heads up on the dual band keypadlinc. Maybe I will wait a bit then and build my own case if required.

 

I did undertake this effort in hopes of helping others and with hopes of providing a tool that others could use if it proved to be useful.

 

I have considered the "kit" idea. The problem would be that I have used one 0.025" pitch IC (for the USB bus interface) that is very difficult to solder. The microcontroller was bad enough at 0.035" pitch. You need a small tip to solder these ICs and a very steady hand.

In fact that 0.025" pitch IC is what has caused me to procrastinate in putting together my third prototype. I feel like I got lucky soldering the first unit.

I bought the PLM a few weeks ago!

 

The other complication is that in addition to plugging onto the standard PLMs internal 8 pin connector it requires 3 other interconnects where you have to cut and jumper onto the PLM. You immediately void the warranty of course

 

I have not given up totally on some way to make it available down the road. At this point I am still planning a little more development on the firmware. I think I may be able to detect and report "noise" severity levels.

This of course would require me to reproduce a noisy environment, confirm it corrupts messages, and then see if the unit can reliably report the presence of that noise.

 

Any ideas on a good noise source that you have had issues with, ... CFL's?

 

ah yes, building Heathkits back in the good old days ! I still have my old 10Mhz dual trace Heathkit scope and function generator.

[io_guy]

Any ideas on a good noise source that you have had issues with, ... CFL's?

In my house I had to add 2 filters. One was my computer workstation (Power Bar, Computer, Speakers, Monitor, Printer)

The other, and huge noise creator (100% loss) was a simple 120VAC->24VAC transformer in an overhead light. Post:

viewtopic.php?f=28&t=4339

[ELA]

ELA

 

I ditto the interest in a parts list/wiring diagram/software package to recover some of the investment. Keep up the posting of your findings. They are fascinating reading for many of us. The fact the body can interfere with the RF signal was great information.

 

Lee

Hi LeeG,

Yes that was very surprising to me. Rf is not my strong suit. I have worked with a few 802.11 radios and my initial guess would have to be Mulit-path signal interference since I doubt my body could totally block the RF.

If I had read someone else post such a result I might be skeptical but having stood there for 5 minutes and confirmed via both the lamplinc LED (not going on/off every 4 seconds) along with my tester logged data I was very surprised.

 

I have a total of 4 RF equipped devices in my network. In addition to the Dual band PLM that was closest I also have two Dual band lamplincs and an Access point that would be about 40-50 ft from the test receiver. As it happens all of these are arranged such that where I was positioning my body could have been partially blocking(reflecting) all of these devices at the same time.

A most interesting result that I may have to follow up on someday.

[Teken]

ELA

 

I ditto the interest in a parts list/wiring diagram/software package to recover some of the investment. Keep up the posting of your findings. They are fascinating reading for many of us. The fact the body can interfere with the RF signal was great information.

 

Lee

 

 

I will add my name to the list as well . . . I too was surprised with your results with respect to the interference with the RF with your body.

 

As it was stated on SH forum a few weeks back . . . Keep posting and testing your new diagnostic tool. What you learn and share with all of us is invaluable!

[ELA]

I was attempting to add an indication of noise level to my test device. I tried several CFLs to see if I could detect detrimental noise from any of them.

While I could see noise added to the line it fell outside of the critical Insteon communications window - zero cross timeslots and so my tester did not indicate anything.

This will remain a work in progress until I identify some Insteon detrimental noise sources for further testing.

 

An interesting outcome of this noise diversion was to show bad of a Signal Sucker CFLs can be. I have only a few brands so it may not pertain to all but my testing of three different brands showed them to be detrimental signal suckers.

 

Keeping with my previous method of comparison I quantified the CFLs in terms of "Standard Insteon Loads".

 

I ran one 100W incandescent as a point of comparison to (4) CFLs (15w,15w,23w,23w). The (4) CFLs together for an approximate compare in terms of wattage consumed.

 

Test was run on a Filterlinc isolated network using the tester to monitor the line and an Appliancelinc as the receiver/load controller.

1) The 100W incandescent presented a load of 0.1 standard Insteon loads.

2) The (4) combined CFLs presented a load of 3.0 standard Insteon loads.

3) (1) CFL presented a load of 1.2 standard Insteon loads.

 

Then as a followup I monitored the line with the oscope. It is very interesting to see that turning on/off the incandescent lamp presented a very minimal loading to the communications network vs the very large effect (4) CFLs have.

It is also interesting to view the effect in terms of the initial send packets vs the hops. I did this test with 3 hops and a direct message so that the effect could be monitored over a long time span.

Using the CFLs there is a very distinct change in amplitude (2:1) between the initial send packet and the remaining hops (both from the send and the response msg).

 

When turning ON: Volts = 4.1Vp-p (first packet only) -> all remaining packets = 2.3Vp-p

When turning OFF: Volts = 2.3Vp-p (first packet only -> ) all remaining packets = 4.1Vp-p

 

A good depiction of the notorious issue people encounter sometimes when their network has marginal communications. They can turn the light on, but not off again.

[Brian H]

Your findings with CFLs. Matches what I have seen in the past.

 

I took some apart.

Many use a cap across the AC input to stop its electronics noise from spewing back to the power lines. They tend to absorb power line signals.

 

Some had no noise reduction parts and spewed noise all over the place.

 

One actually had the cap for noise but used a inductor between it and the line input. It was quite Insteon and X10 friendly.

 

I have a CCFL that radiated noise through the air. That would read on my X10 tester anytime it got too close to one.

[ELA]

Brian,

All CFLs that I have seen are capacitive input devices. A relatively large capacitor is part of their power supply.

Some do incorporate choke coils to reduce their emissions as well as much smaller EMI reduction caps.

 

Here is an interesting site that shows quite a few CFL schematics:

 

http://www.pavouk.org/hw/lamp/en_index.html

 

It is very convenient to now have a device that allows me to quickly and easily check any device to see if it is a sucker before I add it to my network.

 

While doing some testing with the CFLs I spied a plugstrip with (6) various battery chargers plugged into it.

Back in my X-10 days that strip only had 2 or 3 chargers and the number has grown over the years.

 

I tested the entire strip load and found it to be a "2.7" standard Insteon load. A substantial sucker.

I then tested each charger separately. I found that the original chargers did not contribute to the sucking (ones I accumulated during my x-10 days).

 

The newer ones I have added over the years are the issue.

1) The Ryobi 18V lithium charger measured 1.5 standard Insteon loads.

2) A Dremel tool charger measured 1.9 standard Insteon loads.

 

So ideally this would be another place to add a filter. I have not had any issues in this area previously but I now know signal is being sucked at that location.

 

That is a possible downside to being able to quantify signal suckers in this way. It is easy to say filter them all (above a certain load level) however that is prohibitive in terms of filter cost and warts added.

The upside is that it allows you to better understand a network and you can then more intelligently make the decision to add more filters, or devices, to overcome the suckers if required.

[Brian H]

Thanks for the link.

I have found some 120 volt schematics for some of the ones I have used.

[Teken]

Brian,

All CFLs that I have seen are capacitive input devices. A relatively large capacitor is part of their power supply.

Some do incorporate choke coils to reduce their emissions as well as much smaller EMI reduction caps.

 

Here is an interesting site that shows quite a few CFL schematics:

 

http://www.pavouk.org/hw/lamp/en_index.html

 

It is very convenient to now have a device that allows me to quickly and easily check any device to see if it is a sucker before I add it to my network.

 

While doing some testing with the CFLs I spied a plugstrip with (6) various battery chargers plugged into it.

Back in my X-10 days that strip only had 2 or 3 chargers and the number has grown over the years.

 

I tested the entire strip load and found it to be a "2.7" standard Insteon load. A substantial sucker.

I then tested each charger separately. I found that the original chargers did not contribute to the sucking (ones I accumulated during my x-10 days).

 

The newer ones I have added over the years are the issue.

1) The Ryobi 18V lithium charger measured 1.5 standard Insteon loads.

2) A Dremel tool charger measured 1.9 standard Insteon loads.

 

So ideally this would be another place to add a filter. I have not had any issues in this area previously but I now know signal is being sucked at that location.

 

That is a possible downside to being able to quantify signal suckers in this way. It is easy to say filter them all (above a certain load level) however that is prohibitive in terms of filter cost and warts added.

The upside is that it allows you to better understand a network and you can then more intelligently make the decision to add more filters, or devices, to overcome the suckers if required.

 

ELA,

 

Most excellent follow up . . .

[ELA]

Thanks Teken,

I just posted some data on the CFLs in the Smarthome section.

 

 

An update on using my test device for checking communications reliability. And a question for those who have experience with HL and have experimented with communications.

 

As part of this design I incorporated ability to turn on/off the RF communications. This allows me to separate the RF reliability testing from the Power line reliability (within limits). This opens things up to some interesting testing.

 

In my original design I used a on/off toggle message to test the percentage of correct receipts. I did this so that I could be assured that both the on and the off were working, in case of loads that might cause issues only when turned on.

 

I recently added ability to "PING" a device. I did this because I am about to add some Switchlinc Relays for bathroom fans and I did not want to turn them on/off repeatedly during testing. When doing some testing on a test bench I encountered an interesting result that I am unsure of at this point and wanted to ask if anyone might know for sure.

 

In my testing it appeared that: The Ping Command can be sent via RF, and Converted from RF to Power Line, but not responded to directly via RF?

 

Test 1) When a dual band PLM transmits (from a Power Line isolated network, RF only) to a single dual band lamplinc (in another outlet that is also PL electrically isolated) all the on/off commands work but not the Ping command.

 

Test 2) When a dual band PLM transmits (from an isolated network, RF only) to a another dual band PLM (in another outlet that is also PL electrically isolated) all the on/off commands work but not the Ping command.

 

Test 3 When a dual band PLM transmits (from an isolated network, RF only) to a PL only ApplianceLinc -via a-> dual band lamplinc (both in another outlet that is also PL electrically isolated from the PLM) Now the Ping Command works.

 

So it appears as though the Ping Command can be sent via RF, and Converted from RF to Power Line, but not responded to -directly via RF?

 

Is this true?

 

I understand that RF only devices would not respond as they are asleep, to conserve battery, and would not wake up to respond.

But when a device is dual band I would expect it to be able to respond directly via RF since it is awake and there are no battery life considerations?

 

Is this a leave-over from RF only devices, now incorporated into dual band devices?

 

I am curious if anyone else has encountered this as I do not consider my tests as totally conclusive as of yet?

 

It is probably not a big deal as devices will normally have both paths to work with in a typical home network. This only comes into play if a particular dual band device is in an area of marginal powerline communications and is reliant on the RF comm to get messages through.

 

In addition it only appears to affect the PING command. Normal on/off commands worked fine. ??

 

I apologize if this is difficult to follow as I was having a hard time putting it to words.

[ELA]

I was doing some testing of a new 2nd prototype test device today.

I was communicating between my test PLM and a dual band Lamplinc. I made sure that the Lamplinc was isolated from the PLM in terms of power line communications.

The two could only exchange messages via RF.

 

I put the Lamplinc only 10ft away from the PLM, but line of sight was blocked by a row of metal file cabinets. The two would not communicate, all messages failed.

As I got up and approached the Lamplinc to Unplug it I saw the status led blink and realized a message had gotten through. When I went to check the log at the PLM (behind the cabinets) I could now see that no messages were getting through anymore but two had as I moved about. These two were when my body changed the transmission paths.

 

I was able to move just a few feet to a position where my body "appeared to serve as a reflector" to complete the RF path to the Lamplinc and all messages would get through.

 

I am finding it quite interesting as I have observed the ability of my body placement to affect RF communications twice now in two different test scenarios.

 

Nothing conclusive but interesting.

As I think about it now the orientation of the antennas relative to each other were not optimum (totally parallel to each other) and may make a difference in future testing.

[Brian H]

From the internal photos on the FCC web site.

 

2443 Hardware Revision 2 Access Point and 2413S/U PLM.

Two antennas. From the bottom of the board. One up the left side and one up the right side.

 

2443 Hardware Revision 1 Access Point.

Two antennas.

On the daughter card.

PC runs. From the bottom of the board. One up the left side and one up the right side.

 

2477D SwitchLinc Dimmer.

One antenna wire running from the top of the board down the side where the Red Load wire exits.

[ELA]

Thanks Brian,

I am intimately familiar with the 2413 PLMs internal configuration as I have been dis-assembling and re-assembling several over the past year.

 

From your information I would assume they attempt to keep all antennas vertical so as to be parallel to each other in normal operation.

Even though RF is not my strong suit I suspect that antennas that are not in the same (parallel) orientation become less effective.

 

What I meant was that in my testing I did not pay particular attention to keeping the test PLM vertically oriented and this may have helped make the RF links marginal.

I will experiment with that more again in the future out of curiosity.

[Brian H]

Yes keeping all the antennas in the same plane would be best.

Well that is if my rusty RF theory from when I worked for Motorola Communications, is correct.

[ELA]

With my second test device up and running I am learning fun new things. It is very cool how this device allows you to "characterize" your network.

I now have a map of all circuits / receptacles in terms of how difficult the transmitter has to work vs what level of received message is present at each location.

 

While building this map I found that my first prototype did not have a broad enough measurement range capability for all the various loads present in my network. From the maxed out readings I knew there were signal sucker issues that need to be addressed. Before I addressed them I wanted to build the second unit with a broader measurement range capability for more accurate map recordings before I added new devices or filterlincs.

 

In a past post I reported on how my Master Bedroom has three major signal suckers that did not appear to matter much since I did not have any Insteon devices on that particular circuit as of yet. With the new range capability of the second unit I could see that while these signal suckers were not of concern in the bedroom (no Insteon devices), this heavy sucking load was "reflected" all the way back to the service cabinet and made for a very large "suck factor" on that phase (leg) over the other phase.

 

What this points to is the importance of exactly where large signal suckers are located in the system. Even though they may not be of local concern there combined influence on the entire network can be making other areas marginal as well. This is especially true if the suckers are located at the very first receptacle, where the home run to the service lands.

 

As point of reference I will use the same measurement method as in other posts:

 

Phase(Leg) A, Measured at the Service location : Measured 8.9 standard Insteon loads

Phase(Leg) B, Measured at the Service location: Measured 5.7 standard Insteon loads

 

When I unplugged the three signal suckers in the bedroom, the Phase A leg now measured:

5.2 standard Insteon loads. This puts it more in line with the other leg.

 

I will now be adding some devices to the Master Bedroom and will work out what combination of Filtering vs/ dual band devices might be the best solution.

I have no doubt however that the first sucker off of the home run will get a filterlinc.

 

Using this technique I have also confirmed that my Refrigerator is a large sucker. It is also the first receptacle on that circuits home run. It is causing all down stream outlets to appear as a very large suck vortex 9.0 standard Insteon loads..

At present I do not have any Insteon devices on that circuit but I do intend to remove the Refrigerator someday when I am feeling ambitious and characterize it directly. AS well as to add a 20A filter to it at that time.

[junkycosmos]

Wow great topic.

 

Off hand the largest communicaiton issues I stumbled by way through fixing were from 3 very old GFCI outlets in the bathrooms. They clearly were original from early 80s and communciations were drastically improved when they were replaced. Just wish I found them via a test tool instead of by accident after a years worth of frustration. Other issues I still continue to find coming back to strange ways neutrals are run thanks to lots of orginal 3 and 4 way wiring. All that aside from the SH created issues of v5 etc etc

 

I too would be interested in a parts list/wiring diagram/software package to recover some of the investment.

 

Keep up the great work.

[ELA]

Thanks Junkycosmos,

I have never experienced a GFCI contributing to a communication issue directly myself. While I have seen it mentioned in some other posts I have never read any direct proof that they were the "true" issue. I am quite familiar with the current design of GFCI outlets and the Leviton devices I have tested do not signal suck or introduce any noise that I have been able to measure.

 

I would be interested in hearing of testing details as to why a GFCI was causing issues. I guess it could be possible that older designs may have had an across the line cap for noise filtering but newer units do not.

 

In your experience were the GFCIs a constant "signal sucking load", or noise source on the system, or did they degrade over time?

I guess it could also be possible that their internal contacts could cause issues, but then I would expect problems with load connected 60 hz loads.

I certainly could see them causing issues if they were so bad that the contacts arched (that should have caused obvious issues with connected loads though).

 

With the device I have been developing you can very easily identify signal suckers and eliminate any guess work there.

[ELA]

I have progressed and added communications reliability testing with some recent enhancements. The device now will repeatedly send and receive messages and track not only the percentage of completed exchanges, but also note how many hops are being used and whether or not retries are being required.

 

I have found marginal communications situations where messages will show a 100% exchange rate yet the communications could still be marginal.

Testing for a longer period or on a different day the exchange rate might drop off to a slightly lower rate.

The device can now show that even though you may be getting 100% of the messages through, it may be with the aid of all the hops as well as retries.

This can make for a very marginal condition.

 

I have just such a condition present in my home network now. I have had comm issues with my original keypadlinc (hardware ver 1.4, firmware ver29) for a long time. This keypadlinc will occasionally get failed responses in the ISY99. Then when queried again it will appear just fine.

This has been a minor nuisance but now that I can I am investigating it in detail.

 

By using an earlier version of this tester ( I may refer to it as the ELAM for clarity going forward) I was able to record the fact that it would occasionally communicate at less than a 100% success rate. This being one particular days testing. Then on another day it would show 100%. After making the recent changes in monitoring I am now seeing that even though it may be getting 100% message exchange rate it will be using retries in order to do that.

 

I then compared the keypadlinc to three other devices slightly downstream from the keypadlinc. These three other devices were 100% with no retries!

 

This then prompted me to get the Oscope out in order to probe deeper. I took several captures of the retry events. I also compared the signal levels of the suspect keypadlinc to a nearby outletlinc.

 

Here are several captures compared: ( I know it is busy and may be difficult to follow. But if you can review it, it is interesting)

NOTE: these are not totally direct comparisons since all traces were not simultaneously taken. They are intended to be able to see the trend only.

 

 

Up until now I have been tempted to just replace this Keypadlinc. I do not feel there are signal sucker or noise issues at play here. I suspect one of two things. 1) The keypadlinc is intermittently defective. 2) The keypadlinc does not play nicely with other nearby devices (there are two switchlincs very close to it). Meaning that the simulcast feature is not working as it should, either due to the keypadlinc not "syncing" to other devices or some strange and as of yet unexplained interaction between devices.

 

I have always wondered about the infamous v35 firmware issue and if it might not pertain to other versions? I do think this device may have been causing issues from day one but I do not know that for sure. I searched once again on v35 issues to see if it had ever been explained fully at a technical level.

Was it causing v35 devices to be out of "sync" on hops? thus resulting in poor performance for itself and also affecting other communications as well?

 

I intend to do one more test where I power gap the other two nearby devices ( within 2 ft) and rerun some testing. If the Keypadlinc still has issues I will then order a replacement.

 

If anyone with a good eye for reviewing Insteon comm. signal traces should see something of interest I may have missed I would appreciate any input?

 

As I see it the keypadlinc is intermittently failing to "sync up" with other devices on its hops. This results in too low of a signal level being returned to the sender on the ack message.

This can be seen by comparing to the nearby outletlincs hops levels.

 

added this to help understanding of test conditions: