OBC Walkthrough Meeting

OBC Board Walkthrough
- they have rev 1 and rev 2 - different purposes
- rev 1 was developers - had extra peripherals and connections
- rev 2 was what went in the cubesat
- rev 2 is rev 1 without a few things and with PC104
- SECTIONS: microcontroller, power protection, peripherals
- power supply protection: efuse and current sensor (anything else added later?)
  - most of this was bc they didnt have eps so they needed a standalone
  - didnt rlly use the current sensor - (would they do it in the future?)
  - efuse footprint incorrect (pin num inverted) - they shorted it to fix it
  - so not rlly protection working - needs to be fixed from this end then
  - power options from usb or external supply
  - most things use 5v or 1v2
  - nts: ask fw team what extra connections they need - uart debugging/usb, power safety stuff
- dual buck
  - 1v2 output and 3v3 output. 1v2 is just the MCU
  - current sensor was not used on theirs at all
  - voltage monitor resets with overvoltage - has decoupling caps etc
  - Manual button reset
- USB-UART CONV
  - this is not rlly present on rev 2 i think?
  - lets u connect to laptop and send data over UART - converts signal basically
- Microcontroller
  - 144 pin microcontroller - has 3 symbols on the schematic
  - Most got broken out into 50 pin headers/peripherals
  - JTAG connector: flashing RM46 is with JTAG programmer with a certain type of female connector, on board is a male connector - didnt match up perfectly with the pin definitions - this got fixed in REV2
- Peripherals
  - microsd card
  - fram chip
  - connect to microcontroller over the SPI bus
  - They think microSD isnt the most reliable thing - can communicate with SPI or SD protocol. When you startup its not in SPI mode so u have to intialize it before you use other spi devices connected on the bus, small issues with this (what are you planning to replace this with?)
    - not sure about what switching this out would look like yet -they want to do fw by sept so it wouldnt make sense for rn, eventually we should - nand flash (internal microSD structure - more elec work?), embedded multimedia card (actual chip soldered on) - bga package which they wanted to keep away from
  - currently both on the same bus, had issues communicating - on a seperate bus for REV 2 (how many busses?) - microSD was recommended to be on its own bus - 5 spi busses (4 for this package) - cameras MIGHT be a concern - esp w/ 2 simeultaneously - could add SPI mux
  - User LEDs and buttons were there for debugging and development
  - RTC, Temp sensor, RTC (what did they do with their temp sensor?) - (just wanted to track it - req they set for themselves- could add redundancy telemetry) comms over I2C here - common pullups used
  - no i2c address conflicts- important to note - rev2/pl had 2 cameras with the same I2C address
  - Same CAN transciever as eps (did they use it with others? did it work from their end?) - no testing here - they do have a CAN device to plug in though - find it- is can the best protocol for 2 device comms?
  - How did they select components? a lot was driven by fw, they’d pick the sensors and we would integrate it
  - nts: ask fw team about a similar workflow
  - nts: spreadsheet for I2C addresses will be important too - mux, (+ spi devices with special regulations)
- REV1 Layout
  - 4 layer board, most on top layer
  - 3v3, gnd layers
  - headers were nice bc they could select - not PC104
  - nts: better way for pc104 to be laid out? if ur changing everything
  - resources: RM46 launchpad?
- REV 2 - no USB to UART convertor - wasn’t useful for space apps, pwr supply connection was stripped down a lot
- they added reverse polarity protection - bc ppl were developing on it, this was just in case they were using other supplies, they also just created their 1v2 output so they have a new buck here.
- new JTAG connector actually matches with the programmer
  - connector gets removed before satellite, they can either do it with jtag or umbillical connector - desoldered before the adding it to the cubesat
- (what were their umbillicals would they change it?) - programmer requires a 3v3 voltage level & needs to detect it. broken out for jtag but no 3v3 connection on umbillical connector - replace pin 9 with this so theres no external wires soldered in
- Watchdog timer got added to REV2 - interrupts every 10 seconds and togglesa pin - mcu needs to detect and respond - no response = watchdog will reset the MCU so it avoids getting stuck
  - no way to manually disable this right now - while flashing the flash would fail bc the watchdog timer was triggering and resetting - their temp fix was removing it - can add it back after its flashed or we can just add a jumper to disable it
  - could also resource this watchdog timer
- FRAM chip defers REV1 and REV2. REV2 is smd. dip chip was good for breadboard
- PC104 routing was really difficult - it was a 6 layer board cause of it so we should let obc team do the PC104 pinout
- Payload connector:
  - 2 cameras - they use i2c AND spi (config/image data), we need to solve the address issue by introducing an I2C mux (might have been an issue with this?)
- rev 2 layout
  - 6 layer board
  - lot of empty space - no redundancy - so we need to add a lot more to this, thats where we can take up more space
  - camera connector on the bottom
  - DSUB connector is the umbillical
  - decoupling caps on the bottom of the OBC - keeping distance between them and 1v2 pin short
  - top copper, 2 gnd, signal layer, 3v3 layer, ? dk what this one is, more signal layer
  - can ask Kiran about specific layout things
- nts: fw may have questions about removing the watchdog timer - ask them about this - they didn’t love the way it worked - maybe configure the window of when it respects the response- requirement sheet from firmware
- kind of clunky umbillical - it works tho
Special design decisions
- had a stencil - had to cleanup
What went well?
What didn’t go well/tasks for fixing it?
- adding the efuse back on might be nice if we’re still developing
Improvement ideas
- redundancy - whats a critical device? maybe we need another microSD its really critical - maybe a secondary storage device to switch over. maybe switch to fram but it has lower storage cap.
- RTC as well would be critical - it tells us the timer and stuff - gnc needs it
- RTC issue: if it loses power it loses track of the current time. nts: provisions? we write to register over i2c and it increments the current time with internal oscillator. power shuts off otherwise - it has no storage
- this does have the coin cell option - they didnt use it here bc they had a software based solution - keep track from MCU
- this is in case it gets fried or popped out^ nts: talk to fw team about these backup plans
- it just is looking for a rising edge (watchdog)
What needs to be purchased to complete the boards?
- no, everything should be in the locker
- RM46 stock should be checked - out of stock currently - kinda unpopular more niche, safety critical real time
  - nts: talk to fw about this. alternate MCUs they could use? other families wouldddd work
  - nts: will adcs have an MCU?
  - nts: i2c excel sheet
- george did an inventory before building - maybe check back on this
How much documentation already exists within our team about this design?
- obc design might be in the firmware wiki currently- there’s some research about devices and selecting CAN
- requirements are also there
- did they do breakouts for anything? no
Adapter board: REV1 had this to convert non-standard pin output to std 14 pin connector for JTAG - jumper wire situation - this should be in A365
Adapter for umbillical and UART as well - EV9 - this might have some mistakes - didn’t get used for comp
Where are the datasheets and research materials used located?
- Altium cps should have the proper part links - seems ok
- launchpad was for rm46 layout - developed by TI 3 or 4 of these
- lot of inspo from AlbertaSAT OBC for components
Anything else about the boards we should know?