The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


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

Re: Re: Serial protocol questions




Hi Neil

Nice list there ;-))



> 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

Ah No!! not another avr Programmer ;-))....Actually i did get some avr
development kit but it was too much to learn C and a new Processor so i
went
back to my pics and ...asm ;-)....


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

So would you be up for having a go at the main controller ???
*************************************************************************
Would need to get some feedback from the guys on the list and see if
firstly
they are interested in using an RS485 xPL Network  and secondly the sort of
things they would like .......
So Cmon guys some feedback please................
**************************************************************************
Hardware Solutions for above
>         Display,
> 16*2 LCD with LED backlight OR maybe a small graphic LCD, could
display
> small icons for

Have you seen those PLED ?? LCD,S.......no backlit and viewing angle is
qute
good........


>         Light Control
> either 240V relay or triac, triac allows dimming, great for those wee
stops
> in the night

What !!! No CBUS ;-))........Personally not too keen to develope 240v kit
!!!.......

> Universal TV remote. I can currently decode Sony or RC5 signals

I have done Sony decoding in asm, Sony and standard nec format in
Picbasic.....




>         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

Cat5 is a good idea although im starting to run out of points ....I use
them
for my ir hardware and probe system and now the temp sensors......

Why is 24v dc required ????

All sounds good

Frank



----- Original Message -----
From: "Neil Wrightson" <neilw@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Monday, January 24, 2005 5:28 PM
Subject: RE: [ukha_xpl] Re: Serial protocol questions


