Searching \ for '[EE] Universal lightweight protocols' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=universal+lightweight
Search entire site for: 'Universal lightweight protocols'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Universal lightweight protocols'
2008\06\20@210405 by Timothy J. Weber

face picon face
>> This at least illustrates my point - which I think is that anyone
>> dabbling with home automation, and perhaps even serious industrial
>> automation developers, eventually needs/wants some kind of
>> infrastructure like this.
>
> I have seen this actually done or at least "proposed" by some big firms
> around. Looks like people took some time :) but then this way of
> thinking got spread - as the the more efficient. Personally, I'd say
> that I was considering Ethernet as the medium of the future (for home
> automation, but take it as car-automation too) back in 1997... but,
> later, I saw that, smaller, more efficient (and less power/resources
> hungry) protocols could act perfectly down there. But, then, you had to
> interface those protocols to other standards and so...

I should clarify - I'm not suggesting that Ethernet is the right
transfer medium for everything, just that it would be handy to have a
library that can support Ethernet *from the workstation* (where it's
easy) for free.

> And, even in 2008, having a "home automation" node, say a dimmer, with a
> Ethernet I/F would be, IMO, a waste of space, power, and complexity.

Agreed.  But, giving it SOME kind of interface (like ZigBee or RS*) is
essential to the "automation" part.  And once you can get that interface
attached to a PC, you can get it anywhere else for free (with a bit of
programming) (!).

> "Scalability" is probably the right word.

Right.

> Maybe that some "tailoring" will always be needed, i.e. it can be
> somewhat easy to embed a 485 packet (or, for that matters, a X10 frame
> or a Zigbee frame) into a UDP datagram... but requesting a value from a
> Meteo-Station via a HTTP query is less-likely to be standard. Or maybe
> it's just because no one has standardized it yet!

Yes - it's of course possible to propose a standard dictionary for
certain kinds of values, and you could come up with a set for weather
stations as an example.  I have a dictionary of values I'm interested
in, you do too I'm sure.  Perhaps some of them are truly universal, like
a "light level" from 0-255... but maybe you use 16-bit light levels!

And I think having the flexibility to support other devices that aren't
specifically under the "home automation" umbrella would be good too.

So I think trying to standardize the data dictionary side of things is
not the right way to go.  (This is where ZigBee appears to be headed
now, which seems troublesome to me...)

>> Did you find any other options out there worth considering before
>> rolling your own?
>
> Hmmm, I started this home automation thing in 1992, developing some
> Z80-based boards with expansion daughter boards, with I/O @24, 220V and
> such. Then tried Power-line modems (ST7537 from ST and TDA5050...1 from
> Philips) but they were not very good, at least to me. So I started using
> PICs in 2001 and then chose to use RS485: I started out @9600 baud, then
> moved 19200, then 57600 and now 115200.

Neat!  But it sounds like you didn't see anything else attractive for
the protocol layer.

> Writing my own protocol was mostly... fun! But then, you learn a lot
> from your errors and looking at other people's work - for instance, I
> got the "repeated frame" thing attending a Nordic meeting.

What's that?

>> (I've generally discounted X10 and similar as too proprietary and
>> expensive to invest in, especially for someone capable of working with
>> PICs.)
>
> yes, in fact.
> Actually they were also hard to find in Italy, at least back in the 90s
> (where are you located by the way?)

New York State.

BTW, in honor of the summer solstice today, I put together a
solar-powered wireless insolation (solar radiance) meter.  Uses the
protocol I'm talking about above.  Should be graphing the amount of
light getting into my office throughout the weekend; I'll see if it was
working at the moment of the solstice when I go back on Monday.
--
Timothy J. Weber
http://timothyweber.org

2008\06\21@073904 by Dario Greggio

face picon face
Timothy J. Weber wrote:

> I should clarify - I'm not suggesting that Ethernet is the right
> transfer medium for everything, just that it would be handy to have a
> library that can support Ethernet *from the workstation* (where it's
> easy) for free.

