KV Team Multiwii OSD

[subaru4wd]

My FrSky D8R-II and D8R-XP output RSSI in digital PWM form. I wish the use of the MISO pin was better documented, but now I am in the middle of switching over to UHF which uses a 0-3.3v filtered analog signal.

I heard the KV firmware only uses 0-1.1v and this is a limitation of the firmware, not the hardware. I am currently using a modified version of KVOSD by Truglodite so it will use 0-5v for analog RSSI (what his UHF outputs).

I would like to use the upcomming release of the KV OSD, especially if it has a OSD on/off switch and I can easily move items on the screen. But if there's a 0-1.1v limitation, I will just have to stick with Kevins modified code... or i guess bother him to help me with the required code changes.

Anyhow, im eager to see whats next for this OSD firmware. And the release of that new MiniOSD 1.2 looks like more options are on the horizon.

[kataventos]

This is really exciting! Thanks for responding.

On another related point, I just got this new version of the board from jDrones that claims to have an easier RSSI input (along with a bunch of new pins) but there is not documentation on it at all. That new jD board will probably have to be included in the wiki as well because it uses a different power scheme and has a micro Molex connector instead of pin headers.

SD

Mr. JDrones would have to send for free one OSD for each team member/developer if he wants to sell it to the Multiwii user´s if you get my point, we are always open to suggestions... the current hardware fulfill the needs at the moment, and a new dedicated hardware will rise in future...

This is just for receivers with PWM RSSI because we are using digital pins on this...

So that sounds like it would be perfect for the new FrSky receivers like X8R. I'm pretty sure that is a PWM RSSI output (Unlike older FrSky receivers which were analog).

They all output PWM.

My FrSky D8R-II and D8R-XP output RSSI in digital PWM form. I wish the use of the MISO pin was better documented, but now I am in the middle of switching over to UHF which uses a 0-3.3v filtered analog signal.

I heard the KV firmware only uses 0-1.1v and this is a limitation of the firmware, not the hardware. I am currently using a modified version of KVOSD by Truglodite so it will use 0-5v for analog RSSI (what his UHF outputs).

I would like to use the upcomming release of the KV OSD, especially if it has a OSD on/off switch and I can easily move items on the screen. But if there's a 0-1.1v limitation, I will just have to stick with Kevins modified code... or i guess bother him to help me with the required code changes.

Anyhow, im eager to see whats next for this OSD firmware. And the release of that new MiniOSD 1.2 looks like more options are on the horizon.

I have talked about this in the past... besides, Multiwii rocks on all readings at this moment so, why do you need to change the code and solder stuff on the ATmel?

The wiki is out of date because it was made before further developments on both codes so... no need to get stressed, the PWM yes, I agree to use it on the OSD instead on FC but the analog part I disagree because I keep my eye on the future and believe me, the future is a lot different then this... so, do not waste time on past stuff, try to use the FC for these readings and you will be surprised (fully compatible with coming developments on the KVTFirmware, inclusive last developments by Haydent on the the instant consumption (amperage) ).

-KV

[SkyrimDragon]

...................................................

[kataventos]

I have talked about this in the past... besides, Multiwii rocks on all readings at this moment so, why do you need to change the code and solder stuff on the ATmel?

I don't quite understand what you mean here. Can you explain how the MultiWii (code) can natively read the PWM RSSI? I don't see any reference to RSSI in the config.h.

You are out of context...

I heard the KV firmware only uses 0-1.1v and this is a limitation of the firmware, not the hardware. I am currently using a modified version of KVOSD by Truglodite so it will use 0-5v for analog RSSI (what his UHF outputs).
I would like to use the upcomming release of the KV OSD, especially if it has a OSD on/off switch and I can easily move items on the screen. But if there's a 0-1.1v limitation, I will just have to stick with Kevins modified code... or i guess bother him to help me with the required code changes.

The above is what I was talking about.

If you have PWM RSSI just use it on MISO by soldering a pin or a wire and report back... just this simple

Fly safe,
-KV

[subaru4wd]

I have talked about this in the past... besides, Multiwii rocks on all readings at this moment so, why do you need to change the code and solder stuff on the ATmel?

The wiki is out of date because it was made before further developments on both codes so... no need to get stressed, the PWM yes, I agree to use it on the OSD instead on FC but the analog part I disagree because I keep my eye on the future and believe me, the future is a lot different then this... so, do not waste time on past stuff, try to use the FC for these readings and you will be surprised (fully compatible with coming developments on the KVTFirmware, inclusive last developments by Haydent on the the instant consumption (amperage) ).

-KV

I am no longer using MultiWii firmware. I fly a 32bit board with Harakiri and there are no provisions for RSSI readings. I have to rely on the OSD board and mod it as necessary. I also have to modify the code because like I said before, your code limits the analog RSSI input readings to 0-1.1v when my receiver outputs 0-3.3v for RSSI.

Also. You may have mentioned the MISO thing somewhere in the past 55+ pages of threads here... however I tend to rely on official information posted in a Wiki format, and cannot always follow along with discussions here on the forums. Especially since there's a language barrier and sometimes its very difficult to understand what is being said.

Anyhow, i look forward to the next release.

[subaru4wd]

I have talked about this in the past... besides, Multiwii rocks on all readings at this moment so, why do you need to change the code and solder stuff on the ATmel?

I don't quite understand what you mean here. Can you explain how the MultiWii (code) can natively read the PWM RSSI? I don't see any reference to RSSI in the config.h.

Dude, i feel like we are beating a dead horse here. Either Kataventos does not quite understand what we mean. Or maybe he does and we just don't understand what he is saying???

[kataventos]

Yes, beating dead horses...

As I said on a previous post (look for yourself on the 55 pages again) Rushduino users will be using INTERNAL and Minim users DEFAULT, how difficult can this be to understand and to implement?
Anyway, developments were made on the Multiwii code regarding (and I repeat) ANALOG READINGS (nothing to do with PWM) and I would recommend them because in the future we need to have as much as we can on the serial protocol...

What is the difference between reading PWM directly and using a tiny RCFilter, can you tell? Well I can because I use it for a long time with an 100% accurate reading using the Multiwii FCB and tuned on the OSD for Max and Min as well as the Alarm.
If your firmware does not have this function you should request it to Mr. fork developer (whatever he calls himself). Besides, no one on this team use it so, you can also develop the OSD yourself, this still is open source...

Now for the PWM on Multiwii code, Nhadrian started to work on it but we found it useless and painless work so, the OSD would be the way to go on that. The function is available on latest dev, I just hear bla bla bla but no report.

-KV

[SkyrimDragon]

...................................................

[kataventos]

I'm going to do this MISO pin mod today. It sounds better than modding the MultiWii code anyway. BUT, I wonder if there needs to be a common ground (reference voltage) between the ATMega chip and the receiver. Mine have two different power supplies. When I tried to use CPPM (PPMSUM) without a common ground between the receiver and flight controller, it went crazy.

That's an electrical engineering problem that I can only solve by trying it.

Yes, you have an electric problem for sure but it is not "engineering" it is basic...

[SkyrimDragon]

...................................................

[Alexinparis]

Anyway, developments were made on the Multiwii code regarding (and I repeat) ANALOG READINGS (nothing to do with PWM) and I would recommend them because in the future we need to have as much as we can on the serial protocol...

I second that.
I predict OSD will sooner or latter become on ground devices and no more on board devices.
ie:
FPV goggle or ground screen <-> OSD <-> wireless link <-> FC board

[subaru4wd]

Anyway, developments were made on the Multiwii code regarding (and I repeat) ANALOG READINGS (nothing to do with PWM) and I would recommend them because in the future we need to have as much as we can on the serial protocol...

I second that.
I predict OSD will sooner or latter become on ground devices and no more on board devices.
ie:
FPV goggle or ground screen <-> OSD <-> wireless link <-> FC board

That sounds like a horrible idea if you ask me. I am already using 1280mhz for video, and 433mhz for radio... now I have to find another frequency to use for OSD???

I like to keep things simple. If the OSD chip can handle the voltage and rssi, why make the flight controller do it? Sounds rediculous, especially if you are using a firmware that does not have RSSI or voltage data in the serial protocol.

[SkyrimDragon]

...................................................

[copterrichie]

That sounds like a horrible idea if you ask me. I am already using 1280mhz for video, and 433mhz for radio... now I have to find another frequency to use for OSD???

I like to keep things simple. If the OSD chip can handle the voltage and rssi, why make the flight controller do it? Sounds rediculous, especially if you are using a firmware that does not have RSSI or voltage data in the serial protocol.

This is the very reason, I am investigating Wifi (I know and understand the pitfalls) however, I have seen applications that send data over the audio video feed.

[linuxslate]

Wasn't going to get into this since it is O/T for MinimOSD, but ---

Yes, we need to get rid of Analog Video coming down. Once you have digital video, it makes sense to do the OSD on the ground.

You can encode the tlm along with the digital video, and then do the OSD image creation/tlm integration on the ground where CPU power does not add to weight/power consumption.

Even my simple setup is essentially redundant since I have Bluetooth and OSD both sending the same exact values to the ground. (Same for those with a real TLM system.)

Most of the newer (cooler) cameras don't support analog video, and neither will the next generation of goggles. I'm pretty sure an Oculus Rift does not have a yellow RCA connector!

There is real demand for an all-digital FPV standard.

One problem is latency. Any latency in the video will make FPV flying difficult.

[subaru4wd]

One problem is latency. Any latency in the video will make FPV flying difficult.

This is the reason we all use Analog video. Analog video works, and it works great. I don't see any reason to go all digital, unless you want to FPV in HighDef, good luck finding enough bandwidth to pull that off. Also, I would rather see a snowy image than a pixelated broken image when signal is weak or lost.

[copterrichie]

One problem is latency. Any latency in the video will make FPV flying difficult.

The answer in my opinion is to build more intelligences into the copter/aircraft. But this is a topic for another thread.

[katana]

Good morning to all,
congratulations for this fantastic project.
Unfortunately I have problems with the fonts

Hardware: Minim Osd ( http://www.hobbyking.com/hobbyking/stor ... _v1_1.html )

Problem: see the image attached

Followed step by step instructions, I cleaned the eprom, I also tried to reload fonts from the gui, I tried to load the older version(345), but nothing, only the font of the letters and numbers are correct.

[subaru4wd]

Make sure you power the analog & digital side of the MinimOSD board before you upload the new font.

[katana]

subaru4wd,
you're absolutely right, now everything works, thank you very much!!

[Batch1]

When I try to load r370 or r345 or EEPROM Clear to my minimosd V0.1 with Arduino 1.0.4, the 2 last sentences in red at the bottom of Arduino KV_Team_OSD tab,

Serial.ino: In function 'void serialMSPCheck () ' :
Serial:58 error: 'EEPROM' was not declared in this scope

Also I use this FTDI adapter : http://www.rctimer.com/index.php?gOo=go ... oductname=

I change nothing in the sketch (Config.h)

I hope you can help me, I don't what to do know.

[Batch1]

When I try to load r370 or r345 or EEPROM Clear to my minimosd V0.1 with Arduino 1.0.4, the 2 last sentences in red at the bottom of Arduino KV_Team_OSD tab,

Serial.ino: In function 'void serialMSPCheck () ' :
Serial:58 error: 'EEPROM' was not declared in this scope

Also I use this FTDI adapter : http://www.rctimer.com/index.php?gOo=go ... oductname=

I change nothing in the sketch (Config.h)

I hope you can help me, I don't know what to do now.

Edit : Sorry for double post, would like to say that I follow the MinimOSD_Basic_Setup in : rush-osd-development

[katana]

When I try to load r370 or r345 or EEPROM Clear to my minimosd V0.1 with Arduino 1.0.4, the 2 last sentences in red at the bottom of Arduino KV_Team_OSD tab,

Serial.ino: In function 'void serialMSPCheck () ' :
Serial:58 error: 'EEPROM' was not declared in this scope

Also I use this FTDI adapter : http://www.rctimer.com/index.php?gOo=go ... oductname=

I change nothing in the sketch (Config.h)

I hope you can help me, I don't know what to do now.

Edit : Sorry for double post, would like to say that I follow the MinimOSD_Basic_Setup in : rush-osd-development

have you select in aArduino --->"Board >" select "Arduino Pro or Pro Mini (5V,16MHz) w/ATmega328
and the correct "Serial Port >"?

[katana]

Now the Osd it'ok, but i have 2 question:

1 ) the minim osd it's better closing the solder jumpers and power the OSD board from the Multiwii board or is it better to leave the solder jumpers open and provide 12 V to the analog parts? (now i have this configuration, but the osd is very hot)

2)i have this rx (http://www.t9hobbysport.com/frsky-tfrsp ... z-receiver) with rssi out.
i connect the rssi pin of my rx with the A3 pin of my Flyduino Mega, in the multiwii code :

/********************************************************************/
/**** RSSI ****/
/********************************************************************/
#define RX_RSSI
#define RX_RSSI_PIN A3

Now, in the gui of the OSD, I leave the values ​​of default ? it's correct the rssi max 255? how do I know if it is right?

[SkyrimDragon]

...................................................

[carlonb]

Now the Osd it'ok, but i have 2 question:

1 ) the minim osd it's better closing the solder jumpers and power the OSD board from the Multiwii board or is it better to leave the solder jumpers open and provide 12 V to the analog parts? (now i have this configuration, but the osd is very hot)

2)i have this rx (http://www.t9hobbysport.com/frsky-tfrsp ... z-receiver) with rssi out.
i connect the rssi pin of my rx with the A3 pin of my Flyduino Mega, in the multiwii code :

/********************************************************************/
/**** RSSI ****/
/********************************************************************/
#define RX_RSSI
#define RX_RSSI_PIN A3

Now, in the gui of the OSD, I leave the values ​​of default ? it's correct the rssi max 255? how do I know if it is right?

Point 1) I agree with the previous reply of SkyrimDragon
Point 2) Try to set min and max RSSI received values as discussed here http://www.rcgroups.com/forums/showthread.php?t=1786599&page=30 starting from post n. #438 and next page posts #451 and #452.
Carlo

[Batch1]

When I try to load r370 or r345 or EEPROM Clear to my minimosd V0.1 with Arduino 1.0.4, the 2 last sentences in red at the bottom of Arduino KV_Team_OSD tab,

Serial.ino: In function 'void serialMSPCheck () ' :
Serial:58 error: 'EEPROM' was not declared in this scope

Also I use this FTDI adapter : http://www.rctimer.com/index.php?gOo=go ... oductname=

I change nothing in the sketch (Config.h)

I hope you can help me, I don't know what to do now.

Edit : Sorry for double post, would like to say that I follow the MinimOSD_Basic_Setup in : rush-osd-development

have you select in aArduino --->"Board >" select "Arduino Pro or Pro Mini (5V,16MHz) w/ATmega328
and the correct "Serial Port >"?

Yes I select that board and yes I have the correct Serial Port (com6 in my case, the other one is for Bluetooth).

I select in Tool - programmer - Arduino as ISP

The others messages in red are void readEEPROM
void writeEEPROM
void checkEEPROM

After each there is : Serial:58 error: 'EEPROM' was not declared in this scope

Thanks for answering

[SkyrimDragon]

...................................................

[Batch1]

Have you tried just not clearing the eeprom? The clear sketch is not necessary. Actually, after clearing the eeprom on one of my boards it caused more harm than good.

Also, you don't need to select a programmer in Tools. You're using an FTDI to upload a sketch.

First I tried r370, I didn't work with the messages I specified.

Then I tried r345 same thing

Then I tried EEPROM_clear, it didn't work either

I have read this tread and search on the web, I can't find nothing that can help

[SkyrimDragon]

...................................................

[Batch1]

I know this sounds crazy, but I would start from zero. First, use a different computer. Install arduino. Install the drivers. Try to load the sketch.

The second thing I would do is to use a different FTDI programmer.

If NEITHER of these processes work, then the only remaining explanation is that it is the OSD. Then you can begin chipping away at that problem, probably by reburning the boot loader with a USP ASP programmer. Do you have one?

Start fresh and reduce your variables. It doesn't sound like you're doing anything wrong. Probably there is a glitch in your workflow.

(Sadly, I think your bootloader is corrupted, though. But deal with it when you get to that step).

I will have to order another FTDI (that time from eBay) and minimOSD and I have a USP ASP programmer.

On another computer, I load MinimOSD Extra Copter on that minimOSD board and using same FTDI and had no problems loading and configuring it

I didn't try to load the KV Team soft. on that computer, will try that.

Thanks

[katana]

Point 1) I agree with the previous reply of SkyrimDragon
Point 2) Try to set min and max RSSI received values as discussed here http://www.rcgroups.com/forums/showthread.php?t=1786599&page=30 starting from post n. #438 and next page posts #451 and #452.
Carlo

Point 2) I just did as you suggested, perfect!
for those who have had the same problem:
- make sure that the value of rssi max corresponds to 1.1 Volt or less (use a Voltage divider)
- enter the OSD menu, in one of the last pages you can read the current RSSI value, that value can used for calibration.
- that is all

thank you very much Carlo!

[katana]

What version of the OSD do you have? The jumper mod (5v) used to be recommended because of the power management problems. But those have been fixed and the analog side should be able to handle 12 volts. If it's getting hot, maybe you have an old version.

ALSO, the analog side doesn't NEED 12 volts. It can just USE 12 volts. It will run fine all the way down to 5 volts. So if they are separated, (no mod) you can power the analog side with a lower voltage (like a 2S battery) and it will run cooler.

The other benefit of this is that it will operate as designed and remove line noise and potentially provide a clearer signal.

Hi SkyrimDragon,
thanks for the reply.
i have this version : http://www.hobbyking.com/hobbyking/stor ... _v1_1.html (v1.1) it's ok?
now it works, but it seems to me hot... I will try to use only the 5v of flyduino mega.

[SkyrimDragon]

...................................................

[SkyrimDragon]

...................................................

[katana]

i have this version : http://www.hobbyking.com/hobbyking/stor ... _v1_1.html (v1.1) it's ok?
now it works, but it seems to me hot... I will try to use only the 5v of flyduino mega.

The picture that Hobby King has there indicates that it is A-OK. It appears to have the proper voltage regulator. Do you see the dark round thing near to the six pins on the analog side? On the older 1.0 version--or any version/copy/clone that has heat trouble, the area in the corner around the pins was very empty. It only had a couple of small components. In the fixed 1.1 version (whether 3DRobotics or the jDrones MiniOSD or any other clone), if that corner is populated by a lot of "stuff" it means that they added the proper voltage regulators.

I do highly recommend running that side off of a small 2S battery. They weigh very little, are very small, and will both keep the temperature down and keep the signal noise free. It's a good way to go.

If you're interested in even more redundancy, get a battery to run both the analog side AND the video transmitter. After all, they need a common ground between them anyway. Then even in the worst case scenario of a lost and wrecked model, it will keep broadcasting a signal from the debris field (even if it's a black screen with dead OSD overlay). Because the range while in the weeds is severely reduced, it will tighten up and localize the signal. In theory it could provide you with a secondary way to track it down, even if the main receiver and battery are no longer working. That VTX and OSD will keep going for the life of the battery. Several hours.

This is all off topic, but it's a thought. It would solve your heat issue and do so much more in the process!

Interesting advice, I always tried to have a layout with a single battery, I will think about. thanks again

[jphelirc]

i have this version : http://www.hobbyking.com/hobbyking/stor ... _v1_1.html (v1.1) it's ok?
now it works, but it seems to me hot... I will try to use only the 5v of flyduino mega.

The picture that Hobby King has there indicates that it is A-OK. It appears to have the proper voltage regulator. Do you see the dark round thing near to the six pins on the analog side? On the older 1.0 version--or any version/copy/clone that has heat trouble, the area in the corner around the pins was very empty. It only had a couple of small components. In the fixed 1.1 version (whether 3DRobotics or the jDrones MiniOSD or any other clone), if that corner is populated by a lot of "stuff" it means that they added the proper voltage regulators.

Actually it's was Mr.jDrones who released original MiniOSD v1.1 with switching regulator. And it was Mr. jDrones + Mr. Sandro who made original software for it. So I would not call them as clones. Designs are based anyways on our work that Sandro and me made. Now Mr. jDrones made another release of it and it's called v1.2.

Mr. JDrones would have to send for free one OSD for each team member/developer if he wants to sell it to the Multiwii user´s if you get my point, we are always open to suggestions... the current hardware fulfill the needs at the moment, and a new dedicated hardware will rise in future...

This is just for receivers with PWM RSSI because we are using digital pins on this...

KV, no need to be sarcastic.. we are not developing these just because of huge amount of $$$ (which there isn't), we do these because of love to electronics and avionics. Sure we are happy if people want to buy those too. So Mr. jDrones just might send few boards if someone needs them for development. But we are not going to send them to all developers as many times they just end up on collecting dust on someones shelfs. So if there is someone who really want's to develop software on those, I am happy to send few boards to those individuals. Just PM me here or where ever, I think it's easy to find me around net.

And btw. mostlike without Mr.jDrones and few others there would not be even multiwii and many other nice things... Just like OSD, It was us who originally started to create and use Wii based controllers on AeroQuad development team back at early 2010, which is +1 year before multiwii.com was even registered.


Anyways back to v1.2. I just updated few diagrams for it so if someone needs and want's to take a look at those, you can find them from my document site in here http://www.jdrones.com/wiki/jd-miniosd-v1-2-guide

We are going to make one more revision in next few months of it but nothing major changes.

Here are basic digram of it:


And for fun: Early multiwii/wiiquad and aeroquad development boards from early 2010.. Things has changed a lot since then but these should still fly


With best Regards,
Jani aka Mr.jDrones

Fly hard but fly safe...

[jphelirc]

OT: I am looking to make several adapter boards for MiniOSD. Adapter boards will allow easier cabling and will have smaller type connectors. Would be great to hear what type cabling you all have been using on your installations. If we can figure several mainstream installation methods, making simple daughterboard for OSD will be easy.

--jp

[timecop]

I'm curious why time + effort was spent to make NEW hardware with MAX7456? It's been FINALLY EOL'd by Maxim.
It's time to fucking move on.

[jphelirc]

tc, yeah they EOLed those but those are still on market at least about year or so. There are several works going on already for new hardwares but it will take time before those are done. 7456 just were one great and simple chip to work with.

[Batch1]

I know this sounds crazy, but I would start from zero. First, use a different computer. Install arduino. Install the drivers. Try to load the sketch.

The second thing I would do is to use a different FTDI programmer

If NEITHER of these processes work, then the only remaining explanation is that it is the OSD. Then you can begin chipping away at that problem, probably by reburning the boot loader with a USP ASP programmer. Do you have one?

Start fresh and reduce your variables. It doesn't sound like you're doing anything wrong. Probably there is a glitch in your workflow.

(Sadly, I think your bootloader is corrupted, though. But deal with it when you get to that step).

I did what you suggest, on a different computer using same minimosd board and same FTDI

I download a fresh copy of Arduino, KV_TEAM_DEV r370, and I use another USB cable.

I am able now to load the KV_Team r370 on the minimosd and do the configuration with the KV_Team GUI

Thank you very much my friend, you can't imagine how hard I work on that. I never thaught to try on another computer

Thanks again

Robert

[SkyrimDragon]

...................................................

[shikra]

Suggestion... in this bit

if(!armed) {
flyTime=0;
}
else {
flyTime++;
flyingTime++;
configMode=0;
setMspRequests();
}

remove flytime=0 totally - or put it into reset statistics?

Personally I like to have the the total flight time whilst battery connected - not resetting it each time I arm. When I'm filming I know I have say 8 mins, but might fly 4 or 5 scenes and stop inbetween with possibly a long wait so don't know the true total fly time. And on time is not usefull with long waits between flights.

[SkyrimDragon]

...................................................

[kataventos]

KV, no need to be sarcastic...

With best Regards,
Jani aka Mr.jDrones
Fly hard but fly safe...

I was not being sarcastic... just calling for some attention here...
We never let our hardware on the shelf, we use and explore it to exhaustion by flying.

PM will be sent.

Suggestion... in this bit

if(!armed) {
flyTime=0;
}
else {
flyTime++;
flyingTime++;
configMode=0;
setMspRequests();
}

remove flytime=0 totally - or put it into reset statistics?

Personally I like to have the the total flight time whilst battery connected - not resetting it each time I arm. When I'm filming I know I have say 8 mins, but might fly 4 or 5 scenes and stop inbetween with possibly a long wait so don't know the true total fly time. And on time is not usefull with long waits between flights.

Hey Shikra,

Yep that´s a good point, also noted and on the list

Now that we have the official schematics and pinouts on the new MiniOSD 1.2 from jDrones, can someone tell me which analog pin can be used to measure voltage? I believe RSSI is the A3 pin (or MISO)...which is voltage?

Thanks!

Yes we have the schematic ...
We will develop and publish as soon as we have it in our hands

But, ADC3 (PC3) is an analogue input and MISO (PB4) a digital one (PWM), which kind of signal are you trying to get on screen?

Cheers,
-KV

[kataventos]

...Often with Windows based computers, you must do what doesn't makes sense.

[kataventos]

I'm curious why time + effort was spent to make NEW hardware with MAX7456? It's been FINALLY EOL'd by Maxim.
It's time to fucking move on.

This is 100% correct.
Anyway, we will keep developing for MAX7456 with our modest OSD until the real "future" telemetry comes. I predict something a lot different as I said before, but that´s just me speaking until then let´s keep the screen populated with most needed data for Multiwii FPV fun.

-KV

[SkyrimDragon]

...................................................

[carlonb]

Yes we have the schematic ...
We will develop and publish as soon as we have it in our hands

But, ADC3 (PC3) is an analogue input and MISO (PB4) a digital one (PWM), which kind of signal are you trying to get on screen?
-KV

Hi Henrique,
Agree about first point, it's time that someone send to us developers the new hardware to make easy the job.

About PB4 (MISO), are we sure we can use it? MISO is actually communicating with MAX7456

Bye, Carlo

[SkyrimDragon]

...................................................