Intermittent Comm Problem (also how do I read level 3 log)

[Vyrolan]

I just moved my PLM/ISY because I wanted my ISY near my IR distribution and have started to have some communications issues. The move puts the PLM on a different breaker than any other Insteon device in my place. Before I had my PLM on the same breaker as about 80% of my devices. I want it in this new location, but I'll have to figure out the comm issues.

 

Here is a level 3 event log of me just toggling a Switchlinc Relay on and off (via ISY admin console) until there was a communications error. After the error, I just clicked again and it worked.

Thu 12/13/2012 08:35:17 PM : [iNST-TX-I1  ] 02 62 1F BA 42 0F 11 FF
Thu 12/13/2012 08:35:17 PM : [iNST-ACK    ] 02 62 1F.BA.42 0F 11 FF 06          LTONRR (FF)
Thu 12/13/2012 08:35:18 PM : [iNST-SRX    ] 02 50 1F.BA.42 1E.46.16 2B 11 FF    LTONRR (FF)
Thu 12/13/2012 08:35:18 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Thu 12/13/2012 08:35:18 PM : [  1F BA 42 1]       ST 255
Thu 12/13/2012 08:35:24 PM : [iNST-TX-I1  ] 02 62 1F BA 42 0F 13 00
Thu 12/13/2012 08:35:24 PM : [iNST-ACK    ] 02 62 1F.BA.42 0F 13 00 06          LTOFFRR(00)
Thu 12/13/2012 08:35:26 PM : [iNST-SRX    ] 02 50 1F.BA.42 1E.46.16 2B 13 00    LTOFFRR(00)
Thu 12/13/2012 08:35:26 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Thu 12/13/2012 08:35:26 PM : [  1F BA 42 1]       ST   0
Thu 12/13/2012 08:35:35 PM : [iNST-TX-I1  ] 02 62 1F BA 42 0F 11 FF
Thu 12/13/2012 08:35:35 PM : [iNST-ACK    ] 02 62 1F.BA.42 0F 11 FF 06          LTONRR (FF)
Thu 12/13/2012 08:35:36 PM : [iNST-SRX    ] 02 50 1F.BA.42 1E.46.16 27 11 FF    LTONRR (FF)
Thu 12/13/2012 08:35:36 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=1
Thu 12/13/2012 08:35:36 PM : [  1F BA 42 1]       ST 255
Thu 12/13/2012 08:35:47 PM : [iNST-TX-I1  ] 02 62 1F BA 42 0F 13 00
Thu 12/13/2012 08:35:47 PM : [iNST-ACK    ] 02 62 1F.BA.42 0F 13 00 06          LTOFFRR(00)
Thu 12/13/2012 08:35:50 PM : [  1F BA 42 1]      ERR   1
Thu 12/13/2012 08:35:57 PM : [iNST-TX-I1  ] 02 62 1F BA 42 0F 13 00
Thu 12/13/2012 08:35:57 PM : [iNST-ACK    ] 02 62 1F.BA.42 0F 13 00 06          LTOFFRR(00)
Thu 12/13/2012 08:36:00 PM : [iNST-SRX    ] 02 50 1F.BA.42 1E.46.16 2B 13 00    LTOFFRR(00)
Thu 12/13/2012 08:36:00 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Thu 12/13/2012 08:36:00 PM : [  1F BA 42 1]      ERR   0
Thu 12/13/2012 08:36:00 PM : [  1F BA 42 1]       ST   0
Thu 12/13/2012 08:36:00 PM : [iNST-SRX    ] 02 50 1F.BA.42 1E.46.16 23 13 00    LTOFFRR(00)
Thu 12/13/2012 08:36:00 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

 

How does this look to everyone? The PLM is dual-band and it is about 6 feet from some dual-band switches on a different circuit, but there's probably a lot of RF interference in that 6 feet based on the other stuff around the PLM in this new location. Can you tell from the log if it is using powerline or RF? In general I'd like to know how to read this log and understand what's happening. If it's using RF, I doubt it's going to be very reliable and I'll probably accelerate plans to change out other switches near there to improve its communications.

 

