Distance US3

I’ve forwarded your query to engineers

I’m sure gadgeteer has a huge potential, and that’s the reason why we are investing in R&D, and I clearly understand that it’s not a high priority bug since I’m probably the only one with that kind of configuration. I’m just asking to be informed on the “planning”.
As you, I need to plan our developments, and make all of that fit with our “delivery” planning.
In this cas it’s a drone prototype, and we have to make it flying for the end of June…

Where can I find the Distance driver ? I will clearly start debugging right now.

Thanks a lot !

Can you put together a code sample that shows the error with as little code as possible with just the Current and Distance modules?

Here is the code I used to test with only the GPS and the Distance module :

  GT.Timer tmTelemetry;

        void ProgramStarted()

 if (gps != null)
                    gps.Enabled = true;
                    gps.PositionReceived += new GPS.PositionReceivedEventHandler(gps_PositionReceived);
                    gps.InvalidPositionReceived += new GPS.InvalidPositionReceivedEventHandler(gps_InvalidPositionReceived);

tmTelemetry = new GT.Timer(250);
                tmTelemetry.Tick += new GT.Timer.TickEventHandler(tmTelemetry_Tick);

  void tmTelemetry_Tick(GT.Timer timer)
 void gps_InvalidPositionReceived(GPS sender)
            //Debug.Print("Invalid Position");

        void gps_PositionReceived(GPS sender, GPS.Position position)
          if (found) return;
            found = true;
            Debug.Print(position.Latitude.ToString() + "," + position.Longitude.ToString());       

@ GMISoft -

We have checked your code,

The problem is the distance module uses NETMF timer to measure distance.
while it is waiting for response signal, this time value will be changed (longer) if another threads are also running and that thread requires a lot of time to finish their function / commands.

Actually, to reproduce your issue, I don’t need to use Current or GPS modules, just make another thread, like this:

void ReadCurrent()
            while (true)
                //Debug.Print("Current: " + current_ACS712.Read_DC_Current().ToString());
                for (int i = 0; i < 0xFFFF; i++)
                    if (i % 100 == 0) Debug.Print("I don't want to share CPU " + i);

I explain it because in case you want to avoid this issue while you write code in the future.
Following your code that you posted, I modified the driver, so far it is good. But if your project has many threads are running, I highly recommend you should add a flag, and when you need to measure distance, this flag will be active. Once time this flag is active, all your thread should be pause until measuring distance is done. This way will give you more accurate number.

To modify the driver, go here:


Then, replace the function GetDistanceHelper() by this:

private int GetDistanceHelper()
            long start = 0;
            int microseconds = 0;
            long time = 0;
            int distance = 0;


            int error = 0;
            while (!Echo.Read())
                if (error > 1000)

            start = System.DateTime.Now.Ticks;

            while (Echo.Read()) ;

            time = (System.DateTime.Now.Ticks - start);
            microseconds = (int)time / TicksPerMicrosecond;

            distance = (microseconds / 58);
            distance += 2;

            if (distance < MAX_DISTANCE)
                if (distance >= MIN_DISTANCE)
                    return distance;
                    return MinFlag;
                return MaxFlag;


@ Dat, Thanks a lot for investigating my problem ! I’ll try that tomorrow (nearly midnight in Europe…)

So, to get the best of the components, the best way/practice is to only use them when it’s necessary.

I suppose it’s the same for Compass, Gyro and Accelerometer modules.

I keep you informed !

Thanks again !

have a look at the gps module. I notice often a buffer overflow using the gps / seeed gps driver, so I wrote my own one… The GPS is fireing a great number of nmea messages the hole time and maybe blocking the other modules… it’s to fast for the spider until you slow down the gps module

You’re right, and by the way I think I need to deeply check all components on the mainboard, to evaluate the load on the system.
I need “close to real time” processing, and I wrote my algorithms in this mind. I’m figuring that I’m too young in the gadgeteer world to be really efficient. I’ll do my work on that.

@ GMISoft - don’t know your code, but maybe you don’t need all NMEA messages and not every millisecond so you can control the ublox-gps-chip directly so it’ only fires the needed messages in the needed intervall. If you’r interested have a look ad codeshare.
http://www.ghielectronics.com/community/codeshare/entry/634 (vb code)
http://www.ghielectronics.com/community/codeshare/entry/655 (c# code)

questions…please ask…

I confirm It now seems to work ! I did not test all my code, using all modules yet, but my first tests are concluant ! :smiley:

Thansk a lot GHI Team !

@ VB-Daniel - Thanks a lot, in fact I don’t need more GPS Info quicker than 1 every 2-5 sec.

I’ll look at that code this week)end !

Thanks !

It would probably greatful to add a parameter in the native driver to set up the message frequency requested. It could certainly be profitable for the CPU availability.