Walt, I don't doubt that the source data is 20K/Minute or greater, what I question is whether or not sending the 'source' is necessary? It seems to me that you are asking us to find ways to solve a problem, it often helps to step back and look at the problem and ask questions. I make my living as a consulting engineer, and I know I exasperate many of my clients on the first day I walk into a project because, rather than following their predetermined thought processes, I make it a point to question their thought processes. Basically, I define and solve problems, and help implement solutions for a living. It is not unusual for the solutions I engineer to differ greatly from my clients preconceived notions of what they initially thought they needed, but I do solve their problems.
What I question is whether or not we shouldn't look at technology solutions that for instance don't require transmission of 20K/Minute of text, but still solve the problem. Especially for a weather system (I've lived through hurricanes, and spent a fair amount of time in tornado alley as well, so I do understand the importance of this information to public safety), it seems that what we are monitoring is a changing system, we might be able to come up with a data model of it that may be a little more granular, be represented by a lot less data, and still get the job done. We often have more sensors and more precision available to us than we need to make decisions, sometimes we need to trim the data. When normal comms are functioning 100% sending the full data with the greatest precision possible is great, when the normal comms fail, we are left in a fall back position. If we allow our 'fall back data channel' to choke because we are trying to provide a 100% solution, haven't we failed our mission? What if we could condense or abbreviate our data stream significantly, wouldn't it be a worthwhile effort to pursue? Engineering is a discipline of making the appropriate economic trade offs, we live in an era of the information age where data memory, storage, and processing capacity are extremely cheap. Usually bandwidth is cheap as well, so we have a certain mindset about not spending effort or money to maximize its efficient use. In this case though, bandwidth isn't cheap, one could argue that from a public safety point of view, it may be the most precious of resources, which leads me back to my point... is it not possible to spend money and processing power on finding a way to greatly reduce the size of a data frame, thereby reducing the bandwidth requirements of the system? Isn't it possible that effort in this direction might yield the greatest overall system performance. 73, Erik KI4HMS DuBose Walt Civ AETC CONS/LGCA wrote: > Erik, > > Send me your E-Mail address and I will send you an 40K sample file of NWS > data in csv (delimited text format) that represents 2 minutes of WX radar > data. > > I would never want to send this to the entire net. > > Walt/K5YFW > Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/