john, congratulations. you are correct in waiting until the scope of the irda task is evaluated. its a monster. that's why few have used it when it appears such a natural selection.

granted that i don't know your system architecture and have to make some guesses... as to resyncing data, why not let the palm utility and the pc do all the resyncing tasks and just let the 'device' & palm toss data between them?

your first area of attention might be the irda software protocol specification. its cryptic and convoluted with some committee intent.

the second area of attention is the resyncing algorithms. i'll assume you want to organize timestamp exception event reports and weed out those that have been processed or updated. another possibility would be to order the data from an unplanned hop to hop collection traverasal as someone collects the data from devices in the site.

in this task, the palm itself would best pre-order the data. its got a very powerful processor and lots of memory. the only reason to involve an external microprocessor (the 8051 or to-be-selected) would be that it holds a unique part of the information unavailable to the palm until they mate.

in most applications, its best to make the palm do the work. they way to make the '8051' do the work is to make it tokenize the data and only order those tokens to the records on the palm. there are few reasons to use this method instead of using the palm, except when data security protocols require it.

the irda/palm hardware and basic drivers are trivial. be aware that irda can consume a lot of battery power.

if you are usa-based and want some serious help, let me know. however, i'll continue to help via email within certain parameters, most important of which, is that you are not working for/with a competitor. hehehehe

duh

by the way: i did a pc-based software resyncing system that took railroad kleinschmidt reports and chronologically ordered and filtered them with railcar impact datalogger timestamped reports collected by on-arrival datacollectors. it blended instant kleinschmidt reporting on individual railcar index numbers to the datalogger report collected up to months later determine which railcarrier was responsible for the damage. i'd like to do a gps based system and am looking for a company that wants such a system. the different timezone and daylight savings time conversions are a sleeper in such designs, particularly when Arizona and Illinois have strange implementations of daylight savings time. hehehe