I am looking for someone to program Arduino Uno for High Altitude Weather Balloo

Hello, I am looking for someone to program an Arduino Uno for me. I am sending a weather balloon with HD cameras up much like the students at MIT did a few years ago, but I would like to have a microcontroller in mine. The problem is that I have no idea of how to program one. I have a Microsoft Pharos GPS-500 III GPS Receiver, 1 Boost Mobile cell phone (as a tracking device through cell towers), 2 Kodak Playsport HD Video cameras, 2 Wire Digital Temperature Sensors - DS18B20 and 1 climate control system. I would like to have the Arduino Uno control these components. I have wires attached to the Kodak Playsport Circuit board to turn the camera off or on when shorted together, I have also done this for the recording function, and I also have another set of wires with about 1 volt going through them when the camera is powered on, that I would like to have the Arduino monitor to ensure that the camera is always powered on, and if it is not powered on I would like the Arduino to turn it on by shorting the 2 wires together. I could not find anything on the circuit board of the cameras to let me know when it was recording or not so I am wondering if we can make a sensor to detect a blinking red LED on the front of the cameras to let the Arduino know if the cameras are not only powered on but also to ensure that they are recording. I have the same configuration on the cell phone with the wires. 4 wires total. 2 to turn it on and 2 to monitor the voltage so the Arduino knows if it is on. I also have a climate control system that is going to run on two 5 Volt usb batteries that I would like to engage when the temperature inside the basket gets to 50 degrees and to turn off when it gets to 70 degrees. The second thermometer I am going to place on the outside of the basket, just to record temperatures at 100,000 ft.

I have an Arduino Uno with a Xbee shield and a XBee Pro 900 XSC Wire, that I would like to send me the gps informatoin and temperature readings to the ground somehow, either my phone or laptop or another Arduino, I'm not to sure what is required here. I also have a Arduino Datalogger that I would like to have store all the information processed by the Arduinno.

If someone is interested I would like to hear some feedback and eventually talk over skype and maybe somehow create this thing together across the country, or even in another country depending on who responds. I do not have any money to pay you for this, I am hoping to find someone who might be interested in the project itself and enjoys working with microcontrollers. I have launched 2 other balloons before this, but never with microcontrollers. If you are interested please respond to this post or contact me at Bryan246@gmail.com. I am sure there is plenty of things I should have posted but I can't think of anything more right now, so feel free to ask plenty of questions.

Bryan your location might help people make a decision!

cheers Mike

FYI

Federal Communications Commission (FCC) regulation 47 CFR Ch.1 (10/01/98
Edition) which states:

“Section 22.925 Prohibition on airborne operation of cellular
telephones installed in or carried aboard airplanes, balloons or any
other type of aircraft must not be operated while such aircraft are
airborne (not touching the ground). When any aircraft leaves the
ground, all cellular telephones on board that aircraft must be turned
off. The following notice must be posted on or near each cellular
telephone installed in any aircraft: The user of cellular telephones
while this aircraft is airborne is prohibited by FCC rules, and the
violation of this rule could result in suspension of service and/or a
fine. The user of cellular telephones while this aircraft is on the
ground is subject to FAA (Federal Aviation Administration)
regulations.”

Sorry about that, I knew there would be plenty I would forget, my location is Boston, Massachusetts.

I happen to be about 30 minutes west of Boston.. and might be interested in helping out.

The data link to ground is going to be the hardest part to implement.. 100k feet is almost 20 miles, that's not RC transceiver range. Are you expecting to not recover the electronics? It would seem that if data logging is being done, the realtime telemetry at that range is going to be much more trouble than it could be worth.

I will assume you take care of all FCC and FAA clearances and all that.. Boston is of course controlled metropolitan airspace and not a great place to launch uncleared aircraft!

Yes I will handle everything with the FCC, also we probably won't be launching out of Boston, it all depends on what the winds are doing that day. Last Time we had to launch out of N.H. to get it to land in the Norfolk/Medway area. We use a weather balloon trajectory page that predicts what the balloon will do depending on the weather.

The link with the ground will be the hard part, but I'm not expecting to have constant contact with it (Just because I didn't think it was possible? Like i said I am new to the microcontrollers and stuff.) This is my first launch with anything more then a cell phone for a tracking device because I couldn't afford much more and that's what MIT used. Usually we lose contact for about 3-4 hours with a cell phone as a tracking device, with the Arduino Xbee 900 it says that the range is 15 miles, but I would assume that is in a perfect world, but I am curious to see what kind of range we will get with it.

Sparkfun touts the module as up to 15 miles, however the manufacturer only rates it for 6 miles, and that's line-of-sight with a high-gain antenna. That's not to say you might not be able to get spotty connections, but I wouldn't be looking for anything reliable past about 25,000 ft.

The cellular connection (assuming you play legal) sounds to be the most workable; basically having the phone attempt to "call home" every few minutes. It'll either hit a tower or not, and 20 miles straight up is workable for cellular most likely, at least at some points during the flight... especially during the rise and fall, where it matters most, I would think. The cell phone has some type of connection (serial) that allows for use of a modem-type (Hayes "AT" commandset) communication and control, or some way to handle sending SMS texts?

