Custom airborne HD rocket "camcorder" anyone?

[FROB]

I've been thinking that this year i'd really like to start doing some in-flight video etc.
For the camera system, I'd prefer something small, light, and easily fit into a smaller airframe so i can get some pretty high altitude shots with a smaller min diameter purpose-built rocket, and not spend a fortune on big motors to loft a 2 lb camera in a 4+ dia airframe rocket that can hold it. I'm thinking 29mm or 38mm, for flights from 5000' up to 25k. I'd also like something better than VGA or QVGA like most of the small cheap cameras do. Also on my wish list is a camera that can switch modes in flight and take 30-60FPS HD video on the way up, and a continuous series of very high-rez stills on the way down.

From what i've seen, there doesn't seem to be much that even comes close to that description.

It seems i will have to kludge something together using probably a $200 HD camcorder stripped down, hacked with an external microcontroller, and limited to 54-75mm minimum airframe dia.- far from ideal.

So here are my questions for you:

Anyone else in the same (or similar) boat?
What would you use and how would you do it?

Would you like to get into airborne video/photography but consider it too much trouble to bother?
Are you afraid to launch your expensive camera gear, but don't want to spend a bunch of time+money on something you have to kludge together that may or may not work to your satisfaction?
Are you not into high power, but would get into flight videos if you could get high quality video reliably and fairly cheaply using a small low-mid power rocket?

Essentially, i'm wondering if there is a market for a small purpose built HD video flight recorder for model rockets.
Or from another point of view, if i had time this year to complete one and only one major rocketry electronics project, and assuming anything is possible, what would make the most "impact" to help the most people get more enjoyment out for the hobby? would it be the above described device or something else like cheap GPS/ telemetry / advanced altimeters etc etc..?
What is missing the most so far as far as rocket electronics? get out your wish lists!

 

[jadebox]

You'll probably be interested in a discussion at:

https://www.rocketryplanet.com/forums/showthread.php?t=2933

It was started by someone who is thinking about building a camera specifically for rockets.

As I stated in that thread, I don't think HD is important right now. I'd prefer better quality SD. Most of the inexpensive, flash memory camcorders use small sensors and small plastic lenses. They also use compression methods that don't handle fast changes very well. I'd prefer an SD camera with a larger sensor, better lens, and a good implemention of "Motion JPEG" for the video. That would probably result in better quality video than any of the inexpensive HD camcorders provide.

-- Roger

 

[FROB]

Thanks Roger-

Its encouraging that others are having the same idea at the same time- that is usually a sign of a good idea whose time has come.

I agree somewhat with your comments on better quality sensors/lenses but from a practical standpoint a compromise for cost, size and ease of development is inevitably necessary- for me that would mean using one of the more recent 2Mpxl cellphone modules, less than 1cm cube (on a pigtail that can be mounted independent of the logger part) that can do 1600x1200 at 30fps streaming mJPEG, with all image processing done internally. I went to a technical training for the previous generation of these a few years back and the image quality they produce is remarkably good considering the limits of its small F3.2, 52deg FOV plastic lenses and 2uM pixels. that is thanks in part to a lot of work put into the on-chip image enhancement. I feel the wide angle fixed focus lens is perfect for rocketry anyway and since its used outdoors in daylight some of the limits of small well pixels (low-light noise) should generally not come in to play.
The main downside to these modules is that due to the cellphone market any given model is usually available for a year or less and they have high minimum orders, but they can be found on the surplus market at somewhat higher price.
Would you be interested in something with these specs?

 

[jadebox]

Would you be interested in something with these specs?

Oh, yes.

The older cameras I use in my rockets weigh (with batteries) about 4 ounces. The new one I have (a Panasonic SDR-S10) is about 8 ounces. All the cameras are about 4" x 3" x 1" in size. So these camera aren't very heavy or large in relation to other cameras. But, the size and weight does limit their use to mid-power or high-power rockets.

So, something smaller and lighter would definitely be useful for me. I'd like to be able to put a camera in smaller rockets including model rockets. And, a smaller, lighter camera could be added to most any larger rocket by adding an external pod rather than having to build a camera bay as I do now.