no, neither me: I was talking about the "Ethernet physical level" i.e.
RJ, cable, chipser...
agreed on the other part.


>>And, even in 2008, having a "home automation" node, say a dimmer, with a
>>Ethernet I/F would be, IMO, a waste of space, power, and complexity.
>
> Agreed.  But, giving it SOME kind of interface (like ZigBee or RS*) is
> essential to the "automation" part.  And once you can get that interface
> attached to a PC, you can get it anywhere else for free (with a bit of
> programming) (!).

sure, exactly!


>>Maybe that some "tailoring" will always be needed, i.e. it can be
>>[...]

> Yes - it's of course possible to propose a standard dictionary for
> certain kinds of values, and you could come up with a set for weather
> stations as an example.  I have a dictionary of values I'm interested
> in, you do too I'm sure.  Perhaps some of them are truly universal, like
> a "light level" from 0-255... but maybe you use 16-bit light levels!

yep.
no, just 64 levels seem to be ok :)

> And I think having the flexibility to support other devices that aren't
> specifically under the "home automation" umbrella would be good too.

yeah

> So I think trying to standardize the data dictionary side of things is
> not the right way to go.  (This is where ZigBee appears to be headed
> now, which seems troublesome to me...)

I agree on this. I found their "dictionary" quite complex and
complicated. Of course, one can use only the part he needs, but it may
still look hostile.
But, indeed, some standard way of "naming" things or actions has to be
there.

> Neat!  But it sounds like you didn't see anything else attractive for
> the protocol layer.

Oh, I started out with what I considered necessary (in first draft in
1992 I did not even have a checksum, just parity bits... but I was very
young :) )
Then I added features, increased stability and reliability, borrowed
some ideas from here and there... The Powerline protocol, for example,
was "very" complicated and had a lot of overhead.
I digged into TCP/IP only later, and by the time I found out that...
things almost always go that way!

>>Writing my own protocol was mostly... fun! But then, you learn a lot
>>from your errors and looking at other people's work - for instance, I
>>got the "repeated frame" thing attending a Nordic meeting.
>
> What's that?

Nordic wireless chipsets, such as 2401. I used them a lot, and the
meeting was good on the technical level.
I also found good information and hints in the CC2420 (Chipcon/Texas)
application notes.


> BTW, in honor of the summer solstice today, I put together a
> solar-powered wireless insolation (solar radiance) meter.  Uses the
> protocol I'm talking about above.  Should be graphing the amount of
> light getting into my office throughout the weekend; I'll see if it was
> working at the moment of the solstice when I go back on Monday.

nice!
I installed solar panels on the roof of new home, I still have to move
there though. The inverter has an Ethernet port and should be SNMP
capable, so I'll probably use it to monitor it.


Happy solstice everyone :)

--
Ciao, Dario -- ADPM Synthesis sas -- http://www.adpm.tk

2008\06\21@093303 by Timothy J. Weber

face picon face
Dario Greggio wrote:
> Timothy J. Weber wrote:
>> Perhaps some of them are truly universal, like
>> a "light level" from 0-255... but maybe you use 16-bit light levels!
>
> yep.
> no, just 64 levels seem to be ok :)

:)  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.

>> Neat!  But it sounds like you didn't see anything else attractive for
>> the protocol layer.
>
> Oh, I started out with what I considered necessary (in first draft in
> 1992 I did not even have a checksum, just parity bits... but I was very
> young :) )
> Then I added features, increased stability and reliability, borrowed
> some ideas from here and there... The Powerline protocol, for example,
> was "very" complicated and had a lot of overhead.

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.

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.

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.

LonWorks is also open-source, but uses its own wired physical spec.  Its
profile list is pretty comprehensive, though, and freely available:
<http://www.lonmark.org/technical_resources/guidelines/functional_profiles>

>>> Writing my own protocol was mostly... fun!