Ideally, you could simply have the cell connect, and send the data to you via text (SMS) message, or via email. Either way, you'll have your data stored online rather than locally, take advantage of their technology instead of trying to recreate it, if you can.. in fact, what's more appropriate for a flying machine than to TWEET it's data? Okay, maybe that's a little silly, but you get the idea.

What's powering all of this? You are talking about quite a bit of drain (especially a climate control system!), you are going to be carrying a lot of battery power for all this. How long does an average flight take?

It'll either hit a tower or not, and 20 miles straight up is workable for cellular most likely

The problem is not that it will hit a tower, it is that it will hit all the towers.

For the cell phone we use a free program called Mologogo. www.Mologogo.com we have the phone send its location every 10 seconds, also we have the phone restart the program every hour to prevent the phone from "Locking up". I would like the Arduino to ensure the phone doesnt shut off and if it does to turn it back on. For the heating system I have modified a USB Heated lunchbox. http://www.meritline.com/multifunction-usb-keep-warm-lunch-box-food-box---p-61915.aspx?source=fghdac these heaters are powered by 2 5 Volt Duracell USB 1150mah batteries, and I have this wired through a home garage thermostat now, but I would like to have this also controlled by the Arduino but still powered by the USB batteries. The 2 Kodak Cameras and cell phone are each powered by 3 AA batteries. http://www.bestbuy.com/site/Energizer+-+Ultimate+Lithium+AA+Batteries+(8-Pack)/5320814.p?id=1066093723944&skuId=5320814 These batteries gives us the most power and weigh only 15 grams each, and are also rated for extreme temperatures. The balloons usually take about 3.5 to 4 hours to fall back to the Earth.

So you aren't even looking to send data (other than the software data from the phone GPS itself). You aren't looking to take data from the sensors and transmit it.. you are just using the phone as a tracker with it's own GPS.. it's not actually part of the instrumentation, per se. Ten seconds seems a bit frequent, especially if you are just location tracking with it. Does it maintain a single call as long as possible, or is it actually going to try and dial in every ten seconds? That's just the kind of thing that might tick off the FCC. Your data collection can be totally apart from this, and you only want to check a "heartbeat" from the phone and power cycle it if it's not "on". I'm thinking low-tech on that-- there's probably an LED or spot on the display where we can slap a photosensor to "see" the status signal the phone provides, like you said. I'm just wondering about the need in the first place, as pertians to the phone. What makes you think the cell is likely to shut off of it's own accord? I can understand a software reset for the logging site, but do you expect the hardware to be a problem? One thing I can assure you is that every level of complexity you can avoid will prevent ten times the number of failures. Every step is a potential failure point- so unless there's a good reason to believe the phone will shut off for "no reason", adding a reset and heartbeat is likely to create a LESS reliable system than just leaving it be :) The "KISS" (Keep It Simple, Stupid!) principle is a golden rule. If we can keep the two items (phone and your electronics package) totally unconnected, it will be the most reliable.. unless there's a reason to think the phone will need that intervention.

Switching on and off the cameras and low power stuff is likely to be easily done with an optoisolator or even just a NPN transistor.. Those switches aren't carrying a lot of current, it's a logic signal not a power supply. The heater draws a lot more power, either a MOSFET or maybe just a relay would be a good answer. I'd lean towards a FET, a relay has it's own current draw for the coil.. unless you happen to have a REALLY low power relay like a reed relay or something. Photo sensors are going to be the right answer for simplicity, barring a clean signal from somplace.. luckily the Arduino has analog inputs that work perfectly with off-the-shelf light sensitive resistors. You can even get them at radio shack. We've got plenty of analog inputs for those, its a cheap and dirty solution that works.

That basically leaves data logging, and we have the roughest outlines of what you are trying to pull off..right? Temp sensors will be I2C, if I remember correctly, and the GPS is going to send it's data via serial.. we can SoftSerial on a couple of pins for it and call it good. What kind of interface is the data logger?

Seems almost a shame to only be getting temp and position.. I'm already thinking additional sensors: UV/IR/Visible light sensors... that's easy and weigh nothing.. just a couple of phototransistors. Humirel (relative humidity) sensors. If you're doing the backbone, collect as much data as you can, I say..

I do however find it funny for some reason that it was a guy from the UK that was quoting US FCC regs... lol... world just keeps getting smaller, or does it just look that way from 20 miles up?

I told my girlfriend that I was essentially trying to have a conversation with my neighbor, and some guy from around the world keeps butting in. I told her I was going to make a post that said I was going to drive 70 M.P.H. to the launch and nothing else, just to see if he would copy and paste the Massachusetts General Law Chapter and section of the speed limit on I93 :)

I told my girlfriend that I was essentially trying to have a conversation with my neighbor

So go ahead and PM him - don't broadcast on a triillion watt PA system. No wonder the neighbours complain.

