Use this space to cheer the creator along, ask questions, and talk to your fellow backers. Please remember to be respectful and considerate. Thanks!
We're in the final stages of putting together KickSat-2 for what will hopefully be a March 2016 launch. I'll be posting more soon. In the mean time, I've posted some recent stuff on my twitter account: twitter.com/zacinaction
Hope your dissertation writeup went well.
What's the latest on the KS2?
Thanks for posting that Ben. Sorry for not keeping everyone updated here as often as I should. I'm really busy right now finishing up my PhD dissertation. I'll be working on KickSat-2 full time this summer, so stay tuned for more updates in a few weeks.
Make: interviewed Zac last month. Great recap of the KickSat mission and what's coming with KickSat-2 -- https://www.youtube.com/watch…
It looks like KickSat will re-enter the atmosphere shortly, just a couple days short of a possible Sprite release.
Jon Mikel has been posting decay predictions in the KickSat Google group, his latest indicates re-entry might be around 23:44 UTC +- 5 hours.
First telemetry packet has been received from The Netherlands. KickSat is up and running!
KickSat should soon be approaching the US west coast (in 5 mins according to the CalPoly's preliminary keps). Hopefully we'll start getting reports from people picking up its telemetry.
Zac has been tweeting updates: https://twitter.com/zacinaction
Any place we can find out details? Did the KickSat deploy successfully?
And we are now in space!
Best of luck with the launch Zac.
Info will be up in the next day or two. Check the updates section.
What's the word on ground stations, Zach?
Yes, we've actually been making good progress signing up ground stations at schools and met with two different groups yesterday. I'm also still trying to work out a web-based system for collecting recordings. More to come after the holidays.
Have there been any developments for ground stations and combining the expected received signals?
There are some fully assembled KickSat pictures floating around in the updates: http://www.kickstarter.com/projects/zacinaction/kicksat-your-personal-spacecraft-in-space/posts/591851
I'll take closeups so everyone can see their engravings soon.
Great work. Could you post fully assembled pictures and everyone's engravings soon? Thanks.
Good evening Zac.
Here is my code submission:
Not much more fits into memory! Packet type 7 in the Encoder class is my favorite - with a tribute to a childhood inspiration.
We'll publish a packet decoder suitable for use as a web service too.
Thanks again Zac!
-Wes, Don, and PTS.
This is my code submission:
It's pretty simple, based on your example code. I played around with a lot of different things but just went back to something super simple.
I had some problems with the GNURadio Sprite receiver but found a solution here:
Let me know if you need anything else or have any comments.
I will put in the PRN codes on all of the Sprites. You can leave the ones in the example code.
Will you be sending us the radio gold codes or will you modify the code yourself?
I am also pleased to provide two links that could prove useful for GNUradio:
1. A CD ISO for a bootable version of Lubuntu with GNUradio installed.
2. Updated instructions for loading GNUradio on Windows 7 and 8.
Andrew and the BIS team (particularly Laurence for these two).
Hello again Zac,
A final version of the BIS Sprite code has been uploaded to GitHub:
Our code has 3 main sections:
1.Transmitting the temperature readings from the main processor and the gyroscope in Kelvin so we don't have to deal with minus signs. (See line 372 in the "Sprite Main" final code).
2.Transmitting the session information. This includes the minimum, maximum and average session durations as well as the number of times the sprite has started up. (Line 260).
3.Transmitting the results of a memory integrity test. Segment B of the flash memory is filled with 1's. The sprite will then transmit the number of bits which have been flipped to 0's. (Line 434).
Andrew and the BIS team
The receiver noise figure is based on using one of the RTL USB dongles, which have extremely poor noise figure. There are numerous tricks documented online to help get the noise down in those, but I've found that the most effective and easiest thing to do is to simply use a good external LNA. If you want better performance, invest in a better SDR, like one of the USRPs from Ettus.
Why does the link budget ( https://github.com/zacinaction/kicksat/tree/master/GroundStation ) have such a large figure for Receiver Noise Factor?
Yes, there is another good LNA source in the US. Check out the L432LNA from Down East Microwave:
Back in Update #27 you mentioned using a an LNA from dg0ve in Germany. Did you ever find another source for this or something to use instead from the US?
You are free to transmit your data however you like as long as you use the SpriteRadio API. The API handles all of the encoding for you and makes sure that the Sprites play nice together. There aren't any particular restrictions, but I'd recommend keeping things short as the data rate is very low.
I'm just trying to finish up my code for the 09/01 deadline. Is there a special format I should use to transmit data other than the SpriteRadio functions provided? Any limits, guidelines or standards I should be following as well?
I have not played with the temperature sensor much. If you develop some code for it and wouldn't mind sharing it on GitHub, that would be great.
Did you experiment with the integrated temperature sensor in the MSP430 CC430F5137 microcontroller, or do you know if any of the other developers are doing anything with it?
I wonder what it would tell us about the Sprite itself when deployed in space and as it descends to Earth.
Animating the data with a 3D model would definitely be cool. Let me know how it goes.
Yes, I have the Sprite output in Excel - all the movement on each axis is pretty much as I expected. I was surprised by the spikiness of the output, but have found some guides for normalizing the data. I will also experiment with rudimentary normalizing before transmission (not forgetting that power will be intermittent).
It would be great to get the data linked to a 3D Sprite model. This seems feasible, so I will add it to to-do list as a 'nice to have' (and will share if it gets done).
I've just been formatting the sensor output as text strings and printing them to the console for debugging purposes. You can easily import the formatted text into any program you like (Excel, MATLAB, etc.).
What software are you using to plot the output from the sensors?
That's a lot of questions - here are some answers... The solar cell voltages will not actually tell you much of anything. Solar cells are basically diodes and have a constant voltage during normal operation. The voltage will either be 2.2v or the microcontroller won't be alive to read the voltage. A single ground station can indeed receive data from all overhead Sprites. The format for the data packets is already set - if you use the software receiver we've developed it's already baked in. The Sprites transmitting initials can also transmit sensor data. Not sure what we'll do there yet.
Hi again Zac.
Can the Sprites read the voltage levels from their solar cells? It seems a solar cell is a large 1-pixel "camera" and if we aggregate readings from many Sprites we just might create some low-res images. Pardon my [temporary] ignorance, but can a ground station receive data from all overhead Sprites? Being amateur band, do we all have to publish the format of our data packets? Any progress on aggregating all packets? Can the Sprites that just send initials also include some sensor data, even if randomly selected which reading to include in a packet? Again, trying to think of getting the most from the Sprite formation not just a single Sprite.
Unfortunately, no. The souvenir and developer boards differ in several ways from the flight units we're currently working on and won't be suitable for flight. Send me an email and we can talk about what you have in mind and how we can possibly accomodate it.
Can we alter our Sprite board and send it to you for launch? We would keep the physical and mass envelope.
I don't have a final date yet due to the fluctuations in out launch date. For now, you can conservatively plan on May, though you'll likely get more time.
When do you need the final code from the developer kits?
Yes, we'll definitely publish TLEs. We'll get initial orbit data from the launch vehicle and I'm working on a solution for updating them.
Will there be keplerian elements publish so I can easily track the Sprites using my AZ-EL tracking antenna array? Anyway to keep the Keps updated during the potential 2-week orbit? My Antenna array can be seen here: http://bit.ly/Xshu7w
You don't have to send me any hardware - you'll just send me your code and I'll load it onto a flight Sprite. Each Sprite has a pair of unique PRN codes corresponding to binary 0 and 1. There aren't any constraints on bytes per packet, but keep in mind the data rate will be very low (on the order of 1 byte per second). All the TX stuff (encoding, etc) is handled by the SpriteRadio.transmit function, so all you have to do is pass it a byte array to send.
Been playing around with my Sprite Dev Kit for a week or so now mainly as a transmitter to get my groundstation up and running. When will the Dev kit backers need to send their sprites back to be ready for launch, or do we just submit our code to you to load on another Sprite for launch?
So each sprite will have its own spreading code on the tx channel - are there any constraints as to how many bytes per tx packet or how often we can send data?
Sorry - I should have posted about this before. It turns out that our solar cells are export controlled under U.S. law (because they are high-efficiency "space grade" cells). Since many of our backers are located outside the U.S., rather than trying to wade through paperwork and risk getting in trouble, I decided it was best to leave off the solar cells. The rest of the board is still fully functional. I'll post a how-to guide after the holidays for those who want to experiment with programming and modifying their souvenir Sprites.
Hi Zachary. I received the souvenir board in the mail the other day. Thank you.
Some of the earlier posts suggested the board might have a solar cell and working LEDs. Is this still the case? If so, the one I have lacks the solar cells, would adding them power the chip and LEDs? Or does it require some sort of software update also?
Hello everybody, The family is getting quite excited over here! We did not receive our survey, can you re-send to us please? Many thanks and GOOD LUCK. The Inwood family.
Hi Richard and Bookazoid,
The souvenir boards will be "real" boards, but they will not be fully populated. As Richard suggested, the goal is definitely to learn some things and iron out any issues before we make the flight units. The souvenirs will have the flashing LEDs shown in update post 13 in leu of sensors, and the RF crystal and antenna will not be populated. So, to answer Bookazoid, you won't be able to use the board with your SDR setup as shipped, but with some soldering and a couple of parts from Digikey you could (check the schematics on GitHub).
I had always thought the souvenir boards would be the fallout from the real board run. didn't expect a "working" board. hope you learn some things about real board from this run.