Re: Re: Serial protocol questions

["DynamoBen" <ben@xxxxxxxxxxx>]

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@xxxxxxx>
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@xxxxxxx]
> 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