Very cool! What a wonderful game. The Wireless Data Transfer level is unreal.

I am trying to see if I can build some small mechanism that resembles the ATP Synthase mechanism… Perhaps a bit too ambitious of a starting point, haha. The program runs smoothly in my Linux machine.

Yes, this is a problem that happens with a lot of detector types as one tries to push them to detect lower energies.

In this specific case, light is captured by a retinal molecule that is held within an opsin protei and this excess energy allows it to twist. The opsin protein envelope tunes the environment around the retinal molecule such that it absorbs photons of specific colors. To tune these to lower energies means altering the energy landscape in a way that makes the twisting of the retinal molecule require less energy. Temperature is a measure of the kinetic energy of molecules, and some molecules at room temperature can move with kinetic energies that match the energy of infra-red and sometimes near-infra red photons. So, from time to time, molecules with enough kinetic energy may collide against the protein with enough force to induce the twist without light. Absorbing near-IR light would lead to an increase in thermal noise, because the opsin becomes activated by a collisions more often as opposed to light.

Here is an image showing the retinal twisting and the energy landscape. The ‘hv’ arrows indicate light absorption, and the opsin’s structure alters the energy curves.

The core-shell upconversion nanoparticles are special in that the photoactive region in the core is protected from the environment by an inert transparent shell. Light can pass through the shell and create localized electronic excitations within the core, while it is much more difficult to transfer the energy from a molecular collision against the outer layer into a localized excitation in the core. This shell is a strong dampener that protects the core from external influence.

Here is an example image of the core-shell structure, for reference:

What is the justification for selecting the range 2022 - 2025? I suspect that this is cherry picking.

One of the data sources they reference is: https://www.cdc.gov/hantavirus/data-research/cases/index.html, this site has data up to 2023 (I could not find 2024 - 2025). Here is the plot of the total hantavirus cases in the US vs year:

The number of cases vs year is rather noisy, and 2022 was a particularly low year. Saying that there is a ‘192% increase’ might be technically true but misleading.

If you are looking for eye bio mods you might also like this one: https://www.sciencedirect.com/science/article/pii/S0092867419301011

Not yet, unfortunately… But knowing more about what might be happening in the brain to cause it increases the probability that a cure will be found.

Definitely, disclosing (either private or publicly) a vulnerability that has been verified is significantly better than passing on the LLM output without verifying it.

It isn’t my intention to argue one specific case. What I think is that normalizing public disclosure of LLM-inspired vulnerabilities would lead to a wide distribution of cases. We would have some successful cases like yours, and also some cases of the type that I have mentioned. Increase in disclosures will raise the noise floor, and the fact that it is done publicly adds the additional pressure that I mentioned.

I see your point, but I don’t agree that the benefit of public awareness offsets the increase in noise. This disagreement isn’t rooted in aspects that we can objectively quantify though - we just have a difference of opinion here.

And in that world, doing a private disclosure made a lot of sense because you did a lot of hard work to find it, and it wasn’t easy for somebody to replicate. This was valuable and dangerous knowledge that had to be communicated in a responsible fashion.

Private disclosure still makes sense to me when you add LLMs into the mix. It is possible that an LLM outputs some plausible-sounding story that over-estimates the actual risk and impact of the exploit. If this story is publicly announced to people who use the software but are not capable of assessing these risks themselves, this can easily have a negative unnecessary consequence - for example, people may bring their server down until an expert or developer provides an assessment or fix.

This is a source of noise, and I don’t agree that this is better than private disclosure. Via public disclosure one is applying a lot of pressure to the developer(s) to prioritize whatever is being disclosed, which may not always be the nicest thing to do, especially if the impact is not as significant as the LLM suggests. This may not have been what happened in your case (I don’t know the details), but I am thinking about the idea of the average person disclosing publicly LLM-discovered vulnerabilities.

All volunteer efforts are welcome, and using AI tools to support volunteer work is completely reasonable to me.

I personally value well-crafted human-made art more highly than AI-generated art. If someone wants to invest the time to create original icons and donate them, I am always very happy to see that!

That said, requiring unpaid contributors to meet a craftsmanship standard before they are allowed to help does not seem constructive to me. Volunteer communities usually work best when people contribute with the time, skills, and tools they actually have available.

A middle-ground alternative to AI-generated work is searching through Creative Commons assets, but even that still takes time to source, filter, adapt, and integrate. Expecting volunteers to always provide fully custom artwork or spend significant additional time curating assets does not seem like a fair expectation to me.

