Jump to content
Daniel Wee

My little NAV/OSD project - under construction

Recommended Posts

Okay, as I had resolved my video problems sometime last week, I began working on the OSD portion of the FPV setup.

I have an EB-85A GPS module (5Hz updates) and feeding a dsPIC30F4012 controller. So far I've managed to get the whole thing running at 115kbaud and pumping the output to a 16x2 LCD display (mainly for diagnostics - LCD will not be in the final config I think). The GPS is working and I have Lon, Lat, Heading, Speed, Alt, all coming out nicely. The module itself doesn't start reliably though, sometimes I have to disconnect power and reconnect - I need to look into this but it's not a major concern for me right now. I'm just happy to have the basic platform and code working now.

Next, I'll be slapping on the OSD (BOB-4 for the higher resolution - I like the pretty fonts) and getting the SPI portion working. Unfortunately I will be away for a few days from tomorrow onwards and won't be back till mid-week. Once I get back, I reckon I should be able to get everything going within a day or two.

After that, I'll be adding bells and whistles - homing stuff, voltage reading, etc. The BOB-4 OSD is very expensive and so is the GPS module. Between the two, we're already almost at US$200.

After I get done with that, I'll be starting on the artificial horizon unit. Anyway, that's the plan. I'll try to post updates as I move along.

Daniel

Share this post


Link to post
Share on other sites

>The module itself doesn't start reliably though,

just add a lithium coin cell to the battery backup,

then the EB85 works and remembers their settings, and aquire sats darn fast

Share this post


Link to post
Share on other sites

I thought about that - any idea how long a 3V CR2023 will last? I'm trying to keep the whole thing as small and light as possible.

As for my tests - I took the GPS out for a ride just now and noticed that the unit needs good GPS coverage in order to produce reliable altitude readings. This may be a problem of mine because I had the GPS sitting on the dashboard and driving in an urban area often with tall buildings obscuring the sky view. My tests, however, led me to think that a barometric altimeter may work much better for navigation. I guess that's what I'll be looking into next. I'll also have to start thinking about current readings and getting hold of a hall-current sensor.

What's encouraging though, is that the basic platform is working very well and now it's a matter of adding code and peripherals. I find with these projects that the hardest part is getting it off the ground and going.

Daniel

Share this post


Link to post
Share on other sites

Way the go Daniel!!! I'm looking forward to reading your final results!!!

Share this post


Link to post
Share on other sites

Thanks - I'm working on the BOB-4 interface at the moment. The trouble is that the SPI interface on the BOB-4 seems to want 3.3V while my controller is running at 5V currently. I could run my controller at 3.3V with a slight speed penalty but the thing is that the BOB-4 still requires a 5V power-supply. I'm thinking that I should just keep using 5V and use a simple voltage divider for the one problematic pin (SPCK - clock).

The other thing that I'm trying to do is to see if I can run the SPI in a uni-directional mode, ie. I just want to send stuff to the BOB-4 and I really don't care about anything that's coming from it. If this works, I can cut down on one extra wire. There is also a supposed problem with the BOB-4's 75MHz clock interfering with the GPS signal. For this I have ordered a 74MHz clock to replace the troublesome part but that will have to wait a while. Right now my main concern is to get the interface working properly, grrr.... why can't they make up their mind about their operating voltage.

Does anyone know if the SPI will work if I just send data from the master to the slave device and not connect the return data path (assuming I only care about sending the data and there is only one device on the bus)?

Meanwhile, I've improved the GPS code a little bit and it's really nice looking at the info showing up on the LCD. I'm thinking of getting a bigger LCD for more on-screen info. The comms is interrupt driven so it should be quite robust. I need to test to see if it suffers from the lagging updates problem that Thomas mentioned. I'm running this at 115kbaud and I seem to recall a bit of lagging in the altitude earlier on, but was not sure if that was due to the satellite lock changing or if there is a problem with the system. The controller is currently running at 20MIPS so I should have enough computing power to get some other nice things done.

Daniel

Share this post


Link to post
Share on other sites

the lag is not the baud !

