Topic: Low Cost Vario For A Glider

Given the cost of commercial devices have been playing around with a low cost solution. Target price is £50!!

After several false starts have used a circuit design as per the following link  vario

Circuit uses a BMP085 digital pressure sensor which is pretty common and can be purchased here in the UK as a sparkfun brakeout PCB.

Problem was of course  the PIC isn't it always! First of all had to buy 5 just to get a single device.  Then had trouble finding a method to flash the software but finally managed to get the loan of a pucker device at work which did the job in seconds.

Basic trial assembly would have been as shown attached but failed miserably to post pictures on this site.

So does it work....Yes it does but the sound out of the Maplin miniature piezo sounder is very low. Perhaps should have used the recommended Kingstate KPEG006.

Next problem is the down link.  Have a cunning idea which I will explain in my next post but would welcome any suggestions for a 2.4GHz compatible system to get the audio back to the ground.

Was thinking along the same lines.  Cool Components has a 315 MHz Tx/Rx pair: 315 MHz Tx & Rx and if you poke around a bit they also do 434 MHz Tx/Rx.  They quote up to 500 feet range - you may get rather more in the air

I have considerable experience of using 433 and 868 MHz modules which I have designed into literally dozens of products for customers.

I applied the radio technology recently  to send the position of my Easy Glider back to a small handset with LCD display of current position. (its predecessor 'flew away one day !)

It worked a treat, updates every few seconds and the receiver holds the last received position. Thus if you do get a 'fly away' , using a sat-nav the 'plane can be quickly located.

OK - the down link. This used an 868 MHz radio module from company based in Lewes. The transmitter aerial in the EG was a whip of about 15cm of piano wire and the receiver aerial a stub rubber-duck effort. Range - well not as good as I expected but adequate for glider retrieval.

With the vario system you would have to send the signals back as data so this is not a trifling project as sending data over 433/868 links requires a fairly complex packet structure with Manchester coding to allow clock recovery at the receiver - so be warned. In practice if you can come up with a 2.4 G system this will save a lot of heartache!

I have made a Vario/altimeter using a PIC18F2220 and a BPS085.
Currently the proto-type just stores the max altitude and with a plug in module with a press button and a LCD allows me to read the altitude once the model is on the ground.
I am currently looking at Blue-tooth modem http://proto-pic.co.uk/categories/Wireless/Bluetooth/
This would allow me to stream the "live" output from the PIC in the model to another PIC Based design mounted on my transmitter with an audible alarm for going down or going up.

This is really a project to keep my mind going completely useless

I have a ICD2 PIC Programmer, so if anyone wants a PIC Programmed you could send it to me in the post and email me the HEX file and i'll gladly flash it for you and pop it back into the post.

I program my PICs with the ccs 'c' compiler as life is far to short to mess around with machine code !

Have you considered using this device

http://proto-pic.co.uk/xrf-radio-data-module/

http://www.rcgroups.com/forums/showpost.php?p=19176356&postcount=746

I am considering something to take a mlink signal from my SM-GPS / logger units and squirt it home to the ground ....

nice find jib's.
like having a serial wire from your model to the ground.

I dont know what the mlink serial data pattern looks like on a terminal.

My altimeter proto-type currently has the max altitude printed out on a LCD, but I did include the RS232 software, so when ever it streams to the LCD it will also stream to the 232 pins.
A simple CVI GUI could take the data transmitted from the varo and decode it and log it to a file as it comes in.

I have no idea either, I did see someone had managed to hook an openaltimeter to a Mlink evo pro and get it working so I am hunting around for the code related to that as I have a OE as well.  Not sure on if to go the arduino or pic route at the moment... I quite like that you can actually code to the wireless unit, but I am so rusty that I will be lucky to remember any C or pic asm!  Must be going on 11 years since I last did any design engineering in electronics now!

I can give you a hand with PIC C Jason.
My altimeter is based on a PIC18F2220 and the BPS085 from hitatci.
I have the ccs C PIC Compiler.
Havent done any arduino development cos i used PIC's all the time in the past and some of the new PICs are excellent devices.
J

I prefer the bit banging of assembly   Never did get round to using C with them, this was around 1998ish.

Like I said, not sure what to use yet... What ever it will be a squeeze to get it in to anything... my intention is to put it in my ASW17 when its ready to fly, linked up to my SM-Modellbau GPS unit and a receiver which gives me a vario tone in to an ear piece..... should be too hard, infact as its just a conversion of a Mlink signal in to some thing then a decode of ROC in to a suitable tone to represent climb/sink, then I really should be trying to get it in the actual radio units themselves!

Still in my head at the moment.. need to do a bit more thinking and searching first

I have another application for the radio link too, a serial link from my PL8 charger to another PC somewhere in the house so I dont have to leave a laptop teathered... hmmm the applications are quite expansive

I have done a fair bit of assembly coding in my time and consider myself fairly proficient at it, but wouldn't even attempt this in assembler, it would be a mission.
Best of luck if you attempt it in assembler.
I do have a PIC Programmer if you want a PIC Programmed, or want to do some development.

The BPS085 comes with an API that helps make converting the pressure to altitude easier.
The device also has an area of ESquared that contains the calibration data for the sensor.

Interfacing with I2C devices in assembler is a real P.I.T.A but each to there own.
I found this a real interesting project, been a lot better then writing LABVIEW code for test systems.

For the audible tone, you could use a 2khz tone as the standard neutral lift and then increase or decrease the tone for lift and sink.
I will have to experiment with mine proto-type.
Lots of stuff I can do to it.

J

Appologies have not done any more work on this topic for some time. Stil looking for a large glider to put the design into.

As for the link PMR is the answer. Cheap re-conditioned Tx & Rxs are available from e-bay for approx £16-20.  Go for a pair providing VOX.

If anyone is interested have some spare PICS available preloaded with code.

Very interesting.
Many years ago I converted some old pye westminster's to the 2meter band.
Unfortunately the PMR radios are way to big to fit into the fuse of my f3x model.

j

Cricky... old coppers radios LOL....

Right, I have my GPS logger set to output Mlink data and my openaltimeter (OA) connected to it, just need to remember how to code so I can see if I can read the data.

I splashed out on a Arduino Uno last night with a xbee shield and a serial LCD display - worst case is I put the OA in the glider with a trx, then use the Uno with a lcd display on the ground and a piezo for the vario tone.  Best case is I manage to decode the m-link and have a ground station with a display (like a jeti box I suppose).

I havent splashed out on a pair of TRX yet, may as well get it working on a hard wire link before complicating it further LOL.... what have I let myself in for - its not like I dont have a load of repairs to crack on with!

Cant believe the circuit board in one of these radios is very large http://www.ebay.co.uk/itm/BINATONE-LATITUDE-150-PMR-2-WAY-WALKIE-TALKIE-RADIOS-/400244403412?pt=UK_ConsumerElectronics_SpecialistRadioEquipment_SM&hash=item5d306cecd4

Display can go in the bin all you need is the Tx. Pluss you get 2 for this price.

I agree, but the space I have in the fuse of my cyril is around an inch long by half an inch wide with a sky line of around 1/4 of an inch.
The proto-type I knocked up is a smage over, but if I were to use surface mount devices I could really shrink it down.

Jason, coding that lot in asm, well your a far braver man then me !
I do like the look of the Arduino kit.
They must do a C compiler for it somewhere (Megga dosh !).
J

I do like the look of the Arduino kit.
They must do a C compiler for it somewhere (Megga dosh !).

Only if megga==free. Have a look at WinAVR.

I've only done minor things with it so far and I'm away at the moment so I can't look it up easily, but I believe it can do all you want, including libraries for I2C and I2S. All hobbyist done so of variable quality, but available, with source if you want to improve it.

And don't forget to look at the smaller surface mount versions of the arduino... some are pretty damn small.

Well my Arduino Uno turned up yesterday, I went for the easier option...I had it beeping away pretty quickly and printing hello world on a LCD display.  I have found a fair bit of info on the M-link protocol, but I am struggling to get the comms settings right, I can see data coming in from the SM-Modellbau unit, but it isnt like the M-link protocol suggests it should be!

It would be nice to get it as smal as possible, as this is going in a PT ASW17, its not too much of a problem at the moment.

Jon - The Arduino IDE is free, in fact you could probably knock your own board using strip board for less than a fiver!  There is even PIC based boards too...

I had been looking for an excuse to play around with one for some time, I was going to just use my openaltimeter as the development and test bed... in fact it may still feature.  But the dev board setup of the Uno just makes things soooooo much easier 

I can see data coming in from the SM-Modellbau unit, but it isnt like the M-link protocol suggests it should be!


 ...but the dev board setup of the Uno just makes things soooooo much easier 

Could the serial line be inverted, or is it not *that* different?

When the dev is done you can use he same code on any arduino compatible, e.g. the  'Teensy' which is really small, or the 'Teensy++' which has more I/O options. Those two also have direct 12Mbps USB connections as well as the serial port...

Hi Jason,

My Dad looked into using Arduino Uno in a similar way. You should be talking to him (or emailing him), as he needs to be involved in projects like this while convalescing.

Jef

Could the serial line be inverted, or is it not *that* different?

When the dev is done you can use he same code on any arduino compatible, e.g. the  'Teensy' which is really small, or the 'Teensy++' which has more I/O options. Those two also have direct 12Mbps USB connections as well as the serial port...

Tried it inverted this evening and not a lot of difference.  The problem is getting it in to a readable hex format.  I suspect there is something else at play here.  Not having a multiplex radio so I can see what might be working or not isnt helping LOL.

Maybe its a different serial string to what the UART is expecting.  I am showing my age and lack of being out of the game for so long by not being to work this one out! LOL


Jef - I didnt know OldOtt was in to fancy C programming   Thats a great idea

looks more java based to me.
Down loaded the version for mac osx.
I prefer to make my own driver modules, that way you have more control over what the code is doing.

The ardunio stuff does look very interesting, but cant see any application that I cant do with a PIC at the mo.
Will keep one eye on it.

Have you scoped up the serial data stream jason ?

Could be worth doing this and then try and see what the serial data word is.
Jon

have you looked at this ?
http://www.stoeckli.net/Lists/Posts/Post.aspx?ID=4

Yes and the other site too...

I can get half a "Jeti" in the serial stream, so I could read the jeti data if I can work out how to change the code to read 9 bits instead of 8bits.

Here's the other site (you may need google translate to understang it).

http://www.stettmaier.de/stmMPX/stmMPX.htm

From the Stoek site, I assume 1,8,n,1 is just the same as 8,n,1 ?

Off to look to see if I can pull another bit in to teh data in the serial driver.... I suspect it might not happen, its been so long since I did any of this kind of coding I am strugling with pointers and indexs LOL... not had to resort to a text book yet though

Picture of my Proto-type.

Managed to get the proto-type altimeter working, but along the way I managed to fry my LCD (Long story).
Any way before I attach the £15 BMP085 device I decided to get the proto-type code working in the PIC.
I have used a PIC16F876A for this project (Well so far, but that may change when I make the B Model ).

The program so far reads ADC channel 0 (Which is the supply voltage) and prints to LCD.
Then it reads an I2C temperature sensor (TC74-A0) and displays this on the LCD.
Then it read the I2C Humidity device, does some maths and then displays this on the LCD.

The next step over the weekend is to wire in the pressure sensor and uncomment the API code for it and start reading the air pressure, doing some maths to convert this to altitude and then display this on the LCD in the gap below the relative humidity, next to the supply voltage.

The eventual aim of the A model is to have a menu system like the ford dash's of late that will display the readings after a button press as follows :-
Supply voltage
Temperature
Humidity
Air pressure
Current altitude
Max altitude
The back to supply voltage.

There will also be a button that resets the max altitude after a flight.

Once I have all this working I will sort out the wireless link to stream all of this data via the on-board USART to my laptop.

I could then potentially write a C++ program that logs the Supply voltage, Altitude, Humidity and Temperature to a file.

Its the case of making a development system and then shrinking it down.

The next version may even have a mini SD card on-board and I may get the PIC to create a FAT16 file on it so it can be read directly off. (Maybe a CSV file to load into excel.)

If any of you have suggestions or then I'm all ears !

Why humidity?

lol, good question.
I obtained by game of chance a humidity sensor (I2C) so I wired it up.
but - Humidity is a measure of the amount of (invisible) water vapour or the degree of dampness in the atmosphere. If the relative humidity and temperatures are high the air feels damp and murky. It is the condensation of this vapour which gives rise to clouds, rain, snow, dew, frost and fog The limit to how much water vapour the air can hold varies with temperature.
The sensor is titchy, so I may as well use it.

Its a nice project and its going well though.

J

Good stuff

I am still struggling, I have managed to get the UART to do 9 bits receive, so should be able to read JETI.

Can I?

No 

lol, good question.
I obtained by game of chance a humidity sensor (I2C) so I wired it up.
...

I would have thought humidity would affect air density, hence also affecting barometric pressure, air speed indicators, drag and all sorts.

Probably not enough to be worth going out of your way unless you already have one though!

I keepeaning to make a vario from a TI Chronos watch dev kit I got cheap - it has a really good barometric sensor in it as well as a 433mhz transceiver, a display, buttons, accelerometers, all you need. Except time to do it!

Good stuff

I am still struggling, I have managed to get the UART to do 9 bits receive, so should be able to read JETI.

Can I?

No 

Have you scoped up the output of the jeti device to see what message your getting ?
Do you have a RS232 level shifter and a serial lead that you could hook up to a PC with a serial lead and use the VT220 emulator to see if that can read it 1st.
You can easily mess around with the baud rate and data bits until it receives something.
Then you can configure your device to look for the same.

J

Right - I have finally managed to get the PC to read the SM kit (rather than the Uno..)
All I see is a repeated string "SM GPS-Logger    via Jeti Duplex" I suspect there is some sort of transaction that needs to take place to get it to talk with numbers.....

No sign of any Mlink stuff... its getting a bit fustraiting!

Oh - and this appears to be a good terminal prog (free) with hex / ascii display.
http://translate.googleusercontent.com/translate_c?hl=en&rurl=translate.google.com&sl=de&tl=en&twu=1&u=http://www.der-hammer.info/terminal/&usg=ALkJrhgMEHUAujadox1X24x5Yu_DNFRwYw

does this help ?
http://www.rcgroups.com/forums/showthread.php?t=1002362

Right - I have finally managed to get the PC to read the SM kit (rather than the Uno..)
All I see is a repeated string "SM GPS-Logger    via Jeti Duplex" I suspect there is some sort of transaction that needs to take place to get it to talk with numbers.....

No sign of any Mlink stuff... its getting a bit fustraiting!

Oh - and this appears to be a good terminal prog (free) with hex / ascii display.
http://translate.googleusercontent.com/translate_c?hl=en&rurl=translate.google.com&sl=de&tl=en&twu=1&u=http://www.der-hammer.info/terminal/&usg=ALkJrhgMEHUAujadox1X24x5Yu_DNFRwYw

Have you had a look at GPSBabel.org to see if it can help with the protocol?

Found that thread last night, 

 I am slowly working through the german forum.  But none the wiser as of yet.  They appear to just get data straight out of the sensors.  Perhaps its a SM-Modellbau quirk on the jeti side.

Off to look at GPSBabel.org  now

The output of the M-Link stuff is not open Collector/Drain ?

Looking at the link it says that it could be ?

What does your cct look like Jib's ?

http://arduino.cc/en/uploads/Main/arduino-uno-schematic.pdf

PD0 / PD1
Nothing pulling low or high on the circuit. Maybe I need to add a pull up/down resistor?

But if the same output from the SM GPS gives the jeti, how can it also provide the mlink ?  (unless the current draw from the pull down switches it on?)

Finally got got the Jeti text on to the LCD.

Now need to work out hot to get it to do something other than say "SM GPS-Logger via Jeti Duplex"!

At last... after lots of head scratching, I made a breakthrough last night. 

From my experience years ago, I spent a lot of time debugging stuff without the benifit of an in circuit emulator (ICE), they were just too expensive for the R&D budget I had at work back then, then a breakthrough came when there was a cheaper ICE than the official MPLAB one...   I cant even remember the name of the ICE I bought at the time.... anyway in the pre-ICE days, any form of output would be used to flag what was going on inside the 16pin smoke generator I would be developing on....   in those days, you could be sure if you were convinced the code was right and the surrounding hardware was right but it wasnt working as expected it would be that one bit not set somewhere which was the spanner in the works.....  so you can imagin the plateuxs of development when you would hit that brick wall in not being able to find the proverbial spanner.
Last night I hit on a couple of spanners, and the final spanner this lunchtime....

1. First was upgraded firmware for the GPS logger... more likely to work with M-Link !

2. Second was stumbling across Multiplex software for reading sensor values and being able to use it on a FTDI chip.  This provided the information about what reciever sends to the sensors to get them to fire back their data, and the baudrate it does it at.  Sniffed it off the Arduino serial interface.

3. and finally the third was today discovering that the hardware UART is handicaped by the on board USB interface on the dev port.   All the while,  I have been snffing the Arduino output with a FTDI interface, everything going out looked OK, stuff coming back looked OK, but not what I was asking for... I even broke out the osciloscope to check that stuff was happening...  Finally implementing a software serial port sees me now conversing in M-Link with the GPS logger and seeing the data coming back, ready to be acted upon in the controller (at the moment I am just firing the hex data to an LCD)._

So far I spent a perfectly good flying day in here coding.... or rather spanner searching.... now at least with this breakthrough I can be more productive on yet another good day for flying LOL......

Reading this thread with interest. Not too good with all the techie stuff, but can see the advantage in keeping you guys enthused!

Humidity analyser sounds extremely useful to me.

I beilieve that water vapour is lighter than air (something to do with Hydrogen being substantially lighter than Nitrogen), so in the same way that warm air is widely seen as a good thing, 'moist' air is just as useful, but given less publicity.

Keep up the good work guys!

Jef

http://wingedshadow.com/howhigh.html

about $45 delivered to the uk.  Not a vario admittedly but though it might be of interest nonetheless.

Well I had my proto-type sitting there running all day yesterday in the back of my car at the F3B comp.
While it didn't help me out in the comp, it did give me confidence in the code that I wrote and the circuit design.
The code seems very stable with no dodgy stuff going on with it.
There was some problems with my maths to convert the humidity to actual % on the LCD.

Bearing in mind this is my own design, my own code and my component selection I don't think I'm doing to bad!

Unfortunate for me I managed to short out the clock output and bugger it all up :(
I checked out the PIC today on my ICD2 and thats fine.
The feed back I got while debugging was that the clock wasn't working, hey ho I'll get another tomorrow.

If you wanted to have a change in tone if the model was sinking or raising in lift, you could use the PWM function on a piezo buzzer.

The PWM could then change the period of the frequency.

Right more work looking at sorting my maths out for humidity and then start looking into the altitude sensor API code.

Stay tuned
J