Also, the PLM is now plugged into an outlet right next to a power strip. There's two sets of outlets side by side, and the three devices plugged in are the PLM, a basic surge protector from Ace Hardware, and then the Panamax power conditioner for our home theater. I would think the power conditioner isn't too bad about noise considering that's its whole purpose, but I dunno about the surge protector. Should I filterlinc the simple surge protector? If I add other dual-band devices near the PLM, will it help or am I just off on that assumption?

[LeeG]

The variation in Hops Left=x count within a few seconds is a good indication of powerline issues. There is nothing in a trace that indicates how much RF versus powerline is used for any given message flow. The RF aspect of the Insteon mesh network is not under ISY control.

 

Standard things to start with. Put all things electronic other than the PLM on a FilterLinc. Powerline issues can be noise or signal attenuation. Do the 4 tap Set button test to verify good phase coupling. I prefer two Access Points for this. Watch the PLM LED to see how it reacts to the phase coupling test.

 

Thu 12/13/2012 08:35:26 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Thu 12/13/2012 08:35:36 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=1

Thu 12/13/2012 08:36:00 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Thu 12/13/2012 08:36:00 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

[Vyrolan]

The variation in Hops Left=x count within a few seconds is a good indication of powerline issues. There is nothing in a trace that indicates how much RF versus powerline is used for any given message flow. The RF aspect of the Insteon mesh network is not under ISY control.

Thanks LeeG. Is there any spec/docs about the log messages to better understand them?

 

Standard things to start with. Put all things electronic other than the PLM on a FilterLinc. Powerline issues can be noise or signal attenuation. Do the 4 tap Set button test to verify good phase coupling. I prefer two Access Points for this. Watch the PLM LED to see how it reacts to the phase coupling test.

I did the phase detection...turns out I do have both phases covered. I have all my Insteon devices on only two breakers and those two breakers are on opposite phases. They have 6 and 4 dual-band devices respectively. Now the PLM is on a third breaker that is on the first phase. The test log I gave is actually from a device on the same phase. So it seems clear that signal sucking or noise from the other stuff plugged in there is the problem. I will order some Filterlincs and hopefully that clears up the problem. While waiting on their delivery, I'll confirm my performance gets better if I unplug either or both of the power strips.

[LeeG]

There is an old insteondetails.pdf document on the insteon.net web site. It was published in 2007 but the basic Insteon message structure still applies. This link may provide some useful information. The user has been accumulating information on various aspects of Insteon.

 

http://www.madreporite.com/insteon/Inst ... e_list.htm

[Vyrolan]

So as a test, I just moved the simple Ace Hardware surge protector to a different socket. Before it was on the same outlet pair as the PLM. Now both power strips are on one pair, and the PLM is alone on the other. A small difference but it has helped. I was able to switch the same light as from my first post back and forth about 12 times without it ever failing. Before it was failing at least 1 in 4. The hops left were still bouncing around and were sometimes 0...so it's definitely still close to failing. I ordered some filterlincs and hopefully that will fully resolve it, but just moving it to the other outlet will hopefully let me limp along "good enough" until they arrive. Huzzah!

 

 

There is an old insteondetails.pdf document on the insteon.net web site. It was published in 2007 but the basic Insteon message structure still applies. This link may provide some useful information. The user has been accumulating information on various aspects of Insteon.

 

http://www.madreporite.com/insteon/Inst ... e_list.htm

Cool. I think I've seen this link before...I'll bookmark it this time. Thanks again.

[LeeG]

The problem is not solved with the varying Hops Left count but moving the power strips away even a little has improved the failure rate substantially. There could be other sources of noise or signal attenuation. However, getting things the best they can be where the signals originate is always a good place to start. Post back the results once the FilterLinc(s) are in place.

