Why LPC1769 is used for CubeSat OBC ?

[kodsurf]

Referring to a master thesis  : Development of an onboard computer (OBC) for a CubeSat by LWABANJI TONY LUMBWE  

Selection of Microcontroller for OBC of a cubesat section

Main requirements for selection of OBC microcontroller were listed in the table 

Requirement	Description	Physical value range
Power consumption (peak power and stand by)	A low power scheme is the major requirement in satellite systems due to the fact that electrical power is extremely limited	CubeSats have total power budget of 1W is available for a 1U and 5W for a 3U due to the minimal external surface area covered by solar panels
Operating temperature range	Significant variations of temperature in LEOSun side temperature rises up to 150°CIn eclipse temperature can drop as low as -150°CChanges in temperature can cause significant damage to electronic components	All the hardware components of the OBC  should be rated for an operating range between -40°C and 85°C
Operating voltage	The EPS in a CubeSat normally provides an unregulated bus voltage varying between 6V and 8.3VUsage of additional voltage regulators adds weight,size, and complexity to a system.	Most of the active components including the OBC’s microcontroller, should be chosen to operate at or below a value of 3.3VPower consumption is directly proportional to the operating frequency, the operating frequency will be limited to 100 MHz.
I/O and serial bus compatibility	The variety of I/Os (digital and analogue) available on the microcontroller are necessary in terms of connectivity	The data transfer between subsystems is made possible by the OBC’s microcontroller’s integrated serial interfaces (UART, I2C or UART). Selecting a microcontroller which possesses one or more of each of the serial interfaces is highly recommended since each of them is constrained by their data transfer rates and data or address bus sizes

Further on Author creates list of potential microcontrollers to be used for CubeSat OBC to compare them

The rows highlighted with a light green color indicate the 34 parts that did not qualify for the next step and the cells highlighted with a darker green color indicate the requirement that was not met.

It is seen on the table provided by author that LPC1769 does not meet recommended criteria based on maximum operating frequency and supply voltage.

Maximum supply voltage of LPC1769 is 3.6V. 

The LPC1768/67/66/65/64/63 operate at CPU frequencies of up to 100 MHz. The LPC1769 operates at CPU frequencies of up to 120 MHz. [UM10360 user manual]

With LPC1769 it is allowed to change the operation frequency of the chip.

It is important to point out that at the beginning of work related to flat-bed test assembly master thesis - during laboratory experimentation with OBC_EM2 it was detected that software performance is unreliable when OBC_EM2 is powered with 3.3V. Data flow through communication interfaces (UART, I2C) was corrupted. Bytes that was received by serial terminal, and measured using an oscilloscope was not in accordance to what was programmed to be transmitted. 

At that stage it was by acident discovered that increasing the supply voltage to OBC_EM2 above nominal allowed value of 3.3V to 3.6-4V temporary solved software performance problem.

This issue was reported to supervisors and further investigation showed that software of CLIMB project was configured to use 120 MHz frequency at that point. Lowering the operation frequency to 100 MHz has solved the problem, and with 3.3V supply from NXP Link 2 JTAG it is now sufficient for a stable performance. [https://github.com/RobertK66/ado-chip-175x-6x/commit/1f383e60abf30f97c22ac315b4269b43d72328de]

[kodsurf]

Above was from literature review that I made for master thesis.

I wanted to write a couple lines on why exactly LPC1769 was chosen. Any hint ?

Other idea based on what was written above - if LPC1769 allows up to 120 Mhz . Does it mean that we can try lower frequency to say 80 MHz and test what happens ?

[RobertK66]

Yes, I think PEGASUS run on a lower one, but I am not sure wich specific freq. It is the same as for the power modes. It was considered but not really proofed by testing (with higher/lower frequencies) when I was there in the project.

[RobertK66]

I assume you already found my reasoning in https://github.com/RobertK66/obc_1769_core/blob/develop/doc/m90_apendix_a.md

It's not much but it is my state of thought on that issue. I entered Pegasus project on a very late stage and did not run through the decision making on the original OBC. For the Climb project, in the beginning the weight was very high on 'use proven design and change as less as possible'. (Remark to Power consumption: PEGASUS Software never utilized the LPC1769 power save modes. It was foreseen but never tested and implemented. In the end this was no issue at all because PEGASUS had no power problems at all. The solar panels supplied much more power than the operations could use up - so the batteries never really were discharged - as i remember...)

My personal opinion on that issue is, that for new cube sat projects one should reconsider this like your table describes. From a pure software point of view, I would like to keep the ARM-family but switch to a more modern processor core. Reason here is that the old NXP processors are not (fully) supported in modern embedded communities and you have to do a lot of low level stuff 'by hand' on your own! (e.g. porting of a current version of RTOS kernel/making own 'modularity-os', using low level library functions for UART/SPI/I2C, using only the propriety MCUXpresso makes development and debugging harder - and less fun ;-) ... )