Rushduino OSD - Multiwii based open software osd

[carlonb]

.....
Note that on Multiwii code you must define your setup and preferences, why not on your OSD? That´s why it is on config.h
.....

I understand what you mean, but MWii GUI can decode any copter setup we define in MWii config, so I think may be possible also with OSD, my dubt is the memory space in our AT chip other than to understand how to do it.
Carlo

[dramida]

Last fw version of Frsky D8R II receiver has rssi on ch2 as pwm and ppm on ch1 (if you put a jumper between 3 and 4)

OK thanks, I´m going to look into that.
Is this the one?

http://www.frsky-rc.com/DownloadItem.asp

You can find the new software witch works fine on all my receivers (with RSSI and PPM sum) in BETA TEST SECTION tab called "CPPM 27ms for D8R-XP " This new fw also resolves a sync bug with 8 channels all at 100% when ppm sum overlapped.

But the way, i like your latest video, very nice display case and good editing skills also:)

[dramida]

Using minimum hardware OSD with Rushduino firmware on multiwii is easyer than we think:
For RSSI and voltage/ current indicator we don,t need to use the analog inputs from rushduino MCU atmega 32 and to hard-wire the board to battery and receiver.
All we need to do is to use MSP voltage, MSP current and MSP rssi serial commands and controller will respond to this minimum hardware OSD:)
This implementation is used to original firmware with ArduCopter.

[kataventos]

Using minimum hardware OSD with Rushduino firmware on multiwii is easyer than we think:
For RSSI and voltage/ current indicator we don,t need to use the analog inputs from rushduino MCU atmega 32 and to hard-wire the board to battery and receiver.
All we need to do is to use MSP voltage, MSP current and MSP rssi serial commands and controller will respond to this minimum hardware OSD:)
This implementation is used to original firmware with ArduCopter.

Yes, I implemented that and it´s working. I just use Powermeter but if you take a look at config.h you can assign VBat to main or video voltage.

[kataventos]

.....
Note that on Multiwii code you must define your setup and preferences, why not on your OSD? That´s why it is on config.h
.....

I understand what you mean, but MWii GUI can decode any copter setup we define in MWii config, so I think may be possible also with OSD, my dubt is the memory space in our AT chip other than to understand how to do it.
Carlo

You are right, I can do that... just going to take some time! maybe Itain or Shikra can help on that to... they are much more faster!

[kataventos]

But the way, i like your latest video, very nice display case and good editing skills also:)

Thanks Dragu, it´s nothing, you to know very well what you are doing with your videos, they´re great.

[carlonb]

Hi Kata and other developers,
I'm implementing a routine to Right-Justify all numeric data on the screen, I think this is better to show data avoiding it "jumping" left or right when they change in number of digit.
When done I will post a video.
Cheers, Carlo

[kataventos]

Using minimum hardware OSD with Rushduino firmware on multiwii is easyer than we think:
For RSSI and voltage/ current indicator we don,t need to use the analog inputs from rushduino MCU atmega 32 and to hard-wire the board to battery and receiver.
All we need to do is to use MSP voltage, MSP current and MSP rssi serial commands and controller will respond to this minimum hardware OSD:)
This implementation is used to original firmware with ArduCopter.

@Dramida

I was thinking on what you said about the RSSI, and I have a question:
Do you know if we can we get any of this info on TX pin of the FRSky receiver? We are already using RX port with a level converter to get the flight data on ground togheter with accurate RSSI...

[dramida]

rssi on channel 2 is pwm signal. It is meant to be read by OSD or other pwm compatible device like FC. Ofcorse the rssi is coded in serial downlink also. I am not shure if i understood your question.

[kataventos]

rssi on channel 2 is pwm signal. It is meant to be read by OSD or other pwm compatible device like FC. Ofcorse the rssi is coded in serial downlink also. I am not shure if i understood your question.

