48 hours to go until departure

It is now just over 48 hours until we finally will leave on out journey from Stockholm to ESRANGE. We’re still working on our experiment and even if we are getting closer to completing it we still struggle with issues. One examples from the electronics is the sensors in the spheres. Due to problems with miss interpretation of the clock signal  in the spheres we have huge problems with getting the signal from them to the main board where it is supposed to be recorded. Even if we have done some great efforts and been awarded with good progress we’re now at such a late stage that we’ve had to confess that we won´t be able to fly with the sensors in the spheres. This means that we won´t be able to record the dynamics of the individual spheres. Another problem which have raised is the satellite modem. Even if we tested the system as early as during last summer it suddenly have stopped working. What seems to be the problem is that the modem module which is soldered at the flight board isn’t working. We´re now working in replacing it but it has proven to be a challenging task. However we won´t give up just yet.

Another thing we´re still working on is to get a reliable deployment of all four spheres, I´m attaching some pictures of our tries. at this moment we have at least three SCALES which deploys reliable but we have problems with the fourth one.

Thursday – Bench test

As you’ve already seen the hot bench test went quite well at least to begin with. However to tell the story I should maybe start from the beginning. I’ve know that you’ve all heard about this bench test but what is it really? To be honest I’did not really know what it was my self before last week. I’ll try to give you a short explanation. The bench test is can be explained as a dry run of the rockets mission. This means that one tries to run through all the events, from start of countdown till the experiments have reached the ground, that would occur during a real flight. This series of events is usually talked about as the mission time line. In our case we´re a total of four experiments in the same rocket, our self’s, GAGA, FOCUS and M-BEAM. These teams all have their own events during the mentioned timeline.

During the mission each of the experiment is surveilled by one of the members who are using some kind of software at their own computers to do so. In our case it’s me who are using my own developed liveCOM to do so. The data is delivered through a classical serial cable from the main receiver who receives the data from all experiments over a common wireless transmission from the rocket but split it before it is sent to the respective serial interface.

So what happens during these events? For squid parts the timeline look something like this:

T-10m 0s Experiment power on.

T-9m 0s SQUID SOE activated.

T-8m 55s SQUID SOE deactivated.

T-8m 30s SQUID rocket power deactivated.

T-8m 0s SQUID rocket power activated.

T+0m 0s LO.

T+73s SQUID FFU ejected.

After this point no more data is received since there is with the connection the experiment after it has left the rocket. This means that the experiment in it self is only recorded on the on board memory and it is therefore necessary to recover the experiment in order to get access to the data. To do a bench test is a quite nervous thing. I where sitting in front of my computer with a checklist beside me checking of that I perform all necessary actions in the right order and at the right time. In a real situation one would of course be even more nervous, everything happens very quick and the checklist is therefore really important. From this perspective the bench went as a charm. We did however have some problems, these where however due to the fact that the on board software had not been updated for a while which meant that the acceleration profile for the SCALE systems wasn’t as it should have been. We also experienced a power loss at the main rocket power during the first hot count down after our experiment had been ejected. This mean that we lost our video from the rocket mounted camera that where filming the ejection it self. During a real flight this would mean that we would not be able to see the SCALE maneuvering.

Movie from bench-test

Laaadies and Gentlemen, aliens and alienesses!!

SQUID productions is proud (TBD :p ) to present a true action movie full of drama and comedy, the ultimate adventure and sci-fi movie ever, a war-story, thriller and documentary  it is:

REXUS 10 bech-test, a very short summary from Thursday and early Friday.

Enjoy 😀

Day 3 ….. Vibration test….and much much more

After a lot of stress and quick assembling and disassembling of the experiment we finally managed to put everything together after a few changes on the top plate ejection system (which by the way will keep us busy for a few weeks in order to test a new design deeply). One of the problems of vibration is that the screws fall down extremely easily and we have to make sure that all of them are properly secured with a special adhesive, which makes even more difficult and specially time consuming the assembly of the system.

Unfortunately, when everything was ready we found that something was not working as it should as we couldn’t manage to insert properly the umbilical connectors (probably because of a sudden change on the usual assembly procedure) so we were unable to have communication with the experiment, which would basically mean that the vibration test would only allow us to test the structural integrity of SQUID, which in any case was scary enough, specially after the problems we had both with the top plate ejection system and the FFU ejection system.

