Blogs

Inside fuselage.

Underneath.

Rather simple but effective.

More coolness from podcast guest Daniel Mellinger and the U Penn GRASP lab. Check out the spooky looking around starting at 0:27.

ATP uses AFSK method to sending telemetry data over VideoTX’s audio

channel. The carrier is 2100Hz and a byte starts with one 1300hz wave(start bit), ATP sends

data bits after the start bit. and it sends minimum 10 carrier wave(zero) before a new start bit.

You can read my detailed information from this link (sorry for my English): http://www.flytron.com/pdf/audio_modem.pdf

Calibrating a PWM generator for 2100Hz carrier wave (for Atmega328)

This code generates static 2100hz square waves, put a 100nf capacitor on outside of processor and connect it on Audio in of TX, now you have a sinus on RX side ;)

You can send the bytes any time in your main code flow because AFSK protocol following waves not time sensitive protocol.
modem[] is an byte array that filled with data to send.
modem_byte is an integer for selecting byte of modem[] array
modem_bit is an char for counting sinus waves of AFSK

This code sends start bit at start and 8 bit of byte,
you should wait for 5ms for next byte for balancing sinus waves on audio stream, then you can send another byte also.

modem_bit = 0;while (modem_bit<18) //wait for all bit waves        {
                 
        if ((modem_bit%2==0) && ((PINB & (1 << 2))) ) // wait for 1 on PWM output. 
          {
          if (modem_bit==0)  // start bit
                 {
                 TCNT1H = 1;   // this values creates small delay for increasing the wave width
                 TCNT1L = 180; // and AFSK decoder can detect this big waves to 1, other small(2100hz) waves 0
                 }
                
           if (modem_bit>1)
                 {
                 if (modem[modem_byte] & (1<<((modem_bit-2)/2))) // if bit of bte is 1, change the wave width for 1 on AFSK
                   {
                   TCNT1H = 1;   // this values creates small delay for increasing the wave width
                   TCNT1L = 180; // and AFSK decoder can detect this big waves to 1, other small(2100hz) waves 0
                   }
                 }
                 
          modem_bit++;
          }

        if ((modem_bit%2==1) && (!(PINB & (1 << 2)))) // wait for 0 on PWM output  
          {   
          modem_bit++;
          }
        }

ATP Modem Software

I wrote a modem software for reading AFSK waves without any hardware (maybe a serial 100k resistor on microphone in)

File name is: SOSD_Modem.exe

Download link is: http://www.flytron.com/bootloader/xl_tools.zip