I agree!  Time-consuming, though, for sure.

>>> But then, you learn a lot
>>> from your errors and looking at other people's work - for instance, I
>>> got the "repeated frame" thing attending a Nordic meeting.
>> What's that?
>
> Nordic wireless chipsets, such as 2401. I used them a lot, and the
> meeting was good on the technical level.

Yes - I meant what's the "repeated frame" thing?  Repeating until you
get an ACK, or...?

> I installed solar panels on the roof of new home, I still have to move
> there though. The inverter has an Ethernet port and should be SNMP
> capable, so I'll probably use it to monitor it.

Very nice!  I'd be interested to hear how well SNMP integrates with the
rest of your system.
--
Timothy J. Weber
http://timothyweber.org

2008\06\21@102616 by Dario Greggio

face picon face
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:
> <http://www.lonmark.org/technical_resources/guidelines/functional_profiles>

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, °C 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

2008\06\21@151849 by Timothy J. Weber

face picon face
Dario Greggio wrote:
> 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?

Sunrise simulation - a slow-waking alarm clock.

>> 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!

Ah yes!  I have avoided toggle messages.  But I should add that frame
index to my protocol as well.

>> Very nice!  I'd be interested to hear how well SNMP integrates with the
>> rest of your system.
>
> Oh, Classes.

Yes - a classic use of OO - but I mean generally whether SNMP seems like
a good fit for home automation.  I feel like I haven't explored it
enough yet and should - maybe it could BE "the protocol," at least with
a suitable set of gateways to transport layers other TCP/IP.

> I'll let you know!

Please do!
--
Timothy J. Weber
http://timothyweber.org

2008\06\21@183128 by olin piclist

face picon face
Dario Greggio wrote:
> 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!

This is a normal problem in any network where delivery is unreliable.  The
usual solution is to associate a sequence number with each byte or command
or packet.  If the same request is re-sent, then the same sequence number is
used.  The receiver can then detect and ignore multiple copies of the same
request.

Again, this has been a solved problem for a long time.  TCP associates a 32
bit sequence number with each byte, since it is a byte stream protocol.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\21@190312 by Neil Cherry

flavicon
face
Timothy J. Weber wrote:
{Quote hidden}

I don't know if KNX is open source  but there is this:

https://www.auto.tuwien.ac.at/a-lab/knx-eib.html

> 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.
>
> LonWorks is also open-source, but uses its own wired physical spec.  Its
> profile list is pretty comprehensive, though, and freely available:
> <http://www.lonmark.org/technical_resources/guidelines/functional_profiles>

Open Source? Don't you need to purchase Lonworks neuron chips and use
special software to design with?


For lighting controls you might want to look into DMX.

>> I installed solar panels on the roof of new home, I still have to move
>> there though. The inverter has an Ethernet port and should be SNMP
>> capable, so I'll probably use it to monitor it.
>
> Very nice!  I'd be interested to hear how well SNMP integrates with the
> rest of your system.

Ick, SNMP.

--
Linux Home Automation         Neil Cherry       spam_OUTncherryTakeThisOuTspamlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummies

2008\06\21@201652 by Timothy J. Weber

face picon face
Neil Cherry wrote:
> I don't know if KNX is open source  but there is this:
>
> https://www.auto.tuwien.ac.at/a-lab/knx-eib.html

Interesting.  Seems to suffer from the common web site ailment that you
have to know what it's about in order to understand what it's about...
but I will research some of those TLAs and learn more.

>> LonWorks is also open-source, but uses its own wired physical spec.  Its
>> profile list is pretty comprehensive, though, and freely available:
>> <www.lonmark.org/technical_resources/guidelines/functional_profiles>
>
> Open Source? Don't you need to purchase Lonworks neuron chips and use
> special software to design with?

I wouldn't be surprised!  They do claim "open source," but... well,
maybe their only really open part is the profiles, and they DO look like
a useful resource.  And it's refreshing to be able to look at one of
these sites and drill down to byte-level descriptions of data quickly.

