hyperdyne, I don't know what the upper limit for polling would be. We don't poll it faster than 10Hz, but I suspect it would work at higher speeds. Re non-zero readings, are the numbers you are seeing small? Some drift (+/- 4' or so) is normal. But, if you are seeing very large numbers, that suggests that the sensor has not been reprogrammed for "3rd party mode."

Firehopper, that would be cool! I suspect that we'll see someone reverse engineering that link and hooking up an eLogger to it, just like several people did with another recent radio module.

Cloud, I am not sure how we can help you further. The sample code does work, and people on this thread have used it successfully. Sorry about that! Maybe someone else on this thread could post some source code for Cloud?

Regards,

Bill, for Eagle Tree

yes it would, supposedly the telemetry stuff for this hitec is due around feb or so, and is rumored to cost about $250 ish, since I already have a elogger. I am hoping for information on the format for the hitec.

Originally Posted by billpa

Firehopper, that would be cool! I suspect that we'll see someone reverse engineering that link and hooking up an eLogger to it, just like several people did with another recent radio module.


Regards,

Bill, for Eagle Tree

Hey Bill,

I have the sensor in 3rd party mode. Sometimes I can get up to 11' just sitting on the bench here. Other times it is lower. Just wondering if temps or other stuff can cause they larger biases.

The speed sensor is a bit more well behaved, it pretty much zeros itself out.

Thanks for the sample rate info, I have successfully sampled the sensor at 40Hz with no issues.

Hi hyperdyne,

If you place something that's thermally insulating (like a cloth or similar) between the table and the sensor, and if you power the sensor for a couple of minutes then restart it, do you still see that much reading variation? also, are you seeing the variation over more than a few minutes? if so, barometric pressure may be actually changing.

Yes, the change in pressure detected by the speed sensor is much greater than by the altimeter.

Regards,

Bill, for Eagle Tree

I'll try that out and let you know, thanks for the help!

Hi,
I'm trying to interface the sensor (already in 3rd party mode) with an Atmel mega32u4.
I wrote the code below but I can't output meaningful values. Right now I get 0xAAAA, 0xA8A8, 0xA2A2, 0x8A8A, 0xA8A8, 0xA2A2, 0x8A8A and 0x2A2A repeated in this order over and over again. I'm not sure what the 0 and 1 inputs in the pseudo code i2c_read function mean. Any help is appreciated.

#include "maevarm.h" // microcontroller basic functionalities
#include "usb_serial.h"
#define SLA 0xEA // airspeed sensor address

void usb_init(void); // initialize the USB subsystem
uint8_t usb_configured(void); //confirm communications
uint8_t usb_rx_available(void); //number of bytes in receive buffer

unsigned char data[2];
unsigned short reading = 0xFFFF;
unsigned char z;

//// Subroutine protoypes
void i2c_start(void);
void i2c_write(unsigned char status);
void i2c_restart(void);
void i2c_read(void);
void i2c_stop(void);


//// Main
int main(void){

usb_init();
usb_configured();

CLKPR = (1<<CLKPCE); //reduce processor frequency
CLKPR = 6;

while(1){
i2c_start();
TWDR = SLA|0x00; //Load SLA+W
i2c_write(0x18); //Transmit SLA+W and wait for ACK to be received
TWDR = 0x07; //Send "read data" command to sensor
i2c_write(0x28); //Transmit data and wait for ACK to be received
i2c_restart();
TWDR = SLA|0x01; //Load SLA+R
i2c_write(0x40); //Transmit SLA+R and wait for ACK to be received
i2c_read(); //Receive bytes and load data
i2c_stop();
}
}

void i2c_start(void){

TWCR = ((1 << TWINT) | (1 << TWSTA) | (1 << TWEN)); //send START condition
z = 0;
do{
z = TWSR;
z &= 0x08;
}
while (z != 0x08); //wait until START condition is transmitted
}

void i2c_write(unsigned char status){

z = 0;
TWCR = ((1 << TWINT) | (1 << TWEN)); //TWINT clear

do{
z = TWSR;
z &= status;
}
while (z != status); //wait until ACK is received (device addess successfully sent)
}

void i2c_restart(void){

TWCR = ((1 << TWINT) | (1 << TWSTA) | (1 << TWEN)); // send RESTART condition

do{
z = TWSR;
z &= 0x10;
}
while (z != 0x10); //wait until RESTART condition is transmitted
}

void i2c_read(void){

TWCR = ((1 << TWINT) | (1 << TWEN)); // Data byte will be received and ACK will be returned

z = 0;
do{
z = TWSR;
z &= 0x50;
}
while (z != 0x50); //wait until data is received and ACK is returned

data[0] = TWDR; //Read data byte

TWCR = (1 << TWINT); //Data byte will be received and NOT ACK will be returned
do{
z = TWSR;
z &= 0x58;
}
while (z != 0x58); //wait until data is received and ACK is returned

data[1] = TWDR;

reading = *((unsigned short *)(&data[0]));
usb_tx_hex(reading);
usb_tx_char(13);
//_delay_ms(100);

}

void i2c_stop(void){
TWCR = ((1 << TWINT) | (1 << TWEN) | (1 << TWSTO)); // Send STOP condition
}
//usb_tx_receive(reading);

Originally Posted by glauberm

Hi,
I'm trying to interface the sensor (already in 3rd party mode) with an Atmel mega32u4.
I wrote the code below but I can't output meaningful values. Right now I get 0xAAAA, 0xA8A8, 0xA2A2, 0x8A8A, 0xA8A8, 0xA2A2, 0x8A8A and 0x2A2A repeated in this order over and over again. I'm not sure what the 0 and 1 inputs in the pseudo code i2c_read function mean. Any help is appreciated.

The 0 and 1 refer to whether you're going to clock an ACKnowledgement of data received.

In essence, when you read data, be it from this altimeter or an eeprom...you need to ACK each byte read before you read the next one. You don't need to ACK the final byte. You're getting repeating data pairs because you're not ACKing the previous byte, so it's not sending the next one.

So in essence what you want to see is:

START (set the start condition in your TWC)
out: 0xE8
out: 0x07
RESTART (set RESTART in TWC)
out: 0xE9
READ (set the rx enable in TWC)
save the rx register as your first data byte
ACK (set the ACK bit in your TWC)
READ (flip the receive enable bit in control register again)
save the rx register as your second data byte
STOP

Now your AVR chip may work different from my PIC - I cannot set both receive enable and ACK enable or it locks up the bus (target device gets confused and locks SDA low and you have to do the hokey pokey to release it). I have to set the RCEN bit, then read my byte, then set the ACKEN bit, then set RCEN, then read my 2nd byte.

re - log - in doublepost

I misread the Eagltree website as well and assumed you could communicate directly with the sensors and did not purchase the logger.

Has anyone been able to communicate directly with the sensors?

If so, is there any chance of a connection diagram for the altitude sensore and speed sensor and could you post some code?

Thank's,

DR S

Originally Posted by Dr Strangelove

I misread the Eagltree website as well and assumed you could communicate directly with the sensors and did not purchase the logger.

Has anyone been able to communicate directly with the sensors?

If so, is there any chance of a connection diagram for the altitude sensore and speed sensor and could you post some code?

Thank's,

DR S

Everything you asked about is answered in detail in the PDF linked in the very first post of this thread. It's a very short document. It would take me more time to answer your questions than it would for you to gather the information from that file.

Originally Posted by cloudstrife100

Hi Bill,

I've contacted an engineer from the software company (LabVIEW) and we still have problems accessing the sensors. He suspected that the problem is that the I2C addresses you've put into the manual is incorrect. Can you please verify it?

May I also know what's the use of the values of I2C_READ_BIT & I2C_WRITE BIT? Again, is it a need to enter pseudo codes in order to access the sensors?

Thank you.

Regards,
Cloud

Cloud:

have you gotten anywhere with this?

Red box...
bytes to read - 2
eeprom starting address - 0x07 (for altimeter)
Number of address bytes - 1 (If you can set it - it looks grayed out. If you can't change this to 1, it's not going to work).

endianness shouldn't matter since you're only sending 1 "address" byte.

If that still doesn't work, try using 74 (hex, as in 0x74, not 74 decimal) as the (device) address instead of 0xE8. This might be what the labview engineers were referring to. Some systems (and labview may be one) consider the address to be only the 7 lsb of the byte...and bitshift the address to "make room" for the read/write bit. In that light, the Altimeter would be 0x74. Bitshifted left with a 0 (write / output) makes 0xE8 - the address EagleTree provides. Shifted left with a 1 (read / input) makes E9.

Hi,

I'm working with Glauber trying to interface the sensor with an Atmel mega32u4. I think we fixed the problem we had before by working out some bugs in the code that stopped us from properly connecting to the sensor.

Now, though, when I send bits to the sensor, I don't get an "acknowledge" bit in return. I know the address is right, because it can tell the difference between sending a write and a read bit. Any ideas on what we're doing wrong?

Thanks,
Alex

Originally Posted by Teej

Everything you asked about is answered in detail in the PDF linked in the very first post of this thread. It's a very short document. It would take me more time to answer your questions than it would for you to gather the information from that file.

You're right, it is a short document which is why I was asking for a little more info. No, I have never tried to communicate with I2C before. I note that pull up resistors are required. What value should I use? No doubt I could search the I2C standard, or some friendly person could just give me the benefit of their experience. I assume the resistors are 10k and go between the lines and a 5v supply?

Again, if anyone feels like sharing some code that works, that would be great. If not, that's cool too.

dr S

Originally Posted by Dr Strangelove

You're right, it is a short document which is why I was asking for a little more info. No, I have never tried to communicate with I2C before. I note that pull up resistors are required. What value should I use? No doubt I could search the I2C standard, or some friendly person could just give me the benefit of their experience. I assume the resistors are 10k and go between the lines and a 5v supply?

Again, if anyone feels like sharing some code that works, that would be great. If not, that's cool too.

dr S

There is no "right" value for the resistors. With a 5v system on a circuit board, you probably want to be around 4.9k. That would probably also work with the short wires off the ET sensors as well.

As wiring gets into the foot plus range...or you use a lower voltage system...or you start using a solderless breadboard...you need stronger (lower ohm) pull ups to overcome the capacitance.

The resistors are there to make the lines "snap" to the high-state when nothing is pulling them low. Too weak (high ohm) and the state doesn't change fast enough and you get communication errors. Too strong (low ohm) adds unnecessary stress to the controller, altimeter, etc.

I'm using a 3.3v system with a PIC 24F microcontroller, an (I2C) eeprom on board with the micro and header connectors into which I plug the ET altimeter and a CrystalFontz I2C display (CF-533-KC). I use 2.2k pull-ups.

5v and 4900 ohm would mean 1ma current. 3.3v and 2200 means 1.5. I could probably use 3k and work just fine...but I had 2.2k handy and figured with 2 sets of wires hanging off the board, a little stronger pull up would be smart.

As to code...code for what? My first test was a cut and paste of the pseudocode in the original post. I just had to make sure my PIC's I2C was properly initialized and the variables were properly declared and it worked as is. I mean...PIC C doesn't have a 'byte' type, I changed that from "byte data[2]" to "unsigned char data[2]"...and from "USHORT reading=0xFFFF;" to "unsigned int reading=0xFFFF;"

Any code more detailed than the pseudocode Bill put in the original doc will depend entirely on the specifics of the implementation you're attempting.

It will be much harder if you're going to bit-bang the I2C protocol (manually control the lines) such as with older micros that don't have I2C support built in.

Whatever you're working with, I'm sure I2C code relevant to that setup exists (whether it's a generic AVR implementation...or an Arduino...etc). Take any sample code that works from that, and tweak it to make the following sequence occur:

initialize (turn on / set up the I2C bus)
"START" (assert start condition on the bus)
Tx 0xE8 ( address of the altimeter in write mode)
Tx 0x07 (command to read altitude)
"RESTART" (bus condition)
Tx 0xE9 (address the altimeter in read mode)
Rx (byte 1)
"ACK"
Rx (byte 2)
"STOP" (do not ACK byte 2)

My current code differs from the pseudocode primarily in that I now run it as an interrupt driven state machine. I have a system that's running enough tasks that I don't want to essentially sideline everything else for the time it takes to read the altimeter.

Teej,

Thank's for that.

My control system is running on a single board computer, running XP embedded. I am programming in vb.net. The board has 6 comm (RS232) ports which I am using for sensing and control. For example; the sevo commands go out to a java based micro which handles all the PWM for digital servos.

I was planning to use a parallax stamp bs2p24px which has native IC2IN and IC2out commands to read the altimeter and speed sensors and convert the data to RS232 to send to the computer.

I am not great at bitbashing and am still a little confused by the pseudocode.

I assume the two lines ;

data[0] = i2c_read(1);
data[1] = i2c_read(0);

read two consecutive bytes of data. Does this mean that the data comming out of the sensors is 16bit?

I guess that "i2c_read" and "i2c_write" are native functions of teh processor you are using or are functions that the programmer builds. In either case, does the sensor just "know" you want the next byte each time you read? Or do you have to give it the address of the data you want to read?

Finally, I don't understand the line;

reading = *((USHORT *)(&data[0]));

Is this just a means of coverting the two elements of the array to a 16 bit unsingned int by applying a 16bit mask?? In which case data[0] is the high byte? Is this the same as saying;

reading_high = 256 * data[0]
reading_low = data[1]

reading = reading_high + reading_low


Again, thank's for your help.

Dr S