Timothy J. Weber wrote: > :) I'm fading in lights over a 10-minute period, and even 256 levels = > gives perceptible jumps - but only just perceptible, and probably only = > to me, so I called it done. wow, so slowly? well, yes, then this changes things a bit :) Me do that in some 1 second or so. Which is your application? > And in general, it seems like so far the popular (or extant) application = > protocols have been tied to a specific physical layer. ZigBee proposes = > its own "profiles" for dealing with various kinds of data, but they're = > specific to ZigBee. I think X10 is similar. Yeah > KNX seems to be an exception, in that it supports several physical = > media. But it requires ISO 9001 compliance and product certification - = > which is probably good for a pure commercial market, but not exactly = > accessible for the open-source community. Never dealt with it, motly because of the bureaucracy involved, right. > ONE-NET is one completely open-source standard, but it's also specific = > to one physical layer (its own RF spec). And it doesn't seem very active. I don't know it, should take a look. > LonWorks is also open-source, but uses its own wired physical spec. Its = > profile list is pretty comprehensive, though, and freely available: = > I probably looked at it some time ago. > Yes - I meant what's the "repeated frame" thing? Repeating until you = > get an ACK, or...? Basically, one of my latest "obscure holes" in my protocol (2005 or so). I.e., what happens when the receiver has received the command (or frame) = and executed tha action, and ACK'ed, but the Transmitter does not see = the ACK? It will try again, and the receiver will execute again... and = if it is SET -> no problem, but if it is a Toggle -> troubles! Adding Frame Counter Field (something I throw in already before, but was = not using it - of course TCP would've had it long since!) made the = receiver recognize if the command was a new one or simply the same as = before: the receiver will ACK it again, but not execute or store it. > Very nice! I'd be interested to hear how well SNMP integrates with the = > rest of your system. Oh, Classes. I have developed my USB->485 and RF router with a BSD-like Socket layer = (more than one, in the end). So, Devices are built on top of that: you "open a file to the LCD panel" = in order to send it Text; you Read data from the Temperature sensor = using a Read function. The class knows where the data is located and = handles the incoming bytes, converts them to, say, =B0C values, and = returns them. I have a Power-measurer class, which is based on CS5460 from Crystal. It = is connected to the SPI port of one remote device: I guess I'll make = that class smart and let it use SNMP in place of SPI/5460 in order to do = that. I'll let you know! -- = Ciao, Dario -- ADPM Synthesis sas -- http://www.adpm.tk -- = http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist