I have started to add functions to MinimOsd code.
At first i did it for myself only. Added many functions i thought i need. Then opened this thread.
after a while, Pedro and later Miguel came, and things started to happen fast. :D
They have optimised the code and added even more things to it.
They have worked hard on CT, and it became a great tool!
Thank you Bough! :)
By now MinimOSD-Extra got a pretty advanced OSD.
Here it is in action:
- Changeable unit measurement (US, metric)
- Home alt
- Battery Percent
- Battery used mah
- Current Draw
- Time From Startup (cleared at takeoff to show exact flight time)
- OSD Menu
- Wind horizontal speed and direction, and also the average wind speed of the last few minutes.
- OSD on/off
- Switchable secound screen
- WP distance
- WP heading
- Crosstrack error
- Warning messages for Lost GPS fix, Stall, Overspeed, battery volt, battery Percent, RSSI
- Efficiency, glide distance & thermic notifier. 3 in one panel
- OSD Brightness
- HAM Call Sign
- After flight summary
- Trip distance
- Smoothened horizon
- Real heading
- Vertical speed
This functions can be turned on and off, and placed on different screens now, by the Config. tool.
Also RSSI, switching mode and channel and unit measurement, Stall speed warning, Overspeed warning, Battery warning volt, Battery percent warning, RSSI warning, can be set in new Config Tool.
We built in a new way of setting video standards. Now OSD does not guessing anymore :). You can set it fixed from CT. It is in "Video Mode" menu.
Here is how it looks: (This video is a bit outdated, sorry. I will make a new one soon.)
The MinimOSD-Extra project is here: Link
This project is the developing version of the official Arducam OSD located here: Link
The latest stable version is: 2.2
The latest version can be downloaded from here: MinimOSD-Extra R800
CT is included. (The FW for Plane, Copter, Character upload and the character file is in the "FW & Char" directory inside CT directory)
We are sharing it to see videos you make using it! :)
You're absolutely right about the eeprom write - that typically should not have an effect on the bootloader but for whatever reason and in isolated cases - that's what's happened. I don't know if you've been following this Gabor, but everyone's using your code across multiple flight controller platforms now :)
I've seen derivatives pop on Multiwii, Naze32, OpenPilot, APM Clones and lord knows what else. That philosophy of "abstracting mavlink data" worked so well that this was portable across a number of different packaging protocols. All a coder had to do was map the inputs to their respective outputs, and voila - osd info.
As for the bootloader issue, it's even more prevalent now that people are switching firmwares across different platforms, I know of Sandro having to deal with at least one extremely irate person regarding the "bugginess" of his minimosd...they were looking for a polished product in what was essentially a perpetual beta product. We've all managed to figure it out because we've all invested the time to understand the code and have the necessary tools to effect changes, but the average rc'r would have a steep learning curve to get to even a basic level of proficiency.
Mind you I don't fault anyone for that - it's just a practical reality of the people that are using this - in other words some folks are just lazy and don't want to put in the time to make some work even if all the information is sitting right under their noses.
I have 2 more "bricked" minimosd's on my bench - so I'm going to try to isolate the exact operation that's killing the bootloader but there's no eta on that. What's more important is that there's at least a quick fix for it. Yes it involves soldering pin headers, but that's far easier to do than taking 32 AWG wire and soldering directly to the processor's feet :)
If you can - can you grant me access to the wiki? I can update it with a "troubleshooting" section... account is mochaboy at gmail com - maybe take some of the load off of you for updating :)
If you have another Arduino lying around, it is very easy to flash the bootloader of another arduino. I, for example, used an old "promini" as an ISP to flash my Flysky 9x following this guide: http://arduino.cc/en/Tutorial/ArduinoISP. Physically extracting the Arduino of the minimosd seems like heartsurgery to me - i wouldn't dare to do that. Normally it is not possible to kill a once programmed bootloader. If it is somehow possible on minimosd it must be something with the wiring/programming of the osd "max xxx" chip.
I do - and I replicated the entire process using an Arduino, with external crystals and everything. It's not as straightforward as plugging in an ICSP header - to you and I it's a trivial operation but to someone new coming into this problem - I'd immediately recommend a USBASP - plus they're just handy to have around.
For reference I replicated this process:
but where it diverges is the board choice for the bootloader. After looking at the boards.txt file, and confirming that against the eagle schematic - the correct board to choose is Pro Mini 5v 16mhz 328p.
I'm not as talented as that guy is so it took me a month to go through and work out all the permutations...I arrived at the final process taking the longest possible route there, but at least the benefit is I understand why everything works the way it does so at least for that, I consider it time well spent.
I can't reliably replicate the issue but when it does happen it happens when I'm flashing firmwares from different versions that don't correspond to either the existing character set or eeprom mappings.
Charset name is now related to CT Tool version.
This way you allways know what charset should be used with a CT Tool / FW version.
In this case: MinimOSD_22.214.171.124.mcm
I'm sure there isn't the right charset on your minimOSD.
I see two possible causes:
1 - Your're not uploading the right file. Should be MinimOSD_126.96.36.199.mcm
2 - You're not powering both sides of minimOSD while uploading the charset. If you power digital and analog sides of minimOSD separatly you need them both powered so video chip gets the new charset.
this could explain many problem...I used to power only the OSD
thanks for that note
Great, let me know if was this your minimOSD issue.
Yes we may include a message regarding that.
Just take in account that some guys ( me and Gábor included ;) ) use just one power source letting disconnected the +12V pins in the video part of minimOSD like shown here:
In this cases both sides are powered just by connecting minimOSD to the PC / telemetry port.
and me.. one power source, works well and most people say you'll be more safe by this way.
Miguel.. question, is the Compass Rose using magnetometer and Real Heading using GPS?
Is it correct if example Real Heading.. nose facing East, but copter drifting West.. I will get a 180 degrees arrow point down?
Great work Gábor and Miguel. I will try the plane next.. just waiting for a Power Module. Any tips Gábor just message me. I am still deciding what is critical and should be placed apart (FPV tx, Telemety, OSD, receiver, gps) to reduce interference or produce the best results. Thank you all.
Rose is using magneto. Not only but magnetometer is responsible to cancel out drift, cased wind, etc. So rose always shows your plane is "facing to". real heading is different. It shows real heading relative to rose (heading).
need support from somebody who knows better how to debug this board,
on the output video image, i have only a blackscreen with the OSD chars working fine, my video input is working properly but no video is on the output other than than the generated OSD.
running on the latest minimosd extra ,
any ideas what may i try ?
Post a photo of your wiring harness or at least a wiring diagram. The issue you described is typically a wiring problem.