The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024

Latest message you have seen: Re: xPLRioNet - Test Volunteers


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Serial protocol questions





OK,
I'm used to IBM Bi-sync and derivatives which put the CRC after the
ETX and here's no 'length' field in the header.

The 9 bit address is quite useful and some CPU's have special support
for it. Maxim do an add-on (MAX3100) which helps reduce PIC
overheads, see http://pdfserv.maxim-ic.com/en/an/AN1063.pdf
and here
with code http://www.edn.com/article/CA179575.html

At 38k4 and a maximum of 32 addresses then latency shouldn't be a
problem.

Lehane


--- In ukha_xpl@xxxxxxx, "DynamoBen" <ben@b...> wrote:
> Excellent I'm with you on this. Sounds reasonable. The only thing
I'm
> grappeling with is the 9 bit address...I'm not understanding it
> conceptually. This would mean making the Device address a WORD
variable
> instead of a byte. Is that worth it?
>
> As far as the bridge protocol is everyone feeling comfortable with
it? Will
> it be possible to create a xpl ethernet-->rs485 bridge plug-in?
> ----- Original Message -----
> From: "Neil Wrightson" <neilw@n...>
> To: <ukha_xpl@xxxxxxx>
> Sent: Tuesday, January 25, 2005 5:09 AM
> Subject: RE: [ukha_xpl] Re: Serial protocol questions
>
>
> >
> > Hi Guys,
> >
> > The two protocols I originally listed are typically for TWO
different
> > purposes
> >
> > The first protocol
> > 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
> >
> > Is good for PC to "Bridge" applications. Normally I
read in all
bytes
> > until
> > the ETX is reached, check my STX to ETX length and compare
against the
> > message length (Byte(3) and also check the Checksum. This gives
two forms
> > of
> > error checking Length and Checksum. The checksum is just the
addition of
> > all
> > bytes from STX to Checksum position -1.
> >
> >
> > The second protocol is GREAT for inter micro comms. The Address
is
> > transmitted as a 9 bit byte. When the micro receives a nine bit
byte an
> > interrupt is generated and the address is checked to see if the
message is
> > intended for it. If the message is not intended for it, it then
goes off
> > and
> > has a scratch of it's bum or what ever else it wants to do. If
the message
> > was intended for it, it then captures the rest of the data. This
really
> > cuts
> > down on the slaves processing of messages that are not intended
for it.
> > The other reason for 9 bit addressing is that the messages can be
smaller
> > i.e STX and ETX are not required. The address is the STX (Syncing
> > character)
> > and address combined into one.
> >
> > 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
> >
> > The main reason that I suggested a 38400 baud rate was because of
> > potential
> > latency problems. With the 485 network running at this speed and
only
> > state
> > changes being passed between the PC and xPLHAL I think we would
have quite
> > good responses. The comms between the Bridge and xPLHAL could
also be
> > lifted.
> >
> > As far as slave devices, I always said right from the start I
suggested
> > that
> > at least TWO devices be made one with LCD, IR Tx,Rx for living
> > room,Kitchen,
> > Lounge etc the other without for toilet, kitchen etc.
> > Even the more advanced LCD unit would still have some extra plug
options
> > i.e
> > Audio.
> >
> > Regards,
> >
> > Neil Wrightson.
> > -----Original Message-----
> > From: g8kmh [mailto:lehane@m...]
> > Sent: Tuesday, 25 January 2005 6:54 PM
> > To: ukha_xpl@xxxxxxx
> > Subject: [ukha_xpl] Re: Serial protocol questions
> >
> >
> >
> >
> > 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.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
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > 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
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >
> >
> >
> >
> >
> > 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

xPL Main Index | xPL Thread Index | xPL Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.