Hi
Im completely new to FEZ Domino and have only had the board for two days, but there is something I cant figure out.
I have a GPS (http://www.sparkfun.com/commerce/product_info.php?products_id=465 ) connected to the COM2 port (as the COM1 is used by an XBee). The communication seems to be ok but I get a ‘dump from the garbage collector about every 5 seconds or so. Can anyone explain what is going on?
Im using the code snippet from the brochure and the only thing I have changed is the baud rate from 9600 to 4800 in the driver. Any ideas?
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
GC: 3msec 19788 bytes used, 44592 bytes available
Type 0F (STRING ): 636 bytes
Type 11 (CLASS ): 1524 bytes
Type 12 (VALUETYPE ): 60 bytes
Type 13 (SZARRAY ): 2028 bytes
Type 15 (FREEBLOCK ): 44592 bytes
Type 17 (ASSEMBLY ): 12036 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 24 bytes
Type 1B (DELEGATE_HEAD ): 216 bytes
Type 1D (OBJECT_TO_EVENT ): 72 bytes
Type 1E (BINARY_BLOB_HEAD ): 252 bytes
Type 1F (THREAD ): 768 bytes
Type 20 (SUBTHREAD ): 96 bytes
Type 21 (STACK_FRAME ): 708 bytes
Type 27 (FINALIZER_HEAD ): 96 bytes
Type 31 (IO_PORT ): 108 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 1044 bytes
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
GC: 3msec 19788 bytes used, 44592 bytes available
Type 0F (STRING ): 636 bytes
Type 11 (CLASS ): 1524 bytes
Type 12 (VALUETYPE ): 60 bytes
Type 13 (SZARRAY ): 2028 bytes
Type 15 (FREEBLOCK ): 44592 bytes
Type 17 (ASSEMBLY ): 12036 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 24 bytes
Type 1B (DELEGATE_HEAD ): 216 bytes
Type 1D (OBJECT_TO_EVENT ): 72 bytes
Type 1E (BINARY_BLOB_HEAD ): 252 bytes
Type 1F (THREAD ): 768 bytes
Type 20 (SUBTHREAD ): 96 bytes
Type 21 (STACK_FRAME ): 708 bytes
Type 27 (FINALIZER_HEAD ): 96 bytes
Type 31 (IO_PORT ): 108 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 1044 bytes
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
GPS devices can take about a minute or a lot more to start transmitting the GPS data…until the satellite is found.
Also, you may not have it connected properly.
The easiest way to to connect the GPS (through RS232) to a PC and check if you see the data on a PC terminal.
Remember that FEZ gives you debugging. This is the million dollar feature to take advantage of it. Step in your code and see exactly what is happening.
using System;
using Microsoft.SPOT;
using GHIElectronics.NETMF.FEZ;
using System.Threading;
namespace GPS_test
{
public class Program
{
public static void Main()
{
FEZ_Extensions.GPS.Initialize();
int LatH, LatM, LongH, LongM;
bool north, east;
Debug.Print("Waiting for GPS data");
while (true)
{
DateTime gpstime = FEZ_Extensions.GPS.GetUTCDateTime();
if (gpstime != DateTime.MinValue)
{
Debug.Print(gpstime.ToString());
break;
}
Thread.Sleep(1000);
}
while (true)
{
if (FEZ_Extensions.GPS.GetPosition(out LatH, out LatM, out north, out LongH, out LongM, out east))
{
Debug.Print(System.Math.Abs(LatH).ToString() + "o" + LatM.ToString() + (north ? "N":"s") + "-" + System.Math.Abs(LongH).ToString() + "o" + LongM.ToString() + (east ? "E":"W"));
}
else
{
Debug.Print("Waiting for GPS data");
Thread.Sleep(1000);
}
}
}
}
}
The GPS has been taken out of an Arduino project and has worked flawlessly. The GPS has satellite lock and coordinates and gps time are correct.
This dump is from a cold start GPS;
Waiting for GPS data
Searching for satellites…
Searching for satellites…
Searching for satellites…
Searching for satellites…
Searching for satellites…
Searching for satellites…
Searching for satellites…
Searching for satellites…
GC: 2msec 18624 bytes used, 45756 bytes available
Type 0F (STRING ): 84 bytes
Type 11 (CLASS ): 1056 bytes
Type 12 (VALUETYPE ): 60 bytes
Type 13 (SZARRAY ): 1728 bytes
Type 15 (FREEBLOCK ): 45756 bytes
Type 16 (CACHEDBLOCK ): 180 bytes
Type 17 (ASSEMBLY ): 12036 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 1B (DELEGATE_HEAD ): 216 bytes
Type 1D (OBJECT_TO_EVENT ): 72 bytes
Type 1E (BINARY_BLOB_HEAD ): 252 bytes
Type 1F (THREAD ): 768 bytes
Type 20 (SUBTHREAD ): 96 bytes
Type 21 (STACK_FRAME ): 708 bytes
Type 27 (FINALIZER_HEAD ): 96 bytes
Type 31 (IO_PORT ): 108 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 1044 bytes
Searching for satellites…
Searching for satellites…
Searching for satellites…
Searching for satellites…
Searching for satellites…
Searching for satellites…
Searching for satellites…
08/20/2010 22:28:35
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
GC: 3msec 19788 bytes used, 44592 bytes available
Type 0F (STRING ): 636 bytes
Type 11 (CLASS ): 1524 bytes
Type 12 (VALUETYPE ): 60 bytes
Type 13 (SZARRAY ): 2028 bytes
Type 15 (FREEBLOCK ): 44592 bytes
Type 17 (ASSEMBLY ): 12036 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 24 bytes
Type 1B (DELEGATE_HEAD ): 216 bytes
Type 1D (OBJECT_TO_EVENT ): 72 bytes
Type 1E (BINARY_BLOB_HEAD ): 252 bytes
Type 1F (THREAD ): 768 bytes
Type 20 (SUBTHREAD ): 96 bytes
Type 21 (STACK_FRAME ): 708 bytes
Type 27 (FINALIZER_HEAD ): 96 bytes
Type 31 (IO_PORT ): 108 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 1044 bytes
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
I don’t think you actually have a problem here. Garbage collection (GC) always happens. It’s a .Net thing. What you’re seeing here is the GC messages in the middle of your “debug.print” stream. That is totally normal.
If you think you have any other problem, best explain a little more what you see and what you think you should be seeing. As Gus says, you can also dive into debug land with stepping through your code which may help you understand things.
That is great news Brett!
As the code works fine and the output is as expected I could not for the life of me figure out what was happening. Is this ‘random GC dump documented somewhere and is there a way to turn it off?
Thanks Brett
So even if you can, do you need to? At the end of the project, you may not be running the controller board connected to your PC with debugging going on unless you’re actually, well, debugging! Once you disconnect the debugger, either shift-F5 in Visual Studio, or unplugging the USB, you don’t see those messages
I think I’ve said this before - if you’re truly using the debug connection for debugging, then it may not matter (except for asthetics). If you are using the debug.print stream as actual input to something on a PC for instance, you may be better off connecting one of the serial ports and outputting data that way - that way no matter what happens, you can guarantee what actually data is sent and when.
[quote]Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data
58o50N-5o46E
Waiting for GPS data[/quote]
It’s great that you speak of this, because this is something I am wondering about.
Why is this happening? There is a 1 second sleep in the while loops, but why does it output like this?
Why data - waiting - data - waiting - data - waiting etc.?
To be honest I dont know why the GPS driver behaves like that.
I was building my own GPS driver when I first got the GC dump and thought it was some fault in my program. So I decided to copy the test program and the driver from the web to see what happened. As it turned out the GC dump was natural and no fault in my program so I finished that up instead.
