slow serial receive on PC host-side, time-stamps delayed in PLX-DAQ, Bluetooth
BrooksL
Posts: 17
This isn't limited to the BASICstamp but nothing seemed to turn up searching all the forums and BASICstamp is what I was using when I discovered·the problem;
I've been using PLX-DAQ + WindowsXP + SP3 to record a stream of incoming data and put timestamps on the rows in the spreadsheet.
1) First trouble I experienced a while ago is that some rows/cells in the PLX-DAQ/Excel spreadsheet get loaded with corrupt data -·but there was actually nothing wrong with the data, baud rate, or serial signal integrity on the BASICstamp--PCport connection - I checked by listening with a second serial port.· The problem seemed to occur more frequently with increased speed, esp 56kb and 128kb.
1a) The problem seemed to occur only very rarely after changing from a wired connection to EasyBT Bluetooth module + Rocketfish USB Bluetooth adapter while feeding the EasyBT at 115.2kb and receiving at 128kb in PLX-DAQ.· Conveniently, the virtual UART interface on the PC side appears to deliver data at whatever virtual baud rate the PLX-DAQ macro requests; so, it appears the incoming data is well buffered by the virtual com port driver.
1b) Once in a while, something seemed to get corrupted on the PC side, causing lots of corrupted data to be·loaded in the PLX-DAQ spreadsheet.· The only fix seemed to be restarting the host PC since restarting PLX-DAQ did not solve it.··I'm not 100% certain but this problem·seemed to be·exacerbated by having many other applications running at the same time.
2) Time-stamps 'wrong' (significantly delayed from their actual time):· I noticed this recently when I was forced to switch Bluetooth USB adapters on the PC, from the Rocketfish to a Kensignton·adapter which is supposedly compatible with the same driver (and I got no complaints from WinXP·Device Manager);··According to the time stamps on the rows in·PLX-DAQ, I was·receiving ~130 samples/second with the Rocketfish BT adapter.· The time-stamps are generated·by a call to the WinXP system clock by the PLX-DAQ macro when it receives the TIME command·in the incoming DATA packet.···
··· Sometime after switching to the Kensignton·BT adapter, I noticed that according to the time-stamps, sample rate is only 80 samples/second.· However, the BASICstamp has not changed the rate at which is it sending packets.· I also can send data from·the BASICstamp for 10seconds·while the PLX-DAQ time-stamps have elapsed several more than 10seconds for the same data.
··· So, PLX-DAQ·appears to·be receiving data·through some·buffered significant delay.·· Of course, I expect some small delay between when the sample was sent and when it gets picked up by PLX-DAQ, but I would not expect additional delay between consecutive samples.
2a) Further,·I now see the corrupt data row issue a little more frequently - like a·corrupt row ever several hundred row or so (it's not·quite periodic).
So, has anyone seen this before and have·a·more detailed·explanation and/or solution?
I appreciate your insights!
-- BrooksL
I've been using PLX-DAQ + WindowsXP + SP3 to record a stream of incoming data and put timestamps on the rows in the spreadsheet.
1) First trouble I experienced a while ago is that some rows/cells in the PLX-DAQ/Excel spreadsheet get loaded with corrupt data -·but there was actually nothing wrong with the data, baud rate, or serial signal integrity on the BASICstamp--PCport connection - I checked by listening with a second serial port.· The problem seemed to occur more frequently with increased speed, esp 56kb and 128kb.
1a) The problem seemed to occur only very rarely after changing from a wired connection to EasyBT Bluetooth module + Rocketfish USB Bluetooth adapter while feeding the EasyBT at 115.2kb and receiving at 128kb in PLX-DAQ.· Conveniently, the virtual UART interface on the PC side appears to deliver data at whatever virtual baud rate the PLX-DAQ macro requests; so, it appears the incoming data is well buffered by the virtual com port driver.
1b) Once in a while, something seemed to get corrupted on the PC side, causing lots of corrupted data to be·loaded in the PLX-DAQ spreadsheet.· The only fix seemed to be restarting the host PC since restarting PLX-DAQ did not solve it.··I'm not 100% certain but this problem·seemed to be·exacerbated by having many other applications running at the same time.
2) Time-stamps 'wrong' (significantly delayed from their actual time):· I noticed this recently when I was forced to switch Bluetooth USB adapters on the PC, from the Rocketfish to a Kensignton·adapter which is supposedly compatible with the same driver (and I got no complaints from WinXP·Device Manager);··According to the time stamps on the rows in·PLX-DAQ, I was·receiving ~130 samples/second with the Rocketfish BT adapter.· The time-stamps are generated·by a call to the WinXP system clock by the PLX-DAQ macro when it receives the TIME command·in the incoming DATA packet.···
··· Sometime after switching to the Kensignton·BT adapter, I noticed that according to the time-stamps, sample rate is only 80 samples/second.· However, the BASICstamp has not changed the rate at which is it sending packets.· I also can send data from·the BASICstamp for 10seconds·while the PLX-DAQ time-stamps have elapsed several more than 10seconds for the same data.
··· So, PLX-DAQ·appears to·be receiving data·through some·buffered significant delay.·· Of course, I expect some small delay between when the sample was sent and when it gets picked up by PLX-DAQ, but I would not expect additional delay between consecutive samples.
2a) Further,·I now see the corrupt data row issue a little more frequently - like a·corrupt row ever several hundred row or so (it's not·quite periodic).
So, has anyone seen this before and have·a·more detailed·explanation and/or solution?
I appreciate your insights!
-- BrooksL
Comments
Of course, now I've now learned that I can't really trust the PLX-DAQ generated system time stamps because it's difficult to be sure PLX-DAQ is always getting the data at least as fast as it's coming in - and the time stamps are generated when PLX-DAQ gets the DATA statement, not necessarily when the DATA statement arrived in the host serial port buffer.
Oh well, that's what we get for trying to do real-time with programing tools far removed from the real hardware layers...
-- BrooksL
xBee and Bluetooth links have various latencies associated with them. In particular, they both buffer data and either transmit when the buffer is full or a timeout occurs. I don't know what the default timeout is, but it does introduce some delays. In addition, if an error occurs during transmission, it will be repeated until received correctly. This can add to the delays.