I'd also like the other features I enumerated in the other thread. The ability to control the camera externally from a break wire, g-switch, altimeter, or timer would be terrific. Open-source firmware would be a plus.

I don't know if the camera modules you're considering can support it, but the "pre-record" function I mentioned would be really nice. Have the camera record to a one or two-second buffer until lift-off is detected (through an external connection to a break-wire or g-switch) then save the video starting with what's in the buffer. That way, recordings would always start just at ignition.

My rocketry projects are tending to get larger over time, so in addition to using a camera like the one you suggest for small rockets, I'm envisioning using more than one camera like this on a large rocket. One camera could be triggered with a g-switch or break wire to record the lift-off. One could be placed on the ground and triggered by the launch controller or by an external radio control interface to also record the lift-off. One could be triggered by an external altimeter to record ejection of the parachute. Another could be triggered by a timer to record some other event. The possibilities are exciting to me!

Battery life is important. The older cameras I use can record 60 minutes on an SD card, but the batteries only last 20 minutes. I've missed recordings more than once because the batteries ran out before the rocket was launched.

I think you would also find a good market outside rocketry. Obviously, a camera like this could also be marketed to R/C modelers for attaching to boats, cars, or planes. Other potential users could include kite flyers. You could offer a ruggedized housing so people could attach the camera to helmets or to real cars or planes or whatever.

BTW ... I didn't think to mention it in the other thread, but I have 25+ years of software development experience including work on embedded systems (hint, hint).

-- Roger

 

[FROB]

Oh, yes.

Oh, Good! |-)

The older cameras I use in my rockets weigh (with batteries) about 4 ounces. The new one I have (a Panasonic SDR-S10) is about 8 ounces. All the cameras are about 4" x 3" x 1" in size. So these camera aren't very heavy or large in relation to other cameras. But, the size and weight does limit their use to mid-power or high-power rockets.

So, something smaller and lighter would definitely be useful for me. I'd like to be able to put a camera in smaller rockets including model rockets. And, a smaller, lighter camera could be added to most any larger rocket by adding an external pod rather than having to build a camera bay as I do now.

I think this could get inside a 29mm tube- total maybe 3"-4" long, most of that batteries and control/recording board. probably a short 1" flex cable to the camera head is the most practical option there. I'd use Micro-SD card format. A USB port option could be supported too if necessary, but lots more code work is needed there.

I'd also like the other features I enumerated in the other thread. The ability to control the camera externally from a break wire, g-switch, altimeter, or timer would be terrific. Open-source firmware would be a plus.

No problem there, i'm also considering on-board accelerometer and gyro, possibly other sensors and some outputs to be used in various ways- more on that later- so long as it doesn't add to much size/cost/complexity.

Open source - not against it, some concerns though, that's a whole other discussion.

I don't know if the camera modules you're considering can support it, but the "pre-record" function I mentioned would be really nice. Have the camera record to a one or two-second buffer until lift-off is detected (through an external connection to a break-wire or g-switch) then save the video starting with what's in the buffer. That way, recordings would always start just at ignition.

Thats easy (managed by the controller, not the camera), but increases power consumption, while sitting on the pad- which can sometimes be a long time.
something interesting could be done with primitive motion detection, in a low power mode, to trigger start of recording- so it triggers when the camera sees the first whiff of smoke from the igniter, or you can connect an LED or similar in parallel with the igniter in the camera's field of view.

My rocketry projects are tending to get larger over time, so in addition to using a camera like the one you suggest for small rockets, I'm envisioning using more than one camera like this on a large rocket. One camera could be triggered with a g-switch or break wire to record the lift-off. One could be placed on the ground and triggered by the launch controller or by an external radio control interface to also record the lift-off. One could be triggered by an external altimeter to record ejection of the parachute. Another could be triggered by a timer to record some other event. The possibilities are exciting to me!

We're on the same wavelength- I also like the idea of dropping a separate camera with its own chute or small helium party 'ballute' at apogee, to get nice panoramic video of the ground without a lot of bouncing around.- maybe even strap it to a spinning flywheel, or using "post-production" image stabilization to achieve rock-steady video.