>
> 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
>
> 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.
>
> 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.
>
>
> Regards,
>
> Neil Wrightson.
> -----Original Message-----
> From: Frank Mc Alinden [mailto:fmcalind@xxxxxxx]
> Sent: Monday, 24 January 2005 12:29 PM
> To: ukha_xpl@xxxxxxx
> Subject: Re: [ukha_xpl] Re: Serial protocol questions
>
>
>
> Hi Ben
>             I was also thinking of having a little box in each room 
which
> has an lcd display , rfid reader and a small pir head for Occupancy
> detection.....Would be good to throw a few ideas around ...and  as you
say
> have a common rs485 protocol.......
>
> BTW..........Are you on the piclist ???
>
> Frank
> .
>
>
> ----- Original Message -----
> From: "DynamoBen" <ben@xxxxxxx>
> To: <ukha_xpl@xxxxxxx>
> Sent: Monday, January 24, 2005 9:56 AM
> Subject: RE: [ukha_xpl] Re: Serial protocol questions
>
>
> >
> > Neil,
> >
> > Your protocol design is very similar to what I had originally
planned
> prior
> > to stumbling across the xpl documentation.
> >
> > You made and interesting point that I had not thought about in my
design.
> I
> > had assumed that on the PC side of things I would just drop in an
> > RS232->RS485 converter and call it done. Now I'm contemplating
using a
pic
> > as a master and making the door locations slaves.
> > Would that makes sense? Is it worth the extra work?
> >
> > Additionally, I think what you're working on and what I'm working
on
could
> > be very complementary. Is it worthwhile to work together on
system
layout
> > and protocol so that both our devices "play" on the
same RS485 network?
I
> > think in doing that we will indirectly create somewhat of an xpl
standard
> in
> > that one plug-in can be created for all RS485 devices. That
plug-in
would
> > convert RS485 message into xpl network messages. Is my thinking
correct?
> >
> > -----Original Message-----
> > From: Neil Wrightson [mailto:neilw@xxxxxxx]
> > Sent: Sunday, January 23, 2005 6:06 AM
> > To: ukha_xpl@xxxxxxx
> > Subject: RE: [ukha_xpl] Re: Serial protocol questions
> >
> >
> > Frank,
> >
> > Firstly, I'm not sure if everybody is up to speed on RS485 comms.
RS485
> uses
> > 2 wires for the transmission of data. For simplicities sake, lets
treat
> the
> > two wires as one.
> > As you would appreciate, you cannot typically send and receive
data on a
> > single wire at the same time. Thus a master is required that
transmits
out
> a
> > signal, and at the same time slaves are awaiting a signal. When a
slave
> > receives a message specifically address to it, it then talks back
to the
> > master. The actual RS485 IC's in the master and slaves must be
changed
> from
> > Transmission mode to receive and back again for each sent
message.
> > Basically it goes like this -
> >
> > Master
> > Slave
> > 1) Set Master RS485 IC to Transmit mode
> > Set RS485 IC to Receive mode
> >     (Usually RTS signal on comm port)
> > 2) Transmit Message to Slave #03
> > Receive message
> > 3) Set Master RS485 IC to Receive mode (Usually RTS signal on
comm port)
> > If it was for me then process
> > 4) Wait for message from Slave #03
> > All of my messages require an acknowledge
> >     (Usually includes a timeout in case slave #03 does not
respond)
> > So set RS485 IC to Transmit mode and send message
> > 5) Optional delay
> > Set RS485 to Receive mode
> > 6) Goto 1) or poll extra slaves etc
> > Wait for next message
> >
> >
> > I use two different protocols depending on the application.
> > 1) PC to RS485 Devices
> > The communications are between the PC and the remote RS485 slave
devices.
> A
> > RS232 to RS485 converter is required for the PC.
> > This converter can be quite simple and does not require any
brains I.e.
no
> > processor.
> > Although optical isolation at this point is nice (Adds $$$ but
not much)
> > Basically the comms are as per above sample. The PC must be able
to
toggle
> > the RTS line for each transmission. Sounds simple but, the PC
software
> must
> > know when the last character has been completely sent out of the
UART in
> the
> > serial interface. Most PC's are at least double buffered, or even
8 or
16
> > character buffer. So doing something simple in Pascal like saying
> send(Ch);
> > SetRTS(Low); would be guaranteed to not work.
> > Having said that, the protocol I use is
> > 1    Stx                        Byte,#02
> > 2    Addr                      Byte 0..255    Note Generally
RS485
limits
> 32
> > devices to be connected to the bus
> > 3    Message Length     Byte              Allows messages up to
256 -
> > Message size
> > 4    Command              Byte              I.e.Clear LCD
display,
Obtain
> > I/O status etc
> > 5    Data if any             Variable size based on message
length.
could
> be
> > zero
> > 6    Checksum             Byte               Checksum of bytes
from Stx
to
> > Checksum location minus 1
> > 7    Etx                       Byte, #03
> >
> > Thus the minimum message sizes is 6 bytes if no extra data is
transmitted
> >
> >
> > 2) PC to Dedicated master to slaves
> > The first part of PC to dedicated master is as per the above
protocol.
The
> > big difference here is that the PC to master interface is RS232,
thus
none
> > of the waffle with concerns about the RTS handshaking lines being
changed
> > over at the wrong time. Just 3 wires Tx,Rx,0V.
> > The Master is a separate dedicated micro controller board that
talks
RS232
> > to the PC and talks RS485 to the slaves.
> > Here the protocol is somewhat different because of the features
within
the
> > dedicated micros
> > 1    Address                Byte or Word    - Well not quite
These
> > particular bytes are actually 9 bits in size
> > 2    Message Length    Byte
> > 3    Data                     Variable size based on message
length.
could
> > be zero
> > 4    Checksum
> >
> > Good points about this method are that the local RS485 network
can be
very
> > fast and the master is always aware of all changes. It then only
passes
> > state changes to the PC via the RS232 port. Usual delays in PC's
I.e.
> > disappearing for a second do not effect the RS485 comms.
> >
> > Both protocols use an address of 0 (Zero) for general
broadcasting of
> > messages to all devices. I.e. perform a master reset.
> >
> >
> > In other postings I have made reference to a remote RS485
terminal with
> LCD,
> > keypad, I/O, IR Tx & Rx etc that is under development.
> > What I plan is that basically this terminal will be a ROOM
terminal and
> have
> > some smart intelligence built in.
> > I.e.
> >     I/O Inputs for PIR's (Movement sensor) and door/window
switches
(These
> > will be interfaced to the lights for auto light control as well
as
> security)
> >     I/O Outputs for Lights, sound etc
> >     Audio Out - Thinking of relaying HAPC voice annunciations
> >     RTC for determining wake up alarms, sleep modes etc.
> >
> > My idea is that, even if the HAPC or the RS485 network is down a
person
> > should still be able to turn the lights OFF/ON etc NOT have the
house in
a
> > completely shut down mode and stumbling around in the dark.
> > Here I see that the slave room terminals will need to pass all
state
> changes
> > back and forth to the master and to the PC. BUT each slave must
be able
to
> > see an input change I.e. PIR picks up movement and it MUST then
turn on
> the
> > light. It can't wait for it to send a message to the PC saying
movement
> and
> > the PC then respond back with turn on the light.
> >
> > All of the above I do now in various forms. To me the embedded
side is
> easy.
> > Your PC xPL is a bit different. I could do a separate windows app
using
> > Delphi for the xPL IP socket to serial port connection but I
think it
> would
> > be better added into xPLHAL or something ???
> >
> > Well, time to go to bed. Work tomorrow :(
> >
> > Hey Frank, I just noticed your email is bigpond.net.au. Are you
in AUS?
> I'm
> > in the Newcastle region.
> >
> >
> > Regards,
> >
> > Neil Wrightson.
> >
> > From: Frank Mc Alinden [mailto:fmcalind@xxxxxxx]
> > Sent: Sunday, 23 January 2005 6:39 PM
> > To: ukha_xpl@xxxxxxx
> > Subject: Re: [ukha_xpl] Re: Serial protocol questions
> >
> >
> >
> > Hi Ben
> >             I was thinking if Neil already has a reasonably
simple and
> > robust  rs485 protocol for his kit , why not look at that and
take it
from
> > there ...???
> >
> > Frank
> >
> > ----- Original Message -----
> > From: <ben@xxxxxxx>
> > To: <ukha_xpl@xxxxxxx>
> > Sent: Sunday, January 23, 2005 5:52 PM
> > Subject: [ukha_xpl] Re: Serial protocol questions
> >
> >
> > >
> > >
> > >
> > > You make several compelling points. I do agree it might be
best to
> > > have a polling environment.
> > >
> > > I do also think that all HA items should share a similar
protocol
> > > schema. That was the precipitous of my question.
> > >
> > > Its sound like the RS485 network should have one standard
protocol,
> > > possibly similar to that of xpl, and then interface via a
host PC to
> > > xpl.
> > >
> > > So then, what protocol would work best? Is there a dominant
one to
> > > consider in the HA market?
> > >
> > >
> > > --- In ukha_xpl@xxxxxxx, "Neil Wrightson"
<neilw@n...> wrote:
> > > > Hi All,
> > > >
> > > > I have done a lot of comms work in the past, both RS232
and RS485.
> > > > RS485 really has to be a polled environment I.e. a
master with
> > > polled
> > > > slaves. I'm only just starting to look at Xpl at this
stage and it
> > > appears
> > > > that the heartbeat is a rather critical aspect to this
protocol.
> > > > I believe that the RS485 master should be aware of all
of it's
> > > slaves and
> > > > that the master sends a heartbeat to it's master
xXPLHAL??) for
> > > its self and
> > > > each of its slaves.
> > > > Perhaps xPLHAL should advise the master 485 device what
slaves it
> > > should be
> > > > talking to and what there functionality is.
> > > >
> > > > To me part of the question is, should the RS485 network
try to
> > > emulate xPL
> > > > or as suggested just use a proprietary protocol. I
already have
> > > proprietary
> > > > protocols in place so this would be easier.
> > > > But,
> > > > In my house I do not want to have multiple RS485
networks with
> > > separate
> > > > proprietary protocols. I will probably end up making
most of my own
> > > > hardware, but who knows I may wish to buy somebody
else's 485
> > > hardware item
> > > > I.e. RFID and connect it onto my network. This wont
work if we all
> > > have
> > > > separate 485 protocols.
> > > >
> > > > I think one of the early on questions is, What is the
master? Is
> > > it part of
> > > > xPLHAL I.e. a PC is the master or should there be a
separate
> > > standalone
> > > > master that talks to HAL via another serial connection.
If XPLHAL
> > > is the
> > > > master we need somebody that can handle the 485 comms
on the PC
> > > I.e. Rx,Tx
> > > > and a handshake line.
> > > >
> > > > By the way, I have already interfaced to RFID devices.
Most
> > > commercially
> > > > available RFID devices talk to other equipment via a
26bit weigand
> > > > interface.
> > > >
> > > > Regards,
> > > >
> > > > Neil Wrightson.
> > > > -----Original Message-----
> > > > From: Frank Mc Alinden [mailto:fmcalind@b...]
> > > > Sent: Sunday, 23 January 2005 8:08 AM
> > > > To: ukha_xpl@xxxxxxx
> > > > Subject: Re: [ukha_xpl] Serial protocol questions
> > > >
> > > >
> > > >
> > > > Hi Ben
> > > >
> > > >         No one that im aware of has done any xPL stuff
using rs485
> > > and i
> > > > have been pondering over the same questions that you
are currently
> > > asking,
> > > > as i have some rfid readers and i intend to have a
little xPL rs485
> > > > network......
> > > >
> > > > > 1) Should I be implementing xpl on this device via
serial?
> > > >
> > > > Can be done ok , but each device must generate hbeats
and on a
> > > rs485 network
> > > > ,multiple devices could send hbeats at the same time
..???
> > > >
> > > > > 2) What schema(s) should I be using?
> > > >
> > > > I would assume the control.basic..Sensor.basic could be
used here
> > > >
> > > > > 3) Would it be better to create a proprietary
protocol and have
> > > > > someone write a plug-in interface to xpl?
> > > >
> > > > Yes this is another option and i have done this with my
Probe
> > > system....
> > > > You still have the issue of devices sending data at the
same time
> > > therefore
> > > > getting corrupted messages unless the app polls each
device on the
> > > network
> > > > ...???
> > > >
> > > > > 4) What resources are available to use as a
reference beside the
> > > xpl
> > > > > official website.
> > > >
> > > > No rs485 resources that im aware of ....
> > > >
> > > > Frank
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: <ben@b...>
> > > > To: <ukha_xpl@xxxxxxx>
> > > > Sent: Sunday, January 23, 2005 6:24 AM
> > > > Subject: [ukha_xpl] Serial protocol questions
> > > >
> > > >
> > > > >
> > > > >
> > > > > I am in the midst of a project and was thinking
about making the
> > > > > device xpl compatible.
> > > > > The device is a magnetic card reader (credit card)
with and
> > > onboard
> > > > > relay to open an electrical door lock. The idea is
you would
> > > swipe a
> > > > > credit card this device sends the account number
to a host
> > > computer
> > > > > (via RS-485). The host determines if the account
is allowed
> > > access
> > > > > and opens or denies access appropriately.
> > > > > This device is run by a pic microprocessor.
> > > > >
> > > > > Questions:
> > > > >
> > > > > 1) Should I be implementing xpl on this device via
serial?
> > > > > 2) What schema(s) should I be using?
> > > > > 3) Would it be better to create a proprietary
protocol and have
> > > > > someone write a plug-in interface to xpl?
> > > > > 4) What resources are available to use as a
reference beside the
> > > xpl
> > > > > official website.
> > > > >
> > > > > Thanks!
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > xPL Links: http://www.xplproject.org.uk
> <http://www.xplproject.org.uk>
> < http://www.xplproject.org.uk <http://www.xplproject.org.uk>
>
> > > < http://www.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.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>
>  <
> > http://www.xpl.myby.co.uk <http://www.xpl.myby.co.uk>  <
> http://www.xpl.myby.co.uk
<http://www.xpl.myby.co.uk>
> >
> > > > > To Post a Message: ukha_xpl@xxxxxxx
> > > > > To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> > > > > To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> > > > > Yahoo! Groups Links
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > xPL Links: http://www.xplproject.org.uk
<http://www.xplproject.org.uk>
> < http://www.xplproject.org.uk <http://www.xplproject.org.uk>
>
> > > < http://www.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.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>
>
> > > > < 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/>
>
> > > > < 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/>
> < 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.xplproject.org.uk <http://www.xplproject.org.uk>
>
> > http://www.xplhal.com <http://www.xplhal.com>  < http://www.xplhal.com
> <http://www.xplhal.com>
>
> > http://www.xpl.myby.co.uk <http://www.xpl.myby.co.uk>  <
> http://www.xpl.myby.co.uk
<http://www.xpl.myby.co.uk>
>
> > > To Post a Message: ukha_xpl@xxxxxxx
> > > To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> > > To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > xPL Links: http://www.xplproject.org.uk <http://www.xplproject.org.uk>
<
> http://www.xplproject.org.uk <http://www.xplproject.org.uk>
>
> > http://www.xplhal.com <http://www.xplhal.com>  < http://www.xplhal.com
> <http://www.xplhal.com>
>  http://www.xpl.myby.co.uk
> <http://www.xpl.myby.co.uk>
> > < http://www.xpl.myby.co.uk <http://www.xpl.myby.co.uk> >
> > To Post a Message: ukha_xpl@xxxxxxx
> > To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> > To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> >
> >
> >
> >   _____
> >
> > Yahoo! Groups Links
> >
> >
> > * To visit your group on the web, go to:
> > http://groups.yahoo.com/group/ukha_xpl/
> <http://groups.yahoo.com/group/ukha_xpl/>
> > < http://groups.yahoo.com/group/ukha_xpl/
> <http://groups.yahoo.com/group/ukha_xpl/>
>
> >
> >
> > * To unsubscribe from this group, send an email to:
> > ukha_xpl-unsubscribe@xxxxxxx
> > <mailto:ukha_xpl-unsubscribe@xxxxxxx?subject=Unsubscribe>
> >
> >
> > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service
> > < http://docs.yahoo.com/info/terms/
<http://docs.yahoo.com/info/terms/>
>
> .
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > xPL Links: http://www.xplproject.org.uk <http://www.xplproject.org.uk>
> http://www.xplhal.com <http://www.xplhal.com>
> > http://www.xpl.myby.co.uk <http://www.xpl.myby.co.uk>
> > To Post a Message: ukha_xpl@xxxxxxx
> > To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> > To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > xPL Links: http://www.xplproject.org.uk <http://www.xplproject.org.uk>
> http://www.xplhal.com <http://www.xplhal.com>
> http://www.xpl.myby.co.uk
<http://www.xpl.myby.co.uk>
> > To Post a Message: ukha_xpl@xxxxxxx
> > To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> > To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
>
>
> 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.