[Vyrolan]

I spoke too soon...it actually still fails pretty badly to devices further away. It basically never fails on a switch near the beginning of a circuit (defining the beginning as close to the circuit breaker), but it fails almost always on a switch further down the same circuit. That's the noise causing the problem, right?

[LeeG]

I suspect it has more to do with signal attenuation (signal sucker) than noise but the FilterLinc should resolve either problem.

[Vyrolan]

Ok...swapped back to a simple power strip...one that is not a surge protector. That has helped. It is now reaching all my devices again, but occasionally dips to 0 hops left so still borderline.

 

I suspect it has more to do with signal attenuation (signal sucker) than noise but the FilterLinc should resolve either problem.

Sounds good...I'll put one on both of them assuming the filterlincs fit in there. =p For now, I better stop messing with it before I get so crazy I cancel my order and reorder with overnight shipping. =p

[ELA]

 

Also, the PLM is now plugged into an outlet right next to a power strip. There's two sets of outlets side by side, and the three devices plugged in are the PLM, a basic surge protector from Ace Hardware, and then the Panamax power conditioner for our home theater. I would think the power conditioner isn't too bad about noise considering that's its whole purpose, but I dunno about the surge protector. Should I filterlinc the simple surge protector? If I add other dual-band devices near the PLM, will it help or am I just off on that assumption?

 

Hello Vyrolan,

 

Sounds like you are on the right track with filtering. Even though the Panamax is designed to protect its loads that does not mean it might not be a signal sucker on its line side.

When you get your filters consider a test filtering it as well ( if the load is within the filterlincs rating).

As LeeG mentioned, in my experience there are more issues with signal suckers than noise generators.

 

Also you said your PLM is on a third circuit? How far away from the service cabinet is the PLM ( approx. cable length)?

[Vyrolan]

Sounds like you are on the right track with filtering. Even though the Panamax is designed to protect its loads that does not mean it might not be a signal sucker on its line side.

When you get your filters consider a test filtering it as well ( if the load is within the filterlincs rating).

As LeeG mentioned, in my experience there are more issues with signal suckers than noise generators.

Yea I bought enough filterlincs to have one for it too. I'll have to check the specs I'm not sure what the rating is on the conditioner but I was worried about that as well. I also have our sub on another outlet further down the circuit. It may be noisy as well.

 

Also you said your PLM is on a third circuit? How far away from the service cabinet is the PLM ( approx. cable length)?

I'd estimate around 30ft of cable to those outlets assuming the pathing is fairly direct which it probably is based on what else I've seen. Those outlets are probably the first ones on that circuit as well. Nothing between them and the breaker box.

[Vyrolan]

Even though the Panamax is designed to protect its loads that does not mean it might not be a signal sucker on its line side.

When you get your filters consider a test filtering it as well ( if the load is within the filterlincs rating).

Yea I bought enough filterlincs to have one for it too. I'll have to check the specs I'm not sure what the rating is on the conditioner but I was worried about that as well.

Well, the Filterlinc supports up to 10A....the Panamax supports up to 15A. If everything plugged into the panamax were on and running full, it would be at like 10.50A That's excessively unlikely though. That would be both DirecTV boxes turned on, both gaming consoles (xbox/ps3) turned on, the bluray player turned on, and the receiver running all amps at max volume. We only have 5.1, so at least 2 amps are unused always, and it's excessively unlikely that 2 people with 4 TVs are using all 5 sources simultaneously. So I think it's probably safely under the 10A limit for the Filterlinc.

[Brian H]

Filterlinc would probably be OK.

It does have a soldered in 10 amp slow blow fuse in it.

[IndyMike]

I apologize for the rewind, but I'm trying to come back up to speed on the Event Viewer after a hiatus.

 

I don't understand the last communication from Vyrolan's SWL in the log below. Why would the SWL retransmit the Ack? Is there something new in the protocol where the SWL requires an Acknowledge to it's Acknowledge?

 

 

