KSP Community CubeSat

[Nicholander]

Actually, I think the Pi is a better option now.

[henryrasia]

Yay! We've settled something! Updating the doc now!

Great, so computer will be Raspberry Pi, which will only be used occasionally, and then a rad-hard 8051 backup always on auxiliary one? Is that the plan? As for single events, there's still a small chance the Pi will be fried while in use. Are there ways to avert this? This is mission-critical, remember. Like only using the pi at night (orbital night, that is), or is that useless? Or maybe turn it off when power surges occur, is that feasible? I know nothing of Raspberry Pi but would love to learn, if anyone here does.

So K^2, how are we doing for power demand? We now know an 8051 will be always on, and a Raspberry Pi (which model?) sometimes. Orbit will be similar to ISS's (right?). Transmitter is either really puny or 40W one (stretchgoal). How much would each cost approximately (small vs large power generation/consumption)?

And Mazon Del, can you do the experiment? It'd be really useful to know how it would look like. A setup of dark box, moss, IR light and IR camera should do it. If you can't get IR then normal camera is fine. We only need to know how fast we could speed up the video for the particular moss (spirulina, is it?).

This thread is starting to pick up! Are you sure we don't need a subreddit or something to keep track of the different conversations happening here? And Nicholander, K^2, NERVAfan, and everyone who in this for real, we should meet in chat or something. You all have google accounts? So how about we use hangouts? Like in the weekend or something.

PS. I just realized, are we sure the orbit will decay in 4 weeks? Otherwise we can make a mission "continuation" if all systems remain functional, but what woud that be? The moss will probably be dead by then (or is it?). It'd be a shame to waste a relatively powerful cubesat (definitely powerful if we reach stretchgoals)...

Edited December 1, 2014 by henryrasia

[Coga19000]

Can someone inform me of the current decided -upon specifications of the sat? I simply cannot read all the posts in this thread.

Also, from the basic knowledge I have on radiation, there is a slim chance that a Blackberry Pi without radiation proofing has a chance of getting fried even while it is OFF. Maybe the odds are small Emin to be ignored, though.

[RobotsAndSpaceships]

I don't think that a crowdfunding campaign can raise enough money for a mission into LKO, unless you take some drastic measures. Do you have any backup plans for funding?

[astropapi1]

