> Hey Russell (king of the neat [OT]: posts),

Flattery will get you somewhere :-)

> 'phone home'.  My solution (though not yet tried), was to use the
'deviveID' of
> each unit.  Each one is 'uniquely' identified so the master can track temp
> results.  I was going to use this number to affect the retry timing.
>
> I was also thinking about some sort of passed token scheme.  The 'master'
would
> poll the remotes granting them permission to transmit.  This would involve
me
> configuring the master for each new device though.  Or maybe the nodes
could
> pass the token around (more configuration...)

A scheme I was going to try but never used (customer decided not to proceed
befor ewe got that far) was for a new node to be assigned a default address
eg 255. The master would poll this address at a low rate and any new devices
would acknowledge and be assigned a "real" adress. If collisons occurred
here a random backoff was used. (The proposed system was extremely bus
intensive with a large number of slaves and good utilisation of the bus was
vital. Slaves with data to send could ack with a single bit in the right
timeslot to allow the master to ignore them or service them as appropriate.
The system was conceptually full duplex (and very wierd half duplex in
actual implementation due to specialist environment) with slaves only
hearing the master and the master hearing all slaves but not itself).

> I'd like to look into self correcting streams too, sounds way over
> my head, but cool..
>  I figured I could try a few different schemes since this is really is
just for
> fun.


Self correcting (aka FEC = forward error correcting) is indeed fun but
usually very computationally or memory intensive - not a good match to most
PICs probably. Lookup "Reed Solomon" for ideas. For this sort of system odds
are that basic error checing (parity, Hamming, CRC, ...) is good enough with
an ARQ system (blocks are ACK'd or NACK'd or ignored if indecipherable and
are repeated in the latter 2 cases).



        Russell McMahon

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.