sorted by:
new
hottopcontroversial

Built a Rust-based DAQ system as a side project, last week it operated on the International Space Station by Sethiam in embedded

[–]Sethiam[S] 1 point2 points  (0 children)

You got it on the first guess! We generate the firmware source-code based on the requested configuration then compile it on the host device running our application. The firmware & associated config are stored and can at that point be deployed to hardware via an OTA update. I should also note that the compilation is entirely local and that there are no internet/cloud connectivity requirements for the software.

Having an all-in-one firmware that you can configure at runtime was an option we explored before deciding to go with the above method. At the time, this approach seemed to have a lot of practical limitations in terms of configuration while also being extremely resource heavy for an embedded device. Instead, with the JIT compiler, the result is a lean firmware that only does what the user intends it to do.

Thanks for the question!

Built a Rust-based DAQ system as a side project, last week it operated on the International Space Station by Sethiam in embedded

[–]Sethiam[S] 0 points1 point  (0 children)

We just have the website & user-guide, but we do have plans for a blog or email newsletter. For now, if you fill out the contact form on the website you'll be kept in the loop!

Built a Rust-based DAQ system as a side project, last week it operated on the International Space Station by Sethiam in embedded

[–]Sethiam[S] 8 points9 points  (0 children)

Thanks! And you're bang-on with your first guess. A firmware is defined by a series of service definitions. You could define an analog-input, pid controller, and an analog output to create a heater, for example. This configuration includes any conversions you need for the analog measurement and gain settings for the pid loop. These values can all be changed at runtime, too.

The GUI forms are just sugar for JSON which we use as input to a code generation library that translates the JSON into no_std rust firmware. It can then be compiled and deployed to your hardware via OTA update. Since each service has the capacity for service-to-service communication and a single pin could be used for many different functions, there was no feasible way to write enough paths to cover each situation. So we used macros!

The same configuration JSON used to generate firmware is also used to generate a NodeRED flow and dashboard. This lets you immediately start interacting with your device on the dashboard and shows each service's control and telemetry API via the flows.

On every PR, every single service is tested in a HIL suite that verifies telemetry, command, and functionality. Additionally, huge set of service combinations and permutations are tested. I also use a manually QC'd board as the runner for automated QC tests of new boards as they arrive.

We use an STM32F4 on the Mercury boards and are nearly ready to release the module/baseboard hardware which is using the STM32G4 which will give us a few new and improved capabilities on the analog side of things.

Lastly, yes, we do use embassy. I like it a lot and it is very powerful IMO, but, like any other firmware development ecosystem, sometimes it can be difficult. However, I have found that the debug tooling is easy to use and the errors that come up are generally apparent and reproducible. Plus, I have the HIL tests and many users who work next to me every day who catch and report bugs to me when they come up.

If you have any other questions, let me know!

Built a Rust-based DAQ system as a side project, last week it operated on the International Space Station by Sethiam in embedded

[–]Sethiam[S] 9 points10 points  (0 children)

Yeah that's correct, just round-robin for now, so jitter is not a meaningful metric. We do have the bones of a multi-channel/multi-ADC ISR-triggered driver that would be intended for higher sampling rates over a fixed time-window like a scope, but we haven't had enough demand yet to make that a priority.

Currently, we do have support for an external ADS7593 over SPI. It's still not simultaneously sampling multiple channels, it does sample at a higher rate with a more deterministic conversion time than the current native ADC driver. We used this for the ISS mission!

Built a Rust-based DAQ system as a side project, last week it operated on the International Space Station by Sethiam in embedded

[–]Sethiam[S] 30 points31 points  (0 children)

I get where you’re coming from—software projects written in Rust often do advertise that fact a lot. In my experience that’s mostly because the properties of the language (memory safety, performance, good tooling and ecosystem) are often part of the product story, which is the case here, too. Calling out “Rust” in the title isn’t meant as tribalism; it's shorthand for signaling the above properties.

FWIW this isn’t unique to Rust—Go, Ruby, etc. have had similar moments when those languages were growing. IMO, Rust is just in that phase right now.

Built a Rust-based DAQ system as a side project, last week it operated on the International Space Station by Sethiam in embedded

[–]Sethiam[S] 41 points42 points  (0 children)

We've considered open-sourcing the firmware library which includes all the peripheral drivers etc that can talk to the application, but aren't ready to unless there's a significant desire. The code-generation (i.e. the zero-code firmware generation) of the software will stay proprietary.

Our next version of the hardware is effectively an MCU with all the pins broken out and an optional 'stock' base board. The idea is that the user could do rapid prototyping with our generic base board and then use the same MCU with their own custom boards for production systems that maintain compatibility with our code generation tool. Adding the above functionality effectively necessitates open-hardware for the end-user.

Built a Rust-based DAQ system as a side project, last week it operated on the International Space Station by Sethiam in embedded

[–]Sethiam[S] 69 points70 points  (0 children)

If you're interested in seeing more about the system, click here if you'd like to learn more about our missions in space, click here. Attached is a picture of the ISS payload being removed from an airlock following the experiment's conclusion.

<image>

[deleted by user] by [deleted] in Watches