OK, take a look at this, you will understand. Here we are using one serial port but just one way...
http://www.multiwii.com/forum/viewtopic.php?f=7&t=1929&hilit=frsky

[copterrichie]

rssi on channel 2 is pwm signal. It is meant to be read by OSD or other pwm compatible device like FC. Ofcorse the rssi is coded in serial downlink also. I am not shure if i understood your question.

OK, take a look at this, you will understand. Here we are using one serial port but just one way...
http://www.multiwii.com/forum/viewtopic.php?f=7&t=1929&hilit=frsky

But that configuration requires a Mega board with additional serial ports right?

[kataventos]

rssi on channel 2 is pwm signal. It is meant to be read by OSD or other pwm compatible device like FC. Ofcorse the rssi is coded in serial downlink also. I am not shure if i understood your question.

OK, take a look at this, you will understand. Here we are using one serial port but just one way...
http://www.multiwii.com/forum/viewtopic.php?f=7&t=1929&hilit=frsky

But that configuration requires a Mega board with additional serial ports right?

No, just a Mega, you have 4. I´m using 1 for OSD, 2 for GPS and 3 for FRSky telemetry but just to send.

[itain]

I ask for opinions on two things that I want to change.

1. The heading is displayed in degrees -179..180. I would prefer to have 0..360 (which is commonly used in general aviation). Other votes?

2. It looks like the heading graph is offset by 11.25 degrees. The N is centered when the heading is 0 but it's shifted 22.5 degrees at heading -1. I expect N to be centered between about -11.25 and +11.25 (rounded to integer). If others can confirm it's a bug I proceed to fix it.

Thanks,
-- Itain

[carlonb]

I ask for opinions on two things that I want to change.

1. The heading is displayed in degrees -179..180. I would prefer to have 0..360 (which is commonly used in general aviation). Other votes?

2. It looks like the heading graph is offset by 11.25 degrees. The N is centered when the heading is 0 but it's shifted 22.5 degrees at heading -1. I expect N to be centered between about -11.25 and +11.25 (rounded to integer). If others can confirm it's a bug I proceed to fix it.

Thanks,
-- Itain

Hi itain,
1) I've already mod the heading display in degree from 0° to 359° and I agree with you it's better.
2) Yes you are right, not only about N but all other S,W,E. Please mod it and let me now the mod details.

Anyway, I'm almost ready to submit in forum my two weeks of hard work ( a cople of hours a night) on minimosd making all data clean on screen and formatting all data right-justified, more options in config.h, added a default eeprom data at first startup...
I just wait only for a fly test...
If you have done something more or different, please tell me. I'ts better to have a single common revision.

Bye, Carlo

[alexia]

thanks carlo

[kataventos]

@ Itain
please confirm your area MAG declination and submit it first in your MWcode for before any change, but yes, I do think you are right. I´m only be able to test it next year

@ Carlo
we are working in this repository http://code.google.com/p/rush-osd-development/source/list fell free to see what´s going on.

Cheers,
KV

[power67]

Thank you all for this project. I have been following this project now for a bit. I was working on a modified DIY-OSD code project and it looks as though you guys have solved many of the issues that I was having.

Sorry if this is a stupid question, but has anyone done the rssi, main and video voltage utilization on the MinimOSD? I can get a voltage divider setup on my multiwii no problem and have tested the functionality, but, I would much rather have this built on the OSD instead. (experiment on the most inexpensive parts). Also, I would prefer to continue to use some of my Paris Multiwii boards and as you might know, they do not have all pins available, so you have to code around this and loose some camera/gimbal functions.

That being said, if we do that, does that mean we will loose the software powermeter function of the multiwii?

Thank you again and I hope to somehow contribute to this project.

[kataventos]

Thank you all for this project. I have been following this project now for a bit. I was working on a modified DIY-OSD code project and it looks as though you guys have solved many of the issues that I was having.