Battery life is important. The older cameras I use can record 60 minutes on an SD card, but the batteries only last 20 minutes. I've missed recordings more than once because the batteries ran out before the rocket was launched.

The camera uses about 150mA and ballpark for the rest while recording high-def about double that, so for 1 hour we'd need in the range of [email protected]. A small LiIon pack should do.

I think you would also find a good market outside rocketry. Obviously, a camera like this could also be marketed to R/C modelers for attaching to boats, cars, or planes. Other potential users could include kite flyers. You could offer a ruggedized housing so people could attach the camera to helmets or to real cars or planes or whatever.

True- there's probably much more potential demand in at least a dozen different niche's that i can think of outside of rocketry, which is why i'm starting to seriously consider doing it over some of my other project ideas.
DoggieCam anyone?

BTW ... I didn't think to mention it in the other thread, but I have 25+ years of software development experience including work on embedded systems (hint, hint).
-- Roger

Well, let me see if i can get my grubby hands on some sample modules, then we can discuss further....

 

[FROB]

I forgot to mention...
for those that want to stream live video via RF downlink, that's not really practical at 1600x1200x30fps due to bandwidth... but this camera module has a nifty feature that it allows swapping between 2 different image formats on alternate frames - so you can record at full rez while simultaneously streaming highly compressed VGA for QVGA at reduced framerate for example, without having to do a lot of real-time image processing, and send that to a digital downlink using a serial port. it might even be possible to transcode mJpeg to Mpeg4 before transmission for better quality & framerate, depending on the available CPU power.

 

[ttabbal]

I'd be interested in some camera modules with those specs. I would really like it to do JPEG/MJPEG internally and present some standard interface to me. SPI/parallel/I2C even RS232 would be fine. Preferably with some sort of specs for any needed protocols to control it.

 

[FROB]

I'd be interested in some camera modules with those specs. I would really like it to do JPEG/MJPEG internally and present some standard interface to me. SPI/parallel/I2C even RS232 would be fine. Preferably with some sort of specs for any needed protocols to control it.

No difficulty there, but of course downloading a 2GB video over those interfaces might take a while!
I'm curious what kind of camera control functions you think might be useful would you like to propose a list as the starting point for an API design?

 

[ttabbal]

No difficulty there, but of course downloading a 2GB video over those interfaces might take a while!
I'm curious what kind of camera control functions you think might be useful would you like to propose a list as the starting point for an API design?

Well, yeah, RS232 would be stupid slow. 8-bit parallel shouldn't be hard though. Even 16-bit parallel would be OK with me. SPI can also be reasonably fast.

Hmmm... control. Resolution, frame timing (low FPS = less CPU), single shot or movie mode, format change maybe, trigger for shutter in single-frame mode.

What kind of bitrates are we talking here? Any HD video is going to need a decent CPU for even just buffering and storing the data. I was going to attempt it with a PIC32, but I'm not opposed to moving to ARM9. If you include the microSD stuff on your side, my micro could just tell yours what it wants. That means my micro can be smaller, and slower which is nice for those of us that can't afford 4-8 layer boards. It does make the module more expensive for you to produce, and for us to buy though.

I don't suppose the hardware you're looking at can do h264 movie encodes? That really drops the bitrate down.

 

[FROB]

Well, yeah, RS232 would be stupid slow. 8-bit parallel shouldn't be hard though. Even 16-bit parallel would be OK with me. SPI can also be reasonably fast.

The camera chip itself (like almost all video chips) uses a '656' style interface which is really lousy for interfacing to a generic MCU bus- i'll likely use a small CPLD to buffer a few bytes worth and convert it to a generic 8-bit SRAM interface with a couple of interrupts +I/O's for frame / line strobes, fifo data ready etc.. That will in turn probably connect to an ARM 7/9/ or Cortex MCU with USB, SD card, 10/100 Ethernet, SPI, I2C, UARTS and Flash on chip. add a sprinkling of regulators, sensors and connectors, and youre more or less done. If Ethernet's supported, i'd leave the phy/connector to an optional daughter card. with serial ports on small headers, save USB which gets a normal mini-USB OTG connector.

