After the byte counting I figured it was time to check the duration of the requests. I used a stopwatch class which was an approximate equivalent of the full .Net BCL one from netduino.com.

My house is cabled with CAT5 and I have a patch panel in a hall cupboard with gigabit switch and ADSL modem (Fibre is coming to my street soon). The Netduino was plugged into one of the spare ports and was running MF V4.2.

I then timed 10 requests to gpstrackerhttpheaders.cloudapp.net
1780, 1512, 1621, 1516, 1617, 1544, 1672, 1618,1490, 1614
Average 1599 mSec

My initial thought was maybe name resolution was broken so I replaced the hostname in the MF client with its IP address

1099, 1006, 1182, 1006, 1008, 1104,1030, 1092,1002, 1170
Average 1070 mSec – faster but not great

I then built a quick ‘n’ dirty desktop console application for comparison purposes.

gpstrackerhttpheaders.cloudapp.net
965, 243, 246, 242, 242, 249, 240, 242, 241, 518
Average 343 mSec

IP Address
603, 247, 241, 240, 241, 240, 239, 253, 243, 251
Average 280 mSec

The desktop times tally with what I see with other client applications calling Azure instances in the Singapore, West US and South Central US data centres.

I then did some digging and found others with similar results. These durations would go some way to explaining why the NMEA stack was having problems with buffer over runs and data corruption.

Time to move the HTTP request code off to a separate thread. Then have a look at system.http with Redgate Reflector  and see if anything looks suspicious.