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: Re: Serial protocol questions


  • Subject: RE: Re: Serial protocol questions
  • From: "Neil Wrightson" <neilw@xxxxxxxxxx>
  • Date: Tue, 25 Jan 2005 22:09:38 +1100


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



_____


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.