This is only software modem on the planet (or i didn't see another) :)

It is decoding AFSK codes from microphone input like an oscilloscope and giving output values from TCP for 3th party softwares. You can design your loggers, goggle earth interfaces or more with this plug.

It is using 20byte data pack for transmitting and software can separate them

First 16 byte is data bytes last 3 byte is line end and CRC

Pack of Bytes

[0-3] Latitude (4 byte = 32 bit long integer of coordinates)

[4-7] Longitude (4 byte = 32 bit long integer of coordinates)

[8-9] Altitude (2 byte = 16 bit long integer of altitude)

[10] Heading Angle (multiply it with 1.4 for finding angle value)

[11] Battery 1 voltage (divide 10 for value, 111 mean 11.1Volt)

[12] Battery 1 voltage (divide 10 for value, 74 mean 7.4Volt)

[13] Current Sensor 1 (multiply with 0.4 for value, 101 mean 40.4Ah

[14] Current Sensor 2 (multiply with 0.4 for value, 101 mean 40.4Ah

[15] RSSI (It is percentage of maximum value, 35 mean %35)

[16] Speed (km/h)

[17] Line End 1 (value 10)

[18] Line End 2 (value 13)

[19] CRC ( 8 bit totals of first 19 btye)

If you uses my original data pack Software Modem giving this type output from port 1976 (my birth year)

$TELE,lat,lon,alti,heading,voltag1,voltage2,curren t1,current2,rssi, speed, #13 #10

Or you can use your own data pack and you can decode them yourself from modem's RAW data output.

$RAWS,byte0,byte1,byte2,byte3,byte4.........,byte16, #13 #10

then you can decode your data bytes(first 16 byte)

This software only part of ATP i didn't share the codes because i want to share the protocol with all autopilot/OSD producers and i want to use their 3th party tools too.If I share the code, they can change only AFSK frequency and visuals for non compatible products.

New Features

I added direct KML file based live view for Google Earth on the new version of modem software.

You can click on plane_tracker.kml file and Google Earth connects your Modem Software to tracking the plane :)

It is already primitive because we have some connection problem on Google Earth since few months :(

Story Of ATP

If you want to read all discussions follow this link: http://www.rcgroups.com/forums/showthread.php?t=1157558

Thanks for reading

Melih

Michael Oborne has released a Windows GUI version of his great program to interface ArduPilot/APM with Xplane and FlightGear.

It's working well for me. Can you check it out and see how it works for you?

Instructions for setting up ArduPilot and sims are here.

• Modified ArduPilot2.6 and ArduIMU to do interprocessor communications via TWI to free up USART for full-duplex serial comm's between ArduPilot and GCS; can upload PID coefficients in flight. IPC code example: twi_stuff.zip
• Test flown in manual and stabilize modes, IMU appears to be consistently and accurately reporting attitude.
• Stabilize mode is solid with no oscillations using default PID coeff's, but need a way to trim pitch; taildragger isn't at cruise pitch attitude when IMU is initialized.
• Using SUP500 GPS module from SparkFun; altitude values off by up to 100 meters (field elevation 1800m). GPS frequently reports altitude of 1700m at pattern height (0-20m AGL). Also seeing huge intermittent (1 second duration) errors in lat,lon on the order of +/- 2 degrees. I don't think I screwed up the NMEA parser...
• Also switched to a Serial library which performs buffered transmits. This seemed to solve some problems caused by the standard library's blocking writes. HardwareSerial.zip

As we discussed a few months ago, the 2.4Ghz clone receivers have arrived. Above is the new Futaba FASST clone from OrangeRX that HobbyKing will be selling for $29.99 in September (you can pre-order now). The Spektrum clones (shown below) are already available for $14.95.

Lorenz Meir of the Pixhawk team had a good email discussion with the APM dev team on airspeed math, and was kind enough to write it up in a very helpful primer.

Check out the whole thing here, which walks through the math and measurement techniques.

His tips at the end apply to sensor measurements of all sorts:

• Get as much ADC resolution as possible, in the best case 10-100 times or more than your needed accuracy
• Sample at a much higher frequency and take the average/median (e.g. sample 10 times in a row, take the average/median, return this filtered value). This technique is called oversampling and if the sampling repetitions occur at a much higher frequency than the sampling interval, it should not delay the signal (no phase shift).
• Do a plot over a sensor range to figure out if your sensor is linear, if not, fit a quadratic/cubic function and linearize
• Do a static calibration if necessary
• Compensate for temperature changes if the sensor is sensitive to it
• Do not over-fit or over filter and just correct as much error as you need to make your application work. Too many projects and people get entangled in their own complexity and failures and crashes are the result of too high complexity and too few testing"

I noticed that my Garmin never says my location accuracy is better than 10 feet. I suspect that's a hard stop--no matter how good it is, nothing better than 10 feet will be reported. I decided to check this by plotting the coordinates given from the Garmin device in Google Maps, then Google Earth, and discovered that if any inaccuracy exists, it's within these two programs. In each case, the program showed my location a good 40-50' from where I actually was. On the other hand, plotting those same coordinates within Bing Maps showed the location within 6' of where the Garmin actually was located. The beta version of MapQuest allows you to enter cooridinates, and it was better than Google, but not quite as good as Bing.

I realize that both the Garmin and the map program being used have inaccuracies that will be additive, but I am very surprised at the Google results. I'm curious if anyone here who has plotted their flight paths within Google Earth has seen similar inaccuracies. Your plane could be shown either flying underground or taking off and landing from a virtual airstrip in the sky.

Thanks,
Paul

Work has been progressing slowly, but should speed up in two weeks when I will have more time and be back to my equipment and machining facilities. I have a new version of the board coming that should facilitate better proccessing.

It is quite large right now as it is designed to fit on top of the XC-1A dev kit, but the final board will be able to fit into a footprint as little as 1.5"x1" (small size is a key goal here) with a 6 or even 8 layer board to accomodate the proccesor (144 BGA). I am thinking of adding a backup comm system based on a cellular module, which would also be added to the board (64 BGA).

A test stand for the helicopter is in the works. The stand will allow the helicopter to move freely in all directions with boundary limits to prevent crashing. The movement range will be 0-3 feet in the Z axis, and ~150 degrees in the x and y direction. It will add a little bit of weight, but should not matter much with a .30 size helicopter. Motion should not be constrained as it will use PTFE/oil impregnated bronze bearings. CAD files to come later.