Guys, I was talking to a friend of mine who's an amateur astronomer and he told me about Colombia's first satellite (didn't even know we had one), which was Cubesat called "Libertad 1" launched on 2007 on a Dnepr-1. The interesting thing, though, is that one of the engineers from that project lives on my city and is a friend of my friend, so I might be able to get in contact with him. As far as I can tell, he was in charge of communications and energy storage aboard the satellite.

My friend told me the satellite lasted about 6 months but didn't do very much, so we might get more useful information about temperature and radiation tolerance than what antenna or battery to use.

I don't know much about this kind of stuff, so I need help from you guys. What questions should I ask him when I manage to arrange a meeting with him?

I don't think that a crowdfunding campaign can raise enough money for a mission into LKO, unless you take some drastic measures. Do you have any backup plans for funding?

It has been done before, and we're trying to make everything we can ourselves to reduce costs when possible.

[MBobrik]

Yay! We've settled something! Updating the doc now!

Great, so computer will be Raspberry Pi, which will only be used occasionally, and then a rad-hard 8051 backup always on auxiliary one? Is that the plan? As for single events, there's still a small chance the Pi will be fried while in use. Are there ways to avert this? This is mission-critical, remember. Like only using the pi at night (orbital night, that is), or is that useless? Or maybe turn it off when power surges occur, is that feasible? I know nothing of Raspberry Pi but would love to learn, if anyone here does.

First, it will be the 8051 flight computer that is the main one. It will be permanently on, and in charge of keeping the spacecrafts orientation and rotation, managing the power supply, collecting the low volume data like chemical sensors, transmitting and receiving low bandwidth data, and switching the media CPU on when needed, and eventually giving it access to the transmitter to transmit stored high volume data.

The media CPU will be the raspberry pi compute module with two cameras, both the raspberry pi camera module ( as it got direct support for 2 cameras at once, and an additional camera costs mere $25 ) , one internal camera with microscope optics and IR capability, to observe the sample, and one external camera for shooting cool videos, and perhaps an yet unspecified additional experiment.

None of this is rad hardened, so its main line of defense against radiation will be playing possum - for timelapse videos of the moss it will be powered only for say 500 miliseconds each minute (we will have to hack the boot sequence so that only what is needed for the camera will be loaded in this case ), switching it on only at certain positions in orbit got no sense because inside the magnetosphere there is not much difference.

Another option to consider would be adding two redundant media CPUs ( which means cost additional ~ $120 and ~ 20 g weight ). If they both survive, towards the end of the mission, we could switch them on both at once, to shoot stereoscopic timelapse. ( and during release to have a cool 3D video, if we deem it worth )

Further question @Mazon Del.

How scientifically valuable are normal color timelapse video vs IR timelapse video vs both ? What, if any, added science value would have stereoscopic 3D timelapse ?

How big were the scientific loss if we lost all imaging capability say in the middle of mission, and only the numerical sensor data would remain ?

I would like to support C/S band, but that requires an expensive transceiver and a proper tracking station. If we get budget for it, it would be nice. A good stretch goal? But we need to plan to make do with UHF. That will work as fallback in either case. Cannot hurt to plan support for broadband ops on media CPU, though.

So K^2, how are we doing for power demand? We now know an 8051 will be always on, and a Raspberry Pi (which model?) sometimes. Orbit will be similar to ISS's (right?). Transmitter is either really puny or 40W one (stretchgoal). How much would each cost approximately (small vs large power generation/consumption)?

I've done some quick estimates...

First I started with a module with known params, namely the 433 MHz transceiver module sold as rasp pi/arduino accessory. It got :

110 kbps

Power 5 dBm

Range 300 m

To have reasonable communication window say 2 minutes, at orbital height 430 km we will have to extend the range to cca 430 *sqrt(2) kilometers,

which mans adding cca 66 dB to the signal.

First we amp it up to 10 W ( I don't believe we manage to cram an 40 W amplifier or more into the sat ) which leaves us with 41 dB on the demand side

A good low-noise amp on the ground will give us cca 17 dB.

26 dB remain. Which is in the ballpark of a really good and thus proportionally highly directional high gain antenna.

If we manage to keep the satellites axis perpendicular during transmission, we can emit not omnidirectionally, but in a torus (like Herz dipole), we can shave off another 2.5 dB,

and if someone designs an antenna which emits in a thinner torus, we might get say 7 dB on the transmitter antenna side which would leave us with cca 19 dB, so still a directional high gain antenna would be needed.

I don't think we can go without tracking the satellite on the ground.

Of course antenna aperture increases with square wavelength. Thus going for 155 MHz would shave 9 dB. But the antenna would have to be proportionally bigger,

which is not a problem on the ground, but fitting a proportionally bigger antenna on the satellite would be next to impossible, and a small antenna would negate any dB gained.

So either someone can design for us a cca > 7 dB gain @155 MHz antenna that radiates in an uniform flat torus, and is small and light enough to be fit into 1U cubesat, and yet robust enough to survive it spinning at > 80 rpm ( and changing the spin direction ), or we have to go with 433 mHz and a high gain tracking antenna on the ground.

Edited December 1, 2014 by MBobrik

[MBobrik]

Guys, I was talking to a friend of mine who's an amateur astronomer and he told me about Colombia's first satellite (didn't even know we had one), which was Cubesat called "Libertad 1" launched on 2007 on a Dnepr-1. The interesting thing, though, is that one of the engineers from that project lives on my city and is a friend of my friend, so I might be able to get in contact with him. As far as I can tell, he was in charge of communications and energy storage aboard the satellite.

Any input from someone who has actual experience will be appreciated. Especially someone who did the energy management and communications, as those are two biggest empty white patches on our plan.

Edited December 1, 2014 by MBobrik

[Nicholander]

astropapi1, someone who worked on an actual spacecraft? FANTASTIC! Please, get in contact with them!

[Mazon Del]

Greetings everybody! Sorry about not responding to stuff. For the last 10 days or so I was on vacation, so I didn't access the forums much. I'll be reading through the last..10? pages of stuff and compiling a list of what I need to answer later today.

[henryrasia]

Astropapi, great find! Definitely get in contact with him. No need for a proper meeting as of now, I think. Just shoot him an e-mail talking about our project and how we would appreciate his help.

MBobrik, that's for comms budget, which I don't really have the knowledge to comment on but thanks for making them!* I meant our power demand, because K^2 was working on them for some time now, and we got nothing to work with as of now so we're waiting on that.

And Mazon Del, welcome back!

*For this kind of cross-conversations confusion I suggested having our own, neatly organized subforums/subreddit .

Edited December 1, 2014 by henryrasia

[bounding star]

once again, how are we planning to align the craft with the sun in terms of sensors and manoeuvring algorithms? Also, i think that all the craft's functions should be programmed in pre-launch, so that all we have to do is receive data rather than control it as well, which should save on transmitter power

[LordQ]

Spin stabilisation should be sufficient, if that's what you mean, bounding star. I might have a look into that actually, I'm kind of curious about it myself.

I think we can consider preprogramming only, but that's inherently risky isn't it? We should probably only consider that as a last resort if it saves us space or power we can use for something else.

Edited December 2, 2014 by LordQ
fixed typo

[NERVAfan]

I don't think that a crowdfunding campaign can raise enough money for a mission into LKO, unless you take some drastic measures. Do you have any backup plans for funding?

It's been done several times before, and the KSP connection probably gives us a very good chance.

[K^2]

Just came back from Eastern Europe (long trip), so my brain's a bit of a mess.

MBobrick, I'll go through the numbers on transceiver. Unfortnately, I have some blanks in the area, but I can do some rough estimates to at least give a ball-park confirmation.

Yes, both Pi and flight computer will need direct access to transceiver. In terms of pre-programmed actions, I think I'd like to have a job queue of some sort that new messages are added to. That way, we can pre-queue a bunch of reports, so if something happens to receiver, we have the sat reporting in every once in a while. But that's something we can look at much later on, when we have a hardware mockup and start playing with software.

Speaking of, I think I'd like to add an optional 3rd CPU to the list. I have some PIC MCUs I've worked with before that are fantastic for doing USB communications. I want to have a slot for one on the board. That slot will be empty in the live sat, but the PIC sitting there will be able to mimic all of the sensor input. That way, we can do full hardware simulation on the live board.

Finally, on the power requirements. I still have one big item to account for, which is thermal regulation. I'll need a few days to go through all of the configurations we've talked about and come up with the budget. I have a feeling that this will be the biggest "always on" draw. Naive estimates result in much too much power required to prevent the sat from freezing during the 45 minute "night". But we do have spin-stabilization on our side. I'm going to play with different albedo and insulation schemes. I have a pretty good idea what to do with the folding pannels configuration to keep it at constant temperature, but it's also the one that has the most power to spare. I'll have to go through other options to see if they are even viable. Expect full report some time later this week.

[MBobrik]

MBobrick, I'll go through the numbers on transceiver. Unfortnately, I have some blanks in the area, but I can do some rough estimates to at least give a ball-park confirmation.

Well, any improvement would be appreciated because my knowledge about design of antennas and RF components is essentially zero. I just googled specs of an existing transceiver and tried to increase its range with other components I've googled.

Speaking of, I think I'd like to add an optional 3rd CPU to the list. I have some PIC MCUs I've worked with before that are fantastic for doing USB communications. I want to have a slot for one on the board. That slot will be empty in the live sat, but the PIC sitting there will be able to mimic all of the sensor input. That way, we can do full hardware simulation on the live board.

Do you already know the specs of the rad hard 8051 ? Because the one I googled is pretty much weak... no inbuilt RAM nor ROM, no USB, I2C and only 12 MHz, so to the rad hard CPU we would have to buy additional say rad hard 32 kB SRAM and flash which would multiply the cost.

And one more question. How agile will the sat be in changing its axis of rotation ? Will it be capable of changing from its presumed sun oriented axis of rotation to one more suitable for data transmission, and back reasonably fast ?

[K^2]

All of the ones I've found are like that. Which matches specs of original 8051. So yes, rad-hard RAM would be nice. We definitely need PROM that can stand up to radiation. Something old-school, probably. Modern EEPROMs tend to be pretty rad-sensitive. Power isn't an issue, though. I'd write low level rotines in machine code directly, so it will be plenty powerful enough to do everything it needs to.

Not agile at all. For large angle adjustments, think more in terms of hours than minutes. The field is pretty weak, and anything that generates subtantial torque fromm it would be too heavy. We'll need either an omnidirectional antena, or multiple dipoles. Might be possible to switch between dipoles as the thing spins though? That could save on power. But it's likely to create dead zones, so omnidirectional might be better despite horrible waste.

[bounding star]

Spin stabilisation should be sufficient, if that's what you mean, bounding star.

actually, what i was wondering how we align the craft with the sun after launch and correct from any error. we would need a sensor and the craft would have to make these corrections automatically.

[RobotsAndSpaceships]

It's been done several times before, and the KSP connection probably gives us a very good chance.

Could I have a source? And you didn't answer my question. Do you have a backup plan for funding?

[MBobrik]

All of the ones I've found are like that. Which matches specs of original 8051. So yes, rad-hard RAM would be nice. We definitely need PROM that can stand up to radiation. Something old-school, probably. Modern EEPROMs tend to be pretty rad-sensitive. Power isn't an issue, though. I'd write low level rotines in machine code directly, so it will be plenty powerful enough to do everything it needs to.

I've found some hardened MRAMs, the smallest around ~ 1 MBit ( 16 bit x 64k ), which would be ideal for our purposes, but found no price. I guess, it can't be that high because they are already selling 16 MBit and 64 MBit chips.

Not agile at all. For large angle adjustments, think more in terms of hours than minutes. The field is pretty weak, and anything that generates subtantial torque fromm it would be too heavy. We'll need either an omnidirectional antena, or multiple dipoles. Might be possible to switch between dipoles as the thing spins though? That could save on power. But it's likely to create dead zones, so omnidirectional might be better despite horrible waste.

Can gross rotation changes be sped up by deliberately shifting weight to cause precession ? Something like small rods extend diagonally, the craft start precessing because of uneven mass distribution, when it hits the desired axis of rotation, thre rods retract and thus the precession stops.

[K^2]

actually, what i was wondering how we align the craft with the sun after launch and correct from any error. we would need a sensor and the craft would have to make these corrections automatically.

Yup. One of the main functions of the fligh computer will be looking after spin axis. This will be acomplished with a suit of sensors and magnetotorquers. We might be able to get additional info from media computer and its camera.

I've found some hardened MRAMs, the smallest around ~ 1 MBit ( 16 bit x 64k ), which would be ideal for our purposes, but found no price. I guess, it can't be that high because they are already selling 16 MBit and 64 MBit chips.

Sounds good. I could find creative uses for that extra memory, too. Like, writing to multiple chips at once and having RAM error-checked that way.

Can gross rotation changes be sped up by deliberately shifting weight to cause precession ? Something like small rods extend diagonally, the craft start precessing because of uneven mass distribution, when it hits the desired axis of rotation, thre rods retract and thus the precession stops.

You can use this to quickly flip the craft, but not change the actual axis of rotation. Conservation of angular momentum means that you need external torque to change rotation axis. Without RCS, magnetic torque is by far most significant, and even that will take a while.

demonstrates the concept very well. Since flight computer will be looking after rotation, we could make it intentionally unstable, and quickly re-orient the cube relative to the axis of rotation, but that doesn't seem to be terribly helpful if axis itself stays put.

It's also going to be trouble if we have deployable pannels that we cannot retract prior to such maneuver.

[dharak1]

Turns out a university in my city is launching a cubesat soon. From what I've seen it looks like it's going to be a 3U. Interesting that they happen to be planning at the same time as us.

[NERVAfan]

Could I have a source?

https://www.kickstarter.com/projects/575960623/ardusat-your-arduino-experiment-in-space/posts

https://www.kickstarter.com/projects/880837561/skycube-the-first-satellite-launched-by-you/posts

https://www.kickstarter.com/projects/zacinaction/kicksat-your-personal-spacecraft-in-space/posts

And you didn't answer my question. Do you have a backup plan for funding?

I don't know what kind of backup plan could be viable.

Finally, on the power requirements. I still have one big item to account for, which is thermal regulation. I'll need a few days to go through all of the configurations we've talked about and come up with the budget. I have a feeling that this will be the biggest "always on" draw. Naive estimates result in much too much power required to prevent the sat from freezing during the 45 minute "night". But we do have spin-stabilization on our side. I'm going to play with different albedo and insulation schemes. I have a pretty good idea what to do with the folding pannels configuration to keep it at constant temperature, but it's also the one that has the most power to spare. I'll have to go through other options to see if they are even viable. Expect full report some time later this week.

Yeah, the thermal stuff will be critical. I'm eager to see what you come up with.

[MBobrik]

You can use this to quickly flip the craft, but not change the actual axis of rotation. Conservation of angular momentum means that you need external torque to change rotation axis.

Yeah I see. the axis would just reset after the weight balance is restored. Conservation of angular momentum.

Switching between 4 dipoles would give us ccca 1.46 db over omnidirectional. The best solution would be, if we could get a directional antena, and rotate it to keep it aimed.

.

[Nicholander]

K^2, sorry for the unrelated question, but how are you doing on the power requirements? Any info on that would help, really.

[MBobrik]

Well, I did a few calculations myself. but not about power usage. I tried to compute the maximum angular acceleration we can squeeze out of the magnetotorquer. And came to some very interesting numbers and very interesting ideas.

The BIG number first. If we use some very unorthodox solutions, we may get angular acceleration up to 50 RPM/min at 10 W power and the magnetotorquer coils weighting 5 % of the total mass of the spacecraft ( assuming that the sat got relative permeability ~1 ). Which means we would be able to change the spacecraft's axis of rotation within a few minutes, and thus be able to reorient the sat from its usual sun basking orientation, do high speed transmission via a a directional high gain antenna, and then turn back. Now comes unorthodox solutions part.

It would require beryllium wire, and the magnetotorquer would have to have a very unconventional shape - three orthogonal circular coils with diameter 2.25 times larger than the cube's side. Which means it would have to be folded, and expand to its full shape after satellite release. Either by spring action, or something more exotic like shape memory polymers.

Now the maths. I won't write the long tedious derivation here, just the resulting formulae.

AngularAcceleration = B * √(P) /√(Ic) * 1 / √(20*ÃÆ’*ÃÂ) * Q

where

Ic is the inertia momentum of the rest of the satellite without the magnetotorquer Ic = 1/6 Mc * L^2, where

Mc is mass of the cubesat without the torquer and

L is size of the cubesat

B is magnetic field

P is input power

ÃÆ’ is coil material electrical resistivity

ÃÂ coil material density

Q is a dimensionless constant that describes how well is he magnetotorquer matched with Ic of the rest of the satellite. It runs from 0 = useless to 1 maximum = perfect match.

Of course we are aiming at perfect match Q = 1

Q = 2 * √(q) / (1+q)

where the small q is the ratio of magnetotorquer's inertia momentum It to the inertia momentum Ic of the rest of the satellite q = It / Ic

We can see that Q reaches maximum 1 when q is also 1. Of course we want not that the torquer weights half of the satellite. Therefore we will have to make up with its diameter.

It turns out that the torquer coil diameter can be easily computed from the mass fraction of the torquer.

d/L = √( 4/15 * (1/f -1) )

where

d is torquer coil diameter

L is cubesat's size, same as above

f is the torquer mass ratio f = Mt / M

we say f = 5 % so we get that d = 2.25 times cubesat's size, which means it will have to be stored folded and unfold around the sat, but it's not as dramatic as if we needed it to be say fifty times sat''s diameter.

Now back to the original equation. We can see that in the 1 / √(20*ÃÆ’*ÃÂ) factor both resistivity and density of the coil play equal role, so we should not simply choose the least resistive material, but the one which has the least ÃÆ’*ÃÂ. After a short search, it turns out, that the best feasible material is beryllium, which beats copper with 157 % more acceleration, all other things being equal.

Now, let's put all the numbers together

B = 4e-5 T

Mc = 1Kg

L = 0.1 m

P = 10 W

ÃÆ’ = 3.6e-8 Ωm

ÃÂ = 1690 kg/m^3

Q = 1

we get AngularAcceleration = 0.014 rad/s^2 = 51 RPM/min

.

Now back to waiting for K^2 and his numbers. If someone is interested in verifying my numbers, I would appreciate that very much, because, well, it look too optimistic to me.

Edited December 3, 2014 by MBobrik