the way the height is calculated with GPS units makes height the most unacurate parameter, just dont change the height to fast up or down,

since it can also screw up your position information.

I have now also yesterday found another bug on the EB85A:

sometimes when changing direction and height fast,

the speed readout can goto 0 for 1-5 sec !!

while this happen all other parameters count fine, proving the NMEA still run fine.

try to fly 100m with the wind and 100m towards the wind,

and when you fly with the wind try to dive a bit so your ground speed change fronm 20kmh to 120kmh, the dive can be 10-20ms,

you need a powerfull plane or just plenty of wind,

I have a video clip that show I can make the SPEED indicator flip out this way,

I dont know if it is the direction change, or height change that confuses the EB85

but I have double checked the readouts and calculations to be relayable from 0-1500kmh

Share this post


Link to post
Share on other sites

Daniel,

I just swapped out the 75mhz clock for a 74mhz on my Bob-4. It completely fixes the interference.

Share this post


Link to post
Share on other sites

Thanks for the info docphi - I have ordered the crystal from DigiKey and am awaiting it's arrival.

In the meanwhile - Woohoo!!!! Progress!

I must say, it's a nasty thing trying to interface 5V logic with 3.3V logic. I just spent 2-days straight with hardly any sleep trying to get the microcontroller talking nicely with the BOB-4. Halfway through that, I realized that the GPS wasn't talking either (it was earlier on another board) - which led to some panic, thinking I blew the GPS module. After much anxiety and lack of sleep, I finally nailed it down with a small level shifter (1-transistor ugly job but it works) - and the GPS was talking to the controller again.

So back to the BOB-4, after poring over it for hours upon hours, I still could not get it to talk on the SPI bus (although the UART interface works). As it turned out, eventually, there were a bunch of things wrong. First of all, that interface thing is finickier than I had anticipated. Furthermore, there was some confusion on my part as to the SPI I/O pins with the labelling. Then there was a problem that BOB-4 will only work properly in framed (handshaking mode) which was not mentioned anywhere. On top of that, it could not accept the clocking speed that I was testing at, which wasted me a lot of time barking up the wrong tree. To cut a long story short, I finally nailed each of the bugs down and got the framed mode going. When I powered up the controller, I thought something was wrong because the screen cleared - and to my surprise, text started showing up!! Before it was just gibberish!

So, right now - I got the GPS working and talking to the controller. I've taken it out with me for a few rides and it actually works quite well sitting on the dashboard. Usually I get about 10-11 satellites when driving on open roads. The GPS altitude is still a little quirkier than I like - there's still some lag on it (serial running at 115kbaud). Maybe it won't happen on a plane but I've not tested it. I should also add that I have added a connected on my controller for an LCD display which I can plug or unplug as needed. It's currently a 4x20 character display but can easily by a 2x16 one (which was what I was using earlier before I got the bigger display). This allows me to test the unit away from the computer (and show it off to my friends :-)).

I have the whole thing on a board about the size of the BOB-4 (SIMM version) and the two boards are stacked with brass spacers so it is quite small (though not as small as some of the dedicated units). I have ordered a pressure sensor to test so I'll be looking at that. Right now I need to clean up the code and get the basic display going before I start adding too many features. The good thing is that the biggest hurdles are over and I can't wait to really test this thing now. I'll try to post some photos of the board (now in it's second ugly incarnation) later. It's pretty compact and I'll probably just use it as it is although I'm likely to build another one, neater, now that I know all the design issues.

Daniel

Share this post


Link to post
Share on other sites

Amazing Daniel! Simply amazing stuff! :o I thought I climbed a rough mountain when I found my plane, but your mountain definitely makes mine look pretty small!!! ;) Looking forward to your next progress... oh by the way.. get some sleep now... since U got it working! ;)

Share this post


Link to post
Share on other sites

Thanks JMS - things are moving along quickly now that I've sorted out the basic issues. Today I got some of the homing code written and took the setup out for another spin in the car. It will now correctly tell me the distance from the starting point (first good fix after power up, based on HDOP), and also the heading (reference to N) towards that home point. I also managed to put in a small 3V battery for the GPS module so that it will get a lock more quickly, and in fact it works very well now. It takes less than 5-seconds to re-lock from power up as compared to a minute or more from a cold start.

