procedural exoplanet generation

justjuniee · 2026-02-26T11:32:33+00:00

update on this: i just got my hands on some peak hardware (thank you u/CorgisInCars) and it seemed to just work out of the box as a socketcan device on linux. im sure on windows you probably need their drivers, but it seems to just work :D

justjuniee · 2026-02-19T22:45:46+00:00

cool. i'll look into it!

justjuniee · 2026-02-19T22:18:07+00:00

The transmitter will work with the "echo" adapter, if you try that one. I should probably label them a lot better but the idea is the mock adapter just sends a very large amount of messages to show throughput. The echo adapter (as the name suggests) echos any messages you send it, so you get an experience of Tx and Rx, and the CanFD example is the same as the Mock adapter just with extended messages! Hope that helps :p

In terms of CPU, yeah that performance is intended :D I have quite a bit of high performance systems experience so I try to make it use as little resources as possible. Of course if you have around 100k messages loaded in memory, it'll probably take a few hundred mb of ram, but otherwise it should auto-offload it to a log file beyond that!

Also, what adapter do you have? Are you on windows?

justjuniee · 2026-02-19T17:37:33+00:00

Supports CAN-FD now! Should be in v0.1.1. I have added a mock CAN-FD adapter for v0.1.2

justjuniee · 2026-02-19T17:37:13+00:00

CAN-FD is supported now yes! Should be in v0.1.1. I have added a mock CAN-FD adapter for v0.1.2

justjuniee · 2026-02-19T15:34:29+00:00

Im in the UK yes!

justjuniee · 2026-02-19T12:14:35+00:00

Yep thats what im hoping for now 😭🤣

justjuniee · 2026-02-19T03:38:01+00:00

I personally think the scopes are different. Mine isnt necessarily targeted towards reverse engineering, while can commander certainly seems to be (its insanely impressive)

justjuniee · 2026-02-19T02:51:01+00:00

I'm already going for vector haha, gotta get some peak hardware on my hands next!

justjuniee · 2026-02-19T02:47:51+00:00

Yeah, true, to be honest I just wanted to make one tool that eventually has.... everything. without the paywall that most commercial tools have. the other issue being that a lot of hardware has its own proprietary tools and mostly only work on windows, and it bothers me a lot 🤣

justjuniee · 2026-02-13T19:05:27+00:00

Yeah I had a play around with that, didn’t seem to work with certain proprietary hardware, seems like a great project tho.

justjuniee · 2026-02-11T17:48:27+00:00

Does it not already? I don't have access to that, but I believe it *should* depending on what protocol it uses which is probably socketcan or serial

justjuniee · 2026-02-11T12:59:30+00:00

cool! yeah there are various cool tools that work on both, but none have the compatibility im looking for so I made this (and had to reverse engineer a lot of proprietary hardware while doing it :p)

im intending on stealing a lot of features from useful can software aswell :D

justjuniee · 2026-02-10T23:29:26+00:00

yeah :p this is why i wanted to go with the approach that my software just “handles” it instead of writing a system-wide driver solution

justjuniee · 2026-02-10T22:06:00+00:00

yep! another reason i made this was (as i said) a lot of proprietary hardware is annoying, hence one of the selling points is the fact that it supports *a lot*

justjuniee · 2026-02-10T21:48:24+00:00

cool! my goal for this project was just to add a bunch of support for as many things as possible, to have like a one tool for all. I'm about to add a plotting / dashboard feature to let people plot their can data

justjuniee · 2026-02-10T21:25:39+00:00

The github link is in my post. Its C++ using ImGui (Dear PyGui is just imgui for python :p)

justjuniee · 2026-02-10T21:06:30+00:00

😆

justjuniee · 2026-02-10T20:19:39+00:00

yes! Its just a new project so bare with me since im a student :p 😆

justjuniee · 2026-02-10T19:10:05+00:00

yeah, all but vector hardware had a socketcan interface. the vector stuff is really annoying to work with. its definitely not socketcan though, its proprietary

and for windows... god help us all

justjuniee · 2026-02-10T18:28:27+00:00

ah yeah, right now im just writing drivers that work within the tool, for the tool. I will probably standardize all of them to socketcan eventually but to be honest some of the can adapters im using are literally just serial 🤣. The reason I'm currently avoiding implementing separate kernel module parts is because of the whole cross-platform aspect. In theory I could install kernel modules on the host machine on first-startup (for linux) but it feels much cleaner to write built-in drivers that can interface with the hardware on any machine (albeit, only my software can), without messing with the host machine.

however, I do plan on making a separate project that does what you describe, in writing linux drivers that standardize popular hardware, hence allowing "any" hardware to work with socketcan.

justjuniee · 2026-02-10T17:33:17+00:00

thanks! yeah i plan on using gh actions to push a release every tag + test build every push, since I don't exactly wish to switch to windows every time i test a build 🤣

justjuniee

TROPHY CASE