Sorry if this is a stupid question, but has anyone done the rssi, main and video voltage utilization on the MinimOSD? I can get a voltage divider setup on my multiwii no problem and have tested the functionality, but, I would much rather have this built on the OSD instead. (experiment on the most inexpensive parts). Also, I would prefer to continue to use some of my Paris Multiwii boards and as you might know, they do not have all pins available, so you have to code around this and loose some camera/gimbal functions.

That being said, if we do that, does that mean we will loose the software powermeter function of the multiwii?

Thank you again and I hope to somehow contribute to this project.

Welcome Power67,

As for your first questions, the only person I can remember that made a mod for voltage reading was Shikra. This is a simple mod and I think that he will post it as soon as he is able on the wiki.
For more analogue readings like RSSI VID voltage etc, it´s almost the same but you will have to mess up with your OSD seriously... I mean to much soldering in such a small piece of hardware, so I do not want to say that is impossible but I need to have my Minim in my hands to be able to say if it is something practical or not to do.

Paris are great as I have two and never had a problem, but, about coding on the MWC to... I do not recommend, you will mess without reason, and for what?
As for your last question, you will not loose power-meter even if you make some code changes for your needs regarding your (available pins), it is a software thing

[justk1w1]

An update on what I have been doing with the OSD.

Firstly I found the more that I dug into the code the more I found I needed to change, hence it has taken a little longer to achieve what I wanted to achieve. As A short list I have made the following changes:
1. changed the EEPROM proceedure so that it detects the version being loaded against the version being run and either resets to default or loads the currently stored values
2. changed the serial request of information to be related to the function the OSD is performing. i.e. if it is not displaying the PIDS then it is not requesting the PIDs from the FC. If it is in the PID screen then it is not requesting GPS information, etc, etc. I have also attempted to streamline the requests to the FC to reduce any load on the FC.
3. Added a RC sketch to allow for any unused rc aux channels to be plugged directly into the OSD
4. added new pages to the config screen:
a. Local RC channel display - for display of info in 2 above
b. AUX 1-4 configuration - you can now change the functionality of the aux switches from the OSD
5. Remodeled the config pages to get the boxnames directly from MW and reducing the requirements to make changes if MW changes
6. Reduced the flicker on the screen through directed updates to the screen only when data changes.
7. Added switches to turn off features on the OSD to declutter the screen if required
8. Added features to the MAX7456 sketch to optimise the screen write.
9. modified the GPS coordinates to make them look like GPS coordinates
10. added a +/- 10 degree bar to the horizon display - created the procedures to calculate the line offset for roll angle, but have not implemented this as yet.
11. smoothed the horizon display to be more accurate with the pitch of the craft
12. made a few changes to some of the characters displayed on the screen.
13 Changed the display of information so that fixed screen information is not written to the screen all the time.
14 attempted to implement screen changes under vsync control, but there appears to be a conflict between the interrupt routine and the spi routine - on hold at the moment until I can get all the rest of the changes complete.

Changing the way the information was written to the screen has been the biggest issue as it has meant that most of the screen object routines had to be rewritten. I'm hoping to take a video tonight and post it up for comment.

I'm now investigating and testing these as well as just doing some final testing and changes to the above:
1. getting RSSI out of the turnigy 9x 8ch rx. If not possible to get RSSI then the minimum will be to provide a failsafe detection routine based on this rx
2. multi camera input selection so that you can switch to another camera with the option to present different on screen information.
3. Serial relay - provide a piggy back serial feature to then allow connection of xbee without impact. This can then be used to allow for additional control information to be passed to the OSD - joystick command to a camera control.

Cheers

[justk1w1]

Just adding a link to my previous post
http://youtu.be/qW-f77AZSTg

[carlonb]

Just adding a link to my previous post
http://youtu.be/qW-f77AZSTg

