Pirie
asked on
Serial datacomm on Compact Framework using VB.Net 2005
I want to read data into my VB.Net 2005 program from a GlobalPoint GPS reeceiver on COM1 of my Intermec Pocket PC. I am opening the Comm port using:
infilehandler = CreateFile("COM1:", &HC0000000,0,0,3,0,0,).
and then reading bytes by using:
RetCode = ReadFile(Cint(infilehandle
This technique worked fine when I was reading from a Bluetooth GPS or an internal GPS in my WM6 computer. However, on the Intermec the GPS output I read is corrupted.
I think the problem is that the GlobalPoint GPS comes in through a physical Com port (not a virtual one as in Bluetooth) and that I am not programming the Baud Rate, No. data bits, No. stop bits and Parity (should be 4800,N,8,1).
Can anybody help me with code that couples these parameters to COM1? I've heard that SetCommState can play a role here but I can find no examples of its use under the Compact Framework..
infilehandler = CreateFile("COM1:", &HC0000000,0,0,3,0,0,).
and then reading bytes by using:
RetCode = ReadFile(Cint(infilehandle
This technique worked fine when I was reading from a Bluetooth GPS or an internal GPS in my WM6 computer. However, on the Intermec the GPS output I read is corrupted.
I think the problem is that the GlobalPoint GPS comes in through a physical Com port (not a virtual one as in Bluetooth) and that I am not programming the Baud Rate, No. data bits, No. stop bits and Parity (should be 4800,N,8,1).
Can anybody help me with code that couples these parameters to COM1? I've heard that SetCommState can play a role here but I can find no examples of its use under the Compact Framework..
ASKER
The GPS has its own software which has an Auto Detect button. When pressed, this gives 4800 baud. I can't change the baud rate in my VB.Net program since, as I said, it is not programmed.
Could it be that baud rate, parity etc. need to be programmed for this external GPS?
Could it be that baud rate, parity etc. need to be programmed for this external GPS?
normally you don't have to program baudrate, or in worst case, you can switch speed ONCE, with the supplied software.
Most GPSs come with 4800.
Also, ensure other software using GPS are closed when you try to use your application to read it, remember Windows Mobile doesn't close application when you press (X), but it just minimizes.
Most GPSs come with 4800.
Also, ensure other software using GPS are closed when you try to use your application to read it, remember Windows Mobile doesn't close application when you press (X), but it just minimizes.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi imarshad,
I have no reason for not using the System.IO.Ports namespace (or any other method) as long as it is sufficiently documented for use with the Compact Framework (meaning primarilly worked examples).
I am converting my application from Embedded Visual Basic to VB.Net 2005. In the eVB version, I successfully used the Microsoft CE Comm Control 3.0 in which the Comm1.settings="4800,N,8,1
Unaware of any other alternatives, I have tried to convert this to a combination of calling CreateFile (with "COM1" as the first argument) followed by calling ReadFile to read the data. The only example coding I could find on the web didn't set baudrate, databits, stopbits or parity (presumably the default values are used) so I tried that. Data was read in but it was corrupted. This looked to me like a framing problem that in eVB I used to correct using Comm1.settings="4800,N,8,1
So I went looking on the web for a VB.Net way of associating "4800,N,8,1" with ReadFile. I thought I had found the answer in Function SetCommState which uses a DCB. However, as is often the case, I found examples of using that with VB.Net for Desktop Applications but not for the "Compact Framework". Trying to improvise, I coded the DCB and SetCommState into my VB.Net app in a way that compiled and deployed on my PPC without any errors. Unfortunately, I didn;t notice any difference in the results so possibly the DCB is coded wrongly.
Can you advise? I can provide code snippets if needed.
I have no reason for not using the System.IO.Ports namespace (or any other method) as long as it is sufficiently documented for use with the Compact Framework (meaning primarilly worked examples).
I am converting my application from Embedded Visual Basic to VB.Net 2005. In the eVB version, I successfully used the Microsoft CE Comm Control 3.0 in which the Comm1.settings="4800,N,8,1
Unaware of any other alternatives, I have tried to convert this to a combination of calling CreateFile (with "COM1" as the first argument) followed by calling ReadFile to read the data. The only example coding I could find on the web didn't set baudrate, databits, stopbits or parity (presumably the default values are used) so I tried that. Data was read in but it was corrupted. This looked to me like a framing problem that in eVB I used to correct using Comm1.settings="4800,N,8,1
So I went looking on the web for a VB.Net way of associating "4800,N,8,1" with ReadFile. I thought I had found the answer in Function SetCommState which uses a DCB. However, as is often the case, I found examples of using that with VB.Net for Desktop Applications but not for the "Compact Framework". Trying to improvise, I coded the DCB and SetCommState into my VB.Net app in a way that compiled and deployed on my PPC without any errors. Unfortunately, I didn;t notice any difference in the results so possibly the DCB is coded wrongly.
Can you advise? I can provide code snippets if needed.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi Jaime,
Thanks for the tip. I'll get back when I've read the articles.
Thanks for the tip. I'll get back when I've read the articles.
I am not sure about VS2005 but in VS2008 they have provided a serial port control built on the System.IO.Ports.SerialPort
It is almost the exact replica of the VB6 or eVB version of MSComm control(usage wise)...
ReceivedBytesThreshold ----------> RThreshold (In eVB)
SerialPort1_DataReceived ------> OnComm (In eVB)
So it is almostly the same as in vb6 or evb..... I donot have VS2005 installed to be dead sure but I think it was also provided in the VS2005.
It is almost the exact replica of the VB6 or eVB version of MSComm control(usage wise)...
ReceivedBytesThreshold ----------> RThreshold (In eVB)
SerialPort1_DataReceived ------> OnComm (In eVB)
So it is almostly the same as in vb6 or evb..... I donot have VS2005 installed to be dead sure but I think it was also provided in the VS2005.
>>I am not sure about VS2005 but in VS2008 they have provided a serial port control built on the System.IO.Ports.SerialPort
not a namespace but a class, it was introduced in VS2005 with .net framework 2.0
not a namespace but a class, it was introduced in VS2005 with .net framework 2.0
ASKER
Hi imarshad and Jaime,
I replaced the Createfile/Readfile technique by SerialPort and the whole thing worked. Thanks both of you for the tips.
Maybe it's interesting to remark that the reason I used Createfile/Readfile in the first place was that I first ported my eVB application to VB .Net 2003 and SerialPort was not available there. Now, under VB .Net 2005, I've converted to SerialPort, which looks very similar to what I used in eVB. So I've gone from 'a Serialport lookalike' through 'Createfile' back to 'Serialport'. Never mind, put it down to experience.
Jaime,
I read the tutorial links you recommended but they mainly dealt with processing the NMEA information and not how to get the NMEA sentences in the first place (this was my real problem). Thanks all the same.
I replaced the Createfile/Readfile technique by SerialPort and the whole thing worked. Thanks both of you for the tips.
Maybe it's interesting to remark that the reason I used Createfile/Readfile in the first place was that I first ported my eVB application to VB .Net 2003 and SerialPort was not available there. Now, under VB .Net 2005, I've converted to SerialPort, which looks very similar to what I used in eVB. So I've gone from 'a Serialport lookalike' through 'Createfile' back to 'Serialport'. Never mind, put it down to experience.
Jaime,
I read the tutorial links you recommended but they mainly dealt with processing the NMEA information and not how to get the NMEA sentences in the first place (this was my real problem). Thanks all the same.
ASKER
My conclusions are that for the VB .Net >=2005 user the SerialPort technique is superior to the use of CreateFile/ReadFile for the following reasons:
(a) The definitions of settings like baudrate, parity, databits and stopbits are more accessible
(b) SerialPort resembles the MS Comm control available in embedded Visual Basic thus making it easier to port applications.
Out of curiosity however, I would still like to know how the SetCommState function could be used in the Compact Framework to define these datacomm settings for use with CreateFile/ReadFile. I feel sure that this must be possible and, if documented on the web would save other people time.
(a) The definitions of settings like baudrate, parity, databits and stopbits are more accessible
(b) SerialPort resembles the MS Comm control available in embedded Visual Basic thus making it easier to port applications.
Out of curiosity however, I would still like to know how the SetCommState function could be used in the Compact Framework to define these datacomm settings for use with CreateFile/ReadFile. I feel sure that this must be possible and, if documented on the web would save other people time.
Start trying with 9600. Other options: 19200, 2400, 1200