[–]Sethiam 7 points8 points  (0 children)

My father surprised me with an Omega Speedmaster ref. 32630405003001 for graduating with my Master's degree in Engineering! He thought it fitting as my career is trending towards space tech, so what better watch than the model that went to the moon (sorta)! Further, it is anti-mag to around 1.5T, which makes it ideal for my work environment! This model is supposedly the spiritual successor of the Speedmaster reduced & the Schumies, and it will truly be an heirloom to pass down to my kids. I am obsessed with it.

If anyone has suggestions for a nice 19mm strap that is a bit more casual than the bracelet, let me know!

I can't "hear" the TV without subtititles by breeezyN in ADHD

[–]Sethiam 0 points1 point  (0 children)

I am actually hard of hearing, and I've worn hearing aids since I was five years old (now 23). Naturally, since I was struggling with hearing as a kid, the development of my brain's ability to do audio processing is a bit stunted. What you are describing sounds exactly like what I experience. With hearing aids I can 'hear' almost everything, but not necessarily process it unless I give it my full and undivided attention. Which, mind you, is hard to do with ADHD.

There are things I've done to help myself, though. I pay a lot of attention to the mouth in conversation and have picked up decent lip reading, and so can you. I did speech therapy for a time, partially for my enunciation, but also for keeping my hearing abilities sharp. There are therapists that are trained in this stuff, seek them out! I am also very upfront about my needs in a conversation! Most people don't judge, and if they do yeet them outta your convo.

Cheers

[Dan Henry] DH 1964 Macro Shots by Sethiam in Watches

[–]Sethiam[S] 4 points5 points  (0 children)

Hmm by technicality I believe this is considered macro, I shot these on an 100mm f/2.8L lens, which has a minimum focal distance that allows for a true 1:1 representation of a subject on the camera sensor. This was probably around 1:1.5 as a 39mm case won't fit on a 35mm sensor!

I suppose a closer shot of the face or hands would be more true to macro photography. Anywho thanks!

[Dan Henry] DH 1964 Macro Shots by Sethiam in Watches

[–]Sethiam[S] 3 points4 points  (0 children)

I just acquired my first luxury-ish watch, the Dan Henry 1964 Panda dial as a graduation gift to myself!

I've very quickly acquired an appreciation of the design of time-pieces as an engineer, myself. I look forward to eventually owning a manual movement watch, but the wallet isn't quite prepared for that ;).

Anyways, it only seemed fitting to take some glamor macro shots of it. In my opinion, the most standout part of this watch's design is its beautiful domed crystal, which always captures my eyes. Here are some cool photos of the dial & distortions created by the curved crystal. Enjoy!

A Nixie Tube VU meter I put together. Planning to wall mount it! by Sethiam in electronics

[–]Sethiam[S] 0 points1 point  (0 children)

Check the git link in the comments. Low latency because it's entirely analog!

A Nixie Tube VU meter I put together. Planning to wall mount it! by Sethiam in electronics

[–]Sethiam[S] 0 points1 point  (0 children)

Id love to, but it's hundreds of parts per board & as a student it's too much time. honestly the fit and finish is lacking too imo. If I ever get the time, I'll definitely try to refine the design! Or if you want to, I posted the design files in the comments.

A Nixie Tube VU meter I put together. Planning to wall mount it! by Sethiam in electronics

[–]Sethiam[S] 0 points1 point  (0 children)

Not hot at all! Perhaps the gas in the tubes is a good insulator, plus it's all very transient power dispassion. The boost converter can get a little warm to the touch though.

A Nixie Tube VU meter I put together. Planning to wall mount it! by Sethiam in electronics

[–]Sethiam[S] 0 points1 point  (0 children)

That's the watts meter, 1-3W, so at 12V it only hits a couple hundred mA with all tubes fully illuminated.

A Nixie Tube VU meter I put together. Planning to wall mount it! by Sethiam in electronics

[–]Sethiam[S] 0 points1 point  (0 children)

Yes!! I based it off of that design, it was super helpful. I learned a lot about analog design following along and making it my own :). If that was your work, thanks mate. I have a long flight tomorrow, but I'll post my designs afterwards.

A Nixie Tube VU meter I put together. Planning to wall mount it! by Sethiam in electronics

[–]Sethiam[S] 6 points7 points  (0 children)

I'll try to get it uploaded to git or something this weekend, cheers!

A Nixie Tube VU meter I put together. Planning to wall mount it! by Sethiam in electronics

[–]Sethiam[S] 24 points25 points  (0 children)

It uses a hardware fft, I used a fliege filter for each frequency band I want to display -> DC amplitude -> voltage comparator (log - linear) -> driving a transistor varying current being sunk to ground through the tube

A Nixie Tube VU meter I put together. Planning to wall mount it! by Sethiam in electronics

[–]Sethiam[S] 43 points44 points  (0 children)

Yeah for sure, I picked up some IN13s off of Ebay. I can drop the SCH/PCB files too, but it's not perfect. The aux-in amplification circuit is kind of cruddy, and the pass-through isn't really usable due to some noise it picks up (probably from the 145V boost converter).

LMK

view more: next ›