Reading GPS through serial error

NETMF & Gadgeteer
1

Hi everyeone,

Newbie here. I have a GPS I bought here: http://www.parallax.com/Store/Sensors/CompassGPS/tabid/173/CategoryID/48/List/0/SortField/0/Level/a/ProductID/645/Default.aspx and have connected it to my COM1 port on my FEZ domino board. Everything is connecting and running fine except the part where I’m getting errors trying to read from that com port. Here’s my code:


public static SerialPort c1;
        static byte[] buffer = new byte[200];

        public static void Main()
        {
 #region Read GPS
            c1 = new SerialPort("COM1", 4800, Parity.None, 8, StopBits.One);
            c1.ReadTimeout = 0;
            c1.ErrorReceived += new SerialErrorReceivedEventHandler(c1_ErrorReceived);
            c1.Open();

            c1.DataReceived += new SerialDataReceivedEventHandler(c1_DataReceived);
            #endregion

            Thread.Sleep(-1);
        }

        static void c1_ErrorReceived(object sender, SerialErrorReceivedEventArgs e)
        {
            Debug.Print("COM Error: " + e.EventType.ToString());
        }

        static void c1_DataReceived(object sender, SerialDataReceivedEventArgs e)
        {
            Debug.Print("somethin workeded");
        }

I keep getting: “COM Error 1”. It keeps giving me those errors in spurts so I believe that the GPS is sending the data correctly. I’ve also been able to read all the data from my BASIC STAMP II controller with no problems. I guess my next question would be is the COM1 port TTL RS232 or is it EID RS232? I assumed it was the usual TTL but I’m not sure. Also, the error isn’t very detailed, is there more ways to trouble shoot this? Thanks!

2

All looks correct! A stupid question but are you sire you have it connected to the right pins?

Yes they are TTL

3

Not a stupid question. I checked and I have the ouput pin on the GPS device connected to the DI0 also marked as COM1 IN on the board and I assume I need to connect the output from the GPS to the input on the Domino. Its continuously sending large bursts of COM errors so I assume its getting [italic]something[/italic] just not something it can read. The default baud rate on the GPS is 4800 so I assume that I have that right. Any other ideas?

4

Well I tried a different approach:


            c1 = new SerialPort("COM1", 4800, Parity.None, 8, StopBits.One);
            c1.ReadTimeout = 1000;
            //c1.ErrorReceived += new SerialErrorReceivedEventHandler(c1_ErrorReceived);
            c1.Open();

            while (true)
            {
                int i = 0;
                while (i != c1.BytesToRead)
                {
                    //wait till all data is here
                    i = c1.BytesToRead;
                    Thread.Sleep(1);
                }

                Array.Clear(responce, 0, responce.Length);
                c1.Read(responce, 0, responce.Length);
                string resp_Str = new string(Encoding.UTF8.GetChars(responce));

                Debug.Print(resp_Str);
            }

This is now reading the GPS (its in the SIRF protocol format):

I’m wondering, why this wouldn’t work with the delegate method? Any ideas?

5

Can you connect a little wire from D0 to D1 and send something to see if you get it back?

Are you using the latest firmware?

6

Interesting! If you remove the error handler then does it work?

You will almost always have an error on the first byte coming in but then it will work fine after, right?

7

Hmm, very interesting. I tried this:


            c1 = new SerialPort("COM1", 4800, Parity.None, 8, StopBits.One);
            c1.ReadTimeout = 1000;
            //c1.ErrorReceived += new SerialErrorReceivedEventHandler(c1_ErrorReceived);
            c1.Open();
            c1.DataReceived += new SerialDataReceivedEventHandler(c1_DataReceived);
            Thread.Sleep(-1);



static void c1_DataReceived(object sender, SerialDataReceivedEventArgs e)
        {
            c1.Read(responce, 0, responce.Length);

            Debug.Print(new string(Encoding.UTF8.GetChars(responce)));
        }

and I’m getting the SIRF protocol coming through now. However it only works a few times and then it stops. When I change the DataReceived function like so:


static void c1_DataReceived(object sender, SerialDataReceivedEventArgs e)
        {
            Debug.Print("test");
        }

I only get one “test” so it looks like it only reads it once. I’m wondering if this is a result of the domino not being able to read the GPS or if this is an issue of communication between the domino and Visual Studio? I have very limited experience on this so this is just a guess.

8