Hmmm... control. Resolution, frame timing (low FPS = less CPU), single shot or movie mode, format change maybe, trigger for shutter in single-frame mode.

Them's the basics, i'm sure more will come to mind over time.

What kind of bitrates are we talking here? Any HD video is going to need a decent CPU for even just buffering and storing the data. I was going to attempt it with a PIC32, but I'm not opposed to moving to ARM9. If you include the microSD stuff on your side, my micro could just tell yours what it wants. That means my micro can be smaller, and slower which is nice for those of us that can't afford 4-8 layer boards. It does make the module more expensive for you to produce, and for us to buy though.

Thats quite true. In the 'raw' modes, full res = 80MB/S thats (bytes/s) in JPEG mode it varies, the size of a full frame can be anywhere from a 100kB to 2MB depending on content and mostly on JPEG 'squeeze' setting, which is fully programmable. worst case probably 50-60MB/2 at minimum squeeze.
either way the hardware should be able to take in 8-bits +H +V strobes at 80MHz or close to, externally clocked in random bursts by the camera. If you want only highly compressed JPEG and/or reduced size images with reduced framerate, you can probably get by at much lower clock frequency.

My thinking is leaning towards providing the camera management and other low level code & RTOS as a linkable library and let people go to town (at your own risk) modifying the main control task as they see fit- thus if out of the box it doesn't quite do what you want, you can adapt it yourself without needing to kludge-on extra hardware. You will need an ARM compiler & Jtag dongle.

I don't suppose the hardware you're looking at can do h264 movie encodes? That really drops the bitrate down.

Well, in order to do that, the recorder would grow to toaster-oven size and sport a sparkly sticker that says "intel inside". Especially H.264 (or any video conversion at this resolution) is far,far beyond the reach of any reasonably cost MCU that will fit on only 4 layers.
Actually it can be done, but you need to plunk down some serious money- at least $80k+ in R&D and probably $30-50 per device in chips.
I know what you're thinking, but sadly the complex custom asics used in newer consumer camcorders are completely inaccessible.

I spoke with the manufacturer's rep today, he will support me but its really up to the imaging division to decide if they will support this- which is a long shot, as they don't usually get out of bed for less than 1M units/year. I'm about to write a business case for it to present to those folks. With any luck i will know in about a week. Actually it sounds pretty darn compelling in my head, i just need to capture it in writing now...

 

[FROB]

Hey guys,
i'm considering a different processor:
BlackFIN ADSP-BF516F
Ive done some work with this series in the past.
this particular part can interface directly with the camera, and SD card, ethernet too along with usual serial ports- but no USB.
No cpld needed means a smaller board.
Nice thing is, it's got a 400MHz DSP core designed for media/image processing, and codecs like H.264 are available. though it would require external SDRAM to do it, it would be possible to get some H.264 streaming video out of it. My guess is about 2 frames/s at full 1600x1200, and at the other end, 30 fps would get you about QVGA- with any compromise between the 2 extremes possible. ttabbal, would this suit you?
I think this is more appropriate for UAV's, RC remotes and similar applications
Its also supported by dot.net micro framework.
I'd set up the internal flash program to load a configuration file from the SD card, and maybe even reprogram itself if it finds the right kind of binary image there.
Compressed video could be streamed out via high speed sync serial port, so it can directly interface with a digital radio transmitter.


edit: after a little back of the envelope figuring, i worked out rough board dimensions: 29x52mm rectangle with a 10x10mm section on top of that with the camera mounted there. connectors and battery on the back of that. SD card at the bottom, card enters from the side, and projects 1mm beyond the edge when fully inserted.
prototype might be a little longer to allow all parts top side.
So were talking smaller than a D cell, and weight with a battery like below, less than 1 Oz
https://www.sparkfun.com/commerce/product_info.php?products_id=341

What do you think?

 

[sailmike]

I am very interested in this project. A simple video camera that records to onboard memory would be better than the live streaming video stuff you can get from Art. I believe his cameras require a ham radio license? I am wondering if you can separate the camera from it's control board so that only the camera mounts outside the rocket and the rest of the electronics on the inside?

Please keep us up to date on this project.

Mike

 

[FROB]

