HobbyKing.com New Products Flash Sale
Reply
Thread Tools
Old Jan 22, 2013, 11:02 AM
Just another user
Dennis Frie's Avatar
Denmark, Capital Region of Denmark, Naerum
Joined Feb 2011
898 Posts
Quote:
Originally Posted by Ascended View Post
So, I've added the level shifter which actually helps cleanup the routing which is nice.

I'm also hooking up HSYNC/VSYNC/LOS to the uC. LOS will allow internal sync gen to be turned on if something happens to the camera.

I'd really like to get gps coords telemetried down to the ground on video overlay in the VBI, so i'm going to use HSYNC/VSYNC for that. Need to double check that the MAX will generate the same syncs as you'd expect from a sync separator, a quick look at the datasheet makes me feel as though it does. I'll have to check in depth however.

Having VSync hooked up and on an interrupt also allows the OSD data to be transferred during the VBI, which will prevent any corruptions in the display.

This leaves 1 pin free on the uC.
All great ideas, but you should be aware that:

- MAX7456 will automatic detect missing sync and generate sync-pulses if no signal is present. It works just fine on my hardware as well. No need to detect it with the micro-controller, as it's already done on MAX

- Using H-sync and V-sync interrupt will give problems with PPM interrupt and serial-interrupt. if you intend to use H-sync and V-sync for timing with pixel-generation for video-modem you need very accurate timing. That will require serial-receive to be polling and same goes for PPM-input. An entire video-line interrupt will prevent high baud-rates, as you might miss a byte.

- You donīt really have any free communication-lines with buffer that can be used for telemetry. Serial is used by GPS, SPI by MAX and I2C for sensors. Using a normal I/O pin is possible - but you should preferably use some more timing specific.

Not saying it's impossible at all, just a few things to be aware of
Dennis Frie is online now Find More Posts by Dennis Frie
Reply With Quote
Sign up now
to remove ads between posts
Old Jan 22, 2013, 11:39 AM
Just another user
Dennis Frie's Avatar
Denmark, Capital Region of Denmark, Naerum
Joined Feb 2011
898 Posts
Just a few quick notes on the PCB-design. Mainly for a few danish FPV'ers that will have a board available soon

GPS:
The GPS was originally designed to be placed on top of the OSD. I haven't tested with the latest design, but with the GPS mounted directly on top of the PCB, I've experienced problems with the GPS-signal. It was below freezing point and I haven't tested much, but I suspect the short distance to ground-plane on the OSD is causing problems. Long story short, I would recommend to connect the GPS with a few wires for now, or at least be aware of the problem if you placed the GPS directly on top anyway.

Noise
I've only done a few quick scans, but I haven't been able to measure anything to worry about. It's always a good idea to keep some distance to the RC-rx, but it shouldn't be noisy.

PPM-input
The PPM-input have Ground, Vcc (5-volt) and Signal.
Vcc and ground should only be connected, if you intend to power the OSD through the receiver (must be 5 volt). This can be an easy and practical way to power the OSD, if you don't use a seperate 5-volt BEC for FPV-equipment. Just connect a normal servo-cable between RC-receiver and you have power + PPM (if connected to a PPM output)
It should be noted that this is only meant to power the OSD. If the OSD is used to split 5-volt to camera and transmitter, you should connect the 5-volt supply to the bigger Vcc-connection.

I2C connector.
This connector have 5-volt, 3.3-volt, SCL, SDA and ground available. The 3.3v and Vcc/5-volt is connected through a small linear regulator (for 3.3 volt) and a thin Vcc-trace. This is just fine for small sensors etc. but don't use it as a power-output for camera, video-tx or similiar.

RAW-connector
The 2 Raw pads are used to measure battery-voltage. It should be noted that they are connected directly on the PCB. A lot of people uses a 12-volt camera connected directly to the battery. This will allow the camera supply-voltage and ground to be connected to Raw and ground.

