Jump to content

Recommended Posts

I am using an LM1881 Sync detector. It is an old part that is easy to buy and very low cost.

(1) The PIC's software is designed to Genlock to each new video frame. This is done by looking at the field output of the sync detector. The critical code is written in assembly, which is wrapped in C for my convenience.

(2) At the start of a new frame, I count horizontal syncs, in software, until I am at the video line that needs to be written on. This ultimately sets the "Y" screen position. I then count CPU cycles to determine how far into the horizontal line I must delay. The delay sets the "X" position.

(3) The video pixels are transparently added to the composite video. They are one bit representations, so color or grayscaling is not supported. The Pixel signal output is sort of wire or'd together at a resistive summing junction on the composite video signal. This is a simple method (if board size was not a concern then I would do it differently).

(4) The tick mark is one horizontal line tall, about 1.8uSecs long. The pitch's glyph is six horizontal lines tall, each about 1.8uS long.

The jitter is due to the CPU cycle time. Synchronizing to the start of the line is done by polling the composite video sync output. This takes three to four CPU cycles, and it is this timing that provokes the jitter (video is very fussy). I have some ideas on how to do this with less interaction, via code optimization. But at this point I am happy to see what I am getting.

If I could remove the jitter then I could even create simple alpha characters for text. Software wise, that is a tremendous amount of work. But it would be nice (I would love to paint my call sign on the screen). However, there are so many other things that need to be proven that I doubt I will get to that any time soon.

Edited by Mr.RC-Cam
Link to post
Share on other sites
  • Replies 344
  • Created
  • Last Reply

Top Posters In This Topic

So the video is basically allowed to pass unaltered through your board, and only at such time as you want to draw your tick do you inject your signal?

Regards,

Bill

Link to post
Share on other sites
The soon to be released dspPIC's would probably work great

I wouldn't hope on these ones... I remember having thought about using one for a project in October 2002 (they were supposed to be released in december 2002 at that time). I think I made a good choice in changing my mind ;)

Link to post
Share on other sites

The jittery pixels were bothering me. So, I spent all weekend taming the little devils. The results look fantastic. Here is what I get now: New Demo Video

What you can see is that I was able to kill the jitters. That gave me the will to move on and create arrowheads for the pitch and roll indicators, as well as skinny up the centering tick marks.

Lastly, I went for the gold and was able to create bit-mapped alpha-numeric text. The "RC-CAM" you see at the end is created in firmware by the little 20Mhz PIC. This text line is set up to hold up to eight characters, so it should be very useful to the project.

At this point I am really excited about the gagdet. Even if it bombs as an artificial horizon, the concepts can be used to create a VERY tiny OSD to display my ham call sign. That alone is totally cool.

I am really behind in my other responsibilities. So, I will really need to let this sit for a week or two while I get caught up with other stuff. I will certainly post more as I move forward.

Link to post
Share on other sites
the concepts can be used to create a VERY tiny OSD to display my ham call sign. That alone is totally cool

I am really behind in my other responsibilities. So, I will really need to let this sit for a week or two while I get caught up with other stuff.

Priorities, man, priorities ;)

This has to be one of the coolest video projects I've seen.

Once you dig back into this, you *know* the big question will become... can the rest of us program our own call signs into the chip.

Regards,

Bill

Link to post
Share on other sites

If using a part with EEPROM, he could for example define the 10 first bytes as the call sign characters. Then, when we open the HEX with IC-Prog (or other), we could fill these EEPROM bytes with our own string before programming. Just an idea, as we wouldn't need the source code then.

Link to post
Share on other sites

I will try to make entering the call sign a user-friendly feature. Perhaps something that would use a temporary push switch or PCB shorting pads. The PIC includes some EEProm data space, so saving the short text message is not a problem.

But as Kilrah mentioned, I could also just reserve an area in the code space where you would edit in the text data during chip burning.

Link to post
Share on other sites

