[avr / i2c] Pakket naar sensor geeft 'random' waardes

[LauPro]

Momenteel ben ik bezig om met een AVR een Honeywell sensor uit te lezen.

Specs hierover: http://sensing.honeywell....ical-note-008210-5-en.pdf

In principe geeft de sensor zodra hij is opgestart continue data door zolang je hem een i2c read request stuurt. Het lijkt echter zo te zijn dat de data die ik eruit haal continue veranderd qua waarde. Ik heb even een scope op de i2c-lijn gezet en deze lijkt ook willekeurig te zijn ook als er geen airflow is.

Wanneer er wel airflow is lijken sommige waardes te kloppen maar veel ook niet. Ik check wel of er 14 databits zijn overigens. Iemand enig idee waar ik het moet zoeken?

C:

uint16_t res;
i2c_init();
i2c_start_wait((zephyr_addr<<1)+I2C_READ);
res = (i2c_readAck() << 8) + i2c_readNak();
i2c_stop();

[farlane]

En met een scope op het signaal van de sensor zelf? Zie je daar ook een variërende waarde? Zit de airflow in de range van de sensor?

[LauPro]

Ik heb nu geen airflow. Op de scope ook random waardes te zien. Het lijkt erop dat ik meerdere waardes terugkrijg. Ik poll op dit moment elke seconde de data.

[SA007]

Er zijn heel erg veel sensors die slecht gaan meten als hun voedingsspanning buiten het optimale bereik is of als er teveel storing op deze lijn zit.

Ik zou die scope ook eens op de VCC/GND lijnen hangen en kijken of daarin niks vreemds zit.

[LauPro]

Voedingslijn is strak op 5 volt. GND 0. Dit dacht ik ook eerst dat er mogelijk te weinig spanning was. In de datasheet staat tussen 3 Vdc en 10 Vdc.

[Damic]

Je doet de 4 traps toch?

[Sissors]

Is het compleet random of enkele bits random?

[Flake]

Ligt het niet aan je bus? Pull ups in place? ACKs komen door?

[LauPro]

Damic schreef op donderdag 07 april 2016 @ 21:06:
Je doet de 4 traps toch?

Wat bedoel je met 4 traps? Voor zover ik weet de het eerste byte het adres en daarna 2 bytes data.

Sissors schreef op donderdag 07 april 2016 @ 21:41:
Is het compleet random of enkele bits random?

Enkele bytes zijn random lijkt het.

Flake schreef op vrijdag 08 april 2016 @ 07:24:
Ligt het niet aan je bus? Pull ups in place? ACKs komen door?

ACK's zijn er en pull ups ook.

[jeroen3]

Hij heeft een 14 bits data veld. En je moet 2 keer 8 bits lezen om te starten, daarna komen 2 met data. Vervolgens herhaal je telkens 2 reads, waar de 14 bit waarde in zit.

Lees op een je een oneven aantal bytes, dan zit je de 14 bit variabele verkeerd in elkaar te schuiven, en lijkt het inderdaad random.

[Damic]

LauPro schreef op vrijdag 08 april 2016 @ 14:55:
[...]
Wat bedoel je met 4 traps? Voor zover ik weet de het eerste byte het adres en daarna 2 bytes data.

[...]
Enkele bytes zijn random lijkt het.
[...]
ACK's zijn er en pull ups ook.

Table 1 Startup sequence (pagina 2) of doet die dat automatisch?

[LauPro]

jeroen3 schreef op vrijdag 08 april 2016 @ 15:45:
Hij heeft een 14 bits data veld. En je moet 2 keer 8 bits lezen om te starten, daarna komen 2 met data. Vervolgens herhaal je telkens 2 reads, waar de 14 bit waarde in zit.

Lees op een je een oneven aantal bytes, dan zit je de 14 bit variabele verkeerd in elkaar te schuiven, en lijkt het inderdaad random.

Een READ bestaat uit 3x8 bits, 1 address byte en 2 data bytes. Dat voer ik nu zo uit:

C:

i2c_start_wait((zephyr_addr<<1)+I2C_READ);
res = i2c_readAck();
res = (res << 8) + i2c_readNak();
i2c_stop();

Op de scope zie ik ook netjes 3 bytes staan.

Dus in principe hou ik dan toch 3 bytes en niet twee? Ik heb ook getest om geen address byte meer te sturen en alleen te lezen, maar dan krijg ik niets...

[3xhaas]

Je krijgt niet meer dan 3 bytes, omdat je daarna een i2c_stop() doet.
De 4 trap wordt waarschijnlijk de start up mee bedoelt.
Die bestaat namelijk uit 4 stappen, waarbij je het serienummer uitleest.
1 - read - returns 0x0000
2 - read - returns Reg0[15:0]
3 - read - returns Reg1[15:0]
4 - read - returns corrected flow {00,[13:0]}
Maar als je elke keer je data gewoon overschrijft heb je hier geen last van. Alleen maar interessant als je het serienummer wilt weten...

Je stappen lijken in ieder geval correct, namelijk:
1 - start(adress)
2 - wait for ack
3 - read high byte
4 - give ack
5 - read low byte
6 - give nak
7 - stop

Ik zou je code wat meer opsplitsen en zo stap voor stap kijken waar het fout gaat, dus zoiets als:

code:

i2c_start_wait(0x93); //of juiste adres hier 0x93 = ((0x49<<1) | 1)
res = i2c_readAck();
res2 = i2c_readNak();
i2c_stop();
res <<= 8;
res |= res2;

Welke waarde hebben je pullups? Soms als ze een te grote weerstand hebben bij een lage spanning gaat het niet helemaal lekker. Zeker bij een hoge bussnelheid.
Op welke frequentie draait je i2c bus? Probeer deze eens naar 100kHz te zetten als hij daar niet al op staat. Of anders nog lager.