Originally Posted by Ascended

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

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

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?

Originally Posted by Dennis Frie

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.

Originally Posted by msev

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.

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...

Originally Posted by Ascended

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

Originally Posted by msev

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

Originally Posted by Dennis Frie

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

Originally Posted by ElectoPete

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.

Originally Posted by kristaps_r

From experience with MultiWii and IMUs it uses all of them have pullups to 3.3v and Arduino pullups disabled.

Originally Posted by Dennis Frie

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.

Originally Posted by Ascended

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.

Originally Posted by Issus

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.

Originally Posted by ElectoPete

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, 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)

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?

Originally Posted by msev

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)