The next step was to assemble the experiment together with the magic hat in the shaker and place the accelerometers in the different interesting components of the system in order to get the response of the vibration. The test consisted in three different ‘steps’, first a sine sweep, which is basically a sinusoidal excitation of the experiment that is used to obtain the eigenfrequencies of the system without introducing high loads, then the random vibration, which is the real and tough test, as it simulates the vibration levels on the launcher and finally,  a second sine sweep, in order to check if something was broken inside the experiment, as if something got damaged during the random vibration test the responses from the first and second sine sweeps would differ.

As usual we had bad luck. The first sine sweep showed that around 500Hz there was a resonance between the shaker and the FFU, meaning that the signal or the vibration of the shaker would be amplified in the FFU. The worse thing was the magnitude of the amplification, as on the sine sweep seemed to be of 10 times, which was everything but funny. Fortunately, the random vibration test went very well (we didnt see any parts of the experiment flying) and the resonance was finally as bad as expected (the signal was ‘only’ amplified by a factor of 3)  and the second sine sweep was the same as the first one.

The test did show however a couple of minor problems. After the shaking we tested the electronics and the SCALE systems. The electronics were working perfectly, but when we tried the deployment of the SCALEs we saw that one of them was failing. The reason seemed to be that the screw holding the driving gear to the motor shaft went loose during vibration, probably because  the adhesive we were using for the screws was not suitable for plastic (the cogwheels are made of Delrin). Also, and when we removed the e-box we found out that the clamp of the steel wire of the FFU was deattached from the bottom plate (it was originally glued), which means that we will have to make some minor changes on its design in order to be able to screw it to the bottom plate instead of gluing it. In any case, and after all the problems we had during the previous days the test was quite successful.

Mario Valle

Day 2 in DLR Bremen…..Time event simulation

Written by Monica

Today has been a very exciting day, all the experiments in the Rexus 10 (GAGa, FOCUS,M-BEAM and SQUID) were connected together and we simulate the time event, our SQUID communication with the rocket service module is as we expected,for now we just run with  the test mode, i.e. we control everything that happens in the experiment, but tomorrow after a vibration test we will run the mission mode, where the functions should perform automatically.

Of course, watching the experiment working feels very  nice, but it also has represented long days and an incredible amount of work, everything is  small scale and every single screw has its own way to be put.

Right now, the time is devoted to prepare the rope that goes into the cutter that will release parachute… once it is done we can then pack the parachute into the FreeFlightUnit … for 2nd time today 😉

Tomorrow..vibration test..and right after …test ejection of the booms…Lets hope everything works !!!!

Top plate ejection testing

So as (almost) usual we’re at the lab on a Sunday, as most of the testing doesn’t seem to fit in our timetables. However as the sun is not showing up as often as you’d want her to, working seems like a fairly good way of killing time.

So what’s happened is first of all, that we all came in pretty late and somehow tired between 3 and 4 pm. Then we needed some time to find ll the stuff and to remember what we actually wanted to do. Eventually we figured out that we needed some small modifications from Gustav so David and I could do a test on the top-plate ejection system which i a crucial part of the landing system. Hence it is really important that it works cause otherwise the parachute will not open and the experiment might be lost for good.

Our first attempts to test the system failed due to the rope holding down the lock broke while we where still trying to close it. Just as we started to become desperate and thought we’d have to redesign the whole thing Gustav came up with an idea. He suggested to put some tube around the wire at the place where we are joining it with another wire. This “cushion” worked fine and so we consider the Sunday a successful one.


The battle is won but the war is not yet over.

Today SQUID had it’s EAR (Experiment Acceptance Review) which is the last review before delivery. We pushed through limited time, stressfull days, missing components, late workshop evenings, burning electronic boards, short circuited batteries, system failures, moodswings etc. and finally got through the EAR with positive results.

Mikael Inga was visiting us from the Swedish Space Corporation to carry out the EAR and most of the team was present to discuss and demonstrate the experiments current functionality. The day started of at 9:30 in the morning with a check through what has been done on earlier comments recieved from REXUS and what tests we have performed since last IPR.  Just before lunch we started of by demonstrating the functionality and workings of the experiment interface electronics and after lunch followed a more thorough experiment functionality demonstration in which we let the system run through parts of the intended operational phases finally leading to the moment of thruth, the decision. SQUID has passed EAR but as always there are comments and things to care about but nothing came up that we weren’t already aware of.