Hey Jkiwi, looks good.
Very good job, and seems that we have no more glitches on screen. Did you solved with vsyc interrupt refres screen ?
About N and W at side of GPS coord are they received from MWii serial protocol or are a simple hard print on the screen ?
About degree indication on pitch of Art. Horizon, I think they must be fixed and do not follow the pitch line (may be this is only your first step mod).
About info position of all data on screen I made a different place than yours, I will subit the link this nigth a demo vid of my solution to discuss the better we decide as final rev.

Cheers, Carlo

[carlonb]

Hi all,
just now I've added on tube two vid in order to show some tests with full text fixed data and my mods about some data place changes.
Here http://www.youtube.com/watch?v=0JJXrIYUp20 is in mode "WIDE, METRIC units"

and here http://www.youtube.com/watch?v=XEu6_JIa4J8 is in mode "WIDE, IMPERIAL units", these last values are the same as above METRIC but automatically tranformed by OSD, please check if are correct.

My personal consideration: I think that NARROW mode has not to much sense to me due to a lot of data too close.

I'm waiting for suggestions about data layout on screen.
Bye , Carlo

[justk1w1]

Just adding a link to my previous post
http://youtu.be/qW-f77AZSTg

Hey Jkiwi, looks good.
Very good job, and seems that we have no more glitches on screen. Did you solved with vsyc interrupt refres screen ?
About N and W at side of GPS coord are they received from MWii serial protocol or are a simple hard print on the screen ?
About degree indication on pitch of Art. Horizon, I think they must be fixed and do not follow the pitch line (may be this is only your first step mod).
About info position of all data on screen I made a different place than yours, I will subit the link this nigth a demo vid of my solution to discuss the better we decide as final rev.

Cheers, Carlo

Carlo,

N&W are calculated with the +/- signs from the GPS information.
The degree indicator is currently only following the pitch - I have the calculations for the offset, but I need to look into the images that are required to produce a smooth movement to allow for pitch. The main horizon does not account for the pitch at any angle of roll, but displays the roll based on the perpendicular. The original art horizon gives no reference to a center of the line and therefore you perceive that the line is moving in relation to the roll, also the line pitches in increments of 5 degrees which makes it jump up and down. I have actually managed to smooth this action out so that it displays pitch in smaller increments but just looking for a decent combo to display the pitch+roll without having to create a large number of images.
I like your positioning of the GPS coordinates and will look to make the same change. Might look to make the change so that if GPS is turned off then the heading jumps back up to the top line.
Now that I have watched your recording I have Definitely removed most (90%) of the flicker. This is where I have spent most of my work as it has required a large number of changes. I only write to the screen when data has changed and in most cases it has meant setting the old location to transparent before writing the new value. I have still to venture back to the vsync - the max7456 would lock up with the vsync active. Even with restricting it to writing only small amounts of information it would eventually freeze - not a good thing, but will get back to that one soon as the display was a lot smoother with it active.

I still have a bit of cleanup work to do and agree with you on the NARROW mode - I have made most of the objects on the screen selectable in the menu so that you can declutter the screen. With everything turned off then the only information on the screen will be a small art horizon. This is just my personnel preference as I am planning on doing a lot of video recording with the only required info to be the GPS coords and a central marker.

Cheers

[copterrichie]

I have got to get me one of these. Wow!

[KasparsL]

Hi where can I buy rushduino osd hardware? The web pages seems to be always down. Any other hardware that can take rushduino software? I'm in UK, but can order from overseas if a good deal =]

[carlonb]

Carlo,
....
....
I still have a bit of cleanup work to do and agree with you on the NARROW mode - I have made most of the objects on the screen selectable in the menu so that you can declutter the screen. With everything turned off then the only information on the screen will be a small art horizon. This is just my personnel preference as I am planning on doing a lot of video recording with the only required info to be the GPS coords and a central marker.

Cheers

Yes, me too have added some define in order to show only what I need and the screen is more clean removing not needed info, anyway if we remove NARROW mode we save chip memory.
Do you plan to submit your hard job on forum ? I can't wait for your solution

