next topic »

[Reply #15 on:]

ok i was afraid that there is no other way than to get to an oszi. - hm i will try

ok - so simply said - using your programm:

1. load sketch on arduino
2. power off - and plug out Vcc from modul
3. power on arduino
4. wait a sec
5. plug in Vcc ( 3.3V) for the modul

as a lats try ?

but a realy big thanks to you so far that you bother to write this usefull programm !! 

[Reply #16 on:]

No, you cannot use the sketch I posted, you need to modify it for this last check.
You have to remove all delay()s in loop(), the rest probably should work.

If that doesn't work, it's not the stand-by handling that is causing troubles. Without a scope I would guess that the module is damaged.

[Reply #17 on:]

sry - wasnt at home to try it earlier.


but looks bad - commented out the "delays" in the loop, loaded the sketch with Vcc not connected to the sensor - restarted arduino and plugged in Vcc-Sensor - but no response on the SerialMontior

hm i just wonder i added in this loop

Code:

  while (res != 0)
  {
    Wire.beginTransmission(DSCP01_ADDRESS);
    Wire.write(0x70); // wake up
    res = Wire.endTransmission();
    println(res);
    Serial.println(res);
  }

the last line so that it should print me again the NAK - but i only get one response - do i have a missunderstanding what the written line should do ?


hm would there be a solution with a simple loop which and trial which runs through all possible adresses and if there is a result - an aknowledge - i print it

and maybe an second while or whatever which runs through different delay times in principle like that:

Code:

int time_var  // start from 10ms ...1s
int adr_var // start from logic "good" adress to an end adress

for(;;time++)   while no correct answer  <- time varialbe loop
{
    for(;; adr ++)  while no correct answer <- adr. varialbe loop
    {
         send and wait if response  like in your loop !=2  (an other value than NAK/2)
         
          if(correct response)  - JEAH ...do sth
    }
}

or doesnt that have any use - because that i didnt get an asnwer in the 2 test programms you wrote
me includes those cases ?

[Reply #18 on:]

Nick Gammon has such an I2C scanner on his page: http://www.gammon.com.au/forum/?id=10896

You may try that one, but I doubt that it will have another address, the datasheet clearly specifies 0x20 and 0x21 which translates to a 0x10 in 7-bit format.

[Reply #19 on:]

ok thx

hm i tried to run the prog but even it looks somehow not so well

i run this as you posted the link:

Code:

// I2C Scanner
// Written by Nick Gammon
// Date: 20th April 2011

#include <Wire.h>

void setup()
{
  Serial.begin (9600);

  Serial.println ();
  Serial.println ("test");
  Serial.println ("I2C scanner Scanning ...");
  byte count = 0;  
  
  Wire.begin();  
   ... (same as on posted link)

but at the first serial println it doesnt print the last letter of "test"

what could that mean ?

i only get

"tes"
and not even the second line

causes the (maybe broken) sensor modul troubles with the serial communication ?


------------------------------------------------------------------------------------------------------------------------------  add


modified it a bit and now i can see that it got stuck at adress 6:

with this changed code

Code:

// I2C Scanner
// Written by Nick Gammon
// Date: 20th April 2011

#include <Wire.h>

void setup()
{
  Serial.begin (9600);

  // Leonardo: wait for serial port to connect
  //while (!Serial)
  //{
  //}

  
  //
  Serial.println ();
  Serial.println ("test");
  Serial.println ("I2C scanner Scanning ...");
  byte count = 0;
  
  delay(1000);
  
  
  Wire.begin();
  
  for (byte i = 1; i < 120; i++)
  {
    Serial.println(i);
    delay(300);    
    
    Wire.beginTransmission (i);
    
    if (Wire.endTransmission () == 0)
    {
      /*
      Serial.print ("Found address: ");
      Serial.print (i, DEC);
      Serial.print (" (0x");
      Serial.print (i, HEX);
      Serial.println (")");
      count++;
      delay (1);  // maybe unneeded?
      */
    } // end of good response
    
    
    
  } // end of for loop
  
  Serial.println ("Done.");
  Serial.print ("Found ");
  Serial.print (count, DEC);
  Serial.println (" device(s).");
  
}  // end of setup

void loop()
{
}

this is the serial output

Code:

test
I2C scanner Scanning ...
1
2
3
4
5
6

also when i change the range it got stuck at those adresses i tested so far:   6,9,14,17,19,....

dont know what it means or if there is just an loop checker who stops when recognizing that there is an error ... ^^

[Reply #20 on:]

Have you tried running it without the device connected? It should run through without a problem. If it doesn't your Arduino board has a problem.

Usually this code runs through and displays the found devices (if you don't comment out the necessary lines). There is almost no way of letting it break (almost because a slave device can make the communication slower by holding the SCKL low for longer than the master intended. But that means the slave gets active and it has to implement that feature (most don't).

[Reply #21 on:]

hy thx again for your responses,

yes i tried it without the sensor connected and it works as it should

hm not sure if i did get your second point, where you explained how that could be
so - if i understand right it means the device works and holds down the CLK line and my arduino waits for
an high impulse on the CLK ?

ok i now look at my old IC´s if there is an other I2C device and test this and try if i get it running, when my sensor dont want to work

[Reply #22 on:]

so - if i understand right it means the device works and holds down the CLK line and my arduino waits for
an high impulse on the CLK ?

Almost. Usually I2C devices are just slaves, the master is controlling everything. The master is pulsing the clock line (spikes from high to low) which is giving the frequency for the serial transfer (in either direction). If a slave needs more time to fulfill it's task, it is allowed to hold the clock low even if the master isn't still pulling it (clock stretching). I don't know where the limits are for this feature but in every description I read it sounds like: "it's allowed to stretch the clock a little bit".
The blocking of the bus like you may experience is clearly a misbehavior.

[Reply #23 on:]

ah ok thank you again - learned another thing

if i can use an digital analyzer next months or get it running per experimenting i post here more

[Reply #24 on:]

I noted that he datasheet of DSPC01 (http://www.dorji.com/docs/data/DSPC01.pdf) was updated and some interesting information is added.