4

I have a GPS from u-blox.com with a USB-connection and driver. The driver installs a virual COM port that pops up when you plug the USB in. Using a hyperterminal I can then watch the flow of data from the GPS.

Then I want the data in my program, not so easy...

I have implemented some methods using the serialPort class to read from the GPS, but am unsuccessful. I have programmed several serial device readers and writers before in C#, but this one stops me.

As an example, the simple code in simpleSerial will not give you anything unless you unplug and replug the USB.

Have tried reading it with matlab, which works great, but as the rest of my program that needs the GPS data is in c#, that doesn't quite fix the problem.

Is there some high level C# things going on in the serialPort class that I can circumvent? Or is there any known problems reading USB-serialports, which I assume works like my GPS?

luvieere
  • 37,065
  • 18
  • 127
  • 179
user36927
  • 41
  • 1
  • 1
  • 4

9 Answers9

1

Got this from u-blox support.

The following hex command will force a watchdog reset on the GPS module.

B5 62 06 04 04 00 00 00 00 00 0E 64

this a low level command for the ARM7 uP in the GPS It works with all u-blox GPS receiver.

byte[] data = new byte[]{0xB5, 0x62, 0x06, 0x04, 0x04, 0x00,
                         0x00, 0x00, 0x00, 0x00, 0x0E, 0x64}; 
sp.Write(data, 0, data.Length);

It works for me.

jjxtra
  • 20,415
  • 16
  • 100
  • 140
1

If you can communicate with the GPS using HyperTerminal then in principle there's no reason why you shouldn't be able to in C#. Are you sure you've configured the serial port correctly, particularly the baud rate, data bits, stop bits, parity, and flow control settings?

You could use SysInternals PortMon tool to look at the low-level I/O and compare how HyperTerminal and your C# program each configure the serial port. Maybe this will provide some useful information.

ChrisN
  • 16,635
  • 9
  • 57
  • 81
  • Baud rate, data bits, stop bits, parity, and flow control has been quadruple checked:), and because the simpleSerial will read the data IF I unplug and replug the GPS, these settings should be on track. – user36927 Nov 13 '08 at 07:18
1

I have sucessfully used the SerialPort class in .Net 2 also with gps on a virtual comport. It seems your virtual comport driver is slightly off. If you can't locate a newer driver I would suggest you call the WinAPI functions for reading the serial port.

Take a look at this code for instance: http://www.codeproject.com/KB/system/SerialPortComm.aspx

sindre j
  • 4,404
  • 5
  • 31
  • 32
  • The example was in vc++, but I'll try together with http://msdn.microsoft.com/en-us/library/2d9wy99d.aspx to use the WinAPI functions. – user36927 Nov 13 '08 at 08:11
0

Not sure if this is the same issue you are experiencing.

I noticed that if the RX_FLAG is used with SetCommMask API, the GetOverlappedResult does not seems to returns after the first WaitCommEvent. It will appears that the API is waiting for something to happens until the com mask is reset (At least that is what I observed). However, there is still some data received if you go and read the port after which, the device does not respond any more. In this scenario, you would need to unplug and replug the device to get it to respond again.

However, if the RX_CHAR is used instead, the GetOverLappedResult returns with the correct status and the device works as per normal.

Hope this information helps.

0

The problem is that there is a bug in either the USB Serial port drivers or in Microsofts implementation of their SerialPort classes. I have had the exact same issues with USB to Serial adapters using chips made by Prolific (and hence drivers by Prolific).

I have not been able to narrow down the issue exactly but now that the .NET Framework source-code is available I will be trying to step into SerialPort and see what the problem is exactly.

A work around is to use a different Serial access class. Before .Net 2.0 I had written a SerialStream class and for some reason it seems to work fine with these same USB to Serial Adapters that the SerialPort class will not work with.

You can grab my class at http://www.6bit.com/download/SerialStream.zip I've provided this same code to some fellow GPS programmers over the years and they have also had success with it.

joshperry
  • 41,167
  • 16
  • 88
  • 103
0

I have used the following code to communicate over USB to an Arduino, it send and receives a byte from the Arduino. It's simple, and isn't talking to a GPS, but hopefully it will help somehow!

    public static byte ReadByte()
    {
        byte byteRead = new byte();
        SerialPort port = new SerialPort("COM3", 9600, Parity.None, 8, StopBits.One);
        port.Open();
        int byteValue = port.ReadByte();
        port.Close();

        byteRead = Convert.ToByte(byteValue);

        return byteRead;
    }

    public static void SendByte(byte packet)
    {
        SerialPort port = new SerialPort("COM3", 9600, Parity.None, 8, StopBits.One);
        port.Open();
        byte[] writeByte = new byte[1];
        writeByte[0] = packet;
        port.Write(writeByte, 0, 1);
        port.Close();
    }
Dan McClain
  • 11,780
  • 9
  • 47
  • 67
0

Got the same problem with a U-Blox GPS but managed to solve it by enabling the DTR and RTS properties. Now I can read the NMEA sentences just fine. One problem I found is that I still have to remove and replug my GPS to the USB port from time to time. Hope it helps.

-1

I ran into a similar problem in an application I was writing and the problem turned out to be that I was trying to us SerialPort.WriteLine which sends a \r\n to end the line when I really needed to just send \n. When I switched to SerialPort.Write with a \n appended to the end, everything worked as in HyperTerminal.

Jon Norton
  • 2,969
  • 21
  • 20
  • I don't have to write anything to the port to get output, it spews out when I start it. Also the nmea protocol uses carriage return and line feed. Unless the hyperterminal sends anything upon opening that I'm not aware off? – user36927 Nov 13 '08 at 07:22
-1

Try using handshakes/flow-control. They are also useful when employing a usb-serial adapter.