Adobri Solutions Ltd
   Donate to history was removed        P2P web search portal    


AUGUST 19, 2013 01:10 AM Update.

Two words: 3D printer, GPS/Galeleo

Mar 6, 2013 Now, after communication system design done, it is the time to place everything together

In development Craft's /CubeSat's Mission Control. Follow link below.

ON MAY 06, 2013 11:41 AM One checkbox implementation in web interface

One checkbox implementation in mission control web interface - real-time data for orientation vectors for ground station antenna. == Same xml file used for visualization of a CubeSat trajectory, also used to feed antenna control. .
TRA application now can accept data in XML format from a remote, dynamically created "initial" position, and post results of trajectory calculations back to the same or even different server. That future allows to calculate trajectory and engines firing time in parallel via distributed calculations network. Probably the same mechanism can be used in screen saver app.
details on

ON APRIL 28, 2013 01:27 AM  Communication, sat's trajectory simulation.

Communication, packages of commands, re-design from standard modem communication implementation, flush memory buffer to speed up data transfer, triple flush memory with majority voting (protection from radiation damage). Visualization of calculated trajectory in simulator to generate commands for (a) ground station and (b) craft/cubesat. GPS satellites traject's simulation for proper calculation of a craft/ground station positions.

ON APRIL 20, 2013 11:46 PM Overview of mission control

Last week's changes

on -

ON MARCH 19, 2013 02:15 PM Ground Station communication.
Part of the software is It is interface hub talking via communication port to a ground station’s 2.4Ghz communication system and controls. From other side it communicates with a SatCtrl website to provide session’s data to be stored and processed. Via ground station's 2.4ghz system GrStn communicates to a satellite controls, sensors, and data storage. Download of a latest executable module on a page “About” of a SatCtrl.
Difference in packet type – for Cubesat/craft uplink type=’1’; for cubesat/craft downlink type=’2’ for cubesat/craft broken packages type= ‘3’ , for ground station uplink control type ‘4’, for ground station downlink type = ‘5’. Posting to SatCtrl- done, parsing response from satCtrl –TBD, POST from satCtrl –TBD, comm reading/ writing threads -TBD.

MARCH 15, 2013 12:51 PM "Communication session" DB.

