Distance US3

I experienced some problems whith the Distance US3 Module;
I’m using a Spider mainboard, with Distance module connected on Socket 11 (through an Extender)
and a second one connected on socket 14.

No one is working…

It takes nearly 30 sec to get a measure through the “GetDistanceInCentimeters()” method, and I always get 7 as return value, and the SENSOR_ERROR property is -1.

Same result on both sensors.

Is there a driver problem, or something I miss to make it working ?

Do it works fine if you have one?

No, it’s the same thing

Here joind the shema I use.

Thanks for the support !

Can you please try it with nothing connected but the distance sensor?

It’s working correctly when alone…

Then, add devices individually and see what one introduces the issue. You should then remove the ones you add and just add that last device to see if it’s the combination of devices or really just that last one…

@ Brett - Yes in fact, it’s what I’m going to do since I have to find a solution.

But I need all that equipment on my mainboard, so whatever the component that makes it not working, I need all of them running.

So I hope in parallel, GHI will try in their labs to understand (and fix) the problem.

But I’ll do all my best to bring infos. I’m now going to sleep (European time…), but come back tomorrow with more infos I hope.

We will test on our end but providing info if possible will make the answer come sooner.

We are right on it.

It seems to happened (at least) when the GPS is connected.
I used :

  • GPS on socket 4 & 11 (tried both)
  • Distance on 14.

I also remark that the “shortest” detected distance is 7 cm

It seems also that the current_ACS712.Read_DC_Current() method is blocking the distanceUs3.GetDistanceInCentimeters() method.

I’ve no wire connected on the current ACS712 module, do I need to have effective current to check to make the method not being blocking ?

Anybody ?

If you’ve got a question about the ACS712 module as well, perhaps it would get more responses if it wasn’t in this thread.

My question is not really on the current module, the fact is that I asking myself if this problem could affect the Distance US3 process since they seems to be in conflict

If you think it’s blocking, then it would block anything on that thread, not directly related to the US3. Since you feel that this could be blocking your US3, then that tells me they are on the same thread.

Can you put the Read_DC_Current into its own thread?

Yes you’re right, I’ll do it once I finish my test (I probably not express myself correctly, i’m used to speak french…).

But my concern was mainly on the conflict. I expect to test the current module at the end of the week :wink:

Your English is much better than my French!

Did you (GHI Team) try on your side ?

Any feedback would be welcome… I’m starting to be troubled of having no response, not even an update status…

I believe in this technology, but I was hoping more support in case of bugs (which seems to be the case here), especially for giving us trust in building .NET Gadgeteer projects.

I’m actually building a really nice project which is actually blocked because of the component. I spent lots of money to buy your components, and I already cancelled a commercial project because of lack of support, which make me loose money.

I hope I won’t have to cancel this one too, because it would clearly take me off .NET gadgeteer.

It is on the list to look into but there are other higher priority items to look into.

By the way, the distance module driver is open source if you wanted to dig into it.

I am afraid that due to the real time requirements of the distance measurements and NETMF being not real time, the drivers will not properly if the system is busy, like when you have multiple modules. But we will have to confirm this.

Gadgeteer has much to offer, so I hope this small obstacle will not cover the great advantages found in gadgeteer.