Hello!

Thank you so very much for all your efforts, but now I have bigger, not necessarily better news. I kept thinking it was something I was doing that was screwing things up. I ran minicom for the heck of it again, and minicom exhibits the same behavior. It logged about 2066 bytes from the hardware and then just stopped receiving. I tried again and this time it stopped at 1715 bytes.

Does this effectively mean that there is something else the problem here and not the code?

wje_lq: thank you so much for your code and your time. I am going to take a look at it and see what I can get out of it.

Thank you,

Jay

At this point, I would consider downloading serlook, which gives you a good diagnostic way to look at your connection. In spite of it's somewhat clumsy GUI, it can show you the timeline of data sent and received, as well as a display of binary data in human-readable hex format. Perhaps it will reveal something. Also, I find C-Kermit to be a more flexible and robust tool for your kind of purposes than is minicom. Consider trying that, as well.
How would you describe, in general terms, the data stream which you are trying to log? Is it possible that you are required to respond to the device in a certain way, and this response is not correct?
--- rod.

Not necessarily. It could depend on interaction between how you've used minicom to configure the line (for example, is software flow control set? it shouldn't be) and the actual data being transmitted.

But I wouldn't rule out other factors, either.

theNbomr: Thank you for serlook. I am going to compile it(its KDE only, and I am on a gtk thing, so need to dl kde libs etc) and test it out. Looks very useful with its event based view.

wje_lq: My minicom settings accurately reflect my settings, however the setting might be the problem as well. Hard to tell. I am going to give serlook a chance and then update here.

Thank you both for your time.

Jayanth