Topic: Low Cost Vario For A Glider

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.

I had one board I was supposed to be writing a bare-metal kernel for, without any ICE or anything. The only thing I could do for about the first week was blow an EPROM with my code on it, plug it in and see what happened. Except there was only one LED on the board, the one that showed the processor was halted - and that came on if it didn't find a kernel to run anyway.

So my first big success on that system was when I finally pressed reset and it took 5 seconds for the 'HALT' LED to light up instead of instant... amazing how much work it took just to get it to that point!

The write-compile-test cycle on that thing was about an hour long even for a tiny program because I had to burn a fresh UV-erased EPROM every time.


Well done getting it to talk to you - that's the hard part done, everything else now is just prettying it up

When ever I developed s/w in the past I have always had a decode whether its a series of LED's on a port or with the modern PIC coded in C I use the software uart to send out decode message to a VT220 emulator.
But using the ICD in debg mode allows you to view registers and variables to see what the program is doing.

Its always tricky talking to a bit of kit if you dont know what its doing.

Will be interesting to see what the two directions both Jason and myself take.

Keep it up mate.
J

Well from success to not so in a few hours, I cant believe how sensitive the MLINK protocol is to timeing between requests from the reciever (this could of course be SM-Modellbau's implementation thats the issue).  I have added but a sprinkling of code to the programme and its hit or miss now as to when it picks up the receiver requests and stops outputting that dammed Jeti stuff.  I dont think the Arduino is that efficient either, considering its steaming on 16MHz, it seems to get slower with a couple of additional string manipulations in it!

So, if I just want to trigger the gps unit into spurting out its MLINK data, I can, but if I actually want to do anything useful with it, I cant!

Bah.... 

At this rate I'll be switching to my openaltimeter and using that as the source!

I have a feeling I might wander back to some assembly if this C++ malarky doesnt get better!... now where's my hammer?

Is the arduino preloaded with software and you just code up you bit which runs along side the code pre installed ?
The reason why I ask is that from what I have seen in NI kit is like that as well, and it has caused me massive head aches in the past !

There so called FPGA cards with huge FPGA's fitted are already preloaded with code to interface.
You come along and code your stuff in the bit thats left and it doesnt run correct due to the "pre-loaded" stuff.

One of the reasons why I use a blank device and use my own drivers and timings.

Jon

Yes - its an interpretted thing.  Though the idea is you can develop on one device and port it with ease to another... so if I fancied wearing my code, I could......

I am currently favoring one of these for the airborne part of the kit coupled with a Xbee or similar.
http://arduino.cc/en/Main/ArduinoBoardFio


Or if you wanted to wear it, you could go for one of these:
http://arduino.cc/en/Main/ArduinoBoardLilyPad


I think it feels like most of these machines are just used to make nice flashing LED cubes (though there are some autonomous aircraft running them too).

Yes - its an interpretted thing.  Though the idea is you can develop on one device and port it with ease to another... so if I fancied wearing my code, I could......

As far as I know, arduino stuff is compiled by the IDE and the only 'built-in' code is the bootloader that doesn't run once it's handed control to your code. There's no microkernel or interpreter in there.

16MHz sounds fast but once you start having to do serial comms on the CPU instead of with a UART it doesn't take much to slow it down.

Yes - I might branchout and buy something else to remove the UART issue... its not like I dont have any FTDI boards to convert it to 232 levels

I have never seen a problem with software uarts, but then again i have only.ever used them as output diagnosis ports and not for inputs.
Best thing is to use a hardware uart to interface with the device.

Managed to get my prototype working again, but noticed that my voltage readings were incorrrect due to the reference i have used.
Schoolboy error doh.
Tomorrow ill fix that with a band-gap.
Jon

So... my bit of software polls 16 sensors (0 to 15) and stores the data for each one, it recognises when a sensor is disconnected from the bus or times out in responding. There is a 53ms window after each poll to read the 4 data bytes returned from the sensor, if no responce in this window it moves on to the next address.  Once it has been through all the sensors, I do some house keeping on the data which is a structure in an array.  This house keeping adds a delay on to the end of the address poll.

I have so far managed to get the thing to recognise and store up to any 12 out of the 16 sensors I can put on the bus.  I put these on the bus using my Unilog2 at the moment.  If I try and add the 13th sensor to the bus, the print statement to the serial LCD display adds too long to the time between each address poll run and the Unilog2 looses teh Mlink and switches to Jeti output.

I know I dont need all 16 sensors, but whats the point in having the capability if I cant use it   Anyway, different board turning up tomorrow which doesnt have an integrated USB to serial, so hopefully I can move the more critical serial bit (the mlink bus) on to the hardware USART and put the less critical data output to a software serial.

Only problem I can forsee is the board is designed to mount an XBee or similar to it, and I suspect it uses the hardware USART as the communications channel.... where as I could do with that sitting on a digital pin set as a a software serial port...  Might have to do some clever hacking with the connectors... hmmm

I might still head down the PIC route for the Mlink or even just plug the data straight in to the radio gear and do the decode etc on the ground...  certaily would prove a bit easier as long as the link is reliable!

I think I have suffered a bit of scope creep here, its not just a vario now but moving on to a ground telemetry box, like Jeti but without a link over the controller.

I have so far managed to get the thing to recognise and store up to any 12 out of the 16 sensors I can put on the bus.  I put these on the bus using my Unilog2 at the moment.  If I try and add the 13th sensor to the bus, the print statement to the serial LCD display adds too long to the time between each address poll run and the Unilog2 looses teh Mlink and switches to Jeti output.

Why not do half the sensors each time instead, assuming you can draw the screen without clearing what's already there?

I've played around with limiting the number of sensors with not too much success, I think the timeings are quite tight.  I'll have another go now I am happier with the current code.  I had to drop the number down again as it had one instance where the unilog flickered in to jeti mode.

Picture to record the moment of a bit more success....  values on the LCD are teh addresses which are present on the bus and returning data.

I need to workout when the best time is to go through the array of data and convert the encoded data in to the right symbols and values.  The values need a bit of conversion and I still need to understand how they are stored properly.  I think they are in hundredths for the voltages for example so the decimal part of the voltage works out right when multiplied up, i.e. 0002 = 00.02V

I've played around with limiting the number of sensors with not too much success, I think the timeings are quite tight.

If you know you can yield at suitable points, could you read the values on one pass then print them on the next?

Jason,
Is you LCD a 2 wire (I2C) LCD ?
Is the I2C a software or hardware bus ?
I have implemented s/w I2C's on pics that dont have the hardware and found that they also slug the processor speed.
If so it maybe worth getting a device with both hardware I2C and USART's.
J

Its TTL serial Jon, not I2C.  The LCD is sat on the hardware USART port at the moment as it isnt suceptable to the USB interface circuitry.  The timeing critical MLink Bus is still sat on a software UART (albeit interupt driven).

I didnt have any problems with PICs and I2C in the late 90s.  I was mostly using 16C64's & C74's with their builtin SPP functionality to interface with RTC and eeproms for applications in the rail industry.  Other than that I was mostly using 485 for interboard or inter device comms.  This was all in asm, I just couldnt get on with the C/C++ implementations..

Looks like there 16C64 is now a discontinued line, I feel like a dinosaur!

Oh the fun of having to wait for the eprom cooker to finish so I could retry some code....

I am sure there was another one I dabbled with which was like the 16c84 of the time and electrically erasable... not sure the number now.  Oh and the 16C84 featured quite highly in my final year project, mostly because I had an ace simulator on the PC which allowed me to code and see the registers and data bits being set.

I certainly have a historic soft spot for PICs... maybe I should revisit them.... problem is the Arduino is quite a quick platform to develop on and easy to access / prototype with...  the latest additions should be with me today, the radio modules and the smaller Arduino unit with no USB circuit to hog the USART... I am looking forward to playing with that as I am sure it will remove some of the timeing issues and allow me to use the full address range.

Anyway - some more success last night, another 01:30 finish... I now have values from the Mlink with the symbols displayed on the LCD for 2 selected sensors (only a 2 line LCD).  I haev tightened the code up and can get about 14 addresses out of the Unilog but there is an intermittant issue that allows the timeing to get too long and the unilog starts outputting the default Jeti data, so I have reduced back to only worrying about 8 to 10 sensors (which should be more than enough for any ground based telemetary display etc).

Problem I have at the moment is the symbol doesnt match the data selected for output.  For example, if I select temp sensor A & B on the Unilog as say sensor address 0 and 1 on the MLink, I see the right data values, but wrong symbols (when looking at the raw data), I think this may be an issue with the Unilog not MLink or my code, but I want to do a bit more research before I draw a final conclusion.  Another issue is the Unilog stops sending MLink after a long period of time.   My code is still sending sensor polls and the Unilog is still displaying the sensors changing values on the unidisplay so again I think it may be an issue with the Unilog2 code.

I thought of another way to get the data out of the unilog and thats to use the small molex connector which connects to the display and inter units (i.e. joins the GPS and Unilog2 together).  I suspect given that this needs to work perfectly with the unidisplay and the other unit, there is more success to useing that as a data source... just means I lock in to a unilog/sm-modellbau as the source of the data.

More playtime tonight as the Mrs is out at the Theater 

Your not a dinosour Jason, just out of the loop.
I had issues with I2C on non-spp devices, trying to implement a software SPP, was all a bit of a mere really when the device has acknowledged before you had a chance to set the pin back to an input again.

Even the devices that I have heavily used in the past have now been updated with more RAM and E2.
My fave device the 16F876a is in the process of being replaced by the newer 16F886.

Hey ho progression.
Seems like your making steady progress with your one.
I have several ideas for mine now.

Hopefully this will work... posting from my phone.

https://www.youtube.com/watch?v=MPCiijEP8nI

Youtube is blocked at work, so not sure if the link above has worked. 

The unit now reads the MSB and posts the info on a scrolling LCD for however many sensors are operating, including the right symbols.  I havent sorted out negative numbers yet, I need to write / source a simple signed word to ascii routine  to cover it.  The numbers coming out of the unilog need to be divided by 2 to reach the same number as displayed on the unidisplay.  Not sure if this is right, I can see it being right because of the decimal places etc, but I suspect it might just be an ignorant fix on my behalf for some other reason!  Its 2's compliment and supposed to have an alarm bit, so perhaps I am stripping off the alarm bit by the divide by 2?

At the moment, the vario tone beeps every 750ms, the base tone is 300Hz and then the value is added to that with a defined multiplier to adjust the sensativity, so at the moment I think in the clip above this is set to a value of 5.  Its hardcoded to read sensor 0 at present.  Testing with the vario itself is a bit tricky due to the 2's complement / negative number issue at the moment... It probably means a bit more thinking around it...

I received my wireless modules, but I have one thats dead.  They are intollerant to 5V inputs, but the breakout board I was using which braggs about supporting 5V  to 3.3V specifically for the XBee might not have a voltage divider on the RX/TX pins, so I think this is where the damage has happened....  I was hoping to put it in a glider tonight and try it, but looks like it might not happen for a few days now till I get the new module through the post.

How's yours getting on Jon?

Mine is not going to bad.
I have been having issues with the BMP085 api in the PIC.
As the PIC is a 8bit device and the BMP085 generates massive 16bit long integers, you soon run out ram (876 only having 256 to start with.)
Got my head around using the onboard flash to store the bmp085 calibration constants on every power up, but that itself has proved to increase the loop time, and the display started to update every 8 seconds or so (Delay due to taking several readings from the BMP085, running a max, min and mean bit of maths on the readings, and then running the BMP085 api on the readings to get true altitude and with the calibration constants sitting in flash!).
I'm only running the device on a 4MHz clock (Cos thats what I had laying around.)
I have since found a 20Mhz clock which should speed up the loop by 5 times, and hopefully make the loop only 1.5 seconds or so.
Once I have the code running correctly and I have calibrated the altitude (Will do that by going up in a microlight ) I will be in place where I am happy.
I can read the air pressure, relative humidity, battery voltage and temperature and stream them all to my LCD (Oh I had to also write the LCD Driver, which in itself wasnt that hard, but they all have subtly different timings which was a real pain to start with.).
The next step from having the functioning proto-type will be to build another circuit and then stream the data to the serial port for rf transmission to the base station. (The base station will probably be the 1st proto-type hacked about a wee bit to save time.)
The actual code for the base station should be simply the case of decoding the incoming msg, and displaying the data on the LCD. (he says !)

It all takes time when you have to build your own sensors and commission them along side with coding and debugging oh and doing the day job, and decorating the house to boot.
Still I did manage a couple of hours on it this morning while the mrs was watching the rugger !

Its all interesting stuff and keeps me scratching the head and gives the old grey matter a work out.

I still haven't ordered any xbee's yet, so the working proto-type system will initially be wire wired, to prove the concept.

Stay tuned.

J

Have you checked out the winged shadow how high system?

It supports telemetry -  and is only about $50 to buy!


Sent from my iPhone using Tapatalk

Where's the fun in that Rob

They only work with Hitech, Frsky and Spectrum at the moment, so no good for us Futaba boys.

It's easy to go buy one, but more taxing to make your own if you know the score.
It's funny when people suggest cheap alternatives after I've spend over a 50 hours coding, building and debugging.
Still keeps the old grey matter ticking over.
J

Hey...

dont get me wrong 

I am all for building things myself  I am one of the developers on the er9x system; so very aware of the hours of work involved; but also the raw pleasure involved in building it yourself; and doing all the electronics.

I simply felt you where aiming for a similar thing - and it may provide some use full ideas.

Rob

Hey Rob - no worries I am doing something similar to what you suggest, only I am using a SM-Bodellbau GPS receiver (or a Unilog2). 

Biggest problem is no telemetry for Futaba... so its just a glorified one of them I am knocking up

Not much progress this week, too much to do at home and work :(.
Hoping to do some more this weekend.
J

Finally got the negative numbers working!  So now the vario aspect works over a wireless link, so I guess I could test it out tomorrow.

I am a little disappointed with the SM-Modellbau GPS unit, it only outputs in 1m steps for height and vario the speed is at 0.1 kmph steps.  Will see what difference that makes in real life gliding.  It makes it a bit of a pain to test though, I have resorted to running up and down the stairs to test it as I can only get a max of 2m height variation myself!

A bit of soldering tomorrow and I think it will be ready for a test.  I think I might use a pressure sensor and just build the vario as a standalone unit if the resolution is an issue.

http://www.youtube.com/watch?v=0N7EwCF0aiM

Hmmm... embedded youtube seems to be borked....

Use just the pressure sensor.
I need to get going with mine again.

I am a little disappointed with the SM-Modellbau GPS unit, it only outputs in 1m steps for height...

Hmmm... embedded youtube seems to be borked....

Looks fine to me. You only really need the GUID between the 'youtube' tags anyway, not the whole URL.

As for the resolution, I've noticed that all of them seem to be to 1 foot or 1 metre or both. 1 foot is three times better, it's a shame they can't make it 25 or 30cm in metric mode, although 10cm would be even better.

Can you put the SM into imperial mode and apply a metric conversion before you display it?

No, unfortunately it's fully European LOL

I looked at the Open Altimeter next to my radio modules and they will fit on top with little problem, so I might just use a OA with a radio module... then its all in one unit with data logging as well.

Where's the fun in that Rob

They only work with Hitech, Frsky and Spectrum at the moment, so no good for us Futaba boys.

Interesting thread this. So are there any commercial options for Futaba owners at the moment?

Or can I buy an rx with just the vario on board and some sort of receiver on terra firmer?

nothing for futaba just yet, but I think that the 18MZ has the function built into its software.

Well its been in the air.  Still working at 460m!  I had to do some field coding as the vario from the SM-Modellbau GPS loger is a bit Carp in the air, too laggy.  So I wrote my own vario calculator based on teh height and used that.  Still not as good.   Ordered a pressure sensor this morning, in fact I am going to bolt on to the open altimeter in teh first instance and play with that... might buy another of them and piggy back the XRF module on to it.  At least I then have full control of the source data and its transmission instead of the bodge I have to do at the moment.

You're a genius. You must be, because I don't understand 90% of what you write in this thread!

Keep up the good work. Old Ott is interested in the sensors and your use of Arduino. I have given him your email address so that you can boffin away at each other for a bit.

Best regards,
Jef

Right, after a few weeks of decorating, work, sorting various models for the F3B league and flying I have finally managed to get around to doing some work on the vario.

I was struggling with loop delays and it taking 8 seconds to go round one loop.
The main issue was the api for the pressure sensor and the fact that the sensor itself is a I2C device.
Also the floating point calculations to compute the altitude was using 8 - 8Bit registers per calculation, as a required by the api, took up a lot of processing time.
The poor little 2MHz clock I was using just wasnt man enough, bearing in mind that the PIC takes 4 clock cycles to execute a single instruction (All these time delays add up.)

After a wee bit of modelling in C on my laptop I have managed to proto-type a method of reading out the calibration data from the pressure sensor and store it into flash.
Now accessing the flash on a PIC takes time, but not as long as accessing the calibration data via the I2C to the sensor.

This seems to reduce the loop time by up to a third, which is all good.
Also I have changed the clock source to 20MHz, which is the maximum for this device.

Another thing I have done is improved the accuracy of the voltage readings by using a precision voltage reference like a band-gap.
I have also scaled the input to the adc channels and used some ohms law to calculate the input voltage (Noddy stuff, but I thought that I would add it.).

Next step is more messing around with the api for the pressure sensor to get it to run as efficiently as possible.

Probably take me a few more weeks yet and I still haven't looked into transmitting the data down the serial link.

Like british Rail, I'm getting there.

Jason anymore movement with yours ?

Jon

The temperature part of the BMP085 stuff is very slow just to get a value for B5. I wonder what difference it would make just using a constant value for B5. Temperature only varying by small amounts over the altitudes you are flying at.

My Sparkfun BMP085 not here yet. Will have a play when it does.

Dave