mscomm unable to handle long streams?

hi all,

sorry if this has been addressed elsewhere and i overlooked it, but i've been looking for answers to his for days now - so if anyone can point it out or give an assist it'd be greatly appreciated.

i'm attempting to use mscomm to download via rs232 a long stream of data (now approx 100-500kB and later several MB) from an external device. the data from the external device is in good order - i am able to download endless streams with 3rd party freeware apps and can log the output for verification. that being said, let me give the symptoms from within my VB app.

i'm able to download data perfectly at 38.4k until a limit of approximately 4.8kB, at which point the app starts missing bytes. it doesn't garble bytes together or miss one byte and move on, it starts missing bytes at seemingly random intervals rather frequently, maybe one every 4-5 bytes is completely gone.

i've attempted to use both methods of data capture - polling and the _oncomm event. surprisingly i've had better luck with polling, however at nearly the same point in the download the app starts losing much more data than when event driven.

so far i have been able to improve the transfer success rate to nearly 120kB, but only after adding a 5ms delay between every four bytes on the transmitter's end, which is simply unacceptable. i've placed debug messages at every possible error, and frequently see "comEventRxOver" errors, however this seems unrelated to the problems i'm having with lost bytes, as it occurs very soon into the download and much more frequently. Also, after adding the pause in the xmit side of things, if i leave the app running - spitting the values into an excel sheet - i receive a stack overflow error.

i'm relatively new to vb, but have quite a bit of experience coding - mostly lower-level apps, C/++ and scripting. it seems like this is related to the receive buffer overflowing as well as stack issues, however i'm not aware of a way to manage the stack in vb - is there? i've increased the fifo buffers to the max values possible under the control panel. reducing them just seems to exacerbate the problem, so i suspect it's related.

i've posted relevant code snippets below - thanks a lot for any feedback.

the comm port setup:

Code:

---

Public Sub CmdStart_Click()
            ' setup com port
    With Comm
        .InputLen = 4
        .RThreshold = 4
        .RTSEnable = True
        .SThreshold = 1
        .Settings = CboRate.Text & ",n,8,1"
        .CommPort = Val(CboPort.Text)
        .PortOpen = True
    End With

    CreateWrkSht
End Sub

---

the _oncomm routine:

Code:

---

Private Sub Comm_OnComm()
    Dim strDump As String
   
    Select Case Comm.CommEvent
        ' Errors
        Case comEventBreak  ' A Break was received.
                OutputBox.Text = "comEventBreak"
                'Comm.PortOpen = False
               
        Case comEventCDTO    ' CD (RLSD) Timeout.
                OutputBox.Text = "comEventCDTO"
                'Comm.PortOpen = False
               
        Case comEventCTSTO  ' CTS Timeout.
                OutputBox.Text = "comEventCTSTO"
                'Comm.PortOpen = False
               
        Case comEventDSRTO  ' DSR Timeout.
                OutputBox.Text = "comEventDSRTO"
                'Comm.PortOpen = False
               
        Case comEventFrame  ' Framing Error.
                OutputBox.Text = "comEventFrame"
                'Comm.PortOpen = False
               
        Case comEventOverrun ' Data Lost.
                OutputBox.Text = "comEventOverrun"
                'Comm.PortOpen = False
               
        Case comEventRxOver  ' Receive buffer overflow.
                OutputBox.Text = "comEventRxOver"
                strDump = strDump & "***"
                'Comm.InBufferCount = 0
                'Comm.PortOpen = False
               
        Case comEventRxParity  ' Parity Error.
                OutputBox.Text = "comEventRxParity"
                'Comm.PortOpen = False
               
        Case comEventTxFull  ' Transmit buffer full.
                OutputBox.Text = "comEventTxFull"
                'Comm.PortOpen = False
               
        Case comEventDCB    ' Unexpected error retrieving DCB]
                OutputBox.Text = "comEventDCB"
                'Comm.PortOpen = False

        ' Events
        Case comEvCD  ' Change in the CD line.
       
        Case comEvCTS  ' Change in the CTS line.
       
        Case comEvDSR  ' Change in the DSR line.
       
        Case comEvRing ' Change in the Ring Indicator.
       
        Case comEvReceive ' Received RThreshold # of chars.
                strDump = strDump & Comm.Input
                Call logInput(strDump)
       
        Case comEvSend  ' There are SThreshold number of
                        ' characters in the transmit buffer.
       
        Case comEvEOF  ' An EOF character was found in the
                        ' input stream.
    End Select

End Sub

---

and the data logging:

Code:

---

Sub logInput(strDump As String)

    If Col = 9 Then
        Row = Row + 1
        RecCount = RecCount + 1
        Col = StartCol
    End If

    If Row > 32752 Then
        Row = StartRow
        StartCol = StartCol + 10
        Col = StartCol
    End If

    OutputBox.Text = "Record: " & RecCount
    ExcelDat.InsertValue Chr(Col + 96) & Trim(CStr(Row)), strDump
    Print #nFileNum, strDump

    Col = Col + 1
    strDump = ""

End Sub

---

alright, i think the problem is mostly solved.

i can dump the data into a text file without errors creeping in, so it seems like the execution time of the excel methods are causing the ISR to miss data.

I advice you to check the (hardware) handshaking!

this is definately not a handshaking issue.

And "comEventRxOver" means? And what is controlling the filling of the buffer?

the data is being uploaded from a micro i coded, and there is no handshaking - it's one-way communication. the buffer is filled as bytes are transmitted at 38.4k and i cannot believe that a dual p4 machine can't read data faster than that. the ISR called by the _oncomm event was being slowed down, or stopped by the routines calling excel... i am baffled as to why excel would be given priority over a hardware interrupt but it is, hence the rx buffer overflow error.

with the excel calls removed, i can download infinite streams of data without problems.

And that's your problem.
Without handshaking try lowering the baudrate. Or make a gap in the datastream and play with the "InBufferSize" / gap time. In that "gap" Windows gets some time to flush that buffer.