Bye, carlo

[dynai]

hi,

realy greate work and thanks to the developers who keep this alive.

as the rushduino hardware gets harder and harder to get hold of (think i got one of the last peaces) could we put following lines of code in the forthcomming versions to support both Rushduino OSD and minimOSD?

into config.h

Code: Select all

#define minimOSD //comment this out if your running the original Rushduino Hardware

into Max7456.ino

Code: Select all

#ifndef minimOSD    // Original Rushduino OSD
  #define MAX7456SELECT 10//ss 
  #define MAX7456RESET 9//RESET
#else
  #define MAX7456SELECT 6//ss    // minimOSD
  #define MAX7456RESET 10//RESET
#endif

kind regards

Chris

[dramida]

I agree using MinimOSD with rushduino.I also bought one at 18$.

[alexia]

I agree using MinimOSD with rushduino.I also bought one at 18$.

+1
very good working

[carlonb]

hi,

realy greate work and thanks to the developers who keep this alive.

as the rushduino hardware gets harder and harder to get hold of (think i got one of the last peaces) could we put following lines of code in the forthcomming versions to support both Rushduino OSD and minimOSD?

into config.h

Code: Select all

#define minimOSD //comment this out if your running the original Rushduino Hardware

into Max7456.ino

Code: Select all

#ifndef minimOSD    // Original Rushduino OSD
  #define MAX7456SELECT 10//ss 
  #define MAX7456RESET 9//RESET
#else
  #define MAX7456SELECT 6//ss    // minimOSD
  #define MAX7456RESET 10//RESET
#endif

kind regards

Chris

Hi chris,
Yes, it's exactly what all minimOSD user needs (like me)
Bye, Carlo

[justk1w1]

Going to look into getting boards made up. Anyone got any suggestion to where the best place is. What sort of additional features would everyone want. Going to look to use a Mega 1280 or 2560. Its going to have to be pretty cheap though as u can get a Mega for about $20 and Max Breakout for not much more.

Got some code working for the rssi output of the Hk 9x 8 ch rxer. Its pretty basic ATM but I can at least get a failsafe running. Will work on it to get reading to include in the osd.

[trailblazer]

Its nice to have some further developments going on
In the case the world is not ending tomorrow, I´m really interesting in these additional features :

