Jump to content
mikep

In Flight Data Modem

Recommended Posts

I was still waiting for my parts to come in to complete the PCM Locator, so in the meantime I decided I would tackle another project I've wanted to do for a while.

To create an In-Flight Data Modem. Like many people here I've been using the The TinyTrack to pass information back to the ground. Well this is all nice and dandy, but what happends when you want to send data that the TinyTrack and your GPS don't know about.

It's all very rough at the moment but after lots of frustration to figure out how to calculate a CRC for AX.25 frames I got AGWPE to recongize my packets.

In a couple of weeks I will put a project together on the web. Maybe even make some boards, although there are so few compnents that vero board would do fine.

One of the main reasons I wanted to do this is to be able to get a ground station going. I have some code that someone started a while back but he never had time to complete it. Even a simple false horizon would be great to overlay on top of the video feed.

I was wondering if there were any Windows Programmers out there that might want to continue some of the work. I use to do a lot of Mac GUI programming in the past but don't really want to tackle MS GUI stuff unless I really have to. Hopefully someone with experience or at least the ambition might step up to the challenge.

Mike

Share this post


Link to post
Share on other sites

Mike,

I am working on the same project! We should get in touch. I have recently programmed ATMega128 to send AX.25 frames with GPS information (lat/long/alt/speed/heading). Now I have artificial horizon display running at 8 frames per second receiving AX.25 frames through AGWPE and displaying it using Matlab app. I also spent lot's of time making my modem compatible with AGWPE, but now I believe AX.25 is too ineficient for the task. 16 bytes in the packet is wasted to make packet compatible with AX.25 format - that's too much. Also, 2400 bds limit of AGWPE in AFSK modulation is too slow.

So, I am looking to either write my own soundmodem driver or build receiving modem on another chip and hook it up through serial port. Let me know if you think we can combine our efforts.

Regards,

Val.

Share this post


Link to post
Share on other sites

Cyber-flyer, have you had a chance to measure the bandwidth of your audio channel?

Share this post


Link to post
Share on other sites
bandwidth of your audio channel?

I've tested 4800 bds data transfer using audio channel of Lawmate's 900 Mhz RX/TX pair and using AFSK modulation. 4800 bds is the fastest AFSK modulation speed that FlexNet soundmodem driver allows with my sound card. As I've mentioned AGWPE is limited to 2400 bds in AFSK.

FSK is suppose to work at 9600 bds but requires modification of hardware.

I am sure it's possible to send data at faster than 4800 bds using modulation other than AFSK but I haven't tested the other options yet.

If you know good description of other encoding algorithms please let me know.

Regards,

Val

Share this post


Link to post
Share on other sites

I asked because if your video system supported >20KHz audio then you could use a design such as this one: http://www.amsat.org/amsat/articles/kd2bd/9k6modem/

When you have the time just toss your audio generator on the Tx and measure the -3dB points at the output of the Rx. If the general fidelity of the audio path is good then your idea to use the 9600 Baud hardware solution is a good one.

It is something I had planned to create, but I have been too busy. A few years ago I created a BELL 202 FSK 1200 Baud modulator for a commercial product that was based on a PIC. I was hoping to revamp the design for 9600 baud. Maybe one day...

Share this post


Link to post
Share on other sites

VAL: I would love it if we could work on it together. But I don't really see how. I really want to stay with the PICs since this is where I have my investment in. 3 compilers, programmers, dev boards etc.

I downloaded your MatLab stuff last year. I don't really remember what happend past that. I think I stopped looking because a version that allowed me to create stuff using MatLab was quite expensive.

The one thing I think we SHOULD do together though, is come up with a standard AX.25 frame for our telemetry. Well at least the info part of it.

That way we could actually use each others stuff if we wanted to.

I was thinking something like NMEA.

So the info part would look like:

$DATATYPE:VALUE:DATATYPE:VALUE:ENDMARK:Checksum

or

$TIME:162312:ALT:2100:$FF:$CA

Something like that.

I think I might have already seen some standards somewhere, but did not bookmark the page. I will search again.

--------------

The data modem I created is only 1200 baud. But in my tests with AGWPE I'm getting 5-6 Frames a second. This is pretty reasonable for what I want to do right now.

I'm using the MX614 chip. MX has some others at 4800 but I haven't looked into them. I read about doing 9600 somewhere when looking into CRC stuff. Baqsically the frame checking gets a bit more complex.

-------

Edited by mikep

Share this post


Link to post
Share on other sites

I looked at the APRS format and noticed that they have a specification for Telemetry. Using the APRS format adds some amount of overhead because there is a lot more information coming in then we need to simply have a an artificial horizon for instance, but it could have a more universal appeal.