Current and RSSI
Basically, this is just 2 analog inputs. Current is connected directly to the ADC, and RSSI is by default connected through a 1K resistor.

Vcc-pads and Ground
The large Vcc-pads (3 in total) are connected with rather thick traces and meant to be used for splitting 5-volt power to camera and video-tx. This will help with easy wiring and the OSD will provide a bit of filtering on the supply as well (only by capacitance).
All ground-pads are connected directly to the ground-plane
Dennis Frie is online now Find More Posts by Dennis Frie
Last edited by Dennis Frie; Feb 08, 2013 at 07:55 AM.
Reply With Quote
Old Jan 22, 2013, 05:04 PM
Just another user
Dennis Frie's Avatar
Denmark, Capital Region of Denmark, Naerum
Joined Feb 2011
898 Posts
I'll update the software soon, have the following in mind, anything I missed (artificial horizon have to wait until warmer weather).
Must changes are already done.

- GPS altitude can be replaced with altitude calculated from pressure-sensor. (done)

- Negative temperature will now show as negative temperature and not random symbols (well, it's coded, but I don't really feel like going outside to see if it's working. I'll take my chances) (done)

- Better options for customization (some done)

- Changed maximum PPM-pulse acceptance (done)

- Number of sats (not done)

Anything obvious I've forgotten?
Dennis Frie is online now Find More Posts by Dennis Frie
Last edited by Dennis Frie; Jan 22, 2013 at 05:10 PM.
Reply With Quote
Old Jan 22, 2013, 07:51 PM
Registered User
Ascended's Avatar
Joined May 2012
489 Posts
Quote:
Originally Posted by Dennis Frie View Post
All great ideas, but you should be aware that:

- MAX7456 will automatic detect missing sync and generate sync-pulses if no signal is present. It works just fine on my hardware as well. No need to detect it with the micro-controller, as it's already done on MAX

- Using H-sync and V-sync interrupt will give problems with PPM interrupt and serial-interrupt. if you intend to use H-sync and V-sync for timing with pixel-generation for video-modem you need very accurate timing. That will require serial-receive to be polling and same goes for PPM-input. An entire video-line interrupt will prevent high baud-rates, as you might miss a byte.

- You donīt really have any free communication-lines with buffer that can be used for telemetry. Serial is used by GPS, SPI by MAX and I2C for sensors. Using a normal I/O pin is possible - but you should preferably use some more timing specific.

Not saying it's impossible at all, just a few things to be aware of
OK great, not requiring LOS will be good

Interrupts on the atmegas is one of the (many) reasons I really hate these ICs. Give me an ARM any day. I shouldnt need high speed serial, even 2 pixels per bit would be fine with a CRC. Simple GPS coords and altitude can be sent as binary very efficiently.

I dont plan on having any other way of feeding the OSD telemetry - if it's just for tracking/antenna direction then nothing more is needed. With eeprom or flash on the OSD it can log more parameters internally. A second UART would be really nice, but if you really want one it can be added on I2C.
Ascended is offline Find More Posts by Ascended
Reply With Quote
Old Jan 22, 2013, 07:58 PM
Registered User
Ascended's Avatar
Joined May 2012
489 Posts
Quote:
Originally Posted by msev View Post
If you start working some video-telemetry, be sure to post code here...And regarding the ground-station solution hope you go with some generic arduino, not that over-priced Ardustation.
I'm working on something at the moment for a client that is ARM Cortex-M3 based - I'll probably just make that compatible.
Ascended is offline Find More Posts by Ascended
Reply With Quote
Old Jan 23, 2013, 12:11 AM
Registered User
Joined Sep 2011
32 Posts
I'm thinking about adding SDcard for logging.. but it needs cca 4kROM and over 500B RAM (using nanofat)
in standalone GPSlogger it works perfectly.. but wasting 1/2 RAM for that...
Spejlo is offline Find More Posts by Spejlo
Reply With Quote
Old Jan 23, 2013, 03:46 AM
Registered User
Joined Sep 2010
2,414 Posts
Quote:
Originally Posted by Ascended View Post
I'm working on something at the moment for a client that is ARM Cortex-M3 based - I'll probably just make that compatible.
Which hardware, if its stm32f3discovery of f4discovery that would be acceptable too
msev is online now Find More Posts by msev
Reply With Quote
Old Jan 23, 2013, 05:34 AM
Registered User
Ascended's Avatar
Joined May 2012
489 Posts
Quote:
Originally Posted by msev View Post
Which hardware, if its stm32f3discovery of f4discovery that would be acceptable too
It's not something that is open, as its a client product - and its certainly not something you could do with a devkit (the client product, not decoding - thats easy)

