Hi all,I just wanted to announce another new "big project":We (a team of two) have just started to develop something new for home flight simulation and cockpit builders. To be exact, it's going to be a modular system to simulate all kind of avionics, based on latest microcontroller technology.The whole project is done within a diploma thesis and the first prototype will be ready in spring/early summer 2007 - we do not really know yet whether this project will become public after the diploma presentation (depends on if everything works the way it should :-)), but we are planing to publish the whole thing for other sim-builders out there some day ;-)More information can be obtained herewww.sim-modules.atWe're looking forward to having a lot of work, but we'll do our best to accomplish all the things we want to do in the next few months! :-jumpy best regards,Christopher Hauser ;-)

Best of luck to the both of you. Sounds like a good academic project as well as a very useful flight sim system component. I look forward to reading your progress updates.Mikewww.mikesflightdeck.comwww.mikesflightdeckbooks.com

>I just wanted to announce another new "big project":>>We (a team of two) ...I do like you guys spirit and enthousiasm! Try to learn a lot, because that's the purpose of a thesis work.Actually, I think your expectations are set a little bit too high. Designing, developing, (redesigning) and testing of such a system is a major undertaking, especially if you are just with two person's and for a limited period.I hope you start your project reseaching the technology that is already available such as FSBUS, Opencockpits IOCards, Phidgets, EPIC, ...Try to venture the unknown, and develop something new!Personally I don't think using the COM port is a good idea, you better use the USB interface.But like I said in the beginning, don't forget you are still students and use your time to learn. When you are in a real company (either of your own, or employed) you can still spend lots of hours chasing deadlines of products that are already sold by the sales people.. ;-) Good Luck,Nicowww.nicokaan.nl

I am with Mike and support your efforts. Best of luck with your projects. I too look forward to reading your ideas.The market will determine the commercial success. However, advancing the hobby forward is always successful. Giving of yourself, is successful in itself, and is rewarded in many ways.John

Hi all,well thanks a lot for your interest and your feedback! :DAs Nico already said, the reason why we are doing this project is of course that we want to learn as much as possible about project management and product developement (in connection with microcontrollers, modern information technology and so on) - there was a bunch of other things we could have chosen as a topic for our thesis work, but.... who does not want to connect hobby and job as often as possible? ;-)I'm as excited as you are if we can achieve all the goals we have set, and we of course hope that these goals aren't set too high - but as already mentioned, we will give our best :-)One more thing, about the USB/Serial-Stuff: of course we thought about using USB-compatible

Just a short update... so that no one thinks we're getting lazy :-hah Some parts of the program for the microcontroller in the single modules are already finished - eg the code for the LED-displays and the Rotary-Decoding is ready to use, the next thing will be the data format for the communication between the single modules and the master-module (we'll use TWI, this is how the I2C-standard is called at ATMEL)For the hardware, we're currently designing a prototype for a COM/NAV-Module - the pcb routing is indeed rather difficult, but I guess it'll work one day ;-)Yeah and of course some work has been spent on the website as well...there's always something to do everywhere http://www.haus-air.at/smileys/roll.gifso far this short update http://www.haus-air.at/smileys/wink_3.gifbest regards!Chris [email protected] - www.sim-modules.at

What chip are you using to drive the 7-segs ? I agree about the PCB routing. I used a M5421 chip for each bank of 5x7segs, as that reduced the number of outputs I needed from the PIC (One common clock line, plus one data line to each bank of five, meant I could drive 35 digits from a PICAXE 18 with only 8 output lines)I cheated slightly on the routing though - I used a 40 core ribbon cable to connect each driver chip to its bank of LEDs, and thus didn't have to find ways to criss-cross all the PCB traces :-)Richard

Make that an M5451 :-(

It is good to hear you guys are still moving forward. Keep up the good work. I look forward to the time when your dream is a reality.John

>What chip are you using to drive the 7-segs ? The 7-segment-displays are controlled directly by the ATMEGA32 micro controller, using 74HC138/238 DMUX-ICs. This has the advantage that we can output every possible character because the combiation of LEDs for each digit is fully software controlled.Using the multiplexer, it is theoretically possible to control up to 32 digits using only 13 portpins. The biggest problem is, that it takes a lot of cpu-power of the microcontroller, to ensure the displays don't start to flicker, but this hasn't been a problem so far...>It is good to hear you guys are still moving forward. Keep>up the good work. I look forward to the time when your dream>is a reality.Thank you very much, John - we're also looking forward to seeing what the whole project will bring at the end http://www.haus-air.at/smileys/wink.gifBut we'll see in a year! =)best regards,Chris Hauserhttp://www.haus-air.at/smileys/saufen.gif