> For lighting controls you might want to look into DMX.

I do have some light controls, but even those modules use bidirectional
communications, which DMX apparently doesn't do.  And I'm thinking a bit
more generally than DMX appears.

Of course, the Holy Grail of standards would include a bridge to DMX!

> Ick, SNMP.

I'm glad to hear that, if only because it reinforces my initial reaction
to it.  :)  Any specifics you can pass on?
--
Timothy J. Weber
http://timothyweber.org

2008\06\21@210914 by Neil Cherry

flavicon
face
Timothy J. Weber wrote:
> Neil Cherry wrote:
>> I don't know if KNX is open source  but there is this:
>>
>> www.auto.tuwien.ac.at/a-lab/knx-eib.html
>
> Interesting.  Seems to suffer from the common web site ailment that you
> have to know what it's about in order to understand what it's about...
> but I will research some of those TLAs and learn more.
>
>>> LonWorks is also open-source, but uses its own wired physical spec.  Its
>>> profile list is pretty comprehensive, though, and freely available:
>>> <www.lonmark.org/technical_resources/guidelines/functional_profiles>
>> Open Source? Don't you need to purchase Lonworks neuron chips and use
>> special software to design with?
>
> I wouldn't be surprised!  They do claim "open source," but... well,
> maybe their only really open part is the profiles, and they DO look like
> a useful resource.  And it's refreshing to be able to look at one of
> these sites and drill down to byte-level descriptions of data quickly.

I think the profiles are tied to their Lonworks product but I will have
a look later on.

>> For lighting controls you might want to look into DMX.
>
> I do have some light controls, but even those modules use bidirectional
> communications, which DMX apparently doesn't do.  And I'm thinking a bit
> more generally than DMX appears.
>
> Of course, the Holy Grail of standards would include a bridge to DMX!

I mostly mix and match such protocols inside of Misterhouse. Right now
I'm mixing Insteon, X10 and Z-Wave. I have an IP digital device I'll
integrate a little later. Misterhouse is a DIY open source program
written in Perl.

>> Ick, SNMP.
>
> I'm glad to hear that, if only because it reinforces my initial reaction
> to it.  :)  Any specifics you can pass on?

The Rose book, "How To Manage Your Network Using SNMP" - Rose & McCloghrie
t least I think that's the book. I learned SNMP when I was dealing with
Wellfleet/Bay Network routers a long time ago. The mibs drove me nuts
and I never liked the extra overhead associated with it. Of course if
you're running a Linux (or any Unix) you could just download the
SNMP suite and set it up under that OS. If you're thinking about putting
it in a PIC I wouldn't advise it. I like simple and I lean towards the
UDP and bare binary solution for small devices.

--
Linux Home Automation         Neil Cherry       .....ncherryKILLspamspam@spam@linuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummies

2008\06\21@221756 by Bob Ammerman

picon face
>> 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!
>
> Ah yes!  I have avoided toggle messages.  But I should add that frame
> index to my protocol as well.

A protocol which doesn't have problems with repeated meessages is called
'idempotent'. Some remote file system protocols work that way. I often use
this concept when designing protocols.

-- Bob Ammerman
RAm Systems

2008\06\21@221801 by Bob Ammerman

picon face
>> 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!
>
> This is a normal problem in any network where delivery is unreliable.  The
> usual solution is to associate a sequence number with each byte or command
> or packet.  If the same request is re-sent, then the same sequence number
> is
> used.  The receiver can then detect and ignore multiple copies of the same
> request.
>
> Again, this has been a solved problem for a long time.  TCP associates a
> 32
> bit sequence number with each byte, since it is a byte stream protocol.

Actually it has been solved a lot longer than that. Many of the earliest
solutions used a 1-bit sequence number! Instead of a single ACK, there are
two: types ACK-0 and ACK-1, which are alternated.