For most of the code testing, I am presently using an LCD display to give me more mobility. Of course, the LCD will not be on the plane (unless I want it there). The backlight consumes quite a lot of power but I can turn it off if I want to.

I have currently disabled the BOB-4 while awaiting the crystal to swap into the board so as to avoid interfering spurs on the GPS frequency. With the BOB-4 on, the GPS has a really hard time getting a lock from a cold start. In fact, I suspect my controller circuit may also be contributing somewhat to that. I'm going to try to find some ferrite cores and put them on the GPS module cabling to cut that down a bit if possible.

Here are some photos of the module thus far - this is my second test board.

DSC_6401.jpg

DSC_6402.jpg

DSC_6403.jpg

DSC_6404.jpg

DSC_6396.jpg

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

Hi Mark,

Thanks for the heads-up. As a matter of fact I did find that site earlier but their proposed schemes didn't work. It looked very attractive because they offered a very simple passive solution but in the end I needed an active solution for the GPS UART interface. The diode scheme worked for the SPI interface though.

Now I wish I had another SPI port because I could have added logging to an SD card. Alas, pins and time are always too little. I'm running into a hardware resource crunch right now. In order to implement a homing scheme, I will need 2 PWM outputs and 2 PWM inputs, but I also need those same pins for my barometric pressure sensor. I also need another 2 PWM inputs to talk to my other pitch/roll attitude board (dedicated board running computations off the 5DOF IMU), and another PWM input for controlling the OSD remotely. At this moment, it is impossible to implement all of that so something must go. I reckon, I'll give up the artificial horizon for the moment and maybe just have a simple rudder home scheme without elevator control. I've no idea how this will work out though.

Meanwhile, I've got quite a bit of the OSD done and it's starting to look quite nice. I'm working on a nice recticule for the heading and homing indicators. I'll post something once I get some nice results.

Daniel

Share this post


Link to post
Share on other sites

Yayy! I got the OSD part mostly done the way I like it. I even have a scrolling recticular heading/compass with home direction indicator. I still need to test it in the field though but the BOB-4 oscillator is jamming the GPS with one of it's spurs. I'll see what can be done before the new part gets in, and will also try to get some screen captures up as soon as I get some time. I'll start thinking of some code to store custom settings in the EEPROM to make configuring the OSD easier. We are nearly there!!

Daniel

Share this post


Link to post
Share on other sites

Okay, here are some captures of the work in progress. Note that the moving compass is simulated since the GPS won't lock as yet due to interference. Some of the screen info can be turned off selectively. Also, some info is not showing at the moment such as the distance to home, and this is due to the software noting that home has not been set due to the lack of a GPS positional fix. When it does show up, it goes to the lower right side. In particular - the GPS info at the lower left will not normally be shown - it only comes up under certain conditions, or if you want it.

OSDgrab1.jpg

And if you want to see the short clip of it in video format (DiVx):-

OSD Test Clip 1

Daniel

Share this post


Link to post
Share on other sites

Looking great! Any plans on marketing this? My wife accuses me of being a bit of a collectamanic! :o

Share this post


Link to post
Share on other sites

Actually I've not thought of doing this to sell but I did think of making a few units just for friends. The good thing about rolling your own OSD is that you can have just the features you like, the way you like them. If there's someone who's interested to bring this project to market, I'd be happy to cooperate - after all, most of the hard design work is already done. Part of the problem with going commercial is that my local potential market is too small to justify costs so I'll need someone State-side to help. The other problem is that I am relying on the BOB-4S board. Looking at the final product, excluding the GPS module - we're looking at something in the region of about US$120 in material costs, inclusive of the BOB-4 board. When you add up labour and developmental costs, I think it will be closer to about US$170 to make this thing worth it. I don't know if that price will be competitive with the many other OSD solutions already in the market or about to be on the market. Again, if I can get guys to do this with PCB and a bigger MCU, I can add a whole lot of other features easily. Right now - hardware resource crunch time - ran out of pins for really neat stuff. You can have auto-rudder to home, or a bunch of external analog sensors, or artificial horizon - BUT you can't have them all at the same time so pick one (or maybe 2) of the 3.