Next up is delivery and the team will now take the weekend off to recuperate from the last two weeks of battle because on monday we need to pick up the pace even further. Systems have to be fully tested, fligh boards assembled to the ebox and tested, assembly of a second FFU has to start and everyone should be happy and prepared for hard work (at least us slaves have to be) otherwise the big boss will come after us with his grand master-whip which he talks so much about nowadays 😛

Disaster strikes…

Last night actually became a sad story. After all testing and working during last night everything turned out to a small disaster. So what happened really, well we’e not yet entirely sure but I’ll tell you what we observed. Last thing on the task list last night was to mount all hardware in their specified places. Due to that we had been using the eBox (the rectangular middle aluminum box where all the electronic boards are mounted) for some time it had not yet been modified to hold the ovenCutter. This meant that we had to move all the boards to a new eBox. Somewhere here something went wrong cause when everything had been mounted and we tested the communication with the experiment, suddenly magic white SMOKE started to rise out of the eBox. We’re not sure what had really happened but our theory is that during the mounting (which took place at midnight last night) somethng most have been short circuited. This lead to that the MOSFET which is used to switch of the batteries started to boil.


Suddenly white smoke started to rise from the MOSFET

Due to this small disaster we where forced to postpone the EAR until friday. So please wish us better luck for that time.

Busy night before EAR

So today has been busy as always. The day started of with that I (Gustav), Jacob and Amer (from the RAIN team) visited Bergtorpskolan, just north of Stockholm. There we held two lectures which where really well visited. During the first one we had 33 pupils listening and during the second one we had as many as 47 pupils listening on how our project works. This was actually some kind of record for us, we’ve never had as many pupils listening to us during a school visit and of course we loved it! The pupils where all very quiet, seemed interested and asked plenty of question so it was a rather success.

However the main thing about this blog post is not the school visit but instead the much more worrying Experiment Acceptence Review which will be taking place here at KTH tomorrow. The whole team is really fighting to get everything to work in time, and as it looks right now most things will actually work tomorrow. Something which however seems to be a huge problem is the reliability of the SCALE. In the future we hope to be able to deal with it by using more standard parts but since some of the has yet to be delivered they have been custom made in the inhouse workshop. This has led to that the two different SCALE systems really seems to have different personalities and most of the times at least one of them have problems when being run. When it comes to the rest of the mechanical parts they however seems to be on place, and the electronics and software also seems to be in a working stage.

So to end this blog post I beg you all to wish us good luck for tomorrows challenge!

Ground support software

So the time has come to give a brief story about the ground support software (GSS). So what is the GSS? Well, actually it is quite simple to explain. The software used by the SQUID project can be divided into two different main categories. First the software which is loaded on to the probe it self and secondly the software used to monitor and communicate with the probe as well as post flight data analyzes.

The software used in the probe is written in VHDL and will be covered in a separate blog post. In general however one can say that this software controls almost everything that happens on the FFU during the mission. It also logs all sample data from the different sensors onboard the probe.

The GSS consists out of two totally different softwares,readOut and liveCom. The readOut is a Matlab script which reads out the memory data and displays it in form of plots. The tricky thing is to construct a fast script since data is stored in a rate of 2000 Hz while in flight which means that even short tests performed on the probe results in large amounts of data.


A example of how the data can be displayed by the plots genereated from the readOut. In this case it´s the data from the gyros in the eBox.

The liveCom in turn is pretty well explained by its name. The software is run by a computer which druing tests is connected by an old fashioned serial interface with the eBox. While in flight the connection will be wireless and go through the REXUS rockets service module. The software is written in python and makes use of the Tkinter TCL graphical interface. This combination enables the software to be run on a variety of platforms since most platforms supporting Python also suports Tkinter. The software mainly visualizes the low data rate output (LDRO) from the probe but also features a simple interface for controlling the probe which is used during system tests. However the main idea is to provide a fast way to follow the probe during the mission while it´s still in the rocket.


A screenshot from the liveCom software