robertk66 / obc_1769_core Goto Github PK

At least remove the usage of the deb_print_pure_debug() function and replace with 'STR' or 'RAW' event.

But in the end the Thruster module should provide a binary event API. See e.g. this output:

[07:32:12] app/str :' Sequence id=0 start '                                                                                           
[07:32:12] app/str :' Stage SET index= 0 completed '                                                                          
[07:32:12] app/str :' Action 31001:Set Operational Mode 0 '                                                              
[07:32:12] app/str :' Stage SET index= 1 completed '                                                                         
[07:32:12] app/str :' Action 31002: Set Emitter Mode 0 '                                                                    
[07:32:12] app/str :' Stage SET index= 2 completed '                                                                         
[07:32:12] app/str :' Action 31003:Set Extractor Mode 0 '                                                                  
[07:32:12] app/str :' Stage SET index= 3 completed '                                                                         
[07:32:12] app/str :' Action 31004: Set Neutralizer Mode 0 '                                                              
[07:32:12] app/str :' Stage SET index= 4 completed '                                                                         
[07:32:12] app/str :' Action 31005: Set Temperature Mode 0 '                                                           
[07:32:12] app/str :' Stage SET index= 5 completed '                                                                         
[07:32:12] app/str :' Action 31006: Set Reservoire Heater Mode 0 '                                                   
[07:32:12] app/str :' Stage SET index= 6 completed '                                                                         
[07:32:12] app/str :' Action 31007: Set Thrust Ref 0 N '                                                                      
[07:32:12] app/str :' Stage SET index= 7 completed '                                                                         
[07:32:12] app/str :' Action 31008: Set Reservoir Heater Power Ref 6 W '                                          
[07:32:12] app/str :' Stage SET index= 8 completed '                                                                         
[07:32:12] app/str :' Action 31008: Reservoir Heater Power Ref 6 W '                                                
[07:32:12] app/str :' Sequence complete '                                                                                                  

The strings running out over our debug UART here are aprx. 600 bytes sent by 9600 baud -> taking up aprx 65 millSeconds.

The real data included can be expressed as pure 6bit Event IDs for (Seq-started, seq-stoped) and some events with 1/2/4 byte data (Set-Stage-IDX (idx), Action-Nr (Nr), Set-Mode(type, mode), Set-Power-Ref(power). Sent as binary events only I thiong this will be 
2*2 + 9*3 + 9*4 = 70 bytes -> only blocking the debug TX UART for 7,3mS !!! So its a performance factor of aprox. x10 on the debug uart.....

Implement code for performing "test fire" for thruster simulator hardware.

Sequence :

1. Version request for a thruster module during initialization, to verify that thruster subsystem is connected and ready

2. Set thrust and specific impulse to an value (example: 350microN, 3500s)

3. Set thruster mode to start firing sequence ( which initialize heating of reservoire)

4. Firing will occure when reservoire would be heated to sufficient temperature. Monitor the temperature while its heated up. Parse temperature and thruster status values out of register map.

5. With sufficient temperature thruster should change status to firing.

6. After fire for defined time - idle.

Plan is to implement it in layer_7_app. With start/stop/set/read value requests sent manually from command interface.

Note : 1)thruster replies "instantly" after request is sent
2) Length of the reply message is constant and depend on type of the request.
3) There are no unique bytes which would indicate the beggining of reply message, however reply length is know. Reply is only sent upon request. Reply is sent "instantly" after request.

Keeping "Notes" in mind - design RX buffer handling. For every specific request there should be corresponding function that proccesses the received buffer.

Example : Read version request is transmitted ---> expected RX buffer length is N bytes. ----> check validity of reply message with checksum ---> parse version number ----> compare with expected version to verify that correct hardware is connected.

Example 2: Set Thruster Mode request is transmitted ---> expected RX buffer length is N bytes. ----> check validity of reply message with checksum ---> Thruster should reply that mode is succesfully changed. Parse this information ----> return ok status

Intro :

