Re: Re: Serial protocol questions

["Frank Mc Alinden" <fmcalind@xxxxxxxxxxxxxx>]

Hi Neil

> Firstly, I'm not sure if everybody is up to speed on RS485 comms

I have the basics of how it works....

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

This is the sort of stuff i got no experience of ........


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

What micros you using  as slaves ???..Would imagine only things like lcds
would require message data of 256 bytes ????



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

Sounds good although the master is going to be a busy boy  decoding all th
relevent xPL messages...??


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

How do you interface this to your lighting control.......In my case  i
could
incorporate a Clipsal Bus Coupler into the Local Box.....So the pc just
keeps track of the status rather  than getting the light on command from a
switch and then sending an on command to the lights ????
The Occupancy idea is good  but needs to incoprorate time windows when it
can control lights...?

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

Cant answer this as im a hardware geek ;-(....

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

Yep in sunny Melbourne ;-).....

Frank

----- Original Message -----
From: "Neil Wrightson" <neilw@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Sunday, January 23, 2005 11:05 PM
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
>
>
>
>   _____
>
> 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/>
>
>
> * 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/>
.
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> xPL Links: http://www.xplproject.org.uk http://www.xplhal.com
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.xplhal.com 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