From: Bill Y. <bil...@co...> - 2010-06-07 14:45:16
|
Charles Sullivan <cws...@tr...> wrote on 05/06/2010 02:26 PM: > On Mon, 26 Apr 2010 08:14:30 -0700 > Marc MERLIN<ma...@me...> wrote: > >> > Actually I should make a new thread on this: >> > >> > On Mon, Apr 26, 2010 at 07:38:54AM -0700, Marc MERLIN wrote: >>> > > Now, I was going to ask why the X10_W800 had all this code when X10_MR26 >>> > > didn't, but I already noticed that my X10_MR26 (which has much better range, >>> > > even with the crappy built in antenna) than I had envisionned, the interface >>> > > code does die after a few hours for me without anything in the debug logs. >>> > > >>> > > I haven't looked in details yet, but do you think the code just dies there >>> > > while trying to complete an incomplete packet, or is it something else? >>> > > >>> > > (as for why I might even care about X10_MR26, I was curious to see how it >>> > > worked compared to X10_W800 since I have both, and there is a bit of a dead >>> > > spot in my house where it's much easier to throw in the MR26 as a secondary >>> > > receiver than to try and get the X10_W800 to reach there without stopping to >>> > > reach other places). >> > >> > I'm sure there has to be some other MR26 users here. From some quick testing >> > of the current svn code it looks like some incomplete packet might wedge the >> > code and no MR26 data is received anymore (in debug mode) until mh is >> > restarted. >> > >> > Do others see this too? >> > >> > Marc > I haven't used the MR26A a lot recently, but when I did I don't_ever_ recall > receiving incomplete packets. What I did see was a lot of noise pickup - > the packets were all 5 bytes with the correct header and trailer but the > 2 embedded significant bytes were utter trash. > > You might look to see what MH does when it receives MR26A data which doesn't > fit the mould for "standard" X10 RF signals. > > Regards, > Charles Sullivan Sorry for the late reply to this thread (I don't get to my MH mail too frequently nowadays). I did the work on what we can call version two of the W800RF32/MR26A code (Bruce did V1 and it looks like there was some revamping done somewhat recently that we can call V3). The work I did was to add security devices, merge the W800RF32 code and MR26A code together and make it more modular to make it easier to add different kinds of wireless transmitters. The difference between the MR26A and the W800RF32 is that the MR26A only handles wireless devices that generate X10 style codes (i.e. A1 ON). It actively filters out anything that it doesn't recognize. Where the W800RF32 seems to pass everything that it sees through (which is why it works with just about anything you throw at it). Since it is not too picky about what it passes through, it will send through data for random RF noise. Also, I remember that if a button was held down for a very short period of time, the W800RF32 would send multiple events (where the MR26A wouldn't). So, that is the background as to why there is some extra code for the W800RF32. Looking at the code Marc quoted, it looks like the is_within_timeout timeout call is new (V3) and the logic does seem to be reversed from the original V2 code. So, Marc's fix looks good. In terms of the lockups on the MR26A, you might want to go back to the V2 code and see if that works better. That might help narrow down where the problem is (i.e. long standing problem or update related problem). It looks like 2.104 still had the V2 code. Bill |