I am wondering if you can separate the camera from it's control board so that only the camera mounts outside the rocket and the rest of the electronics on the inside?

Mike,

Thats what i wanted to do, but i'm not convinced how practical that is yet -it will take a little experimenting. As a compromise, with the first proto's anyway, in a rocket 54mm dia or larger, the position of the camera at the top center will allow you to have just the camera part sticking out beyond the body tube and pointing down, by mounting the whole unit flat against a bulkplate. For any size between 29mm and 54, you have to mount the thing vertical so the camera looks through a hole in the side, but its not too difficult to find a small front surface mirror or prism to use just outside the airframe to redirect the view downwards.
So with these possibilities available, i figure it's not as much an essential requirement to have the remote mountable camera head, at least not right away. As well, i'm not sure yet whether a longer 'reach' remote camera cable might be desirable or necessary for some applications. In that case, anything over a couple of inches makes it a lot more difficult. So I prefer to see if i can get a basic version working first, hopefully bu then i will have a better idea what's really needed before doing the final 'remote cable' design.
Any suggestions on how long you would like the camera head cable to be would be helpful.
Also note, with a 29mm rocket and the uSDcard socket positioned the way I'd like to, it allows you to cut a tiny vertical slot in the side of the body to insert and remove it without having to take it apart. A little scotch tape over it though might be a good idea...

 

[jderimig]

Hi FROB!!!!

I think you may be underestimating the importance of the megaHF analog part of the signal (the optics). Unless you can get chromatically adjusted image focused on the plane of the image sensor all that extra HD resolution is wasted.

Alot of the complexity of your project revolves around the signal processing of your 1200x1600 pixel video signal. Without a good optical front end to any image sensor you will have mega data but much less information.

There is a reason that companies like Canon routinely get $3000 for their glass. It makes a big difference in IQ. With cheap optics I do not think you will get any additional useful resolution once you pass 720x480p or so. If you go with a smaller image sensor then the processing and storage becomes alot easier.

You make want to make a breadboard to get some stills with the sensors you are considering to see if you are really going to get the benefit of that mega resolution.

--john d

 

[FROB]

Hey John!!!
good to 'see' your voice!

Your right of course, if the optics are bad there's no amount of extra pixels that will make it into a better picture. All i can say is the proof is in the pudding. i haven't seen the output of this particular module myself yet so its possible I'm in for a disappointment. However, this is from the biggest and arguably most advanced supplier of miniature camera modules and imaging co-processors, and I doubt they could sell so many millions of them if they produced very noticeable optical aberration in the output. Anyway I've seen some of their earlier stuff (1.3Mpix.) and i was darned impressed.
The optics are invariably the weakest link, and quite small i don't expect great low light performance- but i'm hoping in outdoor daylight, even under overcast sky, performance should be adequate, especially for a wide angle fixed lens. The lens is plastic but its a 4-element conjugate, so i can only assume the lens is designed as an achromat set- they wouldn't need so many elements otherwise? I don't claim to be an optics expert, so i could be mistaken. I know that the internal DSP also does a couple of different kinds of optical compensation, but i haven't looked too deeply into that.

If the optics do suck and it turns out the best resolution is a bit lower than full size, It might still be an acceptable compromise. If not, there's a decent chance i could find a more suitable module a little later-
Also, using the BlackFIN rather than an low-end ARM here means i'm no longer limited to using a module that does on-board image compression, though i could never get close to the same bandwidth as the dedicated jpeg logic in the module.

I have an old BlackFIN devkit here still in the shrink wrap, so thats exactly what i'm planning to do - soon as i can get a sample module, hook it up to that and play with the settings to see how good a picture i can get from it - it might take a while, but what results i do get i will post up here for everyone to judge for themselves.

On another note I also just discovered there's a port of uClinux for the BlackFIN for those that lean that way- its probably not an appropriate OS for real-time imaging, but it makes the open-source concept a lot easier.

 

[jderimig]

Cool,

Will a prototype be ready by LDRS? NYPOWER? We will have a vendor tent at LDRS28 if you want to give demos and take orders......

 

[mperdue]

I've had great luck with the camera that i built for my LAUNCH Magazine article.

 