I've started adding more advanced software features to the unit. One of the features I have is a progressive low altitude warning - that is, the further you are, the higher the altitude floor warning goes. Some of the information, such as peak values, will only show up once the plane has come to a stop. There are a few more such features I'm including. I'm still trying to decide on the final feature set. I've also moved the GPS data to a better position and added code so that this info only appears when hunting for satellites at startup and when you go below the altitude warning is active. Normal flight will not have the GPS position data visible, only when too low or landing.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

I haven't made a PCB for years now (used to etch my own stuff) and I think this will need through hole vias to make it right. However, I think it will be much smaller because two of the sockets you see in my prototype don't need to be there. One is for the LCD, the big one, and another is for the ICD programming head. Those two don't need to be there. That will free up board space for other more useful sockets, such as to connect the video I/O and maybe some push-to-make switches and servo connectors. I reckon that's what I'll do with the space saved by going SMT on a PCB. Trouble is, if I'm only making one or two units, it will be hard to justify the cost of having through-hole PCBs made. I guess I need to start looking at some of the options. I like keeping the size the same as the BOB-4 so that they stack up nicely.

Daniel

Share this post


Link to post
Share on other sites

Just some minor update here - I just tested the board (and blew a fuse on my FLUKE due to some brain fart) - but I found that the operating current for the setup - including the GPS module - is about 255mA at about 8V. That's about 2W of power right there. This all gets stepped down to 5V through the linear regulator first. Of this, the GPS is drawing about 50mA (but it supposedly drops to about 30mA after some minutes of operation, not verified personally though). Also, the BOB-4 supposedly draws up to 150mA (also unverified), so I am estimating that the controller board is drawing around 100mA. I guess that's about as reasonable as I can go considering the amount of processing power (20MIPS on the controller).

Now, I will have to measure the camera and TX to try to see how much operating time I can get out of my batteries. I wonder how much the other OSDs are drawing as a norm. There's nothing I've got to compare with but I suspect those that are not using the BOB-4 in their designs are likely to draw a bit less.

Daniel

Share this post


Link to post
Share on other sites

Blowing a fuse due to brain farting... yeah it seems you are working passionately hard at this and getting very little sleep. :lol: Just finished going through something similar myself :lol: but not on VP stuff. Anyhow do you think making this as a partial finished product will save cost to others ? You know leave the customers to solder the components themselves? I don't know, I'm not sure if programming is a factor here with all the components in place first. So what do you think Daniel? <_<

Share this post


Link to post
Share on other sites

I suppose it is possible to just make the controller board and have them get the BOB-4 themselves and solder the interconnects. The basic board is very simple really - and even with the prototype, you can see that the layout is already very compact with not much board estate left. I'll think about it, especially once I get everything going. One thing though, if they get the BOB-4 themselves, they'll have to swap out the crystal for one that doesn't interfere with the GPS. That's a surface mounted part and I don't know how many guys really want to do that.

I'll make another prototype once I get this thing working, without the LCD stuffs. That will free up a lot more pins for other features. The only issues remain with getting the AH unit with the rudder-home feature since they both need the same limited pins on board, unless I give up elevator control - something I'm not so sure about. I also have room for 2 or 3 more analog inputs, depending on how I setup the resources. That could be altimeter, a second battery, or current. My preference is to keep things simple though and stick to the most essential bits of stuff. Although a power meter would be nice, it would need getting a hall-sensor and more wires everywhere (I like keeping things neat on my electronics). If a voltage sensor works well enough, I'm quite willing to go with that. That allows me to go with a barometric altimeter instead, which might be more useful (pending tests with the GPS altimeter).

I'm happy to share.

Daniel

Share this post


Link to post
Share on other sites

