Not OP, but I can imagine piloting it with a temperature sensor: too warm=>increase speed. It could avoid some sweat-covered wake-ups, depending on the circumstances (trade it for a noise-triggered wake-up, perhaps).
Another use-case I have for this is in a house where the mezzanine gets much warmer than below when heating during winter: detect this with a couple of temperature sensors and turn the fan on when needed.
Funnily enough, I did almost exactly that last week, but I kind of gave up for now as my 433 MHz transceiver does not seem to work well with esphome? It does seem to output signals when I use the remote. Oh well, I will revisit when I have more time.
A major difference is that I relied on a flipper zero I had to do the 433 MHz capture instead of an RTL-SDR (I have one too, but have not needed it yet).
For reference, the transceiver is the one that came with this product: https://www.athom.tech/blank-1/8ch-inching-self-lock-relay-f... (which I already use for controlling a heater). Weirdly, it is not listed in the official esphome config (possibly because RF is a recent addition to esphome). My next step is to test it on another esp board & compare timings with what esphome generates.
I should start doing write-ups too. I came across quite a few interesting sources during this mini project (2-3 hours max).
2. Go to previous app view. This is app-dependent though it will probably, successively with each press:
a. Close menus if open (context, sidebar, etc)
b. Go to previous (web)page if web/file browser
c. Go out of submenus (ex: settings/WiFi -> settings) if not in a browser or if the oldest page has been reached. Keeps walking the tree upwards.
3. Reach the main app view (usually the one you land on when opening the app)
4. One more press minimizes the app.
It is fairly consistent, but some apps decide otherwise:
* some will minimize as soon as you press it (I've seen games do it)
* some will open a new menu (again, games: pause menu)
* some will seemingly walk you the history of visited pages instead of the hierarchy -- which may make sense but can be confusing
* some old apps will display a toast "press back twice to exit". This used to be common back when physical buttons were the norm, but I haven't seen this message a lot.
So, mostly consistent with some weird-behaving apps. Same as on desktop I guess?
Ah, that's interesting, the requirements are similar in the CAD industry. Dassault Design Sync is used a fair bit for semiconductor design databases, for instance. An open alternative would be welcome!
Edit: I do feel a bit uneasy about epic games, though.
I like Windward a lot, even though it does not feel like a complete game. It would benefit from a storyline IMO, and the dev has stopped updating it. I am longing for an open source project similar in scope.
Should I consider using Iroh for intranet communucation ? Is it a viable use-cases? The use-cases I have in mind is an app being deployed on a HPC cluster, onto many nodes, cut off from the internet.
I had been looking at zeromq, but I very much agree with using keys rather than IPs where possible (after years of using yggdrasil, wireguard, tailscale, tor), so I am tempted to try Iroh.
OTOH, this seems overkill if I'm using a client-server approach where the server IP is known.
Thank you for the detailed answer. This is an interesting engineering problem.
I wish I had more free time, a gearbox or a 4-way differential can probably be used on the extruder head to control the mixing ratios.
Regarding the necessary research, I can picture it being cracked either by hobbyists, or industrial-scale (patent-heavy) players. I imagine that consumer-facing players such as Prusa do not have the means to heavily invest in R&D.
Hence why I was asking the question, thank you for answering, I did not consider the high viscosity of the filament when I wrote this. As you say, it can be worked around, but that would require extra complexity/cost.
Thank you for the clear & concise answer. A rotating nozzle and/or alternating colors might work then, but that would be a relatively complex engineering project.
Hmm, I am not in the 3D printer space anymore, but I am surprised they went with alternating layer per layer, as that severely limits resolution. It's probably the simplest way to achieve reproducible results, but I can think of a few other ways:
* the simplest is just mixing filaments, like one mixes paint. The article doesn't spell out the reason it doesn't work, I am curious as to why.
* together with alternating layers, colors could be alternated in the same layer. Some purging may be necessary, but I think you could either: accept some mixing (compute its impact to compensate) / take into account the volume in the nozzle (extrusion "latency") / discard the unwanted part in the infill (at the cost of less smooth edges)
Of course, the hard work with any approach, including their current work, is calibration, as the article highlights. I wonder if off-the-shelf monitor calibration sensors could help with measuring the filament you have at hand.
I ended up being able to authenticate using a passkey, IIRC. Can't remember if that was my yubikey or bitwarden. I was surprised that it worked at all.
It didn't use to be complicated, but an update messed stuff up a few months ago (halo infinite).
I have been thinking about this for a while. It's not as crazy as it may sound, especially in light of the other comments making a parallel between terminals and notebooks.
A few thoughts:
1. Linux VTs kind of have this feature already: there is the normal buffer, the alternate buffer (that something like htop would draw on), and an IOctl can change them to/from graphics mode.
2. It makes sense for interactivity. Kitty's graphics protocol is quite useful for static shapes, can be abused for animations, but doesn't really cut it for interactivity (say, pan a graph around). Wayland is designed for this.
3. Wayland would be a good fit: isolate each command from another, let them request buffers, but keep control of where to display them, do not update them when off screen, etc.
4. One downside is that terminals excel for one-shot tasks. What's the purpose of the display when you are done with it? Should you kill the process driving it? Due to this, it may make more sense to delegate more features to the terminal emulator (displaying the 3D model, etc). Or maybe just allow the app to temporarily take over the window.
5. Once you have it up and running, have it talk directly to the direct rendering manager. Your "kmscon" is now your compositor / desktop environment. That's a fun thought! Add some basic terminal features like tabs and tiling, and you've inverted the usual setup.
6. One downside is accessibility. I really like that I can copy-paste any part of the interface for reference, "screenshots", etc. It's good for screen readers, too. You lose these advantages by going to Wayland.
7. Another current terminal limitation is fonts. Power line, yazi & other make use of custom fonts for drawing part of the interface, logos, etc. AFAIK there is no good way to query their availability (which is also an issue for color emoji). Custom fonts or a new protocol could be useful, but client apps could draw it themselves if given a surface (that can already do that with the kitty graphics protocol, mind you)
Obviously I am not seriously considering to make such a terminal emulator, but it would be an interesting experiment (heck, maybe something I should try this "vibe coding" with, since I wouldn't want to spend too much time on it).
Not sure why that happens, but you may want to try "borderless window" instead of fullscreen in the game options. If that does not work, you could try running the game in gamescope, or enabling the wine virtual desktop with winecfg (point it at your game-specific wine prefix, you can also run it from protontricks). These are just a few ideas, but it does sound like a mechanism that is part if the game, not wine. Just like some games crash when you alt-tab in windows; gamescope tends to fix that.
Thank you for the explanation, it was most interesting, I had no idea Bedrock could be coerced into talking to java servers.
Here are a few ideas:
1. Geoblocking. Not ideal, but it can make your resolver public for fewer people.
2. What if your DNS only answers queries for a single domain? Depending on the system, the fallback DNS server may handle other requests?
3. You could always hand out a device that connects to the WLAN. Think a cheap esp32. Only needs to be powered on when doing the resolution. Then you have a bit more freedom: ipv6 RADV + VPN, or try hijacking DNS queries (will not work with client isolation), or set it as resolver (may need manual config on each LAN, impractical).
4. IP whitelist, but ask them to visit a HTTP server from their LAN if it does not work (the switch has a browser, I think), this will give you the IP to allow, you can even password-protect it.
I'd say 2. Is worth a try. 4. Is easy enough to implement, but not entirely frictionless.
Ah, thank you for the example, I understand how a linearly-increasing counter can be useful, if you use it that way. It would obviously be more versatile with write access & configurable clock dividers, pre-setters, counting direction, etc. The current design probably allows re-using the counter across cores & minimize space, so makes sense to me. I should dig into the RTL when I have a bit of time… Maybe I'll make it my bedside reading?
You could also say it's up to the user to implement a fully-fledged timer/counter in a BIO coprocessor if they need one, though ideally there would be a shared register (or a way to configure the FIFOs depth + make them non-blocking) to communicate the result.
Small cores like these are really fun to play with: the constraints easily fit in your head, and finding some clever way to use the existing HW is very rewarding. Who needs Zachtronics games when you have a BIO or PIO?
This is true, but only relevant if you order enough units (>100 k? Depending on price & margin of course) to customize your die. Otherwise, you have to find a chip with the I/Os that you want, all the rest being equal. Good luck with that if you need something specific (8 UARTs for instance) or obscure.
Hey, glad to see you here. I'm a huge fan of your projects, and the Baochip was one I didn't see coming. Very nice surprise!
I ordered a few, thinking it would make a good logic analyzer (before the details of the BIO were published). Obviously, it's going to be a stretch with multiple cycles per instructions, and a reduced instruction set. I'll see how far I can push it if I rely on multiple BIOs, perhaps with some tricks such as relying on an external clock signal.
At first glance, they seemed to be perfect for doing some basic RLE or Huffman compression on-the-fly, but I am less sure now, I will have to play with it. Bit-packing may be somewhat expensive to perform, too.
One thing stood out to me in this design: that liberal use of the 16 extra registers. It's a very clever trick, but wouldn't some of these be better exposed as memory addresses? Or do you foresee applications where they are in the hot path (where the inability to write immediate values may matter). Stuff like core ID, debug, or even GPIO direction could be hard-wired to memory addresses, leaving space for some extra features (not sure which? General purpose registers? More queues? More GPIOs? A special purpose HW block?).
I really like the "snap to quantum" mechanism: as you wrote, it is good for portability, though there should be a way to query frequency, if portability is really a goal.
Anyway, it's plenty for a v1, plenty of exciting things to play with, including the MMU of the main core!
You can contact me at hn at mayeul dot net
I live in France, working for a semiconductor company.