-- Bob Ammerman
RAm Systems

2008\06\21@225921 by Dario Greggio

face picon face
Olin Lathrop wrote:
> This is a normal problem in any network where delivery is unreliable.  The
> usual solution is to associate a sequence number with each byte or command[...]
>
> Again, this has been a solved problem for a long time.  TCP associates a 32
> bit sequence number with each byte, since it is a byte stream protocol.

Yeah, Olin, I meant that :)
I.e. I started my protocol with the bare minimum essential to have
Commands working. Then it grew up facing holes and bugs, and I added
features as I understooed them. TCP would probably have been the
ultimate, better place where to study but... I did not have the chance
to dig into that for long time!

--
Ciao, Dario

2008\06\21@230113 by Dario Greggio

face picon face
Neil Cherry wrote:

> For lighting controls you might want to look into DMX.

Yeah, I considered that (with a customer as well) but we've not gone
into that yet. We use the same protocol as home automation for them.

--
Ciao, Dario

2008\06\21@230315 by Dario Greggio

face picon face
Bob Ammerman wrote:
> A protocol which doesn't have problems with repeated meessages is called
> 'idempotent'. Some remote file system protocols work that way. I often use
> this concept when designing protocols.

thank you Bob!

--
Ciao, Dario

2008\06\21@230409 by Dario Greggio

face picon face
Bob Ammerman wrote:

> Actually it has been solved a lot longer than that. Many of the earliest
> solutions used a 1-bit sequence number! Instead of a single ACK, there are
> two: types ACK-0 and ACK-1, which are alternated.

thanks for this too.
I use a 7bit Counter at the moment - and the 8th bit in this byte is the
"WANTS_ACK" field, which tells the receiver whether or not a ACK is
required.

--
Ciao, Dario

2008\06\22@012438 by Josh Koffman

face picon face
On Sat, Jun 21, 2008 at 5:16 PM, Timothy J. Weber <twspamKILLspamtimothyweber.org> wrote:
>> For lighting controls you might want to look into DMX.
>
> I do have some light controls, but even those modules use bidirectional
> communications, which DMX apparently doesn't do.  And I'm thinking a bit
> more generally than DMX appears.

Actually it does now. RDM (remote device management) is an ANSI
standard built on the DMX512A ANSI standard and is backwards
compatible with regular DMX512A.

Check out ESTA (http://www.esta.org) to purchase copies of the standard.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
-Douglas Adams

2008\06\22@074838 by Dario Greggio

face picon face
Neil Cherry wrote:

> I don't know if KNX is open source  but there is this:
> https://www.auto.tuwien.ac.at/a-lab/knx-eib.html

Neil, could you (or somebody else) kindly convert this schematic
www.auto.tuwien.ac.at/a-lab/knxcalibur.html
http://www.praus.at/dl.php?url=https://www.auto.tuwien.ac.at/downloads/knxcalibur/eib_gw.sch

to a PDF? I don't have Eagle and would not want to download a version
(not even sure if a free one is available) just to take a look at it...

many thanks!


>>LonWorks is also open-source, but uses its own wired physical spec.  Its
>>profile list is pretty comprehensive, though, and freely available:
>><http://www.lonmark.org/technical_resources/guidelines/functional_profiles>

This is interesting.
If not else, to take a look at someone else's approach and possibly
improve it :)

--
Ciao, Dario

2008\06\22@083331 by olin piclist

face picon face
Dario Greggio wrote:
> Neil, could you (or somebody else) kindly convert this schematic
> https://www.auto.tuwien.ac.at/a-lab/knxcalibur.html
>
http://www.praus.at/dl.php?url=https://www.auto.tuwien.ac.at/downloads/knxcalibur/eib_gw.sch
>
> to a PDF? I don't have Eagle and would not want to download a version
> (not even sure if a free one is available) just to take a look at
> it...

OK, it will be at http://www.embedinc.com/temp/mess.pdf for a while.

