RE: Re: Serial protocol questions

["DynamoBen" <ben@xxxxxxxxxxx>]

Neil,

Your protocol design is very similar to what I had originally planned prior
to stumbling across the xpl documentation.

You made and interesting point that I had not thought about in my design. I
had assumed that on the PC side of things I would just drop in an
RS232->RS485 converter and call it done. Now I'm contemplating using a
pic
as a master and making the door locations slaves.
Would that makes sense? Is it worth the extra work?

Additionally, I think what you're working on and what I'm working on could
be very complementary. Is it worthwhile to work together on system layout
and protocol so that both our devices "play" on the same RS485
network? I
think in doing that we will indirectly create somewhat of an xpl standard
in
that one plug-in can be created for all RS485 devices. That plug-in would
convert RS485 message into xpl network messages. Is my thinking correct?

-----Original Message-----
From: Neil Wrightson [mailto:neilw@xxxxxxx]
Sent: Sunday, January 23, 2005 6:06 AM
To: ukha_xpl@xxxxxxx
Subject: RE: [ukha_xpl] Re: Serial protocol questions


Frank,

Firstly, I'm not sure if everybody is up to speed on RS485 comms. RS485
uses
2 wires for the transmission of data. For simplicities sake, lets treat the
two wires as one.
As you would appreciate, you cannot typically send and receive data on a
single wire at the same time. Thus a master is required that transmits out
a
signal, and at the same time slaves are awaiting a signal. When a slave
receives a message specifically address to it, it then talks back to the
master. The actual RS485 IC's in the master and slaves must be changed from
Transmission mode to receive and back again for each sent message.
Basically it goes like this -

Master
Slave
1) Set Master RS485 IC to Transmit mode
Set RS485 IC to Receive mode
(Usually RTS signal on comm port)
2) Transmit Message to Slave #03
Receive message
3) Set Master RS485 IC to Receive mode (Usually RTS signal on comm port)
If it was for me then process
4) Wait for message from Slave #03
All of my messages require an acknowledge
(Usually includes a timeout in case slave #03 does not respond)
So set RS485 IC to Transmit mode and send message
5) Optional delay
Set RS485 to Receive mode
6) Goto 1) or poll extra slaves etc
Wait for next message


I use two different protocols depending on the application.
1) PC to RS485 Devices
The communications are between the PC and the remote RS485 slave devices. A
RS232 to RS485 converter is required for the PC.
This converter can be quite simple and does not require any brains I.e. no
processor.
Although optical isolation at this point is nice (Adds $$$ but not much)
Basically the comms are as per above sample. The PC must be able to toggle
the RTS line for each transmission. Sounds simple but, the PC software must
know when the last character has been completely sent out of the UART in
the
serial interface. Most PC's are at least double buffered, or even 8 or 16
character buffer. So doing something simple in Pascal like saying send(Ch);
SetRTS(Low); would be guaranteed to not work.
Having said that, the protocol I use is
1    Stx                        Byte,#02
2    Addr                      Byte 0..255    Note Generally RS485 limits
32
devices to be connected to the bus
3    Message Length     Byte              Allows messages up to 256 -
Message size
4    Command              Byte              I.e.Clear LCD display, Obtain
I/O status etc
5    Data if any             Variable size based on message length. could
be
zero
6    Checksum             Byte               Checksum of bytes from Stx to
Checksum location minus 1
7    Etx                       Byte, #03

Thus the minimum message sizes is 6 bytes if no extra data is transmitted


2) PC to Dedicated master to slaves
The first part of PC to dedicated master is as per the above protocol. The
big difference here is that the PC to master interface is RS232, thus none
of the waffle with concerns about the RTS handshaking lines being changed
over at the wrong time. Just 3 wires Tx,Rx,0V.
The Master is a separate dedicated micro controller board that talks RS232
to the PC and talks RS485 to the slaves.
Here the protocol is somewhat different because of the features within the
dedicated micros
1    Address                Byte or Word    - Well not quite These
particular bytes are actually 9 bits in size
2    Message Length    Byte
3    Data                     Variable size based on message length. could
be zero
4    Checksum

Good points about this method are that the local RS485 network can be very
fast and the master is always aware of all changes. It then only passes
state changes to the PC via the RS232 port. Usual delays in PC's I.e.
disappearing for a second do not effect the RS485 comms.

Both protocols use an address of 0 (Zero) for general broadcasting of
messages to all devices. I.e. perform a master reset.


