EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: butters on June 17, 2010, 12:10:10 am
-
Hey guys, long time lurker, first time poster. Just thought I would share with you my design for a university project. I'm building a flight termination unit for a UAV to compete in the UAV Outback Challenge, which is designed to be a failsafe device that will take control of the aircraft and bring it down safely (with a parachute) in the event of an in-flight emergency. Basically it will talk with the autopilot via RS232 and control a multiplexer to switch between autopilot control and its own control. It will have a GPS unit as well (LS20031) so it can detect if it crosses a mission boundary (and terminate flight automatically).
I also wanted to include a USB->Serial converter to make programming the ATMega chip a breeze (and give it power to run off while developing the software instead of a battery). I'm considering putting the Arduino bootloader on the ATMega chip to make programming it a bit easier instead of programming in the native C.
This is the most complex electronics design I've done, so I would definitely appreciate any advice you guys can offer. This will be the first surface mount board that I do as well, so I'm taking it slow and not rushing the PCB design stage.
-
30 views and no responses? I guess you cannot see the image unless you're logged in. Here is a remotely hosted schematic.
(http://i49.tinypic.com/2hicpd3.jpg)
-
Considered input power supply decoupling?
Also, i'd use 10uF ceramics on the output of the regulators.
-
Also, if you're powering it up from USB, it looks like you wont get a 3v3 rail (3v3 regulator only linked to Vin)? ??? or am i mistaken...
-
With regards the USB power, I cannot see a ground connection?
Also worth using pull up resistors on unused inputs, especially for your intended use, to avoid noise pickup and potential strange behaviour.
-
Yeah I'm going to put a couple of fairly large caps across the "Power In" and "Servo In" connectors to decouple before going into the regulator.
The USB power connector pins 4 & 5 (connected) should be connected to ground as well (oops!). Regarding powering via USB, I've got pin 1 of the Mini-AB connector (I'm lead to believe this is the power pin) going into net Vusb which is then connected to the 5V rail through a shottky diode (top right of the schematic, under the regs), I'm hoping this will have the effect of allowing 5V to come from USB when there is no battery connected to the Power_In connector.
Regarding pull-up resistors on unused inputs, I was hoping to use the internal pull-up mode on unused pins as outlined on Page 74 here (http://www.atmel.com/dyn/resources/prod_documents/doc2549.pdf). That way I can avoid having to use resistor nets, etc. The document says that the pull-up is disabled during reset but I can live with that.
-
still can't see any way you'd get 3v3 volts while USB powered.
-
still can't see any way you'd get 3v3 volts while USB powered.
From the FTDI FT232RL's 3.3V Out pin, but I don't see the connection on the schematic, same with the ground and shield connections with J1
- Patrick
-
Curiously, why does an in-flight board need a manual reset switch? ;D
Dave.
-
still can't see any way you'd get 3v3 volts while USB powered.
From the FTDI FT232RL's 3.3V Out pin, but I don't see the connection on the schematic, same with the ground and shield connections with J1
- Patrick
Be careful if using the 3.3V from the FTDI chip. Read the datasheet as I think It will only supply 30mA max.
-
Yeah I was thinking about using the 3v3 from the FTDI chip, it supplies 50mA and the GPS (the only 3v3 device) uses 45mA... but I think just using the regulator is better, because I'll need to have it with the battery anyway. I'll have the Vusb interfacing with Vin instead, which means that the 5V from USB will be regulated to 5V (again) and 3.3V through the shottky diode.
Curiously, why does an in-flight board need a manual reset switch? ;D
Dave.
Excellent point Dave.. I think that was an oversight on my part, I was looking at some Arduino hardware schematics and they use a pushbutton reset. This is probably a very bad idea, as I don't want anything accidentally brushing up against the reset button in flight. I may just break the reset out to a 2-pin connector that will hold reset high with a jumper or something instead.
-
My previous boss once quoted, "the provision of a reset switch is an admission of defeat".
Never has a truer word been spoken, but you never know when that unexpected alpha particle will upset your perfectly crafted software ;D
A pair of adjacent pads that can be prodded on the bench with a screwdriver may still be a desirable "feature".