isolated box?
Insulated?
box is the easy part. Gotta know what cameras and sensors and pcbâs and batteries are going in it before you can build the box 
Iâm just curious as to whether the electronics we have can even keep themselves warm. The FEZ creates almost no heat.
[quote]The FEZ creates almost no heat.[/quote] I can give you my Domino :whistle:
Btw, forget me for this project now. I canât participate anymore 
Bec, it wont happen for at least 6 months. We need to design all the stuff, get pcbâs made, test tracking and communication systems, wait for good weather, find a good supplier of ballons, etc etc etc.
I dont think the electronics will keep themselves warm, especially on the way down. On the way up it should be no issue, but the way down will be much much colder (instead of the hot air escaping into t he low pressure outside, you have the cold air escaping into the low pressure inside.)
Mark, Iâm on chat if you want to talk about it
Another thought i had whilst on the train in this morning: If your electronics are generating heat youâre doing something wrong 
heat = wasted energy. Power supplies should be ultra clean switchmode and not generate any heat anyway.
I think once we work out what sensors we really want to use and what other features then we can work out the pcbâs weâll need for each module, and then we can lay them out as small as possible. From there we can figure out the internal structure of the box and then figure out insulation/heating requirements. Keeping in mind this needs to be under 4kg (lighter the better though) and run for several hours. Battery is going to be the heaviest part i have a feeling.
Well, if your electronics are not generating heat than they are off 
Where so you suppose all the electrical power goes that an electronic device uses? Into heatâŚ
Someone had a high alt balloon based on an ARM chip. He said it got hot enough to keep itself around 90 degrees F. The board was a lot more powerful than the FEZ, running Linux. I think it was all in a lunch box.
Jeff, i mean enough heat to heat something, sitting 1-2c above ambient isnât really all that much heat 
The fez only consumes 330mw of power, by comparison, 72 watts of energy are required to make 1.8m of nichrome hot enough to cut expanded polystyrene foam.
Iâm not so worried about the processor but more some of the sensors themselves that consume little/almost no power (uW of power).
I do have a possible contribution to make to the project if you want it⌠An Air-To-Ground telemetry communications protocol.
My rocket flight computer is pretty similar in scope to the electronics package on a balloon. The protocol is as follows.
*2 sync/header bytes to detect start of a valid packet
*1 byte packet type (256 possible types of packet, which in practical terms is plenty)
*1 byte payload length (up to 256 bytes of packet-specific data)
*4 byte packet timestamp (millisecond resolution for upto 46 days of continuous transmission before wrapping)
- Variable length payload specific to each packet type
- 2 byte CRC for detecting packet error
In my own application I am planning on writing the packet bitstream to both the SD Card onboard for recording the data, and also over-the-air via bluetooth initially then XBee or something later on.
So far I have packets for the followingâŚ
- GPS lock status
- GPS latitude/longitude
- GPS Altitude
- GPS Speed
- GPS Fault
- Accelerometer Data (Gâs in X, Y & Z)
- Accelerometer Free-Fall event
- Accelerometer Fault
- Barometric Altitude
- Barometric Temperature
- Barometric Fault
- Pyrotechnic Status
- Pyrotechnic Ignition Events (Parachute deployment, stage motor ignition, etc)
- Pyrotechnic Failure
- System Voltages
- System Temperature
So far my source is still only fresh but I will be writing an application (using WPF) to monitor and visualize the data stream, I will probably wind up integrating google maps and stuff for real-time GPS overlay and so on.
Heffo, that sounds pretty well thought out. Is there a reason you didnât want to put all the GPS data into one packet?
Iâd be interested in helping you out with the WPF app (as someone who works with WPF 8hrs+ a day).
Iâm planning to use OziExplorer for my mapping for a number of reasons:
- high res topographical maps (1:25,000) and satellite maps that work offline
- I already have it on a netbook mounted in my 4wd
- Has an easy to use api (interop required, meh)
- I can plot both the vehicle and the balloonâs position using the API with live paths.
- With Ozi3D i can get a better idea of the terrain when driving after the balloon.
For my personal balloon i plan on using a 900MHz xbee and a custom long range 435mhz FHSS UHF transmitter. These play nice with 2.4ghz video and 477MHz UHF Radio (which we use in Australia rather than 27mhz)
A long range plan of a friend and I is to use the balloon as a launch platform for a rocket 
When the balloon pops, CO2 jets will stabilise the payload and then a rocket will be fired from it, hopefully gaining even more altitude.
I based the packet format on the protocol used on the CrystalFontz USB/Serial LCD displays ([url]http://www.crystalfontz.com/product/CFA635-TFE-KU1.html[/url]). Excellent units and the protocol (I thought) is pretty robust. I did add the timestamp field and tweaked the header a bit.
I split the GPS data into multiple packets because on a rocket your latitude/longitude doesnât change too much but your speed and altitude change MUCH faster, so instead of blasting a single large packet at a high update rate, I will update the lat/long not as often as the speed/altitude to keep the data rate down.
For my rocket application the protocol is bi-directional, so I donât need to run massive lengths of wire to launch it. I will be able to configure, monitor and launch the rocket from either my notebook or even my mobile phone, via bluetooth. I do have plenty of safety interlocks planned for both hardware and software so no unintentional pyro ignitions are possible.
The interfacing to the telemetry transmitter (rocket side) is through function calls, where the packet is built and passed back through an event
public void SampleSend()
{
Double latitude = -36.772f;
Double longitude = 147.193f;
Single speed = 102.97f;
TelemetryTransmitter telemTX = new TelemetryTransmitter();
telemTX.PacketReady += new PacketReadyHandler(telemTX_PacketReady);
telemTX.GPSLocation(Latitude, Longitude);
telemTX.GPSSpeed(Speed);
}
private void flight_PacketReady(TelemetryTransmitter sender, byte[] packet)
{
// Send the byte array to your favourite transmitter here
}
On the receiver side I will pass in a byte stream from wherever and it will raise events as packets are decoded. That way I can use the same code for real-time monitoring via radio, or streaming back recorded data from a file in the same codebase.
MarkH:
For any other metrically-challenged Imperialists, 4kg = 8 lbs 12.8 oz.
Bec:
Iâve been following that thread - Iâm sad for you.
Chris:
Imagined post-operation interview:
Interviewer: âWhat was the biggest hurdle? The camera control, telemetry, recoveryâŚ?â
MarkH: âDeciding what lunch box to use.â
Personally, I vote for the Jetsons:
http://americanhistory.si.edu/collections/object.cfm?key=35&objkey=5881
Ah, that makes perfect sense now. Iâm used to all the variables changing at the same time (ie: flying horizontally or on a climb/descent path.)
Iâm sure youâve thought all this out, however i do like to throw a spanner in the works of peoples thinking (i know i like it when they do it to me, so i consider ideas i hadnât thought of previously.)
Have you thought of storing your data as XML for easier reading/processing/sharing? All the XML functions in .net are implemented in the NETMF code, so are not in IL - therefore very fast. The SD cards are insanely fast on Domino too so you shouldnât have any bottle neck.
I like your idea of having packets prepared for transmission, you could almost throttle them if you need a lower baud rate (for increased range) and discard old packets of the same type if a new one is added to the queue before the buffer has been cleared.
LOL FarmerDave, thats pretty funny.
In the embedded (limited ram/cpu) space I have never been too keen on the idea of XML, not that I donât use it in my PC software, I use it there all the time. And since I am already preparing the byte stream for ground transmission I might as well use it as the storage format too. My idea is to use as little resources (read: ram) as possible to accomplish the task at hand, I can output it to an XML stream once the flight computer is back on the ground. I am actually planning KML output for visualizing the flights in Google Earth.
I think for the temperature sensor weâre going to need to use a thermocouple for the low temperature stuff. I havenât come across a temperature sensor that goes down -60 yet.
The Dallas/Maxim DS1822 is good for -55 to +125 degrees and itâs in a transistor TO92 package
I have put some related sensors on over 5m of hookup wire and I could still get a reliable digital signal from them.
They are available from DigiKey for $4.95 each.
1 Like