Re: Serial protocol questions

["g8kmh" <lehane@xxxxxxxxxxxxxxxxxxx>]

Not sure that's right - usually the message is
<STX>message<ETX>CRC-16
That way you know when to stop calculating the checksum. You don't
need an ETX after the checksum as it is always a fixed length.

CRC-16 isn't too difficult to do, whether it is needed on a polling
line is debatable - on a multi-master system, yes. LRC-8 (XOR) would
suffice.

Lehane


--- In ukha_xpl@xxxxxxx, "DynamoBen" <ben@b...> wrote:
> This is what xAP has to offer. I say we use a similar model:
>
> Basic Serial Transport Wrapper
> The xAP transport wrapper for a basic serial connection is defined
as
> follows:
>
>   a.. The xAP message is prefixed with the ASCII control character
<STX>
> (ASCII character decimal 2)
>   b.. The core xAP message is transmitted. Any instances of the
<STX>
> character and <ETX> character (ASCII characters decimal 2 and
decimal 3
> respectively) are escaped by prefixing the character with <ESC>
(ASCII
> character 27). i.e. an embedded <STX>   becomes <ESC>
<STX> and an
embedded
> <ETX> becomes <ESC> <ETX> . This mechanism is
defined here for
completeness;
> in practice it would be very unusual to transmit non-printable
characters as
> part of a xAP message.
>   c.. Instances of the <ESC> character  (ASCII character 27) are
also
> escaped. i.e. <ESC>  becomes <ESC> <ESC>. Again, it
would be rare
to embed
> <ESC> characters within a xAP message in practice.
>   d.. At the end of the xAP message a 16-bit CRC checksum is
appended as
> four ASCII-hex digits (ie. human readable, not binary). The
checksum is
> applied to all data within the message envelope: the <STX>,
checksum itself,
> and <ETX> character are not included in the CRC calculation. 
Hex
digits A-F
> are represented in upper case. Source code examples illustrating
the
> calculation of 16-bit CRC checksums can be found at
> www.planetsourcecode.com.
>   e.. If the checksum is not calculated, four dashes (ASCII code
decimal 45)
> are substituted in its place.
>   f.. The checksum is immediately followed by <ETX> (ASCII
character decimal
> 3)
> What I suggested is similar. The biggest difference is the check
sum. Here
> they use 16-bit crc. To me this is way to much math for a pic
processor. I
> say we just do a byte add and call it done.
> In the version I sent out I included <Command> based on Franks
protocol. Is
> it worth keeping?
>
> BTW they refer to their protocol converter (Master) as a
"bridge."
Not a bad
> term inplace of master.
> ----- Original Message -----
> From: "g8kmh" <lehane@m...>
> To: <ukha_xpl@xxxxxxx>
> Sent: Monday, January 24, 2005 3:42 PM
> Subject: [ukha_xpl] Re: Serial protocol questions
>
>
> >
> >
> > --- In ukha_xpl@xxxxxxx, "DynamoBen" <ben@b...>
wrote:
> >> BTW 1/8 fuses on the data line is always a good idea.
> >
> > Not sure what is being protected.. if I got 240v on the data line
> > then some interfaces are dead and I need to get the soldering
iron
> > out. If the fuses blow, the same (given the space requirements
they
> > may be PCB mounted). OK, OK, it's easier to swap a 1206 fuse...
> >
> > My preference is zener clamping, spark gaps and Varistors.
> >
> > In answer to some other questions  (not Ben's):
> >
> > EPC and ISO 18000-6 relate to RFID tags which you'll see on all
> > products as an adjunct and eventual replacement of bar codes on
> > everything.
> >
> > A standard ISO based magnetic (MSR) card has three tracks
containing
> > various amounts of data. Track 2 on a credit/debit card has the
basic
> > information, Track 1 usually has the cardholder name and other
info.
> > Track 3 gets used by banks/ATM's.
> >
> > There are many barcode specifications - the ones on baked beans
are
> > UPC/EAN but you'll find many others on parcels, pharmaceuticals,
etc.
> > Off the shelf readers will read most of them and tell you what
type
> > by a prefix character ahead of the data.
> >
> > Digital input can easily handle switches with some optional on
board
> > pull up resistors.
> >
> > Lehane
> >
> >
> >
> >> ----- Original Message -----
> >> From: "DynamoBen" <ben@b...>
> >> To: <ukha_xpl@xxxxxxx>
> >> Sent: Monday, January 24, 2005 2:53 PM
> >> Subject: Re: [ukha_xpl] Re: Serial protocol questions
> >>
> >>
> >> >
> >> > RS485 hubs are super easy to build. In fact you could
mock one
up
> > on a
> >> > breadboard in under 30mins. (They are generally called
opto
> > splitters)
> >> >
> >> > Parts Needed:
> >> > Several 75176 chips (less than 32)
> >> > Several 6N137 chips (this is for opto isloation)
> >> >
> >> > Data path is RS485-->75176 Input-->6N137
> >> >
> >> > Then this would be repeated for the outputs. Don't for
get to
tie
> > TX to
> >> > RX.
> >> >
> >> > This make sense?
> >> >
> >> >
> >> > ----- Original Message -----
> >> > From: "Frank Mc Alinden" <fmcalind@b...>
> >> > To: <ukha_xpl@xxxxxxx>
> >> > Sent: Monday, January 24, 2005 2:46 PM
> >> > Subject: Re: [ukha_xpl] Re: Serial protocol questions
> >> >
> >> >
> >> >>
> >> >> Hi Guys
> >> >>        Have to agree with  Lehane that its better to
have lots
> > of small
> >> >> devices than to make one that does all ...........
> >> >> Would that mean then a rs485 hub would be required
so that it
> > could be
> >> >> star
> >> >> wired ??? anybody did a rs485 hub before ????
> >> >>
> >> >> Allowing the network to run at different baud rates
is a good
> > idea
> >> >> ,anything
> >> >> i have done is 9600 , although i dont think 19200
would be out
> > of the
> >> >> question for most pics...??
> >> >>
> >> >> The important thing to get this project going i
think is to
get
> > started
> >> >> on
> >> >> the master device....
> >> >>
> >> >> Neil  do you have any current hardware to develope a
Master
> > on ????
> >> >>
> >> >>> 2) Presumably the host software will do the
device/instance
id-
> >>node
> >> >>> number conversion and the device/instance
config? - Don't
know
> > what this
> >> >> is
> >> >>> yet ???
> >> >>
> >> >> Each node has a name / id and its configurable , so
when you
put
> > a new
> >> >> device on the network it will sent out regular
requests "please
> > configure
> >> >> me" known as config heartbeats....The master
should pick up
this
> > message
> >> >> and
> >> >> pass it on to the xPL network....In xPL Manager
under xPL
> >> >> devices,subfolder
> >> >> awaiting configuration the device should be listed
clicking on
> > it then
> >> >> allows you to configure....The config info would get
send to
the
> > Master
> >> >> which passes it on to the new unit which would
reconfigure its
> > self and
> >> >> immediately send out a regular heartbeat.....
> >> >> Hope that makes sense ??
> >> >>
> >> >> Frank
> >> >>
> >> >>
> >> >> ----- Original Message -----
> >> >> From: "Neil Wrightson" <neilw@n...>
> >> >> To: <ukha_xpl@xxxxxxx>
> >> >> Sent: Tuesday, January 25, 2005 7:21 AM
> >> >> Subject: RE: [ukha_xpl] Re: Serial protocol
questions
> >> >>
> >> >>
> >> >>>
> >> >>> Hi Lehane,
> >> >>>
> >> >>> 1) I made reference to the compiler I use purely
because it
is
> > a good
> >> >>> compiler. Each different type of slave could be
a completely
> > different
> >> >> micro
> >> >>> and language - assembler, C, Basic Pascal etc
etc. The main
> > thing is
> >> >>> that
> >> >>> handles its own task and interfaces to the
required 485
network
> >> >>> protocol.
> >> >>>
> >> >>> 2) Presumably the host software will do the
device/instance
id-
> >>node
> >> >>> number conversion and the device/instance
config? - Don't
know
> > what this
> >> >> is
> >> >>> yet ???
> >> >>>
> >> >>> 3) "Mmm!
> >> >>> I'd caution against making the devices too
complex. Better
have
> > 10
> >> >>> types (smaller/cheaper) than 1 do-everything and
they are
> > likely to
> >> >>> see the light of day faster. You can always put
two/three/four
> > in one
> >> >>> box." - Exactly
> >> >>>
> >> >>>
> >> >>> 4) "So I'd go for:
> >> >>> 1 n-way DC input (maybe analogue) variations can
include
on/off,
> >> >>> momentary, dimmer action, etc.
> >> >>> 2 n-way DC output (maybe PWM on some for LED's)
variations -
> > opto,
> >> >>> SSR, etc
> >> >>> 3 LCD display driver
> >> >>> 4 RFID (...and RFID to me is EPC/ISO 18000)
> >> >>> 5 Universal IR (UIRT on 485)
> >> >>> 6 Dallas touch and/or one wire sensors
> >> >>> 7 MSR (Track 1/2/3)
> >> >>> 8 Bar Code Reader (UPC/EAN/ITF/Code 39)
> >> >>> 9 Analog input/output (0-5/10V)
> >> >>> 10 .... "
> >> >>>
> >> >>> A) I was thinking of analogue inputs for
switches etc, adds
> > additional
> >> >>> security to remote switches I.e. window reed
switches or
PIR's
> >> >>>
> >> >>> B) What is "EPC/ISO 18000"
> >> >>>
> >> >>> C) What is MSR (Track 1/2/3)
> >> >>>
> >> >>>
> >> >>>
> >> >>> 5) "Agree on the power to the unit,
although 12-15V maybe
> > sufficient as
> >> >>> the power consumption is going to be pretty low
on most.
> >> >>> Not sure about the audio..I think that belongs
on Ethernet in
> > the
> >> >>> digital domain. I guess you're looking at
voice/audio
feedback
> > but
> >> >>> would you want output from every device? Or
would you command
> > each
> >> >>> amp on? "
> >> >>> RS485 Cabling is generally as per the old coax
10base2, one
> > long line
> >> >>> with
> >> >>> terminators on either end.
> >> >>> With up to 32 devices on this line, that means
64
connections,
> > each with
> >> >>> it's own voltage drop. The higher you can have
the supply
> > voltage the
> >> >>> less
> >> >>> current in the supply lines the less voltage
drop on the
cable
> > and the
> >> >> less
> >> >>> impact of voltage drops on the network
connectors.
> >> >>> A lot of filed devices requires 12VDC so you
would at least
> > have to add
> >> >> 50%
> >> >>> i.e. 18VDC for the interconnecting power supply.
I know of
lots
> > of off
> >> >>> the
> >> >>> shelf 24VDC supplies out there. But, I think
that as long as
we
> > design
> >> >>> the
> >> >>> system so that it can handle from 12..24VDC, we
can leave it
up
> > to the
> >> >>> individual.
> >> >>>
> >> >>> 6) As far as the audio goes, my intention was
that we use the
> > speaker
> >> >>> out
> >> >> of
> >> >>> the HA pc. Nothing fancy.
> >> >>> I see this as been a separate plug in add on
board to the
main
> > slave
> >> >>> terminal with a small amp etc.
> >> >>>
> >> >>>
> >> >>> 7) RS485 Comms Speed
> >> >>> For each slave the master must Tx a message and
then Rx a
> > message. 32
> >> >> Slaves
> >> >>> times * 2 * Packet size of say ten characters =
640 bytes. At
> > 9600 baud
> >> >> this
> >> >>> would mean dial around would take 1.5 seconds.
In reality
this
> > would be
> >> >>> somewhat longer with internal delays etc. Hence
the reason
that
> > I
> >> >> suggested
> >> >>> 38400 baud. I know basic chips may have issues
with this.
Again
> > perhaps
> >> >> user
> >> >>> definable 9600/38400.
> >> >>> Build the network to your own needs.
> >> >>>
> >> >>>
> >> >>> Neil.
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> written in a completely differant language or
> >> >>>
> >> >>>
> >> >>> Regards,
> >> >>>
> >> >>> Neil Wrightson.
> >> >>> -----Original Message-----
> >> >>> From: g8kmh [mailto:lehane@m...]
> >> >>> Sent: Tuesday, 25 January 2005 12:46 AM
> >> >>> To: ukha_xpl@xxxxxxx
> >> >>> Subject: [ukha_xpl] Re: Serial protocol
questions
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> I've dropped my response in below.
> >> >>>
> >> >>> Lehane
> >> >>>
> >> >>> --- In ukha_xpl@xxxxxxx, "Neil
Wrightson"
<neilw@n...>
> > wrote:
> >> >>> > Hi Guys,
> >> >>> >
> >> >>> > 1) I'm all for a combined project.
> >> >>> >
> >> >>> > 2) I don't want to start another mine is
better than yours
> >> >>> discussion, but,
> >> >>> > I use AVR's :) I have a great compiler
AVRCo with true
> > multitasking
> >> >>> etc
> >> >>>
> >> >>> To some extent it is irrelevent to most
end-users. Few are
> > going to
> >> >>> change code, some will want prog'ed devices and
most a kit
(or
> > at
> >> >>> least PCB and CPU).
> >> >>>
> >> >>> The protocol outline is doable across a wide
range of
devices,
> > indeed
> >> >>> it needs to be interoperable.
> >> >>>
> >> >>> >
> >> >>> > 3) I think that a dedicated 485 network
controller will be
> >> >>> required. I think
> >> >>> > the 485 comms will probably run about 38400
baud.
> >> >>> >     A 16MHz AVR will happily look after
this.
> >> >>> >     The network controller will pass and
receive all state
> > changes
> >> >>> to the PC
> >> >>> > as well as heart beats for each device.
> >> >>> >     Comms to the PC could be 9600.
> >> >>> >
> >> >>>
> >> >>> A separate controller has some advantages of
redundancy and
> >> >>> interfacing with Win* or *nix.
> >> >>>
> >> >>> With xPL not on the wire then heartbeats can be
different
> > internally
> >> >>> to externally.
> >> >>>
> >> >>> Presumably the host software will do the
device/instance id-
> >>node
> >> >>> number conversion and the device/instance
config?
> >> >>>
> >> >>>
> >> >>> > 4) I envisage that there be at least two
types of room
> > controllers
> >> >>> (Perhaps
> >> >>> > we should start by settling on some names
for these things)
> >> >>> >     a) Bedroom/kitchen/Living area
Controller wish list
> >> >>> >         Display,
> >> >>> >         Personnel Switches for lights,
sound muting etc,
> >> >>> >         Data entry method, Set room alarm
clock time etc
> > Sleep time
> >> >>> for
> >> >>> > lighting etc
> >> >>> >         IR Transmitter, Turn telly off when
I fall asleep
in
> > bed,
> >> >>> turn
> >> >>> > ceiling fan off etc etc
> >> >>> >         Personal ID method
> >> >>> >         Sound
> >> >>> >         Movement sensor interface
> >> >>> >         Switch inputs for door & window
reed switches
> >> >>> >
> >> >>> >     b) Basic room as in
garage/toilet/bathroom wish list
> >> >>> >         Personnel Switches for lights etc,
> >> >>> >         Sound
> >> >>> >         Movement sensor interface
> >> >>> >         Switch inputs for door & window
reed switches
> >> >>> >         Note - This is to be a cheaper
version, no display
> > only
> >> >>> beeper for
> >> >>> > sound alerts, maybe a IR receiver for
configuration ??
> >> >>> >
> >> >>> > Hardware Solutions for above
> >> >>> >         Display,
> >> >>> > 16*2 LCD with LED backlight OR maybe a
small graphic LCD,
> > could
> >> >>> display
> >> >>> > small icons for
> >> >>> >
> >> >>> > you have email, voice messages, phone
callers etc.
> >> >>> >         Personnel Switches for lights
> >> >>> etc,                             2..4
> >> >>> > Tactile switches I.e. small PCB mount
> >> >>> >         Light Control
> >> >>> > either 240V relay or triac, triac allows
dimming, great for
> > those
> >> >>> wee stops
> >> >>> > in the night
> >> >>> >         Data entry method,
> >> >>> > Universal TV remote. I can currently decode
Sony or RC5
> > signals
> >> >>> >         IR Transmitter
> >> >>> > IR led on controller as well as capability
to add an
external
> > IR
> >> >>> led else
> >> >>> > where in the room
> >> >>> >
> >> >>> > for better coverage if needed, I.e. Living
room with
external
> > LED
> >> >>> for Stereo
> >> >>> > etc.
> >> >>> >         Personal ID method
> >> >>> > Dallas 1 wire ibutton, A lot cheaper &
smaller than RFID!
> >> >>> >         Sound
> >> >>> > 2 Types, 1) Standard beeper. 2) Optional 1W
speaker with
sound
> >> >>> relaying from
> >> >>> > controller Pc
> >> >>> >
> >> >>> > Probably a separate optional PCB.
> >> >>> >         Movement sensor
> >> >>> interface                                    As
> >> >>> > suggested either a integrated unit actually
on the
controller
> > or a
> >> >>> separate
> >> >>> > security PIR
> >> >>> >         Switch inputs for door & window
reed switches
> >> >>> Standard style
> >> >>> > of inputs on a micro 5..12V tolerant.
> >> >>> >
> >> >>> >         Power Supply and Signal
> >> >>> >             I suggest that we use CAT5
> >> >>> >             Power - 2 Pairs 1 pair for 0V
and one pair for
> > +24V.
> >> >>> >             Comms Signal  - 1 Pair
> >> >>> >             Audio from PC - 1 Pair
> >> >>> >             If we try to use the standard
pin outs for
power
> > over
> >> >>> Ethernet
> >> >>> > and data signals, nothing will be damaged
if
> >> >>> >             a wrong device is plugged in
somewhere.
> >> >>> >             Although, I did see these
devices as being
panel
> >> >>> mounted on the
> >> >>> > walls.
> >> >>> >
> >> >>> Mmm!
> >> >>> I'd caution against making the devices too
complex. Better
have
> > 10
> >> >>> types (smaller/cheaper) than 1 do-everything and
they are
> > likely to
> >> >>> see the light of day faster. You can always put
two/three/four
> > in one
> >> >>> box.
> >> >>> So I'd go for:
> >> >>> 1 n-way DC input (maybe analog) variations can
include
on/off,
> >> >>> momentary, dimmer action, etc.
> >> >>> 2 n-way DC output (maybe PWM on some for LED's)
variations -
> > opto,
> >> >>> SSR, etc
> >> >>> 3 LCD display driver
> >> >>> 4 RFID (...and RFID to me is EPC/ISO 18000)
> >> >>> 5 Universal IR (UIRT on 485)
> >> >>> 6 Dallas touch and/or one wire sensors
> >> >>> 7 MSR (Track 1/2/3)
> >> >>> 8 Bar Code Reader (UPC/EAN/ITF/Code 39)
> >> >>> 9 Analog input/output (0-5/10V)
> >> >>> 10 ....
> >> >>>
> >> >>> Agree on the power to the unit, although 12-15V
maybe
> > sufficient as
> >> >>> the power consumption is going to be pretty low
on most.
> >> >>> Not sure about the audio..I think that belongs
on Ethernet in
> > the
> >> >>> digital domain. I guess you're looking at
voice/audio
feedback
> > but
> >> >>> would you want output from every device? Or
would you command
> > each
> >> >>> amp on?
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> 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
> >> >> 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
> >> > 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
> > 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