I think a basic interface like the temporary switches you suggest would open up the project to the broadest number of hobbyists.

Does all of this assume that you have to code the bitmaps for every letter and digit? Seems like a LOT of work for you!

Regards,

Bill

Link to post
Share on other sites

Yup, I created 7x9 bit maps of A-Z, 0-9, and some others, all inside the PIC. It was an exercise that started with graph paper (kind of a fill-in-the-squares, until I liked what I saw, sort of thing). These were then defined in the PIC as look up tables. A sub routine allows me to pass an ASCII string (the text message) and it converts the text to a serial pixel bitmap; the code automatically builds the bit map on the fly. The predefined maps take up a lot of code space and ram (almost too much).

However, unlike hardcoded messages, the program can now freely update the text to show a call sign and other messages during program execution. I plan to capitalize on this and use the text line to display status messages or prompts. This might be nice for the IR calibrate steps and such.

I must say that the entire video creation is very fragile, especially with a 20Mhz PIC. Any little extra machine cycle, in the wrong place, causes my little house of cards to tumble down. Frankly, I am just amazed that it is working so well. I hope my luck continues!

Link to post
Share on other sites

Thanks to all for the encouragement.

I am not sure what the board size will be. There are only two IC's, a 3.5V Vreg, and a gaggle of R's and C's. I need a 5Vreg for my camera, so I will stick that in too. Like the Co-Pilot, there will need to be some config (DIP) switches. I'll try to make them virtual switches as part of an on-screen setup menu, but it all depends on how things go.

So, how does a target size of .75" x 1.5" sound? I think that is about as small as I dare go if mortals will be soldering it.

Link to post
Share on other sites
So, how does a target size of .75" x 1.5" sound? I think that is about as small as I dare go if mortals will be soldering it.

I think if you stay with components that are at least half the size of a grain of rice, most folks with a low wattage iron will be able to muddle through. I've had very bad experience with those resistors that are the size of a grain of sand!

Regarding the 5v vreg, I'll be selfish here and suggest that it be designed on so we can cut that part of the board off if we don't want it (sorry, I know how ungrateful that sounds)

Regarding the size, a .75" x 1" board would fit splendidly on the back of my 200mw tx ;)

Regards,

Bill

Link to post
Share on other sites
Is it really going to happen?

Probably. But I'm not sure what to expect (accuracy wise) if it is used at the extreme AGL altitudes that some folks are flying in. Only time will tell if it is something that is a concern that we cannot work around.

I have continued to move forward with the project. I completed the SMT board layout a few days ago. A small lot was ordered; should be here in a couple of weeks.

Despite my attempts to meet my projected board size, I missed it by a bit. I gave it my best -- probably consumed 12-15 hours trying different layouts. Although I could have put in more hours to eek out a few mm's less, I ended up with 1.4" x 1.4". Still small, but no where near what I claimed I would do.

Once the boards come in I will build one up and then continue developing the code. My fingers are crossed that nothing serious gets in the way. But so far, things are looking good.

Link to post
Share on other sites

Mr. RCCAM,

Read this thread and I'm really interested in what you're doing. However, one thing confuses me.

Don't you need an absolute angle to know you're level? Specifically, you need to know when pitch and roll are at 0 degrees.

I probably don't understand the output of the infrared sensors. From your description, I concluded the voltage output of the sensor would be somewhere between the voltage rails in the level position and move toward either the positive or negative rail as the sensor is tilted at an angle above or below the horizon.

If the output is actually 0 volts in a level attitude, then I understand your points about not needing an absolute reading, just a relative reading. But if the ouput is 0 volts at level, how would positive tilt from the horizon versus negative tilt be indicated?

What I hope you are saying is that you expect (ignoring high altitude affects and drift since calibration) the "glyphs" will always be centered when the sensor is in a level attitude, but the amount of glyph deflection for a given tilt will be variable. Just can't rationalize how an analog sensor output would be consistent with this conclusion.

Dave Thomas