Sorry, I missed this! But I think that this is due to bots. From time to time, bots attempt to scrape the instance and this makes the site a lot less responsive.

I try to manually block these IPs, but sometimes new IP ranges show up.

In photonic integrated circuits, laser light enters some input port(s) and then travels through optical “wires” called waveguides that are arranged in ways that manipulate the light before it is finally detected using photodiodes.

In this paper, the main idea can be understood from Fig. 1a. A single pump laser with frequency νp enters a straight waveguide, but it is also coupled into three small loops called microring resonators, and there is an output port at the bottom right.

These rings are resonators because certain wavelengths of light can circulate around the loop constructively. In other words, after going around the ring once, the wave comes back in phase with itself and reinforces itself. The rings also have tiny heaters (resistive electrical wires) attached to them, allowing their resonances to be tuned slightly by changing the temperature.

What they show is that, using only one pump laser and careful tuning of the rings, the system can generate additional frequencies besides the original pump frequency.

This relies on nonlinear optics. In ordinary linear optics, the material response follows the electric field linearly, so light mostly stays at the same frequency. But in nonlinear materials, the response depends on the field strength itself, allowing the pump light to generate additional frequencies (“colors”) through nonlinear interactions.

A lot of the terminology in the paper like Kerr effects, χ(3) nonlinearity, four-wave mixing, parametric gain, idler frequencies, and cross-phase modulation, refers to different aspects of these nonlinear interactions.

The end result is that this optical component can generate multiple sets frequencies from a single input laser using these coupled nonlinear resonators.

Here is the homepage, and that is not what it says: https://meshtastic.org/

I promise you I am not lying to you. I may be mis-understanding you.

Here is the source code for Meshtastic firmware: https://github.com/meshtastic/firmware

But I am assume that we have a different understanding of what is and what isn’t open source.

Don’t worry, I wouldn’t ban you for this.

Yes, the physical modulation implemented by LoRa transceivers is proprietary.

It is not entirely correct to say that the “mesh” itself is proprietary. Meshtastic is open source, even if it relies on proprietary radio hardware. In principle, one could take the Meshtastic codebase and adapt it to a different physical layer.

It is perfectly reasonable to reject a technology because the full stack is not open. That said, once you look closely at most modern digital and RF hardware, you are extremely likely to encounter proprietary ICs, firmware, or physical layer implementations somewhere in the stack.

I’m not familiar with Canadian suppliers, sorry. I have bought directly from them in the past, but I’m not sure about shipping to Canada.

Yes, you have many options. It depends on how much “from scratch” you want to go.

The simplest method is to purchase a module with the radio transceiver + microcontroller, flash it, and assemble it. If you don’t want any sensors, you can for example purchase from RAK the kit a kit with a ‘RAK19003’ base board + ‘RAK4631’ module (nRF52840 micro-controller + SX1262 transciever) . For Canada, you would pick the 900 MHz version that operates in the 915 MHz band. (https://store.rakwireless.com/products/wisblock-meshtastic-starter-kit?variant=43884035113158)

For an enclosure, you can look up ‘Project box’ or 3D print a case.

If you want to go even more “from scratch”, you can buy a module without a micro-controller (Waveshare core1262, Ra-01SH, Wio-SX1262), and interface with these using a micro-controller via SPI. At this layer it starts to become more of a hassle if you want to implement Meshtastic, because you will need to either copy an existing configuration, or modify the firmware so that it matches the way that your electronics are connected.

Then, if you do not want to purchase a module, you would buy the transciever directly (for example, the SX1262), and assemble your own module. You can look up the schematic of the basic modules to get an idea of what this looks like. For example, you can see the Waveshare Core1262 schematic here: https://files.waveshare.com/upload/c/c1/CoreSX1262_Sch.pdf

If you do not want to rely on an already existing LoRa transciever, but instead use a more general radio transciever, that is also possible. But, more expensive, and is unlikely to match performance. This is something that one might want to do if you already have an SDR transciever connected to raspberry pi and want to use it to interface with LoRa (still, it is much easier to connect a LoRa device over USB). I would not recommend building a meshtastic device from more general transcievers.

About the immortality of the crab

They are banned

Not really, no

Since my work involves sensors, I set up a continuous testing setup on a raspberry pi and got its IP whitelisted. I ssh into it when something is annoying to do in the Windows laptop.

I’m surviving, and definetly not the fittest.