BTW on page 1 in the pic i see three voltages and another 0% - what does the 0% stand for ? RSSI maybe ? if so can you calibrate high and low values ?

That would mean the G-OSD can take 4 voltage readings, 3 analog and one ADC ?

Great job.
The big problem with G-OSD is GPS's speed (1Hz)
Is it possible to use it faster?

i3dm: No only 3 adc inputs. The last is a battery level status for one of the inputs. It can be configured in code in config.h. You can select number of cells and min/max per cell. Only the total level is used however so you cant see each cell. An RSSI could be added in a similar way.

Mister_a: Why do we need faster? When I started coding I updated the adc as fast as possible and it got really hard to read the last number since it changed all the time. So now the text is only updated once a sec. But if you change GPS just change baude rate in config.h and increase screen updates it should work... No promises though.

Callelj,

First: congratulations for the excelent work,

Did you get the float library linked? Do you think it could fit?

The distance to "home" is fairly easy to calculate in integer, takes one cosine, did before, will figure out. Bearing to home is way more complicated. But: doesn't take a lot of precision, can probably arrange something like your trigometry.h.

Searching my dark old days files for integer navigation, will find something.

The data I would like to have on screen is:

-batery voltage
-bearing home
-distance home
-altitude above home
-gps speed
-gps route
-maybe rssi, probably will never use it

I think...

Originally Posted by callelj

i3dm: No only 3 adc inputs. The last is a battery level status for one of the inputs. It can be configured in code in config.h. You can select number of cells and min/max per cell. Only the total level is used however so you cant see each cell. An RSSI could be added in a similar way.

Mister_a: Why do we need faster? When I started coding I updated the adc as fast as possible and it got really hard to read the last number since it changed all the time. So now the text is only updated once a sec. But if you change GPS just change baude rate in config.h and increase screen updates it should work... No promises though.

so using the 3rd voltage as RSSI would be good, and actually we dont need the voltage reading itself, only calibration for maximum and minimum, and have it display in percentage (XX%) on the screen. the 2 other voltages could be used for motor battery and video battery = perfect as far as voltage readings are required from any OSD (in my opinion).

esreis: No I dont think I can fit the float lib without significant rework.

On both boards there is a Mega88 that have 8k bytes program space to use.
Only adding radians function and math.h adds 1588 bytes.
And adding bearing function takes another 2844 bytes.
Adding distance_between function uses another 664 bytes.

Totaling at 5096 bytes! Thats more than half the program space!

I need to find a way to do the calculations using only ints.

Edit: Compare with the arduino that have 32K flash... Hmm...

understood!

Seems feasible, if we tolerate small errors and short distances (no more than a few hundred km, that is)

I'm on it.

Soldering a atmega328 there is tempting. Not much of a puzzle, though.

esreis: Yes, a atmega328 would be nice...

What if we skip the fact that the earth is round? (Worked for people a long time ago. )
The difference in length for less than 10 km must be really small. Need to calculate a bit on that...

/Calle

Originally Posted by callelj

esreis: Yes, a atmega328 would be nice...

What if we skip the fact that the earth is round? (Worked for people a long time ago. )
The difference in length for less than 10 km must be really small. Need to calculate a bit on that...

/Calle

Yes, if the footprint and pinouts are exactly the same, it would be great to have a larger uC on there, which I can switch out in a few minutes.

Originally Posted by actionplus

Yes, if the footprint and pinouts are exactly the same, it would be great to have a larger uC on there, which I can switch out in a few minutes.

but that would disappoint all of us that dont have the equipment to switch out the uC ! hahaha

working on the skinny functions

i3dm: I want to use the existing µC as well. If I wanted better I could just use my arduino instead.

Originally Posted by i3dm

but that would disappoint all of us that dont have the equipment to switch out the uC ! hahaha

Well, send your board to me with a uC, and I will replace it for you, free of charge

Originally Posted by callelj

i3dm: I want to use the existing µC as well. If I wanted better I could just use my arduino instead.

I think using the currrent uC would be the best solution for a majority of the member. Just need to focus on what is really needed and really wanted. Then compare that with what the uC can handle without overloading it.

Originally Posted by actionplus

I think using the currrent uC would be the best solution for a majority of the member. Just need to focus on what is really needed and really wanted. Then compare that with what the uC can handle without overloading it.

I agree.