Soliciing suggestions for application design

[Byron Morgan]

Oren, thanks for your input.

The processing of captured data can be done without critical time
constraints, but it is important to get the timestamps right, as this is the
only way to reliably correlate responses to polls. The model you suggest is
pretty much what I had in mind, but I am not a C-savvy, so this will be
another hurdle if I have to resort to it (I'd probably get a friend to do
that part).



"Oren Tirosh" <oren-py-l at hishome.net> wrote in message
news:mailman.1048416577.10297.python-list at python.org...
> On Sat, Mar 22, 2003 at 09:33:37PM +0000, Byron Morgan wrote:
> > Greetings all,
> >
> > I need to build an app to do the following:
> >
> > 1. monitor two serial ports: port A polls for data, B carries responses
from
> > a population of 1000 mobile radios
> > 2. match polls to responses based on timing window (between .033 & .066
> > seconds) after poll is transmitted
> > 3. do something interesting to selected poll - response pairs
> > 4. forward results via inet (as telnet stream or cgi post, not decided
yet)
> >
> > Should I try to do it all in a single program, using threading (haven't
> > tried threading yet), or use a parent app to do the interesting stuff
and
> > two children to monitor the ports and supply the data? If the latter,
how
> > best to handle the interprocess comms? I haven't started experimenting
with
> > the live data yet, but it seems to me the single most important part
will be
> > to get the timing stuff right (can't be off doing something else while a
new
> > message is waiting to be read).
>
> The answer doesn't have much to do with Python.
>
> The 33 milliseconds requirement is a little tight for non real-time
> operating systems like Unix and Windows. You will get much better
> resolution most of the time, but it's not guaranteed. How hard is this
> real-time constraint? What is the cost of missing it? A radio system has
> a pretty high chance of data loss anyway so I guess it's not too much
> of a problem but when it does miss - do you *have* to know that you
> missed so you will not generate erroneous results? Is it ok to timestamp
> the message and do the rest of the processing at a more leisurely pace?
>
> A small C program (or two) running with locked memory and high priority
> could handle the low-level communication and timestamping. It can be
> connected to a Python program that generates and analyses the actual
> messages using popen or a tcp socket.
>
>     Oren
>
>