[FROB]

Cool,

Will a prototype be ready by LDRS? NYPOWER? We will have a vendor tent at LDRS28 if you want to give demos and take orders......

Thanks John,
Well i'd love to have a number of things ready for those big events, but with my history, you know i'm not makin' no promises to nobody any more....
I will try and keep this thread alive with updates as things develop though - with a little luck, ya never know.....

 

[FROB]

I've had great luck with the camera that i built for my LAUNCH Magazine article.

Hey Mario, thats very cool!
Thanks for pointing it out - Maybe i should subscribe to the magazine, eh?
Anything more about it on the web or that you can share here? I tried to find the article on the magazine web site, but only found a reference to it in your musings blog. maybe i'm not looking in the right place.

Thanks!

 

[ttabbal]

FROB: That a lot of data. I figured it would be since we were talking HD. I always assumed h264 would be out of budget, though it would be nice. MJPEG would work for me, or even MPEG2 might be possible with the Blackfin. Honeslty, 720p would be more than enough to suit me, but I'm sure some people would love to see 1080p stuff out there.

The comments about the optics are interesting as well. The only way to be sure is to capture at various resoultions and see for yourself. For the really high res modes, snapshots at 10fps or less would be interesting as well.

I haven't found much out there that fits our little niche. I'm very interested in this project. I'd even be willing to go to SD res if I could get something reasonably cheap, with decent performance in a small form factor suitable for rocketry. The price thing is more for the inevitable crash. I'm a lot less bothered by crashing $100 than $500.

Even for lower res stuff, anyone know of a good, well documented camera module that's available to those of us that don't buy millions of units? 1+ Mpix with onboard JPEG would be great. Sparkfun has one that "sort of" has docs, but nobody has been able to get it to produce JPEGs. If I could find something like that, I could make a tiny nose-cone cam or something. Nowhere near the specs we're talking here, but it might make for a fun project for me to mess with.

 

[mperdue]

Hey Mario, thats very cool!
Thanks for pointing it out - Maybe i should subscribe to the magazine, eh?
Anything more about it on the web or that you can share here? I tried to find the article on the magazine web site, but only found a reference to it in your musings blog. maybe i'm not looking in the right place.

That article is in the Sept/Oct 2008 issue. There's really nothing else on the web site at this time.

Mario

 

[FROB]

Yup - lots of data - fo shizzle!

a little number crunching shows the SD card, even the best class 6 ones, will be the bottleneck for getting better quality video out as unmodified mJPEG.
One way of dealing with that might be to dynamically vary the compression ratio and framerate depending on rate of motion etc in the image.
A simpler approach is to use NAND flash chips with a higher bandwidth soldered directly to the board- but then you would be forced to use ethernet to download the video- or i can still have the SD card slot there and transfer video to it after recording stops, if its present.
Any opinions? if i go for the permanent embedded flash - of course the amount of which greatly affects cost (and size a little) how much is enough?
at max quality/framerate, 2GB might hold as little as 30 seconds of video- but with some intelligent real-time tweaking of parameters in response to flight conditions, that could be made to last the whole flight.

Another option is to add more SDRAM to buffer more of the video there, but that gets expensive in real-estate and dollars pretty quick. My original plan is 32MB of RAM.

I'm trying to keep the price target below $200 initially, and below $100 later assuming some real demand picks up in other markets to help bring down the cost. how do you feel about that price point? Unfortunately, in small batches the production overhead really dominates the cost of making these things. Hand assembly is not a viable option.

Finally, for a negligible increase in cost,(but a lot more code) i can add and optional WiFi capability. though slower than 10/100 wired ethernet, is the wireless convenience factor worth it? Anyone with an iPhone or iPod touch will undoubtedly want that.

 

[FROB]

... I always assumed h264 would be out of budget, though it would be nice. MJPEG would work for me, or even MPEG2 might be possible with the Blackfin. Honeslty, 720p would be more than enough to suit me, but I'm sure some people would love to see 1080p stuff out there.