Thu 12/13/2012 08:35:57 PM : [iNST-TX-I1 ] 02 62 1F BA 42 0F 13 00

Thu 12/13/2012 08:35:57 PM : [iNST-ACK ] 02 62 1F.BA.42 0F 13 00 06 LTOFFRR(00)

Thu 12/13/2012 08:36:00 PM : [iNST-SRX ] 02 50 1F.BA.42 1E.46.16 2B 13 00 LTOFFRR(00)

Thu 12/13/2012 08:36:00 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Thu 12/13/2012 08:36:00 PM : [ 1F BA 42 1] ERR 0

Thu 12/13/2012 08:36:00 PM : [ 1F BA 42 1] ST 0

Thu 12/13/2012 08:36:00 PM : [iNST-SRX ] 02 50 1F.BA.42 1E.46.16 23 13 00 LTOFFRR(00)

Thu 12/13/2012 08:36:00 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

 

 

[LeeG]

IM

 

I have been assuming when this is seen it results from the Insteon mesh network having more than one copy of the same message. Perhaps one powerline based, one RF based? The message noted is an ACK which is not normally be retransmitted by the Responder. Also the Hops Left count is 0 in the second ACK which makes me think the path of that message took longer to get to the PLM than the first ACK. I'm thinking the PLM deals with this more than we realize, normally ignoring the duplicate. This time it concludes it is not a duplicate, rather an ACK that should be passed to the application. All pure guess work.

 

I would enjoy hearing other opinions/views of what causes this.

[IndyMike]

Lee,

 

Thank you. Your hypothesis seems to fit the information available. It may also explain why I don't see this in my system using the 2412S PLM (powerline only).

 

I'm now wondering whether this was a concurrent RF transmission that the PLM separated out (for some reason).

or...

This was a mesh unit that saw RF/Powerline traffic and waited for a later time slot to avoid a possible collision.

 

I have seen some evidence of "late responders" while watching the powerline with my scope. The PLM does not seem to pass this information to the ISY and I've never been able to isolate the transmission to a specific device.

 

More questions:

1) Since the SWL Relay that Vyrolan is using is NOT dual band, can we assume that the response below with 2 HOPs remaining came over the powerline? Said differently, if a accesspoint picked up the powerline transmission from the SWL and relayed to the PLM, wouldn't that burn 1 hop?

2) If the SWL Relay were a dual band device and communicated directly to the PLM via RF, would the PLM indicate 2 or 1 Hops remaining?

 

Thu 12/13/2012 08:35:17 PM : [iNST-TX-I1 ] 02 62 1F BA 42 0F 11 FF

Thu 12/13/2012 08:35:17 PM : [iNST-ACK ] 02 62 1F.BA.42 0F 11 FF 06 LTONRR (FF)

Thu 12/13/2012 08:35:18 PM : [iNST-SRX ] 02 50 1F.BA.42 1E.46.16 2B 11 FF LTONRR (FF)

Thu 12/13/2012 08:35:18 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

 

Sorry for all the questions. After 7 years of using Insteon I've found myself needing an education on the DualBand and I2CS devices. I'm trying to proceed cautiously.

 

Thanks,

IM

[LeeG]

Not sure about #1 but I think it does. I had to add a dual band device next to a new KPL (not dual band) and it shows an extra hop count used which I take to be the relay through the dual band device.

 

For #2 I used a RemoteLinc2 next to the 2413 Dual Band PLM and it shows hops left=2 for the RL2 button press. I assume (bad bad) the SWL Dual Band would work the same way if it is in range of the PLM.

 

There is so much about all this increase in RF activity with the advent of so many Dual Band devices that I am not sure about. Wish there was a way to identify how much RF plays in any give message flow.

[ELA]

I experienced duplicate responses passed up from the PLM in test development of my test device. It occurred when the communications was marginal.

Sometimes the second message would be an exact copy and sometime the second message would be close but corrupted in some way.

 