What a mess though!  There are labels overlapping other parts, designators
and values not rotated back to readable orientation, parts with no
designators (you really have to work at it to screw this up in Eagle), and
in at least one place I saw a connection passing right accross another part.

Given the sloppiness and lack of attention to detail, I wouldn't take
anything this guy says as useful information.  And if he's selling stuff,
make a note of the company so that you can avoid their products.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\22@084218 by Dario Greggio

face picon face
Olin Lathrop wrote:

> OK, it will be at http://www.embedinc.com/temp/mess.pdf for a while.

wow, thank you very much Olin!

> What a mess though!  There are labels overlapping other parts, designators
> [...]
> designators (you really have to work at it to screw this up in Eagle), and
> [...]

:)) yep, true! could be better, for sure.

> Given the sloppiness and lack of attention to detail, I wouldn't take
> anything this guy says as useful information.  And if he's selling stuff,
> make a note of the company so that you can avoid their products.

:)
yeah: I just wanted to take a look at the hardware level.

Hmmm, it looks like it is not a differential bus. I find also strange
using a TTL past an opto-isolator...
Who knows if the sloppiness comes from the author or from the
standard... ? :)

--
Ciao, Dario

2008\06\22@085322 by Jinx

face picon face
> I don't have Eagle and would not want to download a version
> (not even sure if a free one is available) just to take a look at it...

http://www.cadsoft.de/freeware.htm

2008\06\22@085851 by Dario Greggio

face picon face
Jinx wrote:

>>I don't have Eagle and would not want to download a version
>>(not even sure if a free one is available) just to take a look at it...
>
> http://www.cadsoft.de/freeware.htm

thank you Jinx :) I seemed to remember that but was not sure!

--
Ciao, Dario

2008\06\22@095304 by sergio masci

flavicon
face


On Sat, 21 Jun 2008, Dario Greggio wrote:

{Quote hidden}

Do you keep sending the same message until it is acknowledged (ACK/NAK) or
do you at some point decide "this message isn't getting through" and
discard it?

What happens if the slaves go off line for a while? Will you have a queue
of messages builing up clogging your network (continually being re-sent).
Will the messages have any meaning if they are delayed for too long.

What happens if the master goes off line for a while? Will the slaves be
left with a stale "frame field count"? Do you have some kind of resync
procedure?

Personnaly I'd rather send a special kind of ACK back to the master if I
got a repeated message, telling the master that there was an error and I
had already received that frame. The master is then in a position to know
if there is a frame sync problem (because the master did not send the
frame before and the slave is saying it has already received it).

Regards
Sergio Masci

2008\06\22@101351 by Dario Greggio

face picon face
sergio masci wrote:

> Do you keep sending the same message until it is acknowledged (ACK/NAK) or
> do you at some point decide "this message isn't getting through" and
> discard it?

I have a max_retries field, usually set to 5, and a return code for
possible errors. Of course, it should not happen. Average communication
is ok (i.e. no errors) and in case of bus congestion, the number of
retries is usually 1 and rarely 2.

> What happens if the slaves go off line for a while? Will you have a queue
> of messages building up clogging your network (continually being re-sent).
> Will the messages have any meaning if they are delayed for too long.

Well, I introduced the possibility of Slaves going off, when I started
adding wireless nodes with power-down features (something like Zigbee's
reduced-nodes). So, with the normal 485 devices, a device not responding
is a fault one. With the Wireless devices, a queue is built but again,
under normal conditions, it never gets filled: it may just happen to
miss the "wakeup signal" from one slave device... and surely it will
receive the next one.

> What happens if the master goes off line for a while? Will the slaves be
> left with a stale "frame field count"? Do you have some kind of resync
> procedure?

At the moment, this does not happen: the whole network is handled by the
Master, either in PC-driven mode or as a stand-alone "router".
Peer-2-peer capabilities are not used.

