Originally Posted by Dr Strangelove

Teej,

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?

Yes, this is to read 2 consecutive bytes. The '1' in the first _read specifies to ACK the receipt of the data byte. The '0' in the second implies not to ACK the second byte.

When the I2C master acks a read byte, it's an indication that it wants another byte. By sending the ACK, the slave loads up the next byte which the master will then clock in. (the master always controls the data clock).

Similarly, sending the STOP condition without ACKing a byte implies that the master has read all it cares to.

i2c_read and i2c_write are not exactly the names of functions I'm using, but it's close enough...and what you're using with the stamp will be different from what I'm using as well.

Yes, you're reading 2 bytes in, high byte first, and generating an unsigned int from it. One could read the first byte, multiply by 256, then add the second byte...but the math takes more cycles than reading the 2 bytes and then using a pointer.

Finally, I don't understand the line;
reading = *((USHORT *)(&data[0]));

* is a syntax for pointer, & means address. Lots of stuff in C is done more efficiently through the use of pointers and addresses.

Essentially what this means is:

*((USHORT *)(&data[0])) gives you the memory address of 'data'
*((USHORT *)(&data[0])) casts that address as a pointer to an unsigned 16 bit integer
*((USHORT *)(&data[0])) pulls out the integer that's being pointed to.

It is (drastically) more efficient than, but equivalent in function to:

reading = ((unsigned int)data[0] << 8) + (unsigned int)data[1]; ( << 8 means shift 8 bits to the left...iow, multiply by 256)

or

reading = ((unsigned int) data[0] * 256) + (unsigned int) data[1];

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

Yes and no. That's the end result but it's not applying a mask.

Teej,

Thank's again. I set up everything on the bench last night (Australian time) and had a hack, but got nothing out. The sensors are in 3rd party mode, and I put the scope on the SDA and SCA lines and it was all crisp, but nothing sensible came out.

Here's the stamp I2CIN protocol;

I2CIN Pin, SlaveID, { Address { \LowAddress }, } [ InputData ]

