It is Open Source, just give credit.

Originally Posted by Dennis Frie

Using the I2C from multiwii could be a possibility, but really don't wanna "take" any work from other people. Any idea about the license or who to contact?

It's GPL v3, feel free to take the source and expand on it as long as the result is offered back to MultiWii and the source code taken stays GPL v3 compatible.

http://www.gnu.org/licenses/quick-guide-gplv3.html

Originally Posted by Dennis Frie

......The timer runs on GPS-time if you have set that in config-file.

Dennis,

Yes, I was inside...did not have satellite fix yet

#define USE_GPS_TIME 1

So change to #define USE_GPS_TIME 0 to use computer time ?

Can't think of why we would want to use GPS time when we are looking at minutes and seconds? All should zero out when we get fix anyway. Then we have another opportunity to zero timer by getting out of menu......

Rick

Originally Posted by RickEis

Dennis,

Yes, I was inside...did not have satellite fix yet

#define USE_GPS_TIME 1

So change to #define USE_GPS_TIME 0 to use computer time ?

Can't think of why we would want to use GPS time when we are looking at minutes and seconds? All should zero out when we get fix anyway. Then we have another opportunity to zero timer by getting out of menu......

Rick

Whenever a GPS is used, I would recommend to use GPS time. It's a lot more accurate and there is not really any drawback.
You dont need GPS-fix to use GPS time, as long as the GPS is connected you should be fine.

Nothing will be more accurate than GPS time, unless you are looking at microsecond levels of jitter in a GPS-unreliable area.

The wire library for Arduino seems to have some problems, especially with timeouts. I just use the existing sensor library info and make my own functions for reading all of the I2C devices hooked up instead of the wire() library. Especially when you are using multiple I2C devices.

Dennis,

BMP085 detected
MPU6050 detected
PPM and menu working fine

For some reason when mpu6050 is connected the bmp085 went crazy ......numbers all over.

Maybe copter is noisy even with 2 filters as in post 345 ? how to test ?

Mpu6050 looks like it is working well.....I need to mount it. Appears it might not be horizontal with the board - maybe need to calibrate gyro ?

Rick

Originally Posted by RickEis

Dennis,

BMP085 detected
MPU6050 detected
PPM and menu working fine

For some reason when mpu6050 is connected the bmp085 went crazy ......numbers all over.

Maybe copter is noisy even with 2 filters as in post 345 ? how to test ?

Mpu6050 looks like it is working well.....I need to mount it. Appears it might not be horizontal with the board - maybe need to calibrate gyro ?

Rick

Sounds great. Any idea why your PPM-signal wasn't detected first time you tried?

You already got the MPU6050 hooked up as well? Amazing
I jave noticed 2 I2C devices at the same time can give some problems at the moment. I suppose it was the pressure-readings that was all over the place?

In regard to the artificial horizon not being horizontal. If it's tilt, it might be NTSC, where I haven't centered it. It have been tuned with PAL, so you might experience a little offset and to much/little variation of the horizon compared to the real horizon.

In the config you can find this:
#define TILT_OFFSET 16
#define ROLL_OFFSET 0

If you increase tilt, the artificial horizon will move down (as in have an offset). If you decrease it, or set it negative, it will move up.
When fine-tuning the offset, you can disable GPS (something like USE_GPS) to get artificial horizon show immediately and not have to wait for GPS-fix etc.

Originally Posted by Dennis Frie

..... Any idea why your PPM-signal wasn't detected first time you tried?

Dennis,

Yep.......I have a real good idea why PPM was not detected. It was not connected.

And yes, it was the pressure numbers that went wild when both sensors were running.

Hope to test in the air soon .....

Rick

Originally Posted by RickEis

Dennis,

Yep.......I have a real good idea why PPM was not detected. It was not connected.

And yes, it was the pressure numbers that went wild when both sensors were running.

Hope to test in the air soon .....

Rick

Great to know about the PPM, I could have used a lot of time to find that bug . The only "problem" left is your timer. If you ever see it stop again, please let me know.

I'll update the I2C routine next time I update the code.

Just tested the OSD with the new EzUHF firmware, to get RSSI and signal-quality in the PPM-stream.

It works like expected, and the scale have been set to reflect 0-100%. Will be included in next update

Default I2C communication routines from MultiWii have been implemented .
Uses less space and works like a charm so far
Also eliminates the previous problem with "infinite loop" in the wire-library

Originally Posted by Dennis Frie

Default I2C communication routines from MultiWii have been implemented .
Uses less space and works like a charm so far
Also eliminates the previous problem with "infinite loop" in the wire-library

Wow... very good Dennis,

I'm taking this time to try another quad design - ha I don't know why I just don't go buy one. I guess I enjoy building and modifying it till it does what I want....

Looking forward to more OSD testing when you are ready

Rick

Originally Posted by RickEis

Wow... very good Dennis,

I'm taking this time to try another quad design - ha I don't know why I just don't go buy one. I guess I enjoy building and modifying it till it does what I want....

Looking forward to more OSD testing when you are ready

Rick

It's always fun to build it yourself
You will probably not notice much difference from the current version available and next version - but it should take care of the known problems with the I2C.

I've uploaded the latest version:
http://code.google.com/p/diy-osd-max7456/downloads/list

Not many visible changes, but in regard to the I2C communication quite a few things have been updated.

NTSC have been fixed a bit, pressure-sensor changed a little + added lift/sink-rate as numbers (sorry, it's only in meters atm) and a quick "error check" in case of bad data from BMP085.

Oh, and all the EzUHF RSSI and Link quality have been updated and tested with the available beta-firmware

Originally Posted by Dennis Frie

Just tested the OSD with the new EzUHF firmware, to get RSSI and signal-quality in the PPM-stream.

It works like expected, and the scale have been set to reflect 0-100%. Will be included in next update

Where did you take this firmware ?? on Beta page of ImmersionRC ??
thanks !