Primeiro tentei fazer por mim próprio e fiquei contente com os resultados. No entanto, encontrei um user aqui no forum que faz as antenas e usa um VNA para as ajustar/calibrar à frequencia que pretendes. Além disso, são verdadeiras obras de qualidade!

Originally Posted by jalves

Checksum added!

Now a checksum test control the servos update.

Next is testing it in the field.

Nice, please bring a camera .

Version 01b

Checksum added.

In this bench test, the model is flying 200m high at aprox. 70km/h and around the hypothetical ground station with a radius of aprox. 150~200m.

Comments?

diyAT_v01b.3gp (1 min 23 sec)

Bad link.

Originally Posted by rimshotcopter

Bad link.

Well,

I didn't get any comments

Someone did some tests to the software??

This is discouraging

Seems like it's working well, need some long range tests though.
The reason that people aren't commenting is probably because there isn't a tutorial yet on how to do it. Also it's early days so we don't know the limits.

Originally Posted by jalves

At the original time, the link that was posted was bad. It is now working. Great Stuff, I need to modify some servos for continual rotation and I will be able to help test.

Is Version 01b uploaded yet?

I'm interested and would like to get started. Could someone please recommend a GPS to use for this project.

Ok!

Version 01b isn't ready yet to go mainstream.

It should work with any gps unit, so far tested with ETEK EB-85/Sanav FV-M8 9600bps@5Hz and MTK 3329 38400bps@5Hz both configured to output only GPRMC/GPGGA

I am still searching for a optimal solution to adapt voltage levels between audio output and arduino input.

I am waiting (stuck in the post office) for an arduino 3.3V to try a direct connection without much trouble...

Update:
I have got the GPS data and battery alarms embedded on 3 spare video lines before the image and it looks OK at the receiver. I have designed a new decoder circuit board because it needs a high speed comparator to get the data from the video. The pcb should be here tomorrow so I can assemble and start the real work.

@jalves
I had a look at your AT code. I think you have more function than I need but I still have to get the data from the video. I am not good with Arduino and using a PIC micro. I am planning to use Pinguino program so that it is easy to convert to Arduino so I have to learn how Pinguino works. There are some differences that have me confused at the moment but I should be able to work it out.

I discovered today that my V-Mate video recorder does not record my embedded video data. It must be ignoring the leading lines and then recreating them on playback. I was hoping to have the GPS data saved in a recording to decode again later into a kml or similar file.

Paul

Paul,

Could you share some more details about how you integrate the data in the video stream?

I am about to quit the use of the audio link, so far couldn't make it reliable as I like.

The detective work about the right RC filters as been difficult without a proper oscilloscope (to bad I can't afford one ) to analyse the signal.

Originally Posted by jalves

Paul,

Could you share some more details about how you integrate the data in the video stream?

I am about to quit the use of the audio link, so far couldn't make it reliable as I like.

The detective work about the right RC filters as been difficult without a proper oscilloscope (to bad I can't afford one ) to analyse the signal.

Here are some details.

Putting the data into the video stream is the easy part in the DIY-OSD. Detecting the data reliably at the decoder is more tricky.

This is still a work in progress. I don't know yet if it is going to work or be reliable. In theory, it should work if the video image is OK and there is lots of redundancy. It would only need a good frame every few seconds to keep up with a distant model. With the data split into 3 lines, a bad line only looses 1/3 of the data, which could be corrected on the next line.

With the HK ckeap CCD camera that I am testing with, the first 18 lines contain no video ie. a quiet black level. This means that data has good definition against the background. A data 1 is the same as a white text pixel.

Encoding

It waits for video line 14 then places 3 lines of bytes (1=white, 0-black) by writing bytes to SPDR. Delays are needed between bytes so they don't overwrite and the SPI clock is reduced back to 1/2 speed (4MHz) for the data lines. Data includes lat, log, sat-cont, batt-alarm and mah-alarm.

A header pattern of "11111111 10101010" starts each line of data and a check character of the XOR of all data bytes with the msb =1 (OR 10000000).

The gap between bytes is variable depensing on the code and timing delays between bytes. Longer gaps make the bytes easier to see by less data per line. So that the decoder can find the start of each byte the msb (1xxxxxxxx) is set high. This leaves 7 bits for each character which is OK for acsii; just do "AND 01111111" on received data.

I may have to adjust the byte spacing timing as I work on the decoder.

Decoding

This uses a LM1881 to detect frame and line syn and interrupt the CPU. The CPU counts to line 14 and waits for a rising edge. It starts the SPI transmitting 1 byte which clocks in 8 bits of data on MISO. If it's fast enough to start the SPI it will read all 8 bits but if not a 1-bit delay will allow it to read 7 bits + 1 from the gap. This would need a simple rotate-right to correct.
Every byte starts with a rising edge of the first bit (1); so after receiving 8 bits the SPI is stopped and the CPU looks for the next rising edge to repeat the process for the number of bytes expected for each line.

When 3 lines have been received and checked the actual position data is updated. Bad lines are counted and could be alarmed or other action taken. The CPU is very busy during receive of each line, looking for rising edges and delaying. I will disable interrupts during each of the 3 lines and just run, probably with a timer based exit for when something goes wrong.

After the 3 lines are received there is plenty of time to work with the data or do other things. The OSD sends XX frames per second but only updates the data occasionally, so there are repeats sent of the data. The decoder could decode all frames or just occasionally. I thought about adding a counter or update flag to the 1st line header to signal the decoder that new data is available, but I haven't done this yet.

I have designed a pcb with a high speed comparator to detect the data from the composite video. The board also has eeprom, gps and a 5V servo power supply.

Paul

Looks very neat! ...Hope you get it to work, and I'm sure you will since this is the principle dakarosd is using and its been shown to be quite successful..

Can this gps (which is one of the most popular ones) be used also: FGPMMOPA6B
I plan to share it with the plane and ground station...Can the groundstation remember its position? So that I could put the gps on the groundstation, get lock - it would remeber its position, and then put the gps on the plane.

Any issues if the gps is configured for 10hz and 115200 baudrate.