Assuming that magnetometer i2c sensor is integrated to obc. Data has to be collected through orbit. Data to be stored untill communication link is established with Earth. After data transmission arrays / memory can be cleared.

LEO orbit is around 130min = 7800s

With sampling frequency of 1/20 seconds array with 390 values is enough to store sensor data over whole orbital period.

According to @WolfgangTreb data transmission windows would be available 3-4 times a week. With such - obviously ram memory won't be enough. And data has to be recorded to SD card.

Task concept :

Using already integrated internal i2c sensor - program the routine which will collect sensor data at specified sampling frequency. Stores it temporary in ram then writes it to SD card, clearing array from obc ram memory.

Todo:

We are at oppen discussion regarding when to collect data : possibly ontly when satellite is in region of interest ( high altitude/ polar caps)

To implement this routines @kodsurf had to be introduced to SD card memory read /write/ access functions. Also hardware (SD card is missing from obc that I am working with)

• add support for PPS pin
• add power on/off support (enable pin)
• add basic PMTK command support (Tx UART conection)
  • get module type&version
  • choose NMEA packets to use and the period of transmission
  • make automatic Standby/On cycles available to use
• optional use of fix pin ?

Either I do something wrong, or

Those checksum cases does not do what they are expected to do.

I had to manually turn off checsum check in order to proccessing function to be executed : 5c1a7d7

P.S : This is how I calculate checksum for autogenerated NMEA string : https://electronics.stackexchange.com/questions/214278/generating-hexadecimal-checksum-for-a-nmea-pmtk-message

If I take example NMEA message : $GPGGA,115739.00,4158.8441367,N,09147.4416929,W,4,13,0.9,255.747,M,-32.00,M,01,0000*6E

(with valid checksum from google ) - Original dev branch NMEA parser still gives an error.

The final version in RAD test jan-2020 was this: https://github.com/RobertK66/Climb-Obc-Hardwaretest/tree/Branch_Release_RadTests

Either we can use some mram test module from there or we 'rewrite them' for EM2....

• Implement NMEA packets to be used as Time synchronization from any external GPS module.
• Implemnt PPS Pin to be used to syncronize 'on board time' with ms accuracy.

According to ENPULSION documentation for RAMP it is required to achive the setpoint within 30s duration.

Ramp value at thruster register have to be updated with 1Hz frequency.

Frequency for the ramp in sequence execution hardcoding is defined with dt (argv[4])

Problem is that with 1Hz Thruster does not reply anything back. Looks like to high frequency. With 0.5 Hz (once every 2 sec) ramp works fine.

I believe problem is somewhere with sequence execution module. But not sure. Might also be something else

In a current develop branch gps module is initialized on LPC_UART0. However comment on the code says that it is sidepanel C (X-)

This looks incorrect.

My own docu "originaly" stated that LPC_UART0 is C/X-

Yesterday with flatbed setup it turned out that LPC_UART3 is C/X-

Please clarify to which sidepanel GPS should be connected by design, and check the code for gps init data.

Due to previously not well understood project maintenance with git (by me) : STP branch is million commits behind dev/master.

Need to synchronize "develop" with "STP" by implementing all the relevant STP features into dev and make pull request.

Further on to avoid this mess - I will be doing feature/< NAME > branch for every new module. And Pull Request as soon as module is finalized.

Sollutions to #24 should be merged to develop branch and make the base for all new features.

-> then establish 'git culture' of smaller 'feature branches'

I made general skeleton for PSU datavector parser c4c80a3

using the same method that I applied to parsing data from thruster registers.

PSU subsustem currently does not provide any real data! Only fake rubbish bytes.

PSU datavector is uint8_t array of bytes.

But values that are "encoded" by that datavector are not uint8_t !

Example from "Communication_Procedure_OBC_to_PSU_V2.doc" at https://github.com/DominicRichter/CLIMB_PSU

Something called "Edge temperature" is assembled out of two uint8_t bytes (low, high) into uint16_t value.

Temperature should in the end be represented as (270.5K) double unit measured in [K]

