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.
I could see the credits for “Everything’s Gonna Be Alright” in Deezer, but I am not sure about how exactly Deezer determines this: https://www.deezer.com/us/album/951602381
I would make use of a VPS to serve a directory with the files using Nginx. The VPS is ~$5 /month. You can share the ip or buy a domain name for ~$10/year. If you are not opposed to vibe-coding, you can probably generate the Nginx + HTML config to play through the songs without having to click them individually with little effort.
Wait what, how do you know my code?
Also: I use the timer very often, and I find setting a timer on a phone to be more awkward.
Sport watches.
Combination of two tings: I used to think that wearing a watch was irrelevant because I could always see the time in my phone. And I did not want to have an app knowing how many steps I take.
What changed a few years ago: I stopped having a phone on me most of the time, so a watch became extremely handy for knowing what time it is, and I found out that Garmin watches work perfectly well without an app. So, now, I really like my watch. I am considering getting a fancier one with solar charging, and I even got a chest strap to improve measurement accuracy while running.
Very interesting! Thank you a lot for finding and sharing that, I couldn’t find any good info myself via online searches.
The song Everything’s Gonna Be Alright is a cover of the song from Sweetbox (1997) that goes by the same name and is based on Bach’s Air from Orchestral Suite No. 3…
I think that the rest are originals. Not 100% sure. I am surprised by how little information they made available, they just randomly dropped this with no context after almost a decade since the previous one. I ordered the physical album so hopefully it comes with some additional info haha.
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.
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.
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.
Is your friend alright?