Yeah I give you credit on the clean layout and compact size ;) As for the surface mount stuff, perhaps some may not like that but for me... I llllllove it! Something I learned from AnthonyRC, dab a little bit of solder on the board, then reheat and mount the part.. easy (thanks Anthony for that trick!) Anyhow you are making upward progress and will figure a solution for the rest. :)

Share this post


Link to post
Share on other sites

You can plug the BOB-4 into a SIMM socket soldered to the controller board. Something to consider when planning the PCB layout. Don't forget "mph" and "ft" for us metrically challenged yanks! Great job! :D

Edited by docphi

Share this post


Link to post
Share on other sites

I thought about the socket but that will add to the length of the unit. The way I have it stacked up is as compact as I can get it. About the non-metric units - this should be pretty easy. In fact, I am quite used to imperial units as well due to my flying in WWII flight sims (Warbirds and AcesHigh) but I decided to go metric here to keep things consistent.

Meanwhile, I managed to find a way to get the whole thing working while waiting for the crystal to arrive. I found a small metal box - for Jujubes (like Altoids) and the boards fit nicely into it. I sanded off the edges to provide electrical contact with the cover, put everything in with the wires coming out at one end. Then I put some ferrite chokes on the cable going to the GPS module and powered it up. And it works! Dang, I should have thought of this earlier. That has allowed me to fine tune the software quite a bit to make it more usable. Basically, the way it is now, it is ready for action. I've not finished the remote activation/deactivation of info displayed as yet but the PWM code is already in. I just haven't tested it yet. What I will do next is to work on the rudder home code, which should be pretty easy to do I imagine (I have great imagination!). I'll have to forgo the artificial horizon for now.

Next up, I will be looking at exactly how much shielding is needed on the BOB-4 to avoid needing a new crystal. It should not be too hard to solder a shield over the pesky part if that's all it takes. I will also start looking at the PCB design soon as I'm thinking of building several of these boards, some for my friends who also want one.

I just spent the last hour or so trying to figure out how to stuff everything into my Cessna. Tomorrow I'll be trying to get hold of more connectors for a breakout board where the camera, transmitter, and battery will all go. This will, hopefully, keep the cables neat and short in the plane. I noticed that the Lawmate TX uses some very small connectors, while the cameras use slightly bigger ones. My present transmitter has stereo inputs for audio so I was planning on using one channel for telemetry, and for the other channel, to mix in some audio alerts with the microphone - things like stall horns, beeping alerts, and so on. The Lawmate though, is only mono. I don't have too much telemetry to worry about at the moment.

With the system I have now, I'm thinking of all kinds of crazy possibilities. For example, if the controller detects that you have crashed or ditched, presumably by detecting a zero or very very low speed, at ground altitude, and more than a certain distance from home, it can be make to do a bunch of things, such as activate a RDF beacon, flash some lights if it is dark, or just sound a beeper like a regular finder. Applications like these are now so easy to implement, limited only by available I/O pins, code and memory space on the controller, and our imagination. It's very cool to be working on this project. I'll try to get some videos tomorrow with the unit running in the car.

Then after all that is done, I'll go work on the artificial horizon board. I've also figured out a way to make the head tracker for under about $50 or so. My only problem is that I am using a JR 9303 which only allows Channels 1-4 to be slaved to the buddy box. I've been trying to think of an elegant way of getting around this problem - including a direct interface to some of the switches or sliders using a DAC. The other possibility would be to intercept the PPM stream from the radio to the TX module and re-encode the data stream while inserting my own channel data. This would be pretty neat actually, if I can get it working. There are two problems with this scheme though. The lesser problem is that of latency. I'm not sure how much latency will be introduced and how that will impact the feel of the control. This isn't critical though and should be manageable. The more serious problem for me is that while this is easily handled with PPM, I've not seen anyone reverse engineer the JR PCM protocol. And I happen to like to use PCM so in order to re-encode the PCM stream, I'll need to do more work there. Unfortunately I don't have access to a protocol analyzer. If this can be done with little latency, it will possibly be the most elegant solution for JR users, short of someone discovering a debug mode which allows all channels to be slaved.

Daniel

Edited by Daniel Wee

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

×