To obtain real physical value from datavector representation there should be something like CONVERSION_FACTOR

VALUE_UINT16 = (received_data[1] <<8 )| received_data[0];
double REAL_VALUE= VALUE_UINT16_t / CONVERSION_FACTOR

Example 1 :

We want to store 270.5 K as 2705

Which is hex 0x0A91

and can be represented with two bytes 0x0A and 0x91

Example 2 :

we obtain and asseble hex 0x0A91 out of received_data[0] , received_data[1] (which are two bytes in datavector)

store it as VALUE_UINT16 = 2705

now to obtain :
ACTUAL_VALUE = 2705 /100 = 270.5

where CONVERSION_FACTOR = 100

Those conversion factors have to be documented by PSU designers !!!

The event sent after reset or after receiving the 'T' command should not fill the random content stored in RTC when there was no sync at all. This only occurs if there is no MRAM available (e.g. when using a developer board) and the RTC Power was not buffered by Capacitor.

Downloading the lpc1769 in the Procedure it is written to create a new folder with CppEthernet, but it seems so that a folder with that name exist already in the project. Screenshot will follow as better description of the issue.

When no slave is connected (ether 0x47 for Power On/off command or 0x0B for commands,) then the software triggers same events as when slave has answered! So the random content of memory on TX buffer is treated as normal answer

• check the i2c Job for BUS Error and do not trigger normal events in this case!

Either just remove the second flash area or try to make other decision based on flight version design.....

Somebody should make a OBC release with feature content for the RAD II test. Lets keep this open as an 'umbrella issue' for planned features

• #29
• #30
• #32
• #33
• #40

All characters that are sent over debug uart has to be utf-8 (ascii)

Non ascii charachet received by rasbery pi would trigger "try, except" failed to read com port error

Log file from raspberry pi shows this error catched by python try except

The radiation test executed in 01-2020 showed that

• the prog flash memory never was corrupted during and after the tests
• after OBC was removed from radtest it was not possible to use the flash utility for program updates any more.

Advanced Testing:
It would be interesting if the flash programming feature was destroyed 'on chip' or only the external interface was lost. Therefore, I think we should make some test code that

• regulary uses flash prog feature to re-program parts of the LPC1769 prog memory
• regulary check the programmed/reprogrammed and some unprogrammed memory areas for bit flips.

Make the MRAM Chips available for generic / specific storage areas

• use for Event Store - local Event Log
• use for HKD/Sensor data store

If I understand it correct, the chapter "3.2.4 PRG Connectors" in the new Document "STACIE Description V042" it will be possible to implement a 'Program via UART'-Proxy feature to be used for Flashing Stacie-D Subsystems.

It has to be defined how the exact protocol and timimng together with the mode GPIO should be handeled. At least the OBC could 'proxy' the uart to simulate the PRG Connector from the UMBILICAL-debug_uart after the cubesat is assembeled and no more access to PRG connectors is possible.

The ADCS Sub Unit has to be controlled by its hardware interface (not decided yet)!?

Features of this Sub unit are T.B.D.

• heartbeat
• debug output is binary
• string is printed over RS485 periodically

The MEM_WRITE_PAGE0(0x3F); in line obc_memory.c initiates SPI DMA writes for all 6 mram chips to write new content of page0.

The Data gets written correctly but the Callbacks for Chip0, Chip1 & Chip2 are never executed !!!???