In my tester the messages are time stamped to the millisecond. This allows you to clearly see that the second message took longer to arrive, as is of course presumed by the hops remaining being lower.

 

Without access to the Insteon firmware I have no clue as to why this happens, but in my experience it has been when communications is marginal to begin with. I have always suspected that sometimes a device "tries too hard" and digs messages out of the noise floor. When this happens I could only speculate that this puts the microcontroller into a loop not normally encountered and timing allows duplicate messages to be passed up to the host?

[IndyMike]

Lee,

 

Thank you yet again for the tests and analysis. I understand your test, and caution, using the RL2. I really wish SmartLabs would grace us with an updated Insteon protocol/white paper. It would seem that the benefits they would gain from the "community" understanding how current devices interact would be huge.

 

If not for issues with my older I1 devices, I would try one of my 2413S dual band PLMs. At this point I still have too many of the I1 units installed to risk it.

 

Thank you again,

IM

[IndyMike]

Hello ELA,

 

It's been awhile... Once again you've awakened some of my dormant memory.

 

I experienced duplicate responses passed up from the PLM in test development of my test device. It occurred when the communications was marginal.

Sometimes the second message would be an exact copy and sometime the second message would be close but corrupted in some way.

 

Thu 12/13/2012 08:35:57 PM : [iNST-TX-I1 ] 02 62 1F BA 42 0F 13 00

Thu 12/13/2012 08:35:57 PM : [iNST-ACK ] 02 62 1F.BA.42 0F 13 00 06 LTOFFRR(00)

Thu 12/13/2012 08:36:00 PM : [iNST-SRX ] 02 50 1F.BA.42 1E.46.16 2B 13 00 LTOFFRR(00)

Thu 12/13/2012 08:36:00 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Thu 12/13/2012 08:36:00 PM : [ 1F BA 42 1] ERR 0

Thu 12/13/2012 08:36:00 PM : [ 1F BA 42 1] ST 0

Thu 12/13/2012 08:36:00 PM : [iNST-SRX ] 02 50 1F.BA.42 1E.46.16 23 13 00 LTOFFRR(00)

Thu 12/13/2012 08:36:00 PM : [std-Direct Ack] 1F.BA.42-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

In the instance cited, the device responded with 2 hops remaining, but after a period of 3 seconds. While we are not able to infer signal level from this response, the timing suggests that there may have been PLM retries involved. In short, you may be correct regarding the marginal communications.

 

I do remember seeing repeated messages passed to the Host with tests of my 2413S PLM. I do not remember seeing a 2412S pass repeated messages to the Host. From this I inferred (possible incorrectly) that the second message was a RF "echo". It is entirely possible that this simply due to a firmware difference between the two devices.

 

In my tester the messages are time stamped to the millisecond. This allows you to clearly see that the second message took longer to arrive, as is of course presumed by the hops remaining being lower.

 

I'm confused by the above. Was the second message delivered "outside" the normal Insteon communication window?

 

Without access to the Insteon firmware I have no clue as to why this happens, but in my experience it has been when communications is marginal to begin with. I have always suspected that sometimes a device "tries too hard" and digs messages out of the noise floor. When this happens I could only speculate that this puts the microcontroller into a loop not normally encountered and timing allows duplicate messages to be passed up to the host?

 

I might be able to understand the above with my environment using the 2412S PLM. I do not understand it when using a 2413S dual band unit with "many" RF devices as in Vryolan's install. It implies that dual band devices have a preference for powerline signals over RF. I'll agree that it fits the evidence that I've observed with my own 2413S/dual band LL's using Houselinc. I simply don't understand why SL would have configured the firmware on "newer" units in this manner given their move to dual band modules. If they are making the concession that the powerline is often corrupted, wouldn't they reverse the preference toward RF?

 

