search

ArduPilot / ardupilot

ArduPlane, ArduCopter, ArduRover, ArduSub source
http://ardupilot.org/
GNU General Public License v3.0
10.81k stars 17.26k forks source link

Airspeed: connecting two SDP3X not working #10305

Open aero4 opened 5 years ago

aero4 commented 5 years ago

Bug report

Issue details

I have a self-made SDP31 board with two SDP31 and each has its own I2C address (accomplished with the external resistor, the first sensor has the address 0x22, the second 0x23). Both sensors are working independently on I2C bus 0.

The problem is, that when ARSPD_TYPE and ARSPD2_TYPE are both set to “6” (SDP3X), then the first SDP31 is initialized two times (with address 0x22) and the logged value for ARSPD1 and 2 are the same.

When I uncomment the continue instruction from the SDP3X initialization (inside the "stop continuous average mode" if-instruction; line 77 of AP_Airspeed_SDP3X.cpp) in the source code, both sensors (with addresses 0x22 and 0x23) are recognized but only the second sensor is logged (first sensor only shows 0). So it seems that only one sensor is supported of the same type and the second one is overwritten.

Version 3.9

Platform [ ] All [ ] AntennaTracker [ ] Copter [x] Plane [ ] Rover [ ] Submarine

Airframe type Fixed wing

Hardware type Pixhawk 2 Cube

I am also interested in a temporary fix, because I need two airspeed sensors to be logged as fast as possible.

Thank you!

magicrub commented 5 years ago

@aero4 I took a glance at the data sheet and the driver and see that the addresses are 0x21, 0x22, 0x23. Have you tried using the first two instead of the last two? It shouldn't matter but it's worth a try.

aero4 commented 5 years ago

I bypassed the ground resistor and then UART says that two SDP31 Sensors with the address 0x21 were found...

magicrub commented 5 years ago

@aero4 so one device's addr pin (pin 9) was 0 ohm to grounded and on another device's pin was 1.2k ohm to ground and that resulted in two devices with address 0x21? Can you post the schematic?

aero4 commented 5 years ago

Yes, this is exactly what I did. And I don't think it were two devices, I think it took the first sensor twice... Schematic: sdp31mult-schematic (U1, R3 and R4 are left blank)

WickedShell commented 5 years ago

There is no way currently to specify the address on the SDP3X sensors. We always scan them all. The best that is currently supported is to put them on different I2C buses. We should really have an address parameter, but in the past we've simply made extra ARSPD_TYPE parameters to map out to a specific address.

magicrub commented 5 years ago

also, for the record, you should remove the 10k pullup. Pull-ups are always on the master.

aero4 commented 5 years ago

Unfortunatelly my SDP31 board does not allow different buses, is there a temporary fix which I can make?

As said beneath the picture R3 and R4 are left bank but thank you for the hint

WickedShell commented 5 years ago

The only temporary one I know of would be to make a patch like https://github.com/ArduPilot/ardupilot/pull/7313 which allowed the MS5525 address to be specified. (Or just add a ARSPD_ADDR param and if it's not 0 use that instead.

aero4 commented 5 years ago

I found a temporary solution for me: I created a new sensor called SDP3Xmult and assigned it to ARSP_TYPE 9. In the SDP3Xmult.cpp file I set all addresses to 0x00 except of 0x23. -> now i can log both sensors!

If anyone else has this problem here is a more detailed description:

Here are my SDP3Xmult files (ending .txt has to be removed): AP_Airspeed_SDP3Xmult.h.txt AP_Airspeed_SDP3Xmult.cpp.txt

Evan1010 commented 5 years ago

This seems similar to a user problem on Discuss a while back, where he could not get two 4525DSO sensors to read separately even when on separate I2C busses.

This could be problematic, if two sensors of the same type number cannot be used - I and a couple others were planning to test with dual UAVCAN airspeed sensors.

WickedShell commented 5 years ago

@Evan1010 yeah MS4525 will always scan all buses in the same order as I described on the other issue.

Evan1010 commented 5 years ago

@WickedShell So am I understanding correctly that - for the MS4525 driver - the I2C Bus parameter has no effect? This is what we had theorized with the afore linked Discuss topic.

For the other issue, are you referring to Pull Request #7313? If I understand correctly that it scans the buses 0 to n and grabs the first MS4525 it sees regardless of the bus parameter, I can see how that happens.

aero4 commented 5 years ago

Another problem, which is the main problem for the bug described here, is, that if a ARSP1 sensor is found at the address e.g. 0x22, this address is not flagged as occupied and therefore the same address (and sensor) is used for ARSP2...