Thanks, Serg, MySQL is not really my, but yours. To my pleasure language is different from another SQL. StorProcs are different, has a problems with integration to VS2010 and etc. All are hard to learn in one day. Pros- for MYSQL - according Victor - available MS product has limitation - on size - for big DB needs to pay in 3 zeroes, another plus for MySQL- according Boris MySQL perfectly can holds gigabytes, especially on SSD. Cons- According to Victor - time to be spend will the same as pay for commercial product in same 3 zeros.
All what needs from you are - to store from a “ground- station- control- computer” via web interface (i.e. page Post.aspx) record into a table in "Communication session" database with fields (a) session identifier (b) type of record ("uplink"/"downlink"/"downlink-was-with-error) (c) packet number (d) station identifier/backup channel (e) variable data size and two times (f) time of WebControl (g) time of send/receive via ground stations. Simple and non fancy. Also need to have one BD per one table.

I'll take care of”listening" software on a ground station computer. It is includes control for a ground station antenna / rover, and transmitter/receiver.

For you- via web interface (you can see "mockup" page GroundStation.aspx) will be set addresses and another parameters for station control computer. Then on a page
CraftCubeSat.aspx will be formed commands to be sent to a craft/Cubesats. Click on "send" button initiates transfer of uplink data to IP connected GrStn computer (that will be my headache to post/get data from one web server to GrStn software). GrStn software accepts command and send it to uplink (or to Azimuth / altitude controls, GrStn diagnostics) and posts back to website one records with a new session number, "uplink" / "GrStn_control" / "diag" type, GrStn number, "real" send time, and with packet's number is 0. As a result in DB will be exactly what send to uplink was. Then response (downlink) received on a 2.4Ghz communication will be posted as a second record into DB. Difference is a received time, packet number, and type. One "uplink" can creates many "downlinks". If packed can not be restored by algorithms inside communication system's microprocessor, then record will be with type of "downlink-broken-record". New uplink reset packet number to 0 and assign new session number. Another page to view (list) is a SessionData.aspx on it will be possible to visually check data.

That approach makes initial data to be stored as its. Any derivatives like retriving video or pictures or telemetry can be done separatly from a process of communication and control. Broken packages (impossible to restore in real time) can be restored later (using hash algorithm's matching). In that case additional record (of a restored packet) will be inserted additionally to a original broken packet. All addons can be done separatly, independently, and from different distributed processing computers.

I need for tonight: (a) Post.aspx page (needs to strip site.master's copy, long responce from IIS is not nessesary) (b)another page (for testing and manual entry) SesionPost.aspx (c) C# code for MyrSQL data insertion (d) visualization DB page Sessiondata.aspx (e) StorProc to get new Session number (table do not have "uniqe key" field or whatever terminology used in YourSQL).
SatCtrl web server available from link on a page If it is not working then ether – I am debugging, or give me a call I’ll reset server.
thnks Serg. Well done. Just to small remind - I need StoreProc. Friday - Are you coming to Korean БАНЯ? I have beer. I have to pick up next portion of just printed lunar money and then we can go.

ON MARCH 12, 2013 11:37 AM Software.

Finally software to be taking care – to get landing page of Craft/Cubesat Mission Control click on link “Craft's /CubeSat's Mission Control. Follow link below” from the page
Source code for mission control RL
Source code for main processor managing GPS, Camera, HD Camera, backup communication is
Source code for 2.4Ghz communication on
That code (I hope) will changed a lot in next 2-3 weeks.
All sources code and 3D designs are on

Feb 21.2011. RFM

When you meet your physics teacher 30 years after the school, and old man told that he do not remember how did you study physics in his class, it mean only one – needs to be careful with anything related to a physics. Specifically needs to RFM old lectures – gravitational potential is a scalar value, to get force from gravitational potential needs to get partial derivative. Particularly:

 U (gravitational potential) =  sum of Unk = fm/r (r0/r)**n Pnk(sinTetta) [Cnk*cos(k*lambda) + Snk*sin(k*lambda). Where Tetta is a latitude and lambda is longitude. Cnk/Snk is a constants from a model. fm= G*M, and r0 is equatorial radius. Partial derivative is (page 90 from Akesenov’s lectures

 Then: Unk separates into 3 parts:

(part 1) Rn(1/r) = fm/r *(r0/r)**n

               derivative => Rn(1/r)' = (n+1) * fm * r0**n * (1/r)**n = (n+1) * fm * (r0/r)**n)

    on a page 12 is (it is kind of hard to write formulas in C code)

    Pnk(sinTetta) = (1-sinTetta**2) ** (k/2) * dk (Pn(sinTetta))/ d(sinTetta)**k

                  = cosTetta **k * dK(Pn(sinTetta))/ d(sinTtta)**k

    now cosTetta**k separated from Pnk(sinTetta) to get clear part 2 and CosTetta**k will end up at part 3.

(part 2) Znk(z/r) = dK(Pn(sinTetta)/ d(sinTetta)**k =

             = Pnk’[n][k] 

   Derivative  => Znk(z/r)' = Pnk’[n][k+1]

   also in (part 2) for K == 0 is:

   Zn0 = Pn(sinTetta)

   Finally cosTetta goes to a last part:

(part 3) Qnk(x/r,y/r) = cosTetta**k * [Cnk*cos(k*lambda) + Snk * sin(k*lambda)]

            = [Cnk*cosTetta**k * cos(k*lambda) + Snk * cosTetta**k * sin(k*lambda)]

            = [Cnk* Xk + Snk*Yk] and

   Xk = (cosTetta)**k * cos(k*Lambda)  Yk = (costetta)**k * sin(k*Lambda)

   or recurcevly:

   X0 =1, Y0 = 0

   X1 = cosTeatta * Cos(Lambda) = x/r; Y1 = cosTetta * sin(Lambda) = y/r

   X[k+1] = Xk * x/r - Yk* y/r  Y[k+1] = Yk* x/r  + Xk * y/r

 D(Unk)/D(x) = d(Rn) / d(1/r)    * D(1/r)/D(x)    * Znk    * Qnk + Rn * d(Znk)/d(z/r) * D(z/r)/D(x) * Qnk + Rn * Znk * [D(Qnk)/D(x/r) * D(x/r)/D(x) + D(Qnk)/D(y/r)*D(y/r)/D(x)]

 D(Unk)/D(y) = d(Rn) / d(1/r)    * D(1/r)/D(y)    * Znk    * Qnk + Rn * d(Znk)/d(z/r) * D(z/r)/D(y) * Qnk + Rn * Znk * [D(Qnk)/D(x/r) * D(x/r)/D(y) + D(Qnk)/D(y/r)*D(y/r)/D(y)]

 D(Unk)/D(z) = d(Rn) / d(1/r)    * D(1/r)/D(z)    * Znk    * Qnk + Rn * d(Znk)/d(z/r) * D(z/r)/D(z) * Qnk + Rn * Znk * [D(Qnk)/D(x/r) * D(x/r)/D(z) + D(Qnk)/D(y/r)*D(y/r)/D(z)]

 All Rnk, Qnk and it’s derivatives calculates recursively, on page 91-92 presents formulas to get partial derivatives for D(1/r)/D(x) and etc. At the end needs to move out of brackets for each partial derivative values fm * x/r**3, fm * y/r**3, fm*z/r**3. And explanation of a stupidity of Alex Dobrianski shines up – in a C code J2 constant really bigger 10 times for 75 degree(just coincident normally it bigger 3 times), in Fx,Fy presents sin(co-latitude), in Fz presents cos(latitude)**2 / sin(latitude), and error drops from 30km to 685m. Needs to read (couple of times) manual (lectures) does not matter how many pages in it.


Feb 1, 2011. For a simulation of a correct position calculations needs to develop a software with 3 simulation satellites on different orbits with a simulation probe calculating distances btw a probe and satellites with a random (set by some parameters) error. Output must be in ID 28 ID 30 format (a floating point). The output fill be stored in onboard storage. Then main onboard computer (backup too) can have access to the data – to process and to calculate current position. For a calculation of a such position enough to calculate Kepler’s elements of a probe’s orbit in a moment of time in a past.

The Simulation software will be based on an existing Sun-Earth-Moon-satellite simulation package developed for a probe’s orbit/flight-path calculation by adding 3 more bodies (satellites) to simulate. A random error will be introduced to estimate correct orbit’s calculation time, and a possible error in a positioning.

Formulas for calculation at :

And at:

Also useful formulas at:


Astro-orientation and gyro-orientation system design and requirements.


It is impossible to do a mission without the ability to orient probe in flight, to calculate position, orientation, center of gravity and speed of a probe. All this is a task for orientation system. Modern technologies allow the use of compact gyroscopes to detect probe's X-Y-Z axes orientation, cameras to make pictures of starts, infrared sensible sensors (cameras) to calculate celestial’s bodies horizons, computers to make calculation and predict location of a probe.

For a prime orbit’s Keplers elements calculation considered to use GPS receiver. It is unknown for now how GPS receiver will perform on flight with speed around 10km/s. Investigation should be done but data from experiment on satellite position calculation was already done and published.

GPS raw data from a SiRF capable receiver with records ID 28,30 will be enough to produce current positions of observing satellites (ID 30), and distances to it (ID 28). Moment of each observation will be recorder in real time. Analyzing data with assumption that orbit is ellipsoid lay in one plane can give data to calculate major axes and parameters for a plane. Algorithms first will approximate plane direction (inclination, longitude of ascending node), then major axes (eccentricity, argument of perihelion) , then point on an ellipse can be calculated to get mean anomaly.

Kepler’s elements needs to be assumed stable (atmospheric influence will be small and can be accounted) that limitation will give constrain on errors sampling GPS raw data. For testing formulas and algorithms on a ground prior launch can be assumed that initial plane is defined by north/south/some-equatorial points, major axes not equal each other and equal earth radius. Then algorithms should produce plane parallel equator and point with location of a receiver, and major exes will be equal radius of calculated plane.

Different type gyroscopes was investigated by parameters and tested. Results give requirements for gyro-platform design, which include temperature restriction, functionality, location, precision, data bandwidth requirements. Precision of a collected data should give requirements for high-thrust engine and low-thrust engine. For example: delays in gyroscopes sensor’s calculation and delays in orientation’s controls motors can create unstable thrust’s vectors, and compensation by reducing thrust must be apply.

Performance in vacuum, in different temperature conditions, under stress of vibration, at landing impact have to be tested. Performance of different lenses (plastic, glass, diaphragms) for different wavelength has to be performed. Power consumptions, assembling capabilities, supporting electronics have to investigate and consider in requirements for probe’s imaging system. Data capabilities / compression capabilities of supporting electronics has to give requirements for Communication system and Data Transfer system.

Position, orientation, speed, centre of gravity of a probe will be stored in 3 separated location. This will include computer's memory and non voltage memory. Verification, calculation and correction of position + orientation can be update by astro-orientation, gyro-orientation system and from mission control. History data of position and orientation enough for on board calculation should be stored in on board computers and can be update/corrected by mission control.

Probe’s orientation on all stages must be  able to execute 4 different tasks:e 4 different tasks:

- centre of gravity positioning, for orientation at main impulses engine’s firing;

- centre of gravity positioning, for changing vector of thrust for low-thrust engine;

- probe’s rotation in axes X-Y-Z before engines firing;

- probe’s rotation in axes X-Y-Z of a probe's manipulator(s), antenna(s), tools, engines components positioning.

All orientation commands have to be done by (a) main on board computer; (b) backup on board computer; (c) mission control. In an absence of communication with mission control all pre-programmed orientations targets will be executed. Mission control can specify source for control devices either with on-board computers, or mission control itself, all settings for all control devices must time out to execute, first-in-last-out fixed size command stack with default (top-of-stack) command's values.

Reference for SiRF can be found at

Reference for ID 28 and ID 30 - see the same document.