• Pin is a variable/constant/expression (0 or 8) that specifies which
I/O pins to use. I2C devices require two I/O pins to communicate.
The Pin argument serves a double purpose; specifying the first pin
(for connection to the chip's SDA pin) and, indirectly, the other
required pin (for connection to the chip's SCL pin). See explanation
below. Both I/O pins will be toggled between output and input
mode during the I2CIN command and both will be set to input
mode by the end of the I2CIN command.

• SlaveID is a variable/constant/expression (0 – 255) indicating the
unique ID of the I2C chip.

• Address is an optional variable/constant/expression (0 – 255)
indicating the desired address within the I2C chip to receive data
from. The Address argument may be used with the optional
LowAddress argument to indicate a word-sized address value.

• LowAddress is an optional variable/constant/expression (0 – 255)
indicating the low-byte of the word-sized address within the I2C
chip to receive data from. This argument must be used along with
the Address argument.

• InputData is a list of variables and modifiers that tells I2CIN what to
do with incoming data. I2CIN can store data in a variable or array,
interpret numeric text (decimal, binary, or hex) and store the
corresponding value in a variable, wait for a fixed or variable
sequence of bytes, or ignore a specified number of bytes. These
actions can be combined in any order in the InputData list.


In my case;

The pin is 13
I assume the slave ID is 0xEA which is $EA in stamp
I assume the address will just be 0

So my code is;

result VAR Byte(2)
speed VAR word

IC2IN 13, $EA, 0, [result(0)]
IC2IN 13, $EA, 0, [result(1)]

speed = result(0) * 256 + result(1)

Again, thank's heaps for spending thetime to help.

Dr S

Try:

I2CIN 13, $EA, 7, [result(0), result(1)]

Teej,

Thanx for all your help. It works and is a rare and ancient thing of beauty.

It helped that I read the manual again and learned that the only pins that work with I2C are 8&9 and 0&1. pin 13 was never gonna happen.

Thank's again.

Dr S

Originally Posted by Dr Strangelove

Teej,

Thanx for all your help. It works and is a rare and ancient thing of beauty.

It helped that I read the manual again and learned that the only pins that work with I2C are 8&9 and 0&1. pin 13 was never gonna happen.

Thank's again.

Dr S

Yep. You've got quite a collection of parts there. Hope it ends up working for you.

Well, I'm starting to think the ET sensor isn't going to work on my project. Sometimes it does better than others, but this is what I often get reading it at 8hz on a 100khz bus...this is on a helicopter, more or less hovering up and down. I'm not sure of the precise atltitude or stability thereof...but I'm very sure it wasn't bouncing 90 feet in 1/8 of a second.

0
91
96
97
0
0
94
91
0
0
90
0
0
90
0
0
0
90
90
90
0
0
0
0
0
0
0
91
94
96
97
96
96
97
0
91
90
97
97
102
102
108
102
102
96
96
0
90
0
94
97
97
99
97
99


Strangely, I get better results if I don't put it in 3rd party mode. In factory mode, I haven't figured out exactly what the readings I get are...seems more pressure than altitude (numbers decrease with climb)...but they're more consistent with few (no?) zero values reported. If I, say, subtract the value I receive from ~ 15,000 I get numbers I can sorta make sense of even if they don't map exactly to feet above ground level...ie I typically get numbers just below 12000. So if I subtract from 15k, I get #s starting at ~ 3100 at ground level and rising with altitude.

Bill,

I'm interested in using the V3 logger to log other data via 12c or other interface. Is there a way to do this? Is it possible to make my sensor impersonate the altimiter and log to the V3 in the altimeter column?

Thanks,
Adam

Hi Adam,

The way things are set up now, this will be problematic. While you could impersonate the altimeter (by implementing the interface described in this thread) the eLogger, which expects raw pressure data from the sensor, will be munging the data into "altitude."

I think we will provide an easy way to do this in future, though.

Teej, the sensor needs to be in 3rd party mode for the data to be meaningful. In "raw" mode, the data format is proprietary and needs lots of postprocessing. There's no advantage to using that mode, and the data will look like random numbers.

If the data stream you are seeing above is in 3rd party mode, something is going wrong with some of your I2C reads. I suspect the correct value is "9X" and the zeros are indicating a bad I2C read. Note that the sensor zero-references itself when powered up, so the altitude of 9X may be due to either rotor-wash from the heli, or a very large temperature change (or baro pressure change) between the time you turned it on and the time you started taking readings.

Originally Posted by billpa

Teej, the sensor needs to be in 3rd party mode for the data to be meaningful. In "raw" mode, the data format is proprietary and needs lots of postprocessing. There's no advantage to using that mode, and the data will look like random numbers.

I understand where you're coming from...and perhaps this means there's something wrong with my Altimeter....or maybe I'm just asking it to deliver
something it's not capable of. I'd love to hear your thoughts.

The doc claims accuracy to within 1 meter. I generally see swings of 2-3 meters sitting inside, on a desk, with no air moving.

With my ET logger, and the sensor in non-3rd-party mode of course, moving around my house with a difference between top height (me standing on main level holding sensor at arm's length...down to basement floor) of about 18 feet....the ET software, or the device in 3rd party mode, give me numbers spanning over 30 feet.

When I take it out of 3rd party mode and log just the first 2 numbers retrieved, I get integers of around 11,500. The variance between the 2 "extremes" above is down to about 23-24 feet...and tracks the actual height much more smoothly (when subtracted from an arbitrary value to account for the fact that it's measuring pressure rather than altitude).

ie I might see 11522 on my desk, 11518 extended up at arm's length, and 11535 on the basement floor, for example. I can almost count the steps on the stairs.

Here's an example with the ET logger software (and obviously not 3rd party mode)... For this, I powered up on my desk. Waited ~ 10 seconds, then put it up on a bookshelf for about 10 seconds (that's nearly 2m above my desk.)

I then lowered it to waist level and walked to my staircase and descended. Waited 20-30 seconds, then walked back up with the unit at waist height the whole time, placed it back on my desk and disconnected.

I should see it settle out...rise 1-2m for 10 sec, descend back 1-2 down for ~ 20 sec (walking to stairs) then descending ~ 4m (going down stairs)...pausing, then rising 4-5m....and shut off at the same height it was powered on at.

This is what I get (first I did the test in feet, then switched to meters):

Is this the expected accuracy or do I have a defective altimeter? Neither graph properly represents the altitude changes...and seemingly neither registered me walking back up stairs. In both cases I walked back to my desk and unplugged my battery from the logger, and attached the USB cable.

Hi Teej,

The resolution of the sensor is +/- 4feet, so it's not ideal for measuring small changes in altitude. Further, after power-up, some drift can occur, though the sensor is thermally compensated. I would supect that, after a stabilization period of a minute or two, you would be able to detect differences on the range you're describing.

Originally Posted by billpa

Hi Teej,

The resolution of the sensor is +/- 4feet, so it's not ideal for measuring small changes in altitude. Further, after power-up, some drift can occur, though the sensor is thermally compensated. I would supect that, after a stabilization period of a minute or two, you would be able to detect differences on the range you're describing.

Possible. It also seems somewhat better after a few recals through the ET software today while I was testing and tweaking.

On the project I'm working on, I ventured down two different paths before settling on barometric as the most workable solution and until today hadn't really optimized my code even for a perfect altimeter, let alone one with some minor error thrown in. Some rework of the algorithm in simulation, along with the sensor behaving better, resulted in a few highly successful tests today.

Thanks - your presence and support on the forums is appreciated.

Thanks for the reply, Bill. Let me know when you are close to having this functionality. I'd love to have raw capture of my sensors even if they don't display in the Data Recorder software. Displaying in the Data Recorder would be a huge bonus, though.

Originally Posted by billpa

Hi Adam,

The way things are set up now, this will be problematic. While you could impersonate the altimeter (by implementing the interface described in this thread) the eLogger, which expects raw pressure data from the sensor, will be munging the data into "altitude."

I think we will provide an easy way to do this in future, though.

I'm thinking of trying to use both of these with the LEGO NXT system. The problem here is it's a bit-banged system that I have no access to at a low level: in other words, I can pretty much just send and receive bytes from requested registers on the I2C device at a certain address. From that standpoint, it sounds like it might work... but I was curious, before risking it and buying one (or more) about a couple of things.

First, what's the slowest I2C speed folks have worked with this? There's a difference between the polling speed ("I'd like one read every second") and I2C speed ("this data needs to be sent at 400 kHz, or the sensor's going to time out because it thinks the master has forgotten about it"). IMS, the NXT FW runs a bit-banged I2C at 9600 bit/sec - what's the chances of this working?

Second, the NXT can power the sensor (the sensor ports supply 4.3V I think)... but they have a current limitation of around 20 mA. How much do these sensors draw? Will I need a separate power supply for them, or will they pull under, say, 30 mA at 4.3V?

I'm sure I have more question, but I think I need to crawl before I can even begin to think of walking here. Ultimately, the goal is to instrument a dropped payload from roughly 80,000'. Yes, I know they won't function at that low a pressure, but I'm having fun pushing off-the-shelf technology to silly limits... I mean, come on, it's LEGO . We've already used it for high-altitude balloon missions, including an autonomous parachute deployment during a 15 minute fall time (exciting to see on the accelerometer record... not a ride I'd like to take).

--
Brian Davis

Hi Brian,

FWIW, I've never tried the sensor below about 80KHz, but in theory it should work at lower speeds. But we know how that goes.

The sensor will work at 4.3V. I am not sure that 20mA would be enough. The LED when fully illuminated draws close to that, alone. Of course, it is off most of the time. If the supply can handle bursts greater than 20mA, you might be ok.