I think I know what it is. For some reason you have to open the port after installing the handler for it to work (or before, I do not remember)

So group your interrupt installers and then try top open the port before or after.

9

hmm, well I tried attaching the delegates before and after but to no avail. It reads it for a few seconds and then just keeps giving me the following blocks of text in my output:

GC: 2msec 63756 bytes used, 624 bytes available
Type 0F (STRING ): 72 bytes
Type 11 (CLASS ): 912 bytes
Type 12 (VALUETYPE ): 36 bytes
Type 13 (SZARRAY ): 336 bytes
Type 15 (FREEBLOCK ): 624 bytes
Type 17 (ASSEMBLY ): 8892 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 1B (DELEGATE_HEAD ): 216 bytes
Type 1D (OBJECT_TO_EVENT ): 72 bytes
Type 1E (BINARY_BLOB_HEAD ): 50412 bytes
Type 1F (THREAD ): 768 bytes
Type 20 (SUBTHREAD ): 96 bytes
Type 21 (STACK_FRAME ): 1020 bytes
Type 27 (FINALIZER_HEAD ): 96 bytes
Type 31 (IO_PORT ): 108 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 600 bytes
Failed allocation for 5 blocks, 60 bytes

10

Hi hobeau
I had the same problem and it turns out that the program is correct. The GC dump is part of the debug stream and is totally normal.
Add this line in the top of your program

Debug.EnableGCMessages(false);
11

In this case Geir the the messages are good it shows a binary blob is taking up all the memory and is not being freed up properly.

Type 1E (BINARY_BLOB_HEAD ): 50412 bytes
Failed allocation for 5 blocks, 60 bytes

12

Thats a good call bstag.
But still, even if you didnt have the memory leak or what it is, the GC dump would still show up in your debug stream. And when I first encountered this I obviously thought it was something wrong with my code.

13

Thanks for the responses guys,

bstag I didn’t realize thats what that error meant. Thanks for cluing me in on that. I wonder if its because I’m not clearing my array in the delegate the way I am in the while loop. I’ll have to try that when I get home.

14

Ran into the same problem hoping you find out why on your own. It will help in the future if you do. If you get stuck just yell i can reproduce it easy enough here too.

15

ok let’s start from the begining:

Here:

You get error 1, if you look this up, it means buffer overflow. This is normal bceause above you are not reading the data. So buffers are getting full, nobody is reading them.

In here:

This should work fine!You are reading the data now! Try reading the entire thing, I think e.DataToRead.

In here:

[quote]GC: 2msec 63756 bytes used, 624 bytes available
Type 0F (STRING ): 72 bytes
Type 11 (CLASS ): 912 bytes
Type 12 (VALUETYPE ): 36 bytes
Type 13 (SZARRAY ): 336 bytes
Type 15 (FREEBLOCK ): 624 bytes
Type 17 (ASSEMBLY ): 8892 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 1B (DELEGATE_HEAD ): 216 bytes
Type 1D (OBJECT_TO_EVENT ): 72 bytes
Type 1E (BINARY_BLOB_HEAD ): 50412 bytes
Type 1F (THREAD ): 768 bytes
Type 20 (SUBTHREAD ): 96 bytes
Type 21 (STACK_FRAME ): 1020 bytes
Type 27 (FINALIZER_HEAD ): 96 bytes
Type 31 (IO_PORT ): 108 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 600 bytes
Failed allocation for 5 blocks, 60 bytes
[/quote]
Actually, I like GC messages because they helpful in many cases like this one!
If turn them off, you could miss a problem in your code. Only turn them off if needed.
Look closely at last line [quote]Failed allocation for 5 blocks, 60 bytes
[/quote]
You ran out of memory, this is why you had problems in previous code probably, so the GC messages found the problem for you.
Clean up your code and find where you are allocating a lot of memory (using new byte…) and they are not getting freed.
Start simple and keep adding code until you find what is causing this.

16

well guys the culprit seems to be the ReadTimeout. I set the timeout to 0 and that seemed to fix the issue. Seems as through there is a ton of data coming in very quickly and the buffers behind the scene are getting loaded up. At least thats what my inexperienced brain is telling me is the problem. I had the ReadTimeout set at 1000 and when I changed it to 0 it was fine. It didn’t affect the while(true) loop i think because I was doing all the reading/buffering myself but something to do with the delegates and whatever is going on behind the scenes seems to have caused an issue.