 | librecube | 241 Members |
| open source space exploration: https://librecube.org/ | 30 Servers |
| librecube | 241 Members |
| open source space exploration: https://librecube.org/ | 30 Servers |
| Sender | Message | Time |
|---|---|---|
| 10 May 2024 | ||
 umeii changed their display name from umei (Old) to umeii. | 16:57:45 | |
| 13 May 2024 | ||
 cajt | Maybe a nice payload, reasonable scientific output and still affordable to play around with: https://hackaday.io/project/194457-pomelo-gamma-spectroscopy-module | 11:10:07 |
| cajt |  Download image.png | 11:12:43 |
| cajt | ... but its 4-layer, 'cause I'm lazy :-D | 11:13:21 |
 Artur Scholz | In reply to @cajt:matrix.orgok great! But 4 layer is more expensive, that's why preference is on 2 layer (to answer your previous question) | 15:49:49 |
| Artur Scholz | The other feature to add is two redundant UART busses. One for Comms and one for payloads. Not sure if this is the smartest idea, but UART works ok and is available on every microcontroller. To ensure that it works even if a line fails, the UART bus shall be redundant as well. Since there are not enough UART ports available on raspi GPIO header, I was thinking just to use an analog switch for TX/RX lines? | 15:55:39 |
| Artur Scholz | cajt: PS: repo link or it never happened š | 15:56:17 |
| Artur Scholz | In reply to @cajt:matrix.orgCool! The idea is we fit the rover platform components in a 2U and have another 1U cube to accommodate your payload of desire (https://fosstodon.org/@librecube/112059471888188218)! | 16:00:04 |
| cajt | UART buses or point-to-point? | 16:11:48 |
| Artur Scholz | UART for point to point (so actually not a bus š) | 16:14:13 |
| cajt | Or maybe 10base t1s? | 17:03:45 |
| cajt | Or spacwire, still a nice protocol, and it has space in the name š | 17:05:01 |
| cajt | There are also nice UART bus solutions out there, but I'm a bit opinionated about those. | 17:08:51 |
| 14 May 2024 | ||
| cajt | Is this worth some effort for architecture exporation? Has the scope shifted? (There certainly is a lot of accumulated legacy there) | 06:29:37 |
| 15 May 2024 | ||
| cajt | That can be a path to innovation and improvement? No Interest at all? | 06:05:21 |
| Artur Scholz | Are you referring to the point to point connection? | 07:07:51 |
| Artur Scholz | What's your proposal then? | 07:08:04 |
| cajt | I see many potential areas of possible architectural improvements. The question if a ptp UART is a great solution and what to use it for can be one. The constraints imposed by that pseudo pc/104 connector is another one, as is the fixed PCB size that comes with that. There is a lot of distributed computing happening, so protocols might be one. Power efficiency, fault-tolerance, testing, scaleability, integration methodology can all be possible cross-sectional domains. Potential drivers of this can be need for higher autonomy, more computational throupghput, larger plattforms, inter-vendor compatibility, transfer from and to other application areas (like robotics, UAVs, etc.) | 11:12:52 |
| Artur Scholz | In reply to @cajt:matrix.orgmeaning, a full overhaul! | 12:21:51 |
| Artur Scholz | Hasan: jenskolb : I did modify the pluto to pdf repository to align with typical prototype layout. Still, there is an error regarding file system that I am not sure now how to solve. Please follow the readme to do the setup and see if you can fix that. Following that we can further work on this repository. https://gitlab.com/librecube/prototypes/python-pluto-to-pdf | 12:24:06 |
| cajt | Stuff will allways co-exist, so no overhaul. But changes that some might consider incompatible might be interesting. | 12:50:48 |
 Hasan | In reply to @artur.librecube:matrix.orgSure Sir, I will look into it šļø | 13:44:26 |
| cajt | The IĀ²C bus is already overhauled ;-) | 14:33:51 |
| Hasan | Update: I have understood the problem, Fix: I can make a quick fix by making a new repo (forked with latest This way I can quickly update each file without having issues with old vs new code structure, Starting Changes now, will make new Merge Request before morning šļø | 14:37:33 |
| Hasan | * Update: I have understood the problem, Fix: I can make a quick fix by making a new repo (forked with latest This way I can quickly update each file, fix issues in new code structure without having issues with old vs new code structure, Starting Changes now, will make new Merge Request before morning šļø | 14:38:24 |
| Hasan | * Update: I have understood the problem,
Fixes:
This way I can quickly update each file, fix issues in new code structure without having issues with old vs new code structure, Starting Changes now, will make new Merge Request before morning šļø | 14:59:30 |
| Hasan | * Update: I have understood the problem,
Fixes:
This way I can quickly update each file, fix issues in new code structure without having issues with old vs new code structure, Starting Changes now, will make new Merge Request before morning šļø | 15:00:02 |
| cajt | This whole pseudo pc104 concept is rather limiting in so many ways, there is need for a better design. It doesn't scale well beyond like 2U in the cubesat context, and is kinda strange for any other domain. The stack-through connectors are okay for 1980 PCs, but not much more. Every CS vendor has o work around it, and components with higher datarates or higher power consumption don't really fit well at all. | 18:14:09 |
| Artur Scholz | PS: Hasan jenskolb : We use the open project server to manage the project (https://66222-44717.pph-server.de/projects/developments/work_packages/62/activity). (--> add yourself) That is, the overall goal and discussions plus supporting documents/images/etc can be put there, whereas in the gitlab repo we create specific merge requests and open issues. | 20:36:15 |
| Artur Scholz | Hello Rajkumar ! Last year you worked on the PLUTO syntax highlighter (https://gitlab.com/librecube/tools/vscodium-pluto-syntax). Would you be able to make this available in the marketplace (https://open-vsx.org/)? This way, people could easily install it in VSCodium and Code OSS. | 20:49:43 |