rharding64

on the PC host side, I have been doing much in creating c# terminal emulator applications along with design/build of electronic test fixtures to provide interface and test of the DUT since 2004. DataReceived should only be performing one job; take in the raw data and push into incoming queue. buffer. Once received, data can be parsed and pushed into individual bins based on requirements.

Primarily, particularly when talking with modem devices, you are concerned with sending command and getting back expected responses. Here you can detect whether you actually send out what you intended to and detect whether the response coming back from the DUT is what was expected. 

Secondly, there is also non-solicited, asynchronous data to contend with.  These are status indicators that can come at any time.  Push these into a separate set of bins. 

by applying various design patterns such as Singleton, Observer and others along with multi-threaded coding techniques provides ability for serial interface that captures both solicited and unsolicited data streams.

My last job dealt with NMEA GPS parsing.  I created c# based utility to test the GPS receiver in the new products. A figure of merit for GPS receivers is the 'TTFF' or 'time to first fix'. There are a series of 12 satellites where you are looking for the best RSSI signal strength results. This occurs across the top 4(since the fix is based the 4 dimensions of latitude, longitude, altitude and time). if you have specific questions i would be happy to answer them for you. 

Ron