This stuff evolves so fast its scary- a couple of years ago you needed the best PC server with specialized hardware acceleration, or $10,000's worth of FPGA's and $50k in IP, to do H.264 encoding at 1080i.
Today there are already specialized chips that can do it for less than $40 in high volume- these are starting to show up in consumer grade camcorders now- but unfortunately only accessible to a well known business with high production rates at the moment. This could change in as little as a year from now.
And it turns out D1 (VGA) or thereabouts might be possible with technology i can use, and MPEG2/4 even more easily. I actually looking into other alternatives as probably the most practical approach- JPEG-2000 or similar wavelet-based compression. the downside is these codecs are not standard on PC's yet.

So the compromise at the moment could give you a choice :
1- very short max resolution video of a minute or less
2- much longer MPEG or other high compression video limited to VGA or so
3- some pre-programmed capture sequence of a combination of 1 and 2.

 

[ttabbal]

Hmmm... well, a minute gets you past the ascent phase of most rocket flights. How about doing snapshots after that? The parachute decent is pretty boring most of the time, so you could take snapshots at some longer interval. Even 1fps would be pretty cool and would save a ton of space. Of course, then you have to detect apogee or use a timer based setup. Being able to choose compression would be kinda nice for people. You can decide if you want HD, or if VGA will do. VGA = 640x480? That interface can do a lot, but that seems to be the threshold.

I don't have a problem with JPEG2000 if there is a free decoder available for Windows, Linux, and OSX. Downloading it is no big deal, better if you can provide them all on a CD with the unit or on your website. Being able to re-encode to normal JPEG/PNG/BMP/MPEG etc. would be handy software to have on the PC side though, for sharing with people that don't have the special decoder.

Wireless? Don't care. Ethernet would be fine with me. USB is probably easier for most people to use though. I have a ton of networking experience so it doesn't bother me to use it for this. Copy to SD after flight would be cool too, also probably easier for most people to understand than networking. Fly, pop in an SD card (perhaps on a small daughterboard?) and it copies over the video data. That would be easy and reasonably fast.

If you need a tester, let me know. I'll push it way up there for you.

 

[FROB]

Hmmm... well, a minute gets you past the ascent phase of most rocket flights. How about doing snapshots after that? The parachute decent is pretty boring most of the time, so you could take snapshots at some longer interval. Even 1fps would be pretty cool and would save a ton of space. Of course, then you have to detect apogee or use a timer based setup. Being able to choose compression would be kinda nice for people. You can decide if you want HD, or if VGA will do. VGA = 640x480? That interface can do a lot, but that seems to be the threshold.

Thats easy- you could have a user-designed script decide how long or how many frames to and at what resolution/quality, and switch to another mode, go though as many phases as you like like that till the memory's full.

This module has an internal scaler that is pretty flexible and can produce pretty much any sized scaled/zoomed output it seems. not sure how good the scaling is though. it also has an optional 3x binning function which essentially results in a 533x400 image with 5x the sensitivity that should look pretty good.

I don't have a problem with JPEG2000 if there is a free decoder available for Windows, Linux, and OSX. Downloading it is no big deal, better if you can provide them all on a CD with the unit or on your website. Being able to re-encode to normal JPEG/PNG/BMP/MPEG etc. would be handy software to have on the PC side though, for sharing with people that don't have the special decoder.

I agree there.

Wireless? Don't care. Ethernet would be fine with me. USB is probably easier for most people to use though. I have a ton of networking experience so it doesn't bother me to use it for this. Copy to SD after flight would be cool too, also probably easier for most people to understand than networking. Fly, pop in an SD card (perhaps on a small daughterboard?) and it copies over the video data. That would be easy and reasonably fast.

USB in this case means adding an extra chip, with lots of high-speed lines on the memory bus (more trouble to lay out in a small space & 4 layers max) but the processor has 10/100 on board. unfortunately the cheap phy, magnetics, and connector conspire to take a lot of space and a bit of cost, but those can be kept on a separate board with a small micro-usb style or even card-edge connector, that you could plug in through the side of the rocket without taking it apart. I might even include the battery charger on that board, and and SD card socket if there is an on-board flash chip. As you say, that is pretty easy to grasp, and i'm starting to like that better. Plus it avoids any issue of the card moving or falling out in flight.