(if you're going to pick an analogy, best make sure it is a good one ;-)

In reality, by the time this is done, it'll probably take the input of a couple of folks... rarely does anything go right the first time...

You'll find that around here, you're going to get a lot of input, particularly if it's a potentially interesting one like this. Don't mistake AWOL for taking a potshot.. that's important info, and something to consider. Just struck me as funny it would be someone outside the USA that would know the USA laws better. Not sure what he does for a line of work but I'll bet there's a story and a good reason he brought it up... did you run afoul of this reg somehow before? I don't do much of it, but I can imagine diddling too much with cellular attracts the ire of the fed and carriers alike.. ;)

To be honest, it's a silly law IMO.. http://www.scientificamerican.com/blog/post.cfm?id=radiation-from-cell-phones-flagged-2011-05-31 demonstration of how the Gov reacts to a perceived but nonexistent threat... I've never understood the potential "threat" of a cell phone on a plane.... and in all honesty, I think it's a much bigger risk dealing with people that believe the world won't turn if they don't tweet and chat about their bowl of morning cornflakes.. Even when I was an infrastructure manager for a trillion dollar brokerage, it wasn't necessary that I be immediately contactable 24x7.. Oh well, I'll get going on a rant and nobody wants that ;)

What is nice that if for some reason the GPS info for the data logger fails, you would still be able to match the data to the location by time. Having a backup without even trying... priceless.

No, never was the wrong side of the FCC. Or any regulatory body, for that matter.

I did once lose a rather expensive flying R/C model because of (at the time) unlicenced transmissions on the 27MHz band - someone thought it would be OK to test his then-illegal multi-watt CB radio near our flying field.

I have the tools and the hardware to do things with cellular devices that Joe Public cannot, but that's my job, and it requires that I remain on the good side of the FCC (and quite a few others).

The 70 mph analogy is not a bad one. I have no problem with people passing me on my way to work on quiet three lane highways at speed in excess of the legal limit. But just make sure that when you have your road-race day that you don't screw up the congested local network for those who really, really need to move at speed.

No I was just kidding AWOL, and I actually don’t speed.

For the Arduino to monitor the phone I think it will have to be through some sort of voltage reading because the display is set to go blank after 10 seconds to save batteries. The phone itself has never “Locked up” but the program has, but resetting the program every hour solved that. So I think your right in saying that we shouldn’t reset the phone, no need to.

Well, given that's your job.. let's assume he'll get the proper permission to go ahead and use cellular inflight, etc..

What's your take on this? I'm thinking the XBEE is of limited usefulness because of the range, but I'm no R/C expert. I like the tracking idea if it's legal to do, would you think that keeping it independant of the datalogging and arduino is the better idea? I see no value-add to connecting the phone to anything unless it's also transferring data from what it's connected to, only a potential failure point. Telemetry isn't really needed it seems, but if he can get it, it'd be a nice-to-have.

The project seems pretty straightforward, sample and datalog, and a couple of "switches" ... let the phone handle the tracking.

Despite the little evil angel which tells you messing with the FCC is harmless and fun, I would assume if you tick off the wrong people, it would probably be no problem from them to make a call and get your flight permissions revoked or something else that would make doing what you are doing a real pain. I'll leave you to worry about that though, especially as it seems it's not really connected to the Arduino in any meaningful way.

From the other side of the world.... (the low frequency typing reaches far further)

I think you will find the FAA/FCC is more related to interference into an aircraft instruments. Obviously anything that interferes (or potentially) during landing or take-off can result in an accident. While cellphones are close to towers, their power output is low, however this ramps up with distance, in order to met the quality required. Digital phones are worse, because their output can get into all sorts. (Try sticking your phone near the speakers on your computer, make a call and see what I mean)

Here we have the CAA who make that rule. They are looking at using a cell site on the a/c to allow calls to be made. (and charging accordingly)

It is interesting to note that pilots often use cellphones to communicate with the ground, and sometimes air traffic control. However they can monitor the effects, and aren't likely to be during takeoff and landing.

Here they also like to be informed of high altitude ballon and rocket launches. They don't show up on radar, and hence talking with the local air traffic control ensures they don't pose a risk to aviation, by way of a NOTAM (Notice to Airman) which ensures non commercial aircraft are advised. There may also be a rule regarding having a device to slow the descent to xxxx ft/sec, to also ensure it doesn't pose a danger. Breaking on of these is more likely to get you a visit from government official, than your high altitide cell phone call.

Sounds like a great project...good luck.

Mark

I think you will find the FAA/FCC is more related to interference into an aircraft instruments

I think that you will find that it is not. It is about operating with multiple base-stations simultaneously because of the massively extended line-of-sight.

Tesla you definitely seem to know your stuff, do you have anyting in mind we could use that would provide us with continous communication from the balloon to the ground? But also keep in mind that this has to be something lightweight because we need to keep the payload under 4 lbs.

Why do you need continuous comms to the balloon? Radios are heavy users of power - maybe useful to wrap other components around the power amp to stop them freezing, but a waste of battery power otherwise. Robust software around the barometer would allow you to transmit updates once the chute got below, say 10k feet. (I don't imagine the FCC would get too upset about transmitting from what is, after all, just a tallish mountain)