In other postings I have made reference to a remote RS485 terminal with
LCD,
keypad, I/O, IR Tx & Rx etc that is under development.
What I plan is that basically this terminal will be a ROOM terminal and
have
some smart intelligence built in.
I.e.
I/O Inputs for PIR's (Movement sensor) and door/window switches (These
will be interfaced to the lights for auto light control as well as
security)
I/O Outputs for Lights, sound etc
Audio Out - Thinking of relaying HAPC voice annunciations
RTC for determining wake up alarms, sleep modes etc.

My idea is that, even if the HAPC or the RS485 network is down a person
should still be able to turn the lights OFF/ON etc NOT have the house in a
completely shut down mode and stumbling around in the dark.
Here I see that the slave room terminals will need to pass all state
changes
back and forth to the master and to the PC. BUT each slave must be able to
see an input change I.e. PIR picks up movement and it MUST then turn on the
light. It can't wait for it to send a message to the PC saying movement and
the PC then respond back with turn on the light.

All of the above I do now in various forms. To me the embedded side is
easy.
Your PC xPL is a bit different. I could do a separate windows app using
Delphi for the xPL IP socket to serial port connection but I think it would
be better added into xPLHAL or something ???

Well, time to go to bed. Work tomorrow :(

Hey Frank, I just noticed your email is bigpond.net.au. Are you in AUS? I'm
in the Newcastle region.


Regards,

Neil Wrightson.

From: Frank Mc Alinden [mailto:fmcalind@xxxxxxx]
Sent: Sunday, 23 January 2005 6:39 PM
To: ukha_xpl@xxxxxxx
Subject: Re: [ukha_xpl] Re: Serial protocol questions



Hi Ben
I was thinking if Neil already has a reasonably simple and
robust  rs485 protocol for his kit , why not look at that and take it from
there ...???

Frank

----- Original Message -----
From: <ben@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Sunday, January 23, 2005 5:52 PM
Subject: [ukha_xpl] Re: Serial protocol questions


>
>
>
> You make several compelling points. I do agree it might be best to
> have a polling environment.
>
> I do also think that all HA items should share a similar protocol
> schema. That was the precipitous of my question.
>
> Its sound like the RS485 network should have one standard protocol,
> possibly similar to that of xpl, and then interface via a host PC to
> xpl.
>
> So then, what protocol would work best? Is there a dominant one to
> consider in the HA market?
>
>
> --- In ukha_xpl@xxxxxxx, "Neil Wrightson" <neilw@n...>
wrote:
> > Hi All,
> >
> > I have done a lot of comms work in the past, both RS232 and
RS485.
> > RS485 really has to be a polled environment I.e. a master with
> polled
> > slaves. I'm only just starting to look at Xpl at this stage and
it
> appears
> > that the heartbeat is a rather critical aspect to this protocol.
> > I believe that the RS485 master should be aware of all of it's
> slaves and
> > that the master sends a heartbeat to it's master xXPLHAL??) for
> its self and
> > each of its slaves.
> > Perhaps xPLHAL should advise the master 485 device what slaves it
> should be
> > talking to and what there functionality is.
> >
> > To me part of the question is, should the RS485 network try to
> emulate xPL
> > or as suggested just use a proprietary protocol. I already have
> proprietary
> > protocols in place so this would be easier.
> > But,
> > In my house I do not want to have multiple RS485 networks with
> separate
> > proprietary protocols. I will probably end up making most of my
own
> > hardware, but who knows I may wish to buy somebody else's 485
> hardware item
> > I.e. RFID and connect it onto my network. This wont work if we
all
> have
> > separate 485 protocols.
> >
> > I think one of the early on questions is, What is the master? Is
> it part of
> > xPLHAL I.e. a PC is the master or should there be a separate
> standalone
> > master that talks to HAL via another serial connection. If XPLHAL
> is the
> > master we need somebody that can handle the 485 comms on the PC
> I.e. Rx,Tx
> > and a handshake line.
> >
> > By the way, I have already interfaced to RFID devices. Most
> commercially
> > available RFID devices talk to other equipment via a 26bit
weigand
> > interface.
> >
> > Regards,
> >
> > Neil Wrightson.
> > -----Original Message-----
> > From: Frank Mc Alinden [mailto:fmcalind@b...]
> > Sent: Sunday, 23 January 2005 8:08 AM
> > To: ukha_xpl@xxxxxxx
> > Subject: Re: [ukha_xpl] Serial protocol questions
> >
> >
> >
> > Hi Ben
> >
> >         No one that im aware of has done any xPL stuff using
rs485
> and i
> > have been pondering over the same questions that you are
currently
> asking,
> > as i have some rfid readers and i intend to have a little xPL
rs485
> > network......
> >
> > > 1) Should I be implementing xpl on this device via serial?
> >
> > Can be done ok , but each device must generate hbeats and on a
> rs485 network
> > ,multiple devices could send hbeats at the same time ..???
> >
> > > 2) What schema(s) should I be using?
> >
> > I would assume the control.basic..Sensor.basic could be used here
> >
> > > 3) Would it be better to create a proprietary protocol and
have
> > > someone write a plug-in interface to xpl?
> >
> > Yes this is another option and i have done this with my Probe
> system....
> > You still have the issue of devices sending data at the same time
> therefore
> > getting corrupted messages unless the app polls each device on
the
> network
> > ...???
> >
> > > 4) What resources are available to use as a reference beside
the
> xpl
> > > official website.
> >
> > No rs485 resources that im aware of ....
> >
> > Frank
> >
> >
> >
> > ----- Original Message -----
> > From: <ben@b...>
> > To: <ukha_xpl@xxxxxxx>
> > Sent: Sunday, January 23, 2005 6:24 AM
> > Subject: [ukha_xpl] Serial protocol questions
> >
> >
> > >
> > >
> > > I am in the midst of a project and was thinking about making
the
> > > device xpl compatible.
> > > The device is a magnetic card reader (credit card) with and
> onboard
> > > relay to open an electrical door lock. The idea is you would
> swipe a
> > > credit card this device sends the account number to a host
> computer
> > > (via RS-485). The host determines if the account is allowed
> access
> > > and opens or denies access appropriately.
> > > This device is run by a pic microprocessor.
> > >
> > > Questions:
> > >
> > > 1) Should I be implementing xpl on this device via serial?
> > > 2) What schema(s) should I be using?
> > > 3) Would it be better to create a proprietary protocol and
have
> > > someone write a plug-in interface to xpl?
> > > 4) What resources are available to use as a reference beside
the
> xpl
> > > official website.
> > >
> > > Thanks!
> > >
> > >
> > >
> > >
> > >
> > >
> > > xPL Links: http://www.xplproject.org.uk <http://www.xplproject.org.uk>
> < http://www.xplproject.org.uk <http://www.xplproject.org.uk>
>
> > http://www.xplhal.com <http://www.xplhal.com>  < http://www.xplhal.com
<http://www.xplhal.com> >
> > http://www.xpl.myby.co.uk <http://www.xpl.myby.co.uk>  <
http://www.xpl.myby.co.uk <http://www.xpl.myby.co.uk> >
> > > To Post a Message: ukha_xpl@xxxxxxx
> > > To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> > > To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > xPL Links: http://www.xplproject.org.uk <http://www.xplproject.org.uk>
> < http://www.xplproject.org.uk <http://www.xplproject.org.uk>
>
> > http://www.xplhal.com <http://www.xplhal.com>  < http://www.xplhal.com
<http://www.xplhal.com> >
> http://www.xpl.myby.co.uk
<http://www.xpl.myby.co.uk>
> > < http://www.xpl.myby.co.uk <http://www.xpl.myby.co.uk> >
> > To Post a Message: ukha_xpl@xxxxxxx
> > To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> > To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> >
> >
> >
> >   _____
> >
> > Yahoo! Groups Links
> >
> >
> > * To visit your group on the web, go to:
> > http://groups.yahoo.com/group/ukha_xpl/
<http://groups.yahoo.com/group/ukha_xpl/>
> > < http://groups.yahoo.com/group/ukha_xpl/
<http://groups.yahoo.com/group/ukha_xpl/>
>
> >
> >
> > * To unsubscribe from this group, send an email to:
> > ukha_xpl-unsubscribe@xxxxxxx
> > <mailto:ukha_xpl-unsubscribe@xxxxxxx?subject=Unsubscribe>
> >
> >
> > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service
> > < http://docs.yahoo.com/info/terms/
<http://docs.yahoo.com/info/terms/>
> .
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
>
>
>
>
>
>
>
>
> xPL Links: http://www.xplproject.org.uk <http://www.xplproject.org.uk>
http://www.xplhal.com <http://www.xplhal.com>
http://www.xpl.myby.co.uk <http://www.xpl.myby.co.uk>
> To Post a Message: ukha_xpl@xxxxxxx
> To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> Yahoo! Groups Links
>
>
>
>
>
>
>



xPL Links: http://www.xplproject.org.uk <http://www.xplproject.org.uk>
http://www.xplhal.com <http://www.xplhal.com>  http://www.xpl.myby.co.uk
<http://www.xpl.myby.co.uk>
To Post a Message: ukha_xpl@xxxxxxx
To Subscribe:  ukha_xpl-subscribe@xxxxxxx
To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx



_____