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 http://www.adobri.com/SatCtrlR.aspx
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 MARCH 19, 2013 02:15 PM Ground Station communication.
Part of the software is https://github.com/alexdobrianski/GrStn. 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 http://www.adobri.com/ProjectGsC.aspx. 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
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
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 =
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)
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
Formulas for calculation 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
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.