I was hoping that the newer dual band I2CS devices/newer PLM's were configured to eliminate my observed preference for powerline transmission. Unfortunately, recent problems posted on this forum involve multiple cases where communication problems were only resolved after installing a filter on the 2413S, thereby forcing it to rely on RF only.

 

Once again, it sure would be nice to have some details on the device implementation. I firmly believe that with this knowledge, members of this forum would provide an invaluable service to SmartLabs.

 

Vryolan,

My apologies for hijacking your post.

 

IM

[ELA]

Hello IndyMike,

 

I agree with your comment that retries may have preceded the first response you highlighted.

 

My comment about logging message timing to the milliseconds was with regard to the the second message received ( hops left = 0) that was a duplicate. All I was trying to say was that with a finer resolution message timer ( sub 1 second values) you can then better gauge what happened when. A finer resolution tool in addition to the hops remaining value.

 

I really have no clue as to what role RF vs. PL may play since we do not have access to more details as you said.

 

Having a millisecond message timer does allow you to better define when retries have occurred. My tester reports the number of retires involved in each receipt.

 

I do believe there is some issue with these devices as I stated with regard to trying too hard to pick a message out of the noise floor. I have often seen where the initial send is received in a corrupted form or not at all. Most likely due to a very marginal signal strength as viewed on the Oscope. Yet subsequent hops signal strengths are very strong, due to multiple repeaters, yet the exchange still fails. Either the simulcast timing is poor resulting in a non valid hops receipt, or the micro-controller has vectored off into a non standard loop such that is is not available to receive the subsequent "good hops"?

[Vyrolan]

1) Since the SWL Relay that Vyrolan is using is NOT dual band, can we assume that the response below with 2 HOPs remaining came over the powerline? Said differently, if a accesspoint picked up the powerline transmission from the SWL and relayed to the PLM, wouldn't that burn 1 hop?

The switchlinc from my test to start the thread is a dual-band one.

 

 

I might be able to understand the above with my environment using the 2412S PLM. I do not understand it when using a 2413S dual band unit with "many" RF devices as in Vryolan's install. It implies that dual band devices have a preference for powerline signals over RF. I'll agree that it fits the evidence that I've observed with my own 2413S/dual band LL's using Houselinc. I simply don't understand why SL would have configured the firmware on "newer" units in this manner given their move to dual band modules. If they are making the concession that the powerline is often corrupted, wouldn't they reverse the preference toward RF?

TBH, I prefer powerline over RF. I guess I prefer dual-band because it should help automagically fill in some holes, but the bulk of my system I'd want to work reliably on the powerline. I like having RF integrated mostly for the wireless stuff. Maybe I'm crazy, but it seems like powerline disruptions are easier to deal with than RF. You have filterlincs and clearer sources of noise. On the RF side, it can be really hard to figure out.

 

 

 

As for my situation, I've just moved ISY and PLM back to their original location for now. Our AV receiver started acting up, and I was wondering if somehow the Insteon stuff was messing with it (even though that seems excessively unlikely). But it seems that it (the AVR) has just shit the bed so I have to return it. I still plan to put ISY and PLM back in that location once I have the filterlincs. I'll report back and show some traces once the filters are in place.

[IndyMike]

ELA,

 

We tend to view things from a bit different perspective. Nonetheless, the result is the same:

 

1) Communications received with a low or non-existent initial transmission, and with good levels on the hops, are sometimes rejected by the PLM.

2) Given that there is powerline communication present, the PLM will ignore any RF communication present (purely my observation).

3) The only way to force the PLM to use RF communication is to isolate it from the powerline (again my observations).

[ELA]

ELA,

We tend to view things from a bit different perspective. Nonetheless, the result is the same:

 

IndyMike,

Wouldn't it be a drag if we were all the same

 

 

1) Communications received a low or non-existent initial transmission and with good levels on the hops are sometimes rejected by the PLM.

Would you please explain what you meant by non-existent? I have never seen a message exchange that was totally missing an initial send (or hop 0)? There are instances where it might appear to be buried in the noise floor?

 

