Hi Sven,
Well currently I'm not sure if it matters or not. I only noticed this yesterday when looking at a scope trace of i2c activity with the sensor. What I've seen so far is that after a read of the device the data pin is held low by it, for a short period (less than 1ms). Having said that this is after the end of a transaction so the clock is not running and we have not attempted to initiate a new transaction by putting a start state on the bus. So there may or may not be an issue (and if there is an issue it may only exist when other sensors share the same bus), it was just something else that Chris could try.

I'm still working on this and I hope to have access to a couple of the Mindsensors devices for testing in the next week or so...

As I said before the big issue is with the pull up resistors, if you have more than one set on the bus then things are very marginal....

gloomyandy wrote:Hi Sven,Well currently I'm not sure if it matters or not. I only noticed this yesterday when looking at a scope trace of i2c activity with the sensor. What I've seen so far is that after a read of the device the data pin is held low by it, for a short period (less than 1ms). Having said that this is after the end of a transaction so the clock is not running and we have not attempted to initiate a new transaction by putting a start state on the bus. So there may or may not be an issue (and if there is an issue it may only exist when other sensors share the same bus), it was just something else that Chris could try.

I'm sorry, but I don't understand. From your previous comment I was concluding that the Ultrasonic-Sensor is blocking the I2C bus for a while and that things will become pretty messed up, if we put a start state on the bus while the Ultrasonic is still pulling the data pin to low.

gloomyandy wrote:I'm still working on this and I hope to have access to a couple of the Mindsensors devices for testing in the next week or so...

As I said before the big issue is with the pull up resistors, if you have more than one set on the bus then things are very marginal....

Would it help, if we'd knew all the pull up resistors on the bus? Would it be possible, to adjust the voltages to a proper level?

I'm saying I'm not sure what is happening at the moment. I briefly saw the Ultrasonic sensor driving the data line (to zero) for a short period after a read completes. I've not had chance to go back and repeat this, but given that Chris is experimenting with this I thought it was worth trying a small delay between the two operations to see if this might have any impact. Certainly such a delay will do no harm...

I don't think there is anything we can do if there are too many pull up resistors on the bus. The problem seems to be with the 0V level, we are already driving this at 0V, but there is then a resistor between the Arm chip and the external connector on the NXT. This means that the external pull up resistors raise the voltage seen by the external device, the more pull ups the more it gets raised, and at some point the device no longer sees a 0 as a 0... The only thing we can do from the NXT side would be to turn on the internal pull ups but that would make things worse not better...

gloomyandy wrote:I don't think there is anything we can do if there are too many pull up resistors on the bus. The problem seems to be with the 0V level, we are already driving this at 0V, but there is then a resistor between the Arm chip and the external connector on the NXT. This means that the external pull up resistors raise the voltage seen by the external device, the more pull ups the more it gets raised, and at some point the device no longer sees a 0 as a 0... The only thing we can do from the NXT side would be to turn on the internal pull ups but that would make things worse not better...

That doesn't sound like the port splitter would actually work with any other firmware.

Am I right, that a normal I2C bus would have pull up resistors at the start and end of the bus, and not at each slave?

The port splitter should work with the Mindsensor sensors (plus one other I think) as they have some sort of mechanism (ADPA) to disable the pull ups. But at the moment that does not seem to be the case (at least with leJOS)! Normally there is only one set of pull ups on the bus. It is actually fairly unusual to use i2c with pluggable components like this, it is usually used to connect devices within a PCB. It would have made sense to have the pull ups on the NXT but by having them on the sensors it allows the same I/O lines to be used for other purposes (like analog line with the new color sensor), so I can see why Lego have done things this way. After all most people only want to use one sensor per port... Also having that extra resistor means that the NXT is protected from shorts etc. but it really causes problems for i2c...

I've just taken delivery of 3 mindsensors sensors so hopefully I should be able to try and get things working...

Hi Chris,
I've just made some pretty big changes to i2c. With these I can happily use the Mindsensors accelerometer and the Ultrasonic sensor on the same port. I did not need to enable the ADPA stuff. My version of the sensor is later than yours though (3.2). So if you are feeling brave and understand how to update to a snapshot (and the possible problems/risks of using it), then you could give it a try! One other thing, you may want to put your test code in a loop, I've seen (with other sensor combinations), the first request or two fail and then things settle down and start working. Oh and one other thing with this build we have changed how we handle i2c addresses to match how the rest of the Lego world uses them. So if you have set the address of your sensor using NXC or NXG to say address 8 then you now use 8 with leJOS rather than 4...

Thanks Andy, Sounds great! I will have a look at downloading the snapshot (perhaps this weekend). I might try to create an api for working with the port splitter (checking compatibility, assigning addresses, monitoring power consumption, ...).

I just got a reply from the Mindsensor support that it's not possible to change the i2c address of ultrasonsic sensors... How did you manage to do it and connect multiple ultrasonic sensors on a port splitter?

Chris was not using multiple ultrasonic sensors. He was using one ultrasonic sensor and other sensors from Mindesensors that do allow the address to be changed and so would not clash with the fixed address of the ultrasonic sensor.