I think i'm going to switch the baro over to a MeasSpec one, I just dont like the BMA180, it's too innacurate and limited compared to the measspec stuff - the Bosch sensor also huge :P
Ascended is offline Find More Posts by Ascended
Reply With Quote
Old Jan 23, 2013, 06:03 AM
Registered User
Sweden
Joined Aug 2004
104 Posts
Quote:
Originally Posted by Dennis Frie View Post
I'll update the software soon, have the following in mind, anything I missed (artificial horizon have to wait until warmer weather).
Dennis,
Have you seen the Rushduino thread (http://www.rcgroups.com/forums/showt...ight=rush+osd) ?
It is also an OSD using the MAX7456 - and it has a artificial horizon

/Pete
ElectoPete is online now Find More Posts by ElectoPete
Reply With Quote
Old Jan 23, 2013, 07:11 AM
Registered User
kristaps_r's Avatar
Latvia, Riga
Joined May 2010
661 Posts
Quote:
Originally Posted by ElectoPete View Post
Dennis,
Have you seen the Rushduino thread (http://www.rcgroups.com/forums/showt...ight=rush+osd) ?
It is also an OSD using the MAX7456 - and it has a artificial horizon

/Pete
This has also
I am not yet familiar with code and MAX7456 specs but I have thought that it could be possible to make say 6 different angles for line symbols that make horizon to have it smother.
kristaps_r is offline Find More Posts by kristaps_r
Reply With Quote
Old Jan 23, 2013, 07:34 AM
Registered User
Issus's Avatar
Joined May 2012
220 Posts
Quote:
Originally Posted by kristaps_r View Post
From experience with MultiWii and IMUs it uses all of them have pullups to 3.3v and Arduino pullups disabled.
Quote:
Originally Posted by Dennis Frie View Post
All great ideas, but you should be aware that:

- MAX7456 will automatic detect missing sync and generate sync-pulses if no signal is present. It works just fine on my hardware as well. No need to detect it with the micro-controller, as it's already done on MAX

- Using H-sync and V-sync interrupt will give problems with PPM interrupt and serial-interrupt. if you intend to use H-sync and V-sync for timing with pixel-generation for video-modem you need very accurate timing. That will require serial-receive to be polling and same goes for PPM-input. An entire video-line interrupt will prevent high baud-rates, as you might miss a byte.

- You donīt really have any free communication-lines with buffer that can be used for telemetry. Serial is used by GPS, SPI by MAX and I2C for sensors. Using a normal I/O pin is possible - but you should preferably use some more timing specific.

Not saying it's impossible at all, just a few things to be aware of
Why not use a faster controller then? Or one that has more communication-lines? Could you do it then? I'd love to see an open source antenna tracking thing that doesnt use audio.
Issus is offline Find More Posts by Issus
Reply With Quote
Old Jan 23, 2013, 11:12 AM
Just another user
Dennis Frie's Avatar
Denmark, Capital Region of Denmark, Naerum
Joined Feb 2011
898 Posts
Quote:
Originally Posted by Ascended View Post
OK great, not requiring LOS will be good

Interrupts on the atmegas is one of the (many) reasons I really hate these ICs. Give me an ARM any day. I shouldnt need high speed serial, even 2 pixels per bit would be fine with a CRC. Simple GPS coords and altitude can be sent as binary very efficiently.

I dont plan on having any other way of feeding the OSD telemetry - if it's just for tracking/antenna direction then nothing more is needed. With eeprom or flash on the OSD it can log more parameters internally. A second UART would be really nice, but if you really want one it can be added on I2C.
Quote:
Originally Posted by Issus View Post
Why not use a faster controller then? Or one that has more communication-lines? Could you do it then? I'd love to see an open source antenna tracking thing that doesnt use audio.
The Atmega328 controller wouldn't exactly be my personal choice. The 32-bit ARM-controllers is by far more powerful, have better specs and can even be found cheaper.

But as the Atmega328 is a very popular controller within the OpenSource community, it seemed like the best choice. Pretty much everyone can use Arduino or AVRstudio (or learn to upload code very quickly), so I decided to stick to that. If people have to use a large STM32-discovery board, an advanced tool-chain etc. it would make things a lot more difficult.

Sure, the Atmega328 might have a few limitations, but as it was able to do all the things I originally planned for this project - I decided to develop for that controller.

If I was making a commercial product, things would most likely have looked quite different.

Quote:
Originally Posted by ElectoPete View Post
Dennis,
Have you seen the Rushduino thread (http://www.rcgroups.com/forums/showt...ight=rush+osd) ?
It is also an OSD using the MAX7456 - and it has a artificial horizon

/Pete
The artificial horizon routine is also done in this project and works just fine. But the filters for gyro/accelerometer data is not finish. It works great on the ground, but when airborne the G-force and vibrations is a pain in the a**

Long story short, it's really cold in Denmark and I don't feel like going outside with all the FPV-equipment, laptop etc. and analyze data

So that's on hold atm - still have a few updates left to do anyway
Dennis Frie is online now Find More Posts by Dennis Frie
Reply With Quote
Old Jan 24, 2013, 03:01 AM
Registered User
mike_o's Avatar
Denmark, kbh
Joined Jan 2012
1,468 Posts
Frozen night flight

Dennis, thanks for nice company and an interesting flight last night. Looking through the video and noticing the pos/alt off-set, I realize how difficult the landing would have been without the guide light:



The video:
EasyStar FPV dark night flight over frozen lake. (7 min 53 sec)
mike_o is online now Find More Posts by mike_o
Last edited by mike_o; Jan 24, 2013 at 03:08 AM.
Reply With Quote
Old Jan 24, 2013, 03:35 AM
Registered User
Joined Sep 2010
2,414 Posts
Wait were you touching the surface of the lake (0 alt) or is that number besides ALT something different? Whats that other number bellow it?
msev is online now Find More Posts by msev
Reply With Quote
Old Jan 24, 2013, 03:54 AM
Registered User
mike_o's Avatar
Denmark, kbh
Joined Jan 2012
1,468 Posts
Quote:
Originally Posted by msev View Post
Wait were you touching the surface of the lake (0 alt) or is that number besides ALT something different? Whats that other number bellow it?
The two numbers in the upper right corner are the GPS derived altitude (upper) and the barometric pressure sensor (lower) derived altitude. For some strange reason, the GPS settled on a wrong figures on the home position and altitude.

Previously, the exact same set-up provided perfect data. In this video, the OSD isn't updated for barometric pressure read-out, but displays only GPS altitude data:

FPV EasyStar flying high (17 min 16 sec)
mike_o is online now Find More Posts by mike_o
Reply With Quote
Reply


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Help! OSD version UNKNOWN and fail to update (error) dROb Eagle Tree Systems 9 May 16, 2012 05:12 PM
Sold EASY OSD (Version 1.2) Brand New . $75 shipped. LHTPlane FPV Equipment (FS/W) 7 Mar 20, 2012 10:45 PM
For Sale MAX7456 OSD Break out board. ziomatrixacs FPV Equipment (FS/W) 4 Jun 18, 2011 03:50 PM