What do you think?

You can get the specs at:

http://www.tapr.org/tapr/html/Faprswg.html

Look at chapter 13.

Share this post


Link to post
Share on other sites
I was hoping to revamp the design for 9600 baud.

Mr. RC-CAM, I remember reading a description of 9600 bds FSK modem operation (probably on TAPR web page). They were pretty specific about not using audio channel but hooking TX directly to FM modulator and RX directly to the demodulator to make it work. I can see you point about fidelity of audio channel. My thinking was the same - audio channel bandwidth of video link is much better than regular FM voice links. Honestly, I even spent couple of hours by coding 9600 FSK modulation on ATmega chip and trying it on direct link between the modem and soundcard but got nothing out of it. May be I gave up too early, may be the problem was with some error in my interpretaion of FSK algorithm...

I really want to stay with the PICs since this is where I have my investment in

Mike, I was afraid you would say that. I have the same reason. I was following your progress with autopilot with interest... but I've already invested in AVR programmers :(. I originally bought AVR prorgammer to reprogram Carvec software.

SHOULD do together though, is come up with a standard AX.25 frame for our telemetry

It would be great. But then again, will you agree with my format?

I've decided not to use strings and pack all data into binary form. So my frame looks like this:

FLAG

FLAG

"AX.25 required fields" (16 bytes)

"Roll"(1 byte)

"Pitch"(1 byte)

"Yaw"(1 byte)

$DATATYPE (1 byte)

VALUE (2 bytes)

CRC (2 bytes)

FLAG

FLAG ....

$DATATYPE identifier cycles through different GPS data fields: altitude, speed, heading etc. VALUE is 2-byte binary data. Because the overall frame rate is relatively fast and GPS data are slowly updating the successive 2-byte transfer of GPS data is sufficient. Roll/pitch/yaw are required to be updated as fast as possible, so they are included into each frame.

I had to give up string format to improve speed. For example your string:

$TIME:162312:ALT:2100:$FF

is 25 bytes long (assuming one byte per character).

Add to this 16 AX.25 bytes, 2 CRC bytes and say 4 flags => 47 bytes

At 1200 bds this will result in ~3 frames per second updates.

For the same reason I don't want to use APRS format for telemetry. In fact I'd rather not to use AX.25 as well.

Let me know what you think. Anybody are welcome to comment as well.

Regards,

Val.

Share this post


Link to post
Share on other sites

I need to think about it for a while. Will get back to you.

In the meantime. I'm curious about how many steps are you using in your SINE wave. I haven't tried generating my own yet. But I might give it a try.

Alsol take a look at:

http://www.cmlmicro.com/products/wdata/FX929B.htm

It's a 4-Level FSK Packet Data Modem. Speeds up to 19.2 over narrow band.

Means illiminating AGWPE for hardware though.

And here's a response I got from George about adding a pass all on AGWPE. Meaninsg we could illiminate AX.25.

-------------------------------------------------------------------------------

We have discussed it many times, I mean the pass all option.

Unfortunately this cannot be done, because each frame passes different

modules for processing. All these modules need real data.

I could create a new special frame kind just for those frames, but the

overhead is enormous. Soundcard DSP modem driver creates too many random frames, and have to stop them as soon as possible, to keep processing time as low as possible. Even logging of fault frames is impossible, they are so many................

And I mean with no packet transmition, just the FM Hisssssss.

That's why Packet Engine even if it has two channels it consumes very few

system resources. You can compare it with other dsp software which uses only

a channel at see the processor times.

Press CTRL+ALT+DELETE on win200/xp and check the resources.

Packet Engine Pro consumes half of the resources AGW Packet Engine uses.

73

(SV2AGW)George Rossopoulos

Edited by mikep

Share this post


Link to post
Share on other sites

Val.:

Another couple of questions for you....

What sensors are you using for roll, pitch and yaw?

Also how do you feel about using CAN?

I've been torn about bus protocols. Serial, SPI, I2C. LIN, CAN? Which way to go.

CAN seems to be the most promising but a bit complex.

I'm thinking every components needs to support a communication protocol so they can pass each other info.

Like the modem, has a CAN bus and listens for messaged to it. When it gets one it passes it on to the Transmitter.

Edited by mikep

Share this post


Link to post
Share on other sites
how many steps are you using in your SINE wave

12

4-Level FSK Packet Data Modem

It is FSK - it will send out high/low levels not frequency beeps. Direct connection to TX's on-board modulator will be required.

I could create a new special frame kind just for those frames, but the

overhead is enormous.