>The 7-segment-displays are controlled directly by the ATMEGA32>micro controller, using 74HC138/238 DMUX-ICs. This has the>advantage that we can output every possible character because>the combiation of LEDs for each digit is fully software>controlled.You might want to look into using a driver chip. The M5451 I chose latches the 35 individual segments when it receives its data, so the CPU is then free to go ahead and do whatever you want without having to worry about the displays flickering. Since all the chip needs to receive from the PIC is a clock pulse and a data pulse, and if it receives a clock pulse with no data pulse nothing happens, you can control five digit displays with only one more output pin than the number of displays. Your 13 output pins could display 12 x 5-digit displays, or 60 digits, and there'd be no worry about flicker at all. Here's a picture of the block schematic...http://forums.avsim.net/user_files/153628.jpgRichard

Jep, we indeed had a look at some LED-Display driver chips (like the 5451 or BCD-to-7-Seg-drivers like the CA3161), but we found it more practically to have full control on the combination of LEDs - to put it into words, we wanted to be able to create custom characters via software rather than to be dependent on predefined character tables.But we did a lot of calculation on this, and at the end we decided for the DMUX-solution for some reasons:First, the power consumtion is much higher with the shift register or BCD-driver solution. Thinking of a full radio stack with lots of displays, the current needed could be rather high, as all displays are always on. In fact, using multiplex-technology there's only one character (max. 8 LEDs including decimal point) light up at the same time. Secondly, if the refresh rate is at least 50 times a second, the human eye doesn't notice any flickering at all - if you think of e.g. 20 displays for a typical COM/NAV module and using timer-interrupts on an 8 or 16Mhz micro controller, this is no problem at all.Thirdly, it may be easier to provide the possibility of dimming the LEDs via software to adjust the brightness according to the environment.And last but not least, as already mentioned, the possibility of defining our own characters.Of course, it was no easy decision as both technologies have their (dis)advatages, but we just think in our special application the DMUX-solution would be slightly better - but don't forget we are still at an relatve early stage of developement, so make us change our minds! http://www.haus-air.at/smileys/wink_3.gifbest regards,[email protected] - www.sim-modules.at

"to put it into words, we wanted to be able to create custom characters via software rather than to be dependent on predefined character tables."Just as a correction, you don't use character maps if using a driver chip like a 5451. The data is sent to the chip bitwise.ie, to send "11111", the a and b segs of each LED must be illuminated. You would therefore send a 35 bit datastream of "11000001100000110000011000001100000" out of the PIC's data out pin, telling the 5451 to light a and b and not c, d, e, f or g.Thus you can illuminate any character or symbol you can imagine.Richard

Yes, sorry, the point with custom characters was connected to the BCD-to-7seg-driver solution, not the shift-register thing - I mixed it up a bit in my post http://www.haus-air.at/smileys/smile.gifand I just saw that I didn't mean the M5451, but some other ic - I noticed that this one also supports brightness control and is especially for LED-displays (I have only found generic shift registers so far)But thanks for this hint, I just skimmed through the data sheet a bit, really looks like a good solution... well, I guess I'll come back to it if the DMUX-solution turns out to be not that good at the end http://www.haus-air.at/smileys/wink_3.gifregards,Chris

Sorry for the double-post ^^ but...there's just one little thing I'd like to hear your opinion of ;)I was thinking of how to include the rotary switches into the system. Using dual-rotaries (so concetric ones) is mechanically a tough thing... Although I made some of those out two 12-Way-Switches a while ago (and it wasn't too hard to do), due to money, time and last but not least space reasons (those things get rather big) I decidided thinking of another way...The idea came up of using just those some single rotary switches with integrated pushbutton. (A german store once gave some of them away rather cheap, so I got myself a bunch of them a time ago)No I'm planning like this - take a COM-Module for example. Turning the (single-) rotary normally, the frequency would be tuned in .025Mhz-steps - turning it while pushing the integrated button at the same time, the step would be 1 Mhz...I don't know if this is useful in everyday life or if this is nothing but purely unrealistic.. but I think it may be a good compromise between expensive, complicated concentric rotaries and some other way...I've never seen this solution out there, should I give it a try? http://www.haus-air.at/smileys/icon_question.gifgreetings,Christopher Hauser