This leads the memory module in unsave state (trying to finalise the writePage0 operation and no other read write is going to work afterwards. (-> Busy Error)

dec64af

With Neutralizer Heating Test seqeunce

Ramp function does not triggered in sequence

Ramp function is triggered succesfully within sequence 3 "Heater Ramp Test"

However after completion of ramp substage_index =1

substage_index should be returned to 0 after execution of ramp !!!

Find bug and fix

output - the sensor vals every x seconds.

Need to implement a delay between adding the jobs (processing ??)for I2C.

Delay between write and read job should be implemented in accordance to cooperative multitasking. (what on an example is wrong)

1. TLE can be obtained by API

https://celestrak.org/NORAD/elements/gp.php?CATNR=25544&FORMAT=JSON

CATNR is ID of object in NORAD database

Object ID can be searched by the name using
https://celestrak.org/satcat/search.php

Example :

substitute CARNR with PEGASUS ID :

https://celestrak.org/NORAD/elements/gp.php?CATNR=42784&FORMAT=JSON

To obtain TLE of PEGASUS

JSON

Or text

https://celestrak.org/NORAD/elements/gp.php?CATNR=42784&FORMAT=TLE

Output of simple HTTP GET request is

3 lines of strings.

2. Capture those strings with python (using curl http request)

And use : https://rhodesmill.org/pyephem/

pyephem to calculate object possition (lat/lon/alt)

Example :
https://space.stackexchange.com/questions/4211/calculate-satellite-coordinates-from-tle-data

3. Use obtained lat,lon,alt ( and possible other data)

to create NMEA messages and print them to UART in a loop over time.

After git clone and submodules init

Project remains uncompiliable due to folder structure of ado_chip_175x_6x

To make project compilable I have to manually copy files from ado_chip_175x_6x folder. But this way git references are removed for ado project.

@RobertK66 Could you please look into structure of ado_chip folders so that whole OBC thing becomes instantly compiliable after git clone of obc_1769_core ?

Or possibly I do something wrong with git initialization ?

Problem is that we get folder inside a folder with "ado_chip_175x_6x"

I think your checking the RX length in thr.c ine 185 (commit d06a41d ) is not working correct.

I wrote a 'Thruster-Simulator' connected to the RS485 UART and simulated OK answers to Register Set and Data answers to Register read requests. When I change the line 185 to check '<=' iso '<' everything seems to work !?

Not sure if this is the 'correct' resolution or the setting of the variable l4_thr_ExpectedReceiveBuffer is to be blamed here .....

When the 's' command is issued the first time after power on, or very fast for 2 times (send string "s\ns") then it shows wrong values:

[09:36:53] sen/val Vcc:2,80V Icc:116,9mA Isp:1,6mA t1:29,87°C t2:-340282300000000000000000000000000000000,00°C hum:-34028230000000000000000000000000000000000,0%

re issuing the commad gives correct raedout.

In Pegasus we had the Document "STACIE Command-Interface OBC <-> STACIE".
It described the Commands used on the 2 UART interfaces between OBC and Stacie-D.

I did not manage to get any (even a DRAFT) Version prepared/agreed for the CLIMB project until now :-(.

IMHO it does not make sense to start any implementation (porting of Pegasus code!?) if there is no agreement on the usage and needed changes(!) for this COM-Interfaces.

This issue here exists to give an overview on 'missing'/unimplemented features needed to complete a CLIMB OBC firmware able to be used as 'flight version'.

When using the GPRMC message of GPS to synchronize the OBCs time following observations where found:

• on 30.11.2022 the time sync generated a RTC Time of '2022-12-00'
• on 1.12.2022 the time sync stopped to work at all

Develop a format to store signals efficiently.

• Compress with usage of board time and expected signal content (e.g. periodic changes - temp, fast changes - current sensors)
• Store HKD in format to be transmitted with beacons in efficent manner.

• Add meassurments to detect mainloop anomalies regarding to runtime of module main routines.
• move the 'LaststartedModule' debug featur to the mainloop. (Expand it with 'IRQ marker'
• add (debug) functionality with global availability of raw/string event.

Meassure runtime per module.
include 'current running' module to monitor structure
make and persist events absout treshholds violations

• single module out of 'optimal runtime'
• single module out of 'allowed runtime' -> disable calling of this module
• main loop execution out of 'optimal' runtime
• main loop execution out of 'alowed' runtime -> ??? / extra thing needed or is Hardware Watchdog good enough in this
• (try to) make usefull event with 'current module nr' and 'soft reset' with hard faults and other fatal IRQs.

make 'module enabled/disabled' possible. Switch on/off (with 'reInit' or without !? switch off with DeInit !?)

I want to write a function that will send data over i2c into arduino for a test.

How should I know which freequency to use ?

LPC_I2C0
LPC_I2C1
LPC_I2C2
LPC_I2C3

???

Can you please tell which side (X+, X-,Y+,Y-) correspond to which LPC_I2C* device ?

3. I also remember that LPC_I2C devices should be switched ??? depending on which side we indent to use.

Please explain it again here in issues. How to select which I2C side on OBC (X+,X-,Y+,Y-) should be used and how to switch it ?

During testing of SRS and implementing conversion to UNIX Timestamp, I found some path of syncing the OBC time to be 'unreliable'. There are Values which do sync to incorrect offsets:

• e.g. when using "t 19700101 000000" -> should generate a UNIX time with very low number -> but does generate UNIX time on 2.1.1970 !? (using "t 19700101 001000" -> seems to work correct and shows 1.1.1970 00:10:00!
• There was a bug by not storing the Year in all path of syncing (not used for TLE at all, but very confusing not to have!)
• at this moment there are 2 code places where leap Years are generated -> unify
• The situation that reset occures shortly before Midnight and especially before 31.12.20xx 23:59:59 should be considered correctly ->I think the year, day of year and day of month could cause problems here!!!!

-> make more (automated!?) tests to show all path are good !!!!

• Enable all 4 sidepanel I2C buses and configre them (to use 100kHz at this time)
• write testcode to address external slaves

also see discussions here: #23

Use custom datastructure as an input to sequencer functions instead of "string" arguments. Avoid using atoi() .

Use the SD-Card to backup MRAM storage areas

• use for event Store Log
• use for Sensor ans Signal Values

Modify/redesign the thruster scripting engine to build the base for future 'Mission-Scripts".

I propose to design a generic "Scripting Engine" which can be used to control the higher (mission) levels of the CLIMB OBC Software in future.

All C-Level modules will provide the 'Command-API' (currently also used by the debug UART) to be triggered. Additional we will need some sort of 'Register/WaitFor - API Events" command and some primitive control structures (IF-THEN/LOOP/..) to be available.

Scripts should be provided either from Flash (hard coded basic and emergency scripts), or from MRAM Storage.

I think we should aim for possibility to run N (~10) scripts in parallel. The engine module should provide the commands to activate/run and deactivate/stop any available scripts and also to upload new scripts (from ground station) to MRAM storage.

Details for that are T.B.D. and documented as they evolve.

I have to set the goal here to myself to conclude PSU work within the scope of my master thesis.

So the task in this issue is a bit aside on how I would approach problematics in real works. The status with actual EPS system SW is FROZZEN. Still I need to fulfil an academic goal.

It is assumed that real physical values are encoded with Q-formats ( https://chummersone.github.io/qformat.html ) and compiled into a datavector[88]. Which is then send to OBC.

My academic goal is to write datavector parser which would decode the data and store it as real physical values. (similarly to what was done with Thruster module) .

Currently there are no real example of PSU datavector output avaliable due to some HW issues or work in progress with HW dev.

Within academic goal I will manually generate encoded datavector, which would be transmitted to OBC from arduino upon I2C request that would be similar to PSU.

Encoding of datavector is provided in a table below. Encodings were obtained by reverse engineering PSU and Pegasys repos

Please fix compilation error with dev branch. MCUExpresso runs crazy when I pull recent commits

Switch the Debug Interface to use 2 general IO Pins and implement a
9600 baud Soft Uart

for the next release do not forget to:

• adapt the module design in documentation (status, runtime, current running, ...)
• adapt the action script for release to work with new project layout
• adapt the https://github.com/RobertK66/actions-build-mcuxpresso action template
  • to be able to make a loop for build projects (Independent of their path)
  • to use a fixed version and not dependent on (external!) main branches...
• make a dedicated release of tools - to get the debug/dump binaries translated with map file (#17)