> Personnaly I'd rather send a special kind of ACK back to the master if I
> got a repeated message, telling the master that there was an error and I
> had already received that frame. The master is then in a position to know
> if there is a frame sync problem (because the master did not send the
> frame before and the slave is saying it has already received it).

Hey, this is indeed smart! :)
I can't figure out, now, an use for this... but I'll think about it.

Thanks for your comments, Sergio.

--
Ciao, Dario

2008\06\22@205526 by Timothy J. Weber

face picon face
Neil Cherry wrote:
> I think the profiles are tied to their Lonworks product but I will have
> a look later on.

Their collection does seem to me to be a generally useful resource - as
in, "I'm adding a device that does X.  What data might I want to
expose?"  E.g., their standard profile for a light can report the number
of hours the light has been on.  Neat idea - not that I'm going to
implement it, but I can see where it would be useful to change bulbs
every X hours in an industrial setting.

> I mostly mix and match such protocols inside of Misterhouse. Right now
> I'm mixing Insteon, X10 and Z-Wave. I have an IP digital device I'll
> integrate a little later. Misterhouse is a DIY open source program
> written in Perl.

Wow - I had glanced at its page on SourceForge, but somehow missed the
main project site.  Looks very cool.  I'll have to check it out in more
detail and see how easy it would be to add support for ZigBee devices
and/or my existing stuff.

Though my personal taste is to not have a PC on 24/7, so I tend to push
the scheduling down to the remote devices after setting things on a PC.
 Seems like this is still worth a look, though.

> The Rose book, "How To Manage Your Network Using SNMP" - Rose & McCloghrie
> t least I think that's the book. I learned SNMP when I was dealing with
> Wellfleet/Bay Network routers a long time ago. The mibs drove me nuts
> and I never liked the extra overhead associated with it. Of course if
> you're running a Linux (or any Unix) you could just download the
> SNMP suite and set it up under that OS. If you're thinking about putting
> it in a PIC I wouldn't advise it. I like simple and I lean towards the
> UDP and bare binary solution for small devices.

Thanks, that's good to know - it did seem way too fat for a PIC.
--
Timothy J. Weber
http://timothyweber.org

2008\06\22@211058 by Timothy J. Weber

face picon face
Josh Koffman wrote:
> On Sat, Jun 21, 2008 at 5:16 PM, Timothy J. Weber <.....twKILLspamspam.....timothyweber.org> wrote:
>>> For lighting controls you might want to look into DMX.
>> I do have some light controls, but even those modules use bidirectional
>> communications, which DMX apparently doesn't do.  And I'm thinking a bit
>> more generally than DMX appears.
>
> Actually it does now. RDM (remote device management) is an ANSI
> standard built on the DMX512A ANSI standard and is backwards
> compatible with regular DMX512A.
>
> Check out ESTA (http://www.esta.org) to purchase copies of the standard.

Hm... certainly interesting for wired lighting specifically.
--
Timothy J. Weber
http://timothyweber.org

2008\06\22@211725 by Timothy J. Weber

face picon face
sergio masci wrote:
>
> Do you keep sending the same message until it is acknowledged (ACK/NAK) or
> do you at some point decide "this message isn't getting through" and
> discard it?

I first interpreted this as somehow referring to PIClist
politics/protocol... heh...

> What happens if the slaves go off line for a while? Will you have a queue
> of messages builing up clogging your network (continually being re-sent).
> Will the messages have any meaning if they are delayed for too long.

I find these questions are generally best resolved by looking at an
individual device and value.  E.g., for a pager event (a button is
pressed in room A, intending to trigger a tune played in room B), I
repeat the message up to five times or until I get an ACK, and play a
confirmation/error sound in room A as feedback.  For a temperature
sensor that's reporting frequently, maybe a simple broadcast with no ACK
is fine.

So I think in general, a good protocol layer provides for these
alternatives, and standardizes them, but the application layer needs to
decide which is appropriate.
--
Timothy J. Weber
http://timothyweber.org

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...