- switch input (either ppm-servo in HW or through MWC FC Aux channels) for in-flight selectable (preconfigured) osd layouts, or other functions. Maybe its even possible to have a layout editor like the remzibi one in the future.
- map-feature: if someone knows other OSDs, they have something like a realtime map, where you can locate your flying vehicle relative/absolute to your home position with an arrow representing the current flight vector. we nee some additional chars for that, but calculations schould be not that hard to implement ( e.g. http://www.youtube.com/watch?v=-AvuTqVgidE). As a suggestion the map area should be aligned north and have a range off approx. 2 by 2km.

[faraz]

Hi Community,
From where i can download latest Rushduino OSD sketch ?
I have multiwii with r1240
Thanks

[itain]

Hi Community,
From where i can download latest Rushduino OSD sketch ?
I have multiwii with r1240
Thanks

The most recent open source is in http://code.google.com/p/rush-osd-devel ... 2FRush_OSD . Get the files from there (some changes are not yet in the Download link).

justk1w1 and carlonb have done a very nice work on fixing bugs and adding more features. AFAIK they have not released their source code yet. I hope the three versions could be merged soon.

-- Itai

[itain]

Its nice to have some further developments going on
In the case the world is not ending tomorrow, I´m really interesting in these additional features :

- switch input (either ppm-servo in HW or through MWC FC Aux channels) for in-flight selectable (preconfigured) osd layouts, or other functions. Maybe its even possible to have a layout editor like the remzibi one in the future.

Actually you can select between "Wide" and "Narrow" layouts using the config screen, but not in-flight. I don't see a good enough reason to change the layout during flight, however an option to turn off most (or all) items during flight could be useful.

- map-feature: if someone knows other OSDs, they have something like a realtime map, where you can locate your flying vehicle relative/absolute to your home position with an arrow representing the current flight vector. we nee some additional chars for that, but calculations schould be not that hard to implement ( e.g. http://www.youtube.com/watch?v=-AvuTqVgidE). As a suggestion the map area should be aligned north and have a range off approx. 2 by 2km.

There is already a direction to home (arrow), heading to home (degrees) and distance to home display.
I have not yet seen any OSD with a moving-map display. I guess you can do moving map on a base station if you transmit the location and interpret is using a mapping software, but that would not show on the OSD.

-- Itai

[copterrichie]

There is already a direction to home (arrow), heading to home (degrees) and distance to home display.
I have not yet seen any OSD with a moving-map display. I guess you can do moving map on a base station if you transmit the location and interpret is using a mapping software, but that would not show on the OSD.

-- Itai

Well, it is not possible now but if the telemetry data was sent to the ground and the OSD was generated on the ground, it is a possibility.

[faraz]

The most recent open source is in http://code.google.com/p/rush-osd-devel ... 2FRush_OSD . Get the files from there (some changes are not yet in the Download link).
justk1w1 and carlonb have done a very nice work on fixing bugs and adding more features. AFAIK they have not released their source code yet. I hope the three versions could be merged soon.

-- Itai

Thanks Itain

[kataventos]

As the most close to me know, I will be little out for some time more ( until January), but you all don´t need me anyway ... great job.

Cheers,
KV

PS: At this speed I should say... we will have a new dev for Wise Men's day

[kataventos]

The most recent open source is in http://code.google.com/p/rush-osd-devel ... 2FRush_OSD . Get the files from there (some changes are not yet in the Download link).
justk1w1 and carlonb have done a very nice work on fixing bugs and adding more features. AFAIK they have not released their source code yet. I hope the three versions could be merged soon.

-- Itai

Thanks Itain

Hi Faraz... you were able to get here to join us, welcome.
Like I told you on last email, this is the best place to be if you have a OSD

[kataventos]

Did I made two rhymes followed? must be happiness for this community work!

Because I know that some will celebrate xmas and others don´t, I just wish good things for everyone!

Cheers,
KV

[itain]

Did I made two rhymes followed? must be happiness for this community work!

Because I know that some will celebrate xmas and others don´t, I just wish good things for everyone!

Cheers,
KV

@kataventos ans all forum members, Merry Christmas and happy new year!

-- Itai

[carlonb]

@ all forum members and all developers, Good things for you all, Marry Christmas and happy new year.

Carlo

[carlonb]

Here http://youtu.be/BregLjfDfQI you can see my first ground piloting fly test with Minim OSD and Rushduino S/W last dev version with added my mods. You can see some little bugs on Heading & Batt already solved.
A very bad cold and foggy day here....
I hope tomorrow can do a second fly test.
Carlo

[power67]

Ok, guys,
I need some help.

I bought a few minimOSD from goodluckbuy and just got them in.

I hooked them as is to test video throughput(gopro vid out and ground on top or inside set of pins, vid on outside pin)
monitor on bottom pins.

I got nothing out of it, no camera passthrough-no osd.

I then flashed the max update code and pushed the new char set and then flashed the latest kv code.

Still nothing.

What am I doing wrong.

I got 3 osds and tried it on 2 of them to no avail.

Can someone please help.

Thanks in advance.
Ross

[carlonb]

Ok, guys,
I need some help.

I bought a few minimOSD from goodluckbuy and just got them in.

I hooked them as is to test video throughput(gopro vid out and ground on top or inside set of pins, vid on outside pin)
monitor on bottom pins.

I got nothing out of it, no camera passthrough-no osd.

I then flashed the max update code and pushed the new char set and then flashed the latest kv code.

Still nothing.

What am I doing wrong.

I got 3 osds and tried it on 2 of them to no avail.

Can someone please help.

Thanks in advance.
Ross

How do you supply the MinimOSD ?
It's better use 5V from FC and connect it to -,+,rx,tx serial main 6 pin port of minim.
Do not supply with 12V on CAM side or became too hot.
Have you soldered the 2 jumpers pads on back of OSD? (Only if you use a single 5V power from serial connector).
Please search on web Minim-OSD for connections and supply.

Bye, Carlo

[power67]

thank you Carlo for the fast response. at the moment I was only testing with the osd powered through the ftdi plug to pc on usb.

which jumpers are you talking about? the ones that tie the grounds together?

sorry to be so limited in my experience, I am a software programmer but limited in electronics.

thanks

EDIT----- Just soldered up the 2 pads on the board and everything is up and showing great. --------------

[power67]

Hello all,

Started testing the Rush_OSD development version and having some issues.

the AH is wonderful. faster than ever before.
Varo appears correct but hard to tell with some alt issues.

1. Direction home appears to be 180 degrees off.
2. Changing units from meters to feet causes quite a few issues.
3. As others have said, I too would like to see 0-359 deg. heading rather than +- 180
4. In Metric mode, I can only go 650 meters before it starts back at 0

I am testing the Rush_OSD Dev version with paris multiwii with MultiWii_dev_r1240

Any thoughts?

[carlonb]

Hello all,

Started testing the Rush_OSD development version and having some issues.

the AH is wonderful. faster than ever before.
Varo appears correct but hard to tell with some alt issues.

1. Direction home appears to be 180 degrees off.
2. Changing units from meters to feet causes quite a few issues.
3. As others have said, I too would like to see 0-359 deg. heading rather than +- 180
4. In Metric mode, I can only go 650 meters before it starts back at 0

I am testing the Rush_OSD Dev version with paris multiwii with MultiWii_dev_r1240

Any thoughts?

Hi power67,
1. To me seems ok, what kind of GPS are you using ? Are you using I2C GPS with serial/i2c converter and related S/W?
2. Will be corrected in next rev
3. Will be done in next rev
4. Seems a bug in MWii S/W, to be verifyed. Are you speaking about distance to home ?

Bye, Carlo

[power67]

Carlo,

yes, I am using Paris i2c gps with mag built into the gps module. I know that you have to change the sensor orientation in the MW def for the mag.
The compass heading appears to be correct. (or at least matches the GUI)

As a test, I put the unit on the dash of my car and did a small pattern. with the unit facing forward (on the paris, the cable is to the front) I could not ever get back to where I started by following the home arrow.
I then turned the entire unit around (ignored the heading) and drove a different pattern. I followed the arrow and distance home and it got me to withing 1 meter of where I started
I will try to investigate further after tomorrow.

Glad to hear about #2 and #3 are not just me.

#4 Yes, I am speaking about the distance to home. Tried it a few times and with the same result. around 650 Meters, turns back to 0

any idea on the date of the new rev?

I was also thinking of a FSK Modem on one of the spare analog pins, we could pass the GPS coord to the ground station for antenna tracking. What do you think?

Thanks for all the great work and the replies, it may take me a bit to get up to speed but I hope to be a part of this adventure.
Happy Holidays to everyone.

Bye, Ross

[dynai]

Hi,

i now got a minimOSD clone in addition to my Rushduino... and i had the same problems as Carlo (power67) and what baffeled my that there seems to be no connection betwen the arduino pin 10 on the atmega and the reset of the max 7456
reset of the max 7456 is connected to the common reset of the atmel.

where you able to upload the code (character table) and get it working only with adding the jumpers?

i got mine working with adding a wire from pin 10 to the max7456 but if it works without doing this modification would be nice to know.

cheers Chris