Yes, there is a lot of potential. There are micro-spectrometers available covering this range, like the MEMS-FPI type spectrometer or the multi-pixel arrays with filters (example: https://www.mantispectra.com/products). But this new kind of detector seems to come with higher resolution, faster readout than the MEMS-FPI, and more sensitivity. It is quite exciting, I’m curious to see if they commercialize it soon.

I am not 100% sure, but I think that the designer bears the cost of the wafer yield.

The PDK is specific to the manufacturer, and I imagine that the risk associated with specific features is known and the yield range can be estimated. A design with more and riskier the features would lower the expected yield, and it makes sense that this risk gets passed onto the designer. The contract may have some protections for the case when the yield is significantly lower than expected because of the manufacturer’s fault. Just a guess though, it would be great if someone with real experience can answer.

Very cool!

I also like that they included a device cost analysis. I think they used some aggressively optimistic assumptions (100% yield from the wafer) and large-volume procurement prices that I am skeptical of, but if true it is valuable info.

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

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.

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.

I do have a wall with similar boxes. From the image, I am not sure if they are the same size. I just measured one of my small drawers and it is 14 cm x 5.5 cm x 5 cm. Since I have many different tiny components, I quickly ran out of space when I tried to give each component its own drawer.

But I think that I might be able to do a better job with these if I take everything out and start organizing again. I set the rules for how to place things before I started buying SMD components, and many of the through-hole components I can combine without problem. An improvement would be if I can find something like this but with many more and much smaller boxes.

I’d rather pay for preventing the front passenger from reclining into me.

El del presidente de los eeuu no lo vi… Cual es? Mi favorito es el de Willem Alexander: https://www.youtube.com/watch?v=HbgPqccCQcs

Jajaja, al menos lo intentó 😅 Un 8 por el esfuerzo!

✌️😀🤘 💯💯 🎉

It seems like as of right now meshtastic devices don’t have the ability to finely control LEDs/button actions to work for my use case. Which is a shame since I was hoping I could just buy a meshtastic device that has some programmable buttons inside a pre-built enclosure.

Maybe they do have that ability already. I am not sure. I have mostly used Meshtastic devices for communication and I have played a little bit with LoRa modules for more basic sensors and logging. Perhaps someone else knows more about the Meshtastic-specific features when it comes to telemetry and triggering devices.

Hmm this is what I think about this:

On the device by the gate:

Continuous loop:

• Switch to transmit mode

• Check if the gate is open or closed

• Transmit the result

• Switch back to receive mode and wait 15 seconds

When a message is received:

• Run a security check

• If the message is the Open or Close command, forward it to MQTT

On the device in the car:

Continuous loop:

• Decrease the timer value

When a message is received:

• Set connection state to connected

• Enable the Open/Close display and set it to the received state

• Reset the timer to 45 seconds

If the timer ends:

• Set connection state to disconnected

• Disable the Open/Close display

On button press:

• Stop receiving

• Generate a secure message (Open or Close)

• Transmit the message

• Resume receiving

Option 1: Use an ESP32 with WiFi and a LoRa module near the gate. This device can handle both the LoRa interface and the MQTT push with relatively simple firmware. For the device in the car, WiFi is not needed, so you can choose any microcontroller and a LoRa module.

For the interface, LEDs are the simplest. Map the GPIOs to four LEDs (Red, Green | Red, Green). For example:

• Red and Off = Disconnected

• Green and Red = Connected and Closed

• Green and Green = Connected and Open

Two more GPIOs in input mode can handle the two physical buttons for Open and Close.

If you want a screen, there are many options. You can use a small OLED, touch screen, or colored E-Ink. The choice depends on whether the car device is battery powered or has constant power, and how much complexity you want in the code.

Option 2: Use Meshtastic. The device by the gate can be connected to something like a Raspberry Pi, and a Python script can process incoming messages and handle the heartbeat transmissions. Meshtastic gives you some built-in security, but you still need to be careful. The difficulty is keeping track of the connected state and the Open/Close state from the heartbeat, and then mapping that to a display or LEDs. That would probably require customizing Meshtastic firmware.

Because of that, I think writing custom firmware is easier than trying to adapt Meshtastic for this use case. BUT - I have not been keeping up to date with the newest Meshtastic versions, and I don’t know all of the sensor-related features. So it is possible that there is already some built-in method that replicates this and I just don’t know about it.

I agree. I think that a firmware update taking several minutes to complete would be alright. If loss of service is a concern, they can keep more than one device at the tower and one acts as a backup while the other updates.

One problem is that the data rate I quoted is the maximum capacity for a continuous stream. In practice, that is often illegal due to duty cycle rules. So, you might get 40 kbps while transmitting, but local laws may let you transmit only 1% of the time. If you choose to be obedient it will take a lot longer to get the firmware across.

Even then, let’s say it takes a few hours to get the full firmware, I think this can be alright for sporadic firmware updates.