2) Given that there is powerline communication present, the PLM will ignore any RF communication present (purely my observation).

This is interesting. Understood that you say it is your observation.

Something I have never attempted to investigate and now I am curious. What lead you to this conclusion? How would one test for this or even suspect?

 

3) The only way to force the PLM to use RF communication is to isolate it from the powerline (again my observations).

I am not aware of any way to force RF in the PLM without using an isolator. I do have an option to disable the RF in my testers PLM.

If one could say that this is then the equivalent of the 2412?, I have experienced these duplicate or what I call "Extraneous" messages when the PLMs RF is disabled.

However there were other dual band devices at play ( possible repeaters) during that testing so the RF still would not be discounted as a contributor to the extraneous message.

 

I was searching my archives of message logging when testing and here is one example I found of an Extraneous message. This example shows what I was attempting to explain about the millisecond message timer. If this was the ISY the two messages would likely be time stamped with the same 1 second resolution time.

Here you can see that the second replay(3rd) message occurred approx. 1 standard message time slot later.

2 62 3 e6 91 0 d 0 6
             Hops, Max : Remaining   0 : 0 
2 50 3 e6 91 18 d4 d4 20 d 0
             Hops, Max : Remaining   0 : 0 
2 50 3 e6 91 18 d4 d4 27 f2 c0
             Hops, Max : Remaining   3 : 1 
Msg2 Rcv Time:   111 
Msg3 Rcv Time:   161 

 

The initial send was with zero hops. Times are in milliseconds.

[IndyMike]

1) Communications received a low or non-existent initial transmission and with good levels on the hops are sometimes rejected by the PLM.

Would you please explain what you meant by non-existent? I have never seen a message exchange that was totally missing an initial send (or hop 0)? There are instances where it might appear to be buried in the noise floor?

Bad choice of words - below the noise floor was intended.

2) Given that there is powerline communication present, the PLM will ignore any RF communication present (purely my observation).

This is interesting. Understood that you say it is your observation.

Something I have never attempted to investigate and now I am curious. What lead you to this conclusion? How would one test for this or even suspect?

1) Observations of posts on this forum. I've seen numerous instances where isolating the PLM (forcing RF) fixed communication problems. My take here is that there is sufficient powerline signal present in the initial transmission to effectively shut down the RF (powerline preference by the modules). Once the PLM was filtered, the first transmission was RF and was picked up/transceived by multiple dualband units resulting in a much higher powerline signal.

 

2) My own tests on a heavily loaded circuit (8 Insteon loads + accesspoint). I began applying loading upstream by inserting across the line caps - communications steadily degraded despite the presence of the accesspoint. Ran out of caps - plugged in my HP printer (Large EMI cap) and communications suddenly improved with no observable "initial" transmission on the line.

 

My take is that I loaded the line enough that the accesspoint could no longer detect the initial PLM powerline transmission and reverted to RF. One in this mode, communications were steady at 1 Hop remaining.

I was searching my archives of message logging when testing and here is one example I found of an Extraneous message. This example shows what I was attempting to explain about the millisecond message timer. If this was the ISY the two messages would likely be time stamped with the same 1 second resolution time.

Here you can see that the second replay(3rd) message occurred approx. 1 standard message time slot later.

2 62 3 e6 91 0 d 0 6
             Hops, Max : Remaining   0 : 0 
2 50 3 e6 91 18 d4 d4 20 d 0
             Hops, Max : Remaining   0 : 0 
2 50 3 e6 91 18 d4 d4 27 f2 c0
             Hops, Max : Remaining   3 : 1 
Msg2 Rcv Time:   111 
Msg3 Rcv Time:   161 

 

The initial send was with zero hops. Times are in milliseconds.

While I've seen extraneous messages on the oscilloscope, I've never had a method to decode them. Are you thinking there was a bit slip by one module that resulted in it's believing that the message was sent with 3 Hops? Too bad we don't have access to the checksum.