Bug UltrasonicSensor Calibrate ?

[HoppyFrod]

Hi

I have taken a look into the setCalibrationData() Method, which "This does not currently seem to work."

I was wondering if the problem why it is not doning the right thing at the moment is, that in this method

Code: Select all

private int setMultiBytes(int reg, byte data[], int len)
   {
      /*
       * For some locations that are adjacent in address it is not possible to
       * read the locations in a single write, instead we must write them
       * using a series of individual writes. No idea why this should be, but
       * that is how it is!
       */
      for (int i = 0; i < len; i++)
      {
         byteBuff[0] = data[i];
         int ret = sendData(reg + i, byteBuff,1);
         if (ret < 0)
            return ret;
      }
      return 0;
   }

the sendData Mthod of I2CSensors is used and not the one of UltrasonicSensor, which requieres an additional parameter (offset, I presume).

Changing

Code: Select all

int ret = sendData(reg + i, byteBuff,1);

to

Code: Select all

int ret = sendData(reg + i, byteBuff,0,1);


might fix that?

P.S.: I know my written english is, let's put it that way, not so good. I hope I was able to transport the meaning anyway.

[skoehler]

Here's that is being called:

Code: Select all

public int sendData(int register, byte [] buf, int len) {
        return sendData(register, buf, 0, len);
}

So as you can see, it calls the method that is overwritten by the one in UltraSonic sensor.

[HoppyFrod]

Yes, that is true. But that is the problem.
As you can see here,

Code: Select all

/*
    * Over-ride the standard send function to ensure the correct inter-command
    * timing for the ultrasonic sensor.
    */
   @Override
   public synchronized int sendData(int register, byte[] buf, int off, int len)
   {
      waitUntil(nextCmdTime);
      int ret = super.sendData(register, buf, off, len);
      nextCmdTime = System.currentTimeMillis() + DELAY_CMD;
      return ret;
   }

the send-method of the ultrasonic sensor is keeping a special timing.
It is not the offset I was worried about. Sorry for that misunderstanding.

[skoehler]

Yes, but I2CSensor.sendData(int, byte[], int) calls this.sendData(int, byte[], int, int) which is overwritten by UltrasonicSensor.sendData(int, byte[], int, int).
In result UltrasonicSensor.sendData(int, byte[], int, int) is already used.

[Aswin]

Hi,

I also tried to get the setCalibrationData to work with no success. I also directly used the overwritten sendData and tried both to update a single register as well as all three calibration registers. I also tried different operating modes (off, ping, continuous) and the effect of a reset. All without success.
One thing I noticed is that according to the driver the first calibration register is 0x4a, the datasheet states it is 0x50. 0x4a works for reading, 0x50 does not, reading 0x50 returns an error.

Furthermore I found out that you must read (or write) each command separately. You cannot read consecutive registers in one go, hence the fact that the calibration settings have to be read as three separate bytes by the driver. You can also not read an individual byte of one of the constants. I mean you cannot read just the second byte of the product ID.

My conclusion is that the US sensor does not have registers as we find on other digital sensors. What the datasheet calls an address should be interpreted as a command to the sensor. Also the datasheet contains at least two errors, the calibration read addresser are wrong and the calibration write addresses do not work.

I also found out that you can decrease the measurement delay quite a bit, there is a trade off with the maximum range though. But this is a different story.

[gloomyandy]

Hi,
All of the above sounds in line with what I found when I wrote the original code and tried to get as much of the sensor working as possible. At the time I searched pretty hard to find any evidence that anyone had ever got some of the more obscure modes working and failed to find it! I think the information contained in the comments is still correct but please feel free to update them with any new findings...

Andy