He makes a good point. But solution is pretty simple imho: let's add special starting signature in out packet like $$. This will exclude most of spurios packets from propagating along.

What sensors are you using for roll, pitch and yaw?

I have Carvec which outputs roll/pitch/yaw angles on its serial port. I realize that Carvec is not up to everybodys budget and I have plans to use co-pilot sensors for roll/pitch. While using co-pilot sensors yaw byte is optional - it can be sourced from magnetic compass.

Also how do you feel about using CAN?

I have no opinion about it. I haven't looked into possible protocols for device-to-device communication. Why are you asking?

Regards,

Val.

Edited by cyber-flyer

Share this post


Link to post
Share on other sites

I'm surprised the sine wave works with 12 steps. From the stuff I was reading people were worried about 128 steps not being enough. And the DTMF article I read was using 256 steps.

I took a look at the Carvec stuff, but did not see any prices. How much was the unit? Also what makes it so special? Is he filtering the Gyro and Accelerometers?

Do you have any pics of the unit (close up)?

About CAN. I ask because what would be cool is if you created an X/Y/Z axis sensor with the IR stuff and we use the same protocol, than we could simply plug in your sensor to a complete system.

So I was wondering how you felt about implementing CAN as a communication protocol with your stuff.

Basically what I think we need to do is come up with some standards as a community so that we can benefit from each others work.

Edited by mikep

Share this post


Link to post
Share on other sites
From the stuff I was reading people were worried about 128 steps not being enough.

I do not see why - all the higher harmonics are effectively limited by the bandwidth of the audio channel. I looked at FlexNet soundmodem source code - their filter sample at 8 times the baud rate, why go higher?

I took a look at the Carvec stuff, but did not see any prices. How much was the unit? Also what makes it so special? Is he filtering the Gyro and Accelerometers?

Do you have any pics of the unit (close up)?

I believe that Carvec prices depends on options that you request. I've heard a price of 2500 UKP for complete package which inlcudes camera control module.

It depends what you call filtering - but in some sense yes, Carvec reconstructs exact attitude angles from 3 gyroscopes and 3 accelerometer readings. It is pretty tricky to fuse accelerometers and gyroscopes correctly because gyros drift while accelerometers are affected by centrifugal forces. Carvec is not the only system available. Rotomotion and Neural Robotics make flight controllers that rely on gyro/accelerometer sensors. I believe their prices are all $5000+ range.

I am actually planning to sell my Carvec system soon - I will post close-up pictures when I do.

I ask because what would be cool is if you created an X/Y/Z axis sensor with the IR stuff and we use the same protocol, than we could simply plug in your sensor to a complete system.

My x/y/z IR sensor will be connected directly to ADC inputs of ATMega128. I will try to integrate as much funcionality as possible into a single microprocessor to keep weight/size down.

Regards,

Val.

Share this post


Link to post
Share on other sites

Actually I'm very open to the idea.

I just don't want to have a fixed type frame since that wil become very limiting very fast.

So we need a key:value for each piece of data.

We can maybe even get George AGWPE author, to add a datakind just for us. I've been trading some e-mails with him and he's been very responsive so far.

My Ground Station Sofware is coming along quite well. I should have a general release in less than 2 weeks.

So far the only instruments I put in are an altimeter and variometer. But adding instruments is very easy.

The hard part is actually communicating with AGWPE.

Basically I'm used to event driven io. In Java they use selectors.

So what needs to be doe is to create a thread simply to read the socket and fill the buffer with complete frames.

Once it has a frame it triggers an event to the main thread that processes it, updating the instruments etc.

I see two types of displays. One classical for instruments and one for HUD view.

It's actually easier than I thought it would be for the graphics part. For the thread part I found someone that is giving me a hand. I understand the concepts very well, but I don't really know the language yet. But I'm picking it up pretty fast.

Right now I'm only concentrating on the instrument panel version. I will work on a HUD one later.

I will make a web installer for it when Ihave something to show. I will want feedback from everyone for the layout.

Mike

Share this post


Link to post
Share on other sites

I don't want to sound ignorant about this whole packet format, but could you implement something in XML?

It seems to me that you could take advantage of a lot of existing and robust programs to capture and parse out your telemetry.

<edit>

Oops, nevermind, I just re-read the thread and it sounds like the overhead of XML would be a deal killer for your bandwidth limited environments

Bill

Edited by yb2normal

Share this post


Link to post
Share on other sites

You saved me from having to answer you!

But if I had the bandwidth it sounds like a good idea!

Share this post


Link to post
Share on other sites

Val:

I wonder if we should remove AX.25 altogether. I could ask George (AGWPE) if he would be willing to do this. I've also seen code for other soundcard TNCs.

