[Ground-station] Open Source CubeSat Workshop notes from Hugh

[Zach Leffke]

not at all an expert in this area, but relative to the point about I2C 
locking the bus and potentially bricking spacecraft (towards end of 
notes).......

This is the second time I've heard of this issue, though haven't 
directly experienced it myself (though not a lot of experience in this 
area).

The other data point on this was from NASA Goddard's Dellingr project, 
where they experienced similar I2C issues.  in their case the main 
computer kept crashing every 45secs right at the point where I2C drivers 
were being loaded during the boot process. Something about the bus being 
already 'occupied' which was not expected by the flight computer.  The 
reload of the I2C driver was just enough that it was resetting the comms 
watchdog timer on the EPS (clyde space product), preventing it from 
triggering a full spacecraft power cycle (as far as the EPS was 
concerned, it was seeing I2C traffic, so 'all was well' from the comms 
watchdog perspective).  In their case, they were able to command 
'constant' resets for a pass via the CADET radio, which caused the 
computer to reset faster than the 45 sec rate (before I2C driver 
loading) for the 4min WD window of the EPS.  Net result was a full SC 
power cycle, clearing the I2C fault.  Memory dumps of the crashes 
(enabled by the use of NASA's Core Flight System) allowed them to 
post-mortem the problem and determine the issue was with the reaction 
wheels saturating the I2C bus.  They used NASA's cFS (Core Flight 
System, open source flight software running on RTOSs of various flavors) 
for the main control software which enabled them to do the memory dump, 
upload new 'apps' for interfacing with the reaction wheels, and 
ultimately develop a workaround to continue on with the mission.


I know other groups are looking at CAN as an alternative to I2C for the 
main comms bus (google Cubesat Next Generation Bus).  Not sure if this 
is a good idea or not, how it stacks up to CAN, etc, but maybe should be 
considered........I know its heavily used in automotive applications, so 
probably plenty of available component level HW available and probably 
SW as well, and if implemented correctly, probably is pretty robust.


As far as open source ground software.....COSMOS from Ball Aerospace 
appears to be picking up momentum.  Its used by many companies and 
NASA.  We're now using it on our VCC cubesat mission at VT for the main 
Command and Control suite.  We had to develop custom parsers for AX.25 / 
KISS, but the whole thing is written in Ruby and after the 'learning 
curve' related to their config files, its pretty easy to work with and 
develop custom pieces/modules for.



-Zach

Research Associate
Aerospace Systems Lab
Ted & Karyn Hume Center for National Security & Technology
Virginia Polytechnic Institute & State University
Work Phone: 540-231-4174
Cell Phone: 540-808-6305

On 10/1/2018 7:12 PM, Michelle Thompson via Ground-Station wrote:
> Please read Hugh's working group report from Open Source CubeSat 
> Workshop 2018. He will be writing a blog post about the event shortly!
>
> -Michelle W5NYV
>
>
>
>
> _______________________________________________
> Ground-Station mailing list
> Ground-Station at lists.openresearch.institute
> http://lists.openresearch.institute/mailman/listinfo/ground-station

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20181001/62ee4e77/attachment.html>