Link to post
Share on other sites

The outputs of the Co-Pilot IR module do not have an absolute magnitude or scale. The min, max, and center positions will vary, depending on the environmental conditions. The calibration step is where this is all sorted out.

I expect that high altitudes (miles up) will cause some headaches, especially with my two-axis sensor. This was Cyber-Flyer's point. But, it is not clear to me just how big a problem it will be. It certainly won't affect me, since I like to stay much lower to the ground.

The project's issues go further though. There are very few CPU machine cycles to spare; nearly all used up in drawing the graphics. All the math must be integer, and it must be minimal. That is where I'm a bit nervous, since the thermopile data needs to be scaled and graphically mapped, in real time.

The design will not rely on absolute positioning. Everything will be relative. It will operate like a carpenter's level, but instead of a moving bubble you will get quaint little arrowheads.

If it all falls apart, then at least I will have a nice way to display my call sign and battery voltage!

Link to post
Share on other sites

I haven't played with the sensors yet, but I'm pretty sure it will not be 0V when level. It is simply a light sensor in a sense.

I imagine you get the value of when the plane is level. So the sensor is seeing both ground and sky. Read that in as your calibrated value.

My guess is that voltage will go up when tilted so that the sensors sees more sky and down when it sees more ground (that is simply a guess, it could be the opposite).

Anyways you make a correction until the voltage is back to the value it was when it saw both the sky and ground. Having two sensors, you probably also want them to have the same voltage output on each side. So I guess you would also correct until that happends.

What I would imagine would cause more headaches at high altitude is that you would probably be seeing much more sky and less ground. So logically you will think that the sensor is pointing towards the sky. So a small tilt might not even create a very big difference between 2 sensors.

It reminds me of a PIC project that has a motor move a plant to always have the most light available to it using a pair of photoresistors.

-- edited ---

After thinking about it for a bit... wouldn't you only need to display the difference between the 2 sensors. If there is a big difference then you are more banked. If there is a small difference then you would be closer to being level.

Which ever on is the higher voltage would determine the direction of the bank.

Cheers,

Mike

Edited by mikep
Link to post
Share on other sites
My guess is that voltage will go up when tilted so that the sensors sees more sky and down when it sees more ground (that is simply a guess, it could be the opposite).

That is about it. With the Co-Pilot IR sensor design, in a perfect world, down would be 0V, level 1.6V, and up would be 3.2V. Too bad mother nature and the silicon gods prevent that.

Link to post
Share on other sites
in a perfect world, down would be 0V, level 1.6V, and up would be 3.2V.

So are you referring to a single sensor output, or the difference between common axis sensors? In other words, when level, each of a pair of IR sensors outputs something around 1.6V? So while the voltage of single sensor in a level attitude may vary significantly, the sensors should track? So the differential voltage is 0, hence level attitude. Calibration is required to determine min and max thermal brightness so optimal gain can be calculated? Calibration for gain optimizes dynamic range but isn't required to eliminate offset from level.

Have I got it right?

If so, I don't understand the concern about altitude. EACH sensor of a pair sees more sky than earth, so EACH sensor outputs something higher than 1.6V. But the differential voltage should still be zero.

So altitude introduces a gain error, but not an offset error. I.E, (like I think Mr. RCCAM was saying), you'll know when you're level, but determing an attitude given a specifc deflection of the CDI requires calibration and will be affected by altitude.

If I've got it right, not sure why it's important (gain error), except for maximizing dynamic range and/or design of an optimal control system.

Dave Thomas

Link to post
Share on other sites

Nice work. A couple months ago I tried to do overlay with an 18F1220 (similar to a 16F628) at 48mhz and one ordinary NPN transistor to shift the video DC voltage level up to the TTL inputs (instead of a sync IC). I got a horizontal resolution of 200 lines and vertical 250 and set it to drag the lines across the screen, but I didn't get any further. I would really like to see how you got it to do text!

Kyle

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...