The positive side of using AX.25 is that it is a standard. So that it's easier to use non-proprietary equipment. Such as real TNCs etc.

The negative side is we need to add more info to the data.

For the protocol itself of the telemetry data.

How about simply:

$ALT:2575,ASPD:456,GSPD:420,CRC

So $ indicates the begining of data.

There is no need to terminate the string since the last value is the CRC.

We then need to come up with Key names and factors.

Everything gets sent as WHOLE numbers. The precision is added on the ground.

So if we want Temp to the 100th of a degree we would send 2052 for 20.52 degrees.

The values are all sent as decimal values. So we end up working with strings which are easy to tokenize.

Also I'm thinking we go metric. Conversion can be done on the ground for those that want to use imperial.

Let me know what you think.

Mike

Share this post


Link to post
Share on other sites

Mike,

My feeling is that the string format is too slow. We need to get 20 packets per second transfer rate for reliable attitude indication. Even if George agrees to remove AX.25 requirement I don't see how can we get the fast refresh rate using strings. Am I missing something?

Regards,

Val.

Share this post


Link to post
Share on other sites

OK so what would be the largest number and highest precision we would need.

Lets say we use 4 bytes for everything. That would be a very easy thing to implement. It also matches up size wise with an integer on many platforms, making it easy to copy into.

We could also decide certain keys have certain sizes.

For instace for direction we only need a value of 0-360 and perhaps a precision of .1.

So lets say 0-3600. wich takes 12-bits. Personally I think I would rather work with bytes so lets say in this case 2-bytes.

It would be easier to simply have everything the same size but this would save of bandwidth.

Comments?

And then to really save on space we can assign a value lets say for the instrument.

With one byte we get a possible 255 instruments which seems adequate for a long time.

0x01 = altitude

0x02 = air speed

0x03 = ground speed and so on.

0x04 = longitude

0x05 = longitude dir

0x06 = latitude

0x07 = lat dir

And so on....

What do you think?

Edited by mikep

Share this post


Link to post
Share on other sites
We need to get 20 packets per second transfer rate for reliable attitude indication.

I don't see how that is possible.

Even here in my simple test I only get about 5 frames a second.

This is at 1200 baud.

Lets do the math for a 1200 baud modem.

1200 baud gives us 150 bytes per second.

A AX.25 packet with lets say 10 bytes of info in it takes up 30 bytes.

So at our 1200 baud we can only get 5 frames a second best.

So to get 20 frames a second we need at least a 4800 baud modem.

Next thing we can do is prioritize info. Certain things might not need to have a refresh rate that is so high and can be put on hold to when there's some free time to send it.

Edited by mikep

Share this post


Link to post
Share on other sites

So after doing that math and thinking about it for a minute, here's what I think.

We don't need the CRC stuff because AX.25 already checks the frame.

We should drop precision to a minimum because most of our sensor will not be that precise anyways.

Each piece of data has a specified size, as tight as possible.

It is identified by 1 byte. You need to read in that byte, see what it is, read in the number of bytes for that type of info. The following byte will be the next key.

We know when we are at the end by the AX.25 frames data length.

Edited by mikep

Share this post


Link to post
Share on other sites

I keep replying to myself. It's like if I'm talking to myself! ;-)

Anywas I trying to find out how to officially add a protocol to AX.25.

Basically removing the address bits and protocol identifier.

So it would become Flag|Control|Info|FCS|Flag

That would save 120 bits

I use to be on a list for AX.25 specification but never got any messages. And now I can't even find the list anymore. If anyone knows where it is, please let me know.

Mike

P.S. I also asked George if he would be willing to implemebt this in AGWPE.

Share this post


Link to post
Share on other sites
0x01 = altitude

0x02 = air speed

0x03 = ground speed and so on.

0x04 = longitude

0x05 = longitude dir

0x06 = latitude

0x07 = lat dir

Hi Mike,

Yes, that is exactly what I am using. 1 byte to identify the instrument and two following bytes are actual data. Notice that for most of the instruments 2 bytes are enough but lat/lon need 4 bytes. APRS spec has description how to encode lat/lon into four byte number - it's rather involved. lat and lon will need to be sent in two frames each. But we can work out these details later.

But there is another difference: attitude angles (three of them) are sent in the same packet because they need to be updated fast and you can not afford to cycle through frames.

Overall there are 6 data bytes in my packet. Add 2 bytes for CRC - we need it to discard corrupted packets. Plus add 3-4 more for flags.

Total 12 bytes - that's 12 frames/s at 1200 bds. Not fast enough.

If you can convince George to drop AX.25 format - that's will be a big progress.

Regards,

Val.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×