Which way is easier will win, and that depends mostly on software, but i'm leaning more towards ethernet right now because that meshes better with some of the unrelated applications i'm also targeting. (though USB would be a requirement for some as well)

Wireless can be in the form of an optional (and cheap) WiFi SD card. I know of one brand/chip i can get the driver code for (i have an older version now). that means reserving space for that relatively large connector somewhere in the flight package.

If you need a tester, let me know. I'll push it way up there for you.

Youre first on the list ... but sorry the hardware wont be free for testers, i can't afford it. i'll find some kind of incentive to offer though.

 

[FROB]

Forgot to mention-
there will be a couple of inputs to allow triggering from external things/ events like altimeter outputs etc. they will be designed to "direct-wire" safely without a relay or isolator.
Having a barometric sensor or acceleromter on board, or both, and a couple of ematch outputs would also be possible and not affect the cost too much, so for say 25% more $$ you have a built-in full function altimeter.
Would that have some appeal, or not?

The other approach is to have optional sensors and input/output 'mini' boards that all connect together daisy-chain on a 4- or 5-wire bus. If you wan the whole enchilada all-dressed it costs a little more this way, but you can go bare bones too, you're choice. Not sure if the remote mini-boards is a nice feature or a pain in the a##. Thoughts?

 

[FROB]

Update-
Still waiting for official word on the sensor module, but unofficially it looks doubtful- seems like the cell phone companies are still going gangbusters and are eating them up faster than they can be produced. Still, i can get a few on the grey market, but that makes supply, condition and price very uncertain.

Plan B
- I've identified some other bare sensors that would work swimmingly, but it means getting the optics separately- making the 'head' a little bigger and costly than it would have been with the first option, but likely will greatly improve the image, as i'd have a bigger aperture and better glass lenses vs plastic.

 

[sailmike]

Just a thought, but you might want to make this modular somehow so that there is more flexibility and, therefore, a larger market. That could make the cost per unit lower. If I don't want the altimeter, I'll just get the camera. Don't want the apogee detection? Don't buy it.

Some ideas,
Mike

 

[FROB]

Just a thought, but you might want to make this modular somehow so that there is more flexibility and, therefore, a larger market. That could make the cost per unit lower. If I don't want the altimeter, I'll just get the camera. Don't want the apogee detection? Don't buy it.<snip>

Yes, good point-
I've been thinking about that for a while- They key is keeping the cost per unit lower. It's not that easy- adding one or more connector on the board to allow a bunch of little daughter cards to connect to it is almost as or more expensive as the actual active component in many cases (when you count assembly and other overhead) and makes the deluxe version more expensive- and complex- since now you have more boards, connectors and wires that are always weaknesses as far as reliability.
I think what might be a suitable compromise is to have all the components on the same board, but leave some unpopulated in the 'basic' version.

In as much as it may be a useful feature to have some remote modules that you can locate in a separate place in the airframe via a cable, and to be able to upgrade the 'basic' model later, i may still do remote modules for pyro outputs and a barometric sensor - the baro being a fairly pricey item, and the convenience of having the pyro's on the outside of the ebay being the main justifications.

Spreaking of pyro's, i have invented a novel way of getting more channels cheaply - so i might have as many as 9 channels available, in a little board that connects via a 4-wire cable. The same cable with a 3rd connector on it could interface with a tiny board for a barometric sensor, about the size of a small stamp.

 

[FROB]

I've gotten some encouraging responses from other sensor manufacturers, though i'll have to figure out the optics separately, it looks like plan 'B' at least will be viable.
In the mean time i want to see what kind of radio modem i can use to send live video during the flight. that depends on one thing- bandwidth -so the question of the day is:

What is the minimum *useful* picture resolution for a live feed:
VGA (640x480)?
HVGA (480x320)?
QVGA (320x240)?
1/8VGA (240x160)?
QCIF (176x144) ?
QQVGA (160x120)?
Sub-QCIF(128 x 96) ?

Is monochrome acceptable? or reduced color depth ?

What framerate? is 1 frame/sec too slow? 2? 4? 6?

The 3 "features" above can be traded off for best overall effect -i.e. higher framerate & lower rez, or vice versa.