AGUCUAGCAUAC

Woah! Congratulations!!! 🥳 🎉

Cool to see you here too! 😄

It’s spider season! That’s very normal in September/October. At least in the Netherlands but I imagine it’s similar in the UK.

I didn’t know about Foxes. I very rarely see them.

I’d be happy to contribute to a fedi-organized charity!

‘Christmas’ can create a bit of a split as there is a wide range of opinions on it, so you could also consider framing it differently if you are not attached to the Christian tradition. For me, I’m OK, Christmas or otherwise 😁

If fundraising you may want to put some effort in providing options that preserve anonymity considering that Lemmy has a large demographic of privacy-conscious individuals.

✌️😀🤘 💯💯 🎉

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.

Is it legal or technological?

Bandwidth is a resource that limits the amount of information that you can transfer per unit time. You can get a higher throughput if you can increase the information density or by using more bandwidth. Physically, both are possible. Increasing bandwidth of a 868 MHz radio signal is primarily limited by law, not technology. Increasing the information density is limited by the technology of the receiver, transmitter, and modulation.

As for Meshtastic, they often rely on the SX1261/2 chips that have a bandwidth limit by design. The people who manufacture that chip could design it to support a wider bandwidth, but it makes more sense for them to optimize the specs in a way that falls within the legal boundaries of the target applications. This comes from the chip’s datasheet:

So… It is both, legal and technological. The technology is designed considering the law. But it is not limited by the laws of physics.

And there is an additional layer of constraints that are imposed by the Meshtastic firmware itself.

The frequency ranges, power of the transmitter, signal bandwidth, the fraction of time that the transmitter is transmitting (duty cycle), and some other parameters are regulated. LoRa usually transmits in an unlicensed ISM region of the radio spectrum. So, you don’t need a license to transmit, but devices still need to comply with the regulations to remain lawful.

I’m not sure about the legal bandwidth limits in different locations. The commonly used LoRa chip (SX1261) can support up to 500 KHz bandwidth, and the OP mentioned 250 KHz as their limit.

According to the SX1261/2 datasheet, the maximum RAW bit rate of this LoRa chip is 62.5 kb/s for 500 KHz bandwidth and spreading factor of 5.

The bit rate is constrained by the spreading factor and the bandwidth. Bandwidth is constrained by law, spreading factor is constrained by design. You can find the details in LoRa™ Modulation Basics, AN1200.22, section 4.

For 250 KHz Lora, you can use the equation to get the theoratical max:

If we set SF = 5, BW = 250,000, bit rate is 39.0625 kb/s for a raw bit stream.

So, I think that the limit of 62.5 kb/s is a safe speed ceiling to consider. I am not sure how you would get 125 kbps using LoRa and current constraints. You could switch the chip to FSK mode and pull at 300 kb/s IF the FSK link is strong enough.

Fair point - I completely forgot to take the 3D geometry into account. I guess this could be solved by either making both sp³ (sub the Si-O with Si-Cl) or both sp² (sub the H-O-Si with H-N=Si)? But then writing data becomes more complicated than just adding or removing hydrogens that, as you said, isn’t as simple as it looks like.

I think that the solution that life came up with - making a flexible double helix-forming backbone from which base pairs hang is actually a pretty good way of going about it. Similar as with proteins - a standard flexible backbone with different groups hanging off the chain and influencing how it folds. In your proposition you have the silicon backbone and a single atom as the ‘side chain’, so there is no separation between the backbone and the pairing elements to add this flexibility.

There are also some other details to consider. For example, the amount of data you can store in a given chain length changes depending on how many different types of chemistry you have. In your example, you are using only one type of ‘base’ because the only options are ‘hydrogen bond donor’ or ‘hydrogen bond acceptor’. If you have a chain length of 3, you get only 3 bits, which can store one of 2^3 = 8 values from 0 to 7 (000 to 111). With DNA, you have 4 different base pairs, so a chain length of three can encode 4^3 = 64 values.

That means that, to get a good information density, you would also want to increase the number of possibilities. The challenge here is that you need to tune the set of possibilities so that the thermodynamics are balanced. You don’t want some pairs to stick very strongly while others stick only loosely, and you also don’t want certain bases to be able to pair with each other. See: https://en.wikipedia.org/wiki/Nucleic_acid_thermodynamics

You can perhaps dispense with some of the thermodynamic tuning if you don’t need to be able to easily replicate the data through a process similar to DNA replication, as you don’t actually need to ‘pair’ at all - you have a single string of data. But in that case you lose a very powerful method as you are forced to re-synthesize every data chain from scratch - I think that with such a system you lose too many benefits.

If you go through the steps of creating a system of molecular data storage from scratch, I think it is easy to converge towards something similar to DNA. A lot of ‘origin of life’ research is actually about this - thinking about these systems and how to engineer them from scratch, and… DNA is pretty good at this. When you consider that early chemical evolution was an optimization algorithm to solve this problem, it makes sense that DNA is a good choice.

I do think it is good and fun to explore this. We do have at least some advantages over nature - for example, we have managed to purify many compounds that were not abundant in early chemical soups. So, perhaps we can find something.

Like the dNaM / dTPT3 pair, right? That’s perhaps more viable, at least to increase information density.

Yeah, like those. In this recent paper, for example, researchers sequenced a chain of four anthrophogenic base pairs that they refer to as ‘ALIEN bases’: https://www.nature.com/articles/s41467-025-61991-9

The R2S=O case is closer to a trigonal planar geometry, the other silicon is tetrahedral. The silicon-silicon distances for different pairs of adjacent molecule types will be different. In a very very rough forcefield optimization I see about 3% difference. I don’t think this one will work out structurally because the chains will become unable to pair after a short length as the chain will not have the flexibility to create the O–H bond without adding too much strain.

But, that’s just one thing. You then need to consider how to actually selectively place/remove the hydrogen atoms, how to avoid the molecule from chemically reacting, and how to read out the data.

So, yes, eventually it would be nice to have a fully orthogonal system. There are already several synthetic DNA base pairs that can be used instead of the naturally present bases. But these would still be susceptible to DNAses or RNAses.

The way I see it is that the chemistry of living things is currently centuries ahead of human tech. A large portion of the techniques used in biochemistry rely on using living things to produce the components, and then we purify those components and use them. It makes a lot of sense to make use of that toolkit because the amount of challenges that need to be solved to create this system from scratch is massive.

Your proposal of your silicon chain reminds of the Ferroelectric RAM, where the state is encoded by the polarity of a cell that is changed by moving a zirconium or titanium cation:

This does work, but it works because the crystal is contained within a semiconductor scaffold, and this is something that we do have a good handle on.

Very cool!

I love this!!! That’s a very cool technique and you draw very well! 😄

Hahaha, didn’t mean to send a message 😆

Whether it “spoils” is a matter of perspective, this guy has a recipe on making a Shaggy Ink Sauce: https://foragerchef.com/shaggy-mane-ink/

It reminds of huitlacoche. I am curious if it equally delicious. I have only foraged them once and ate them fresh, but next time I want to try out this recipe.

Yes, you did!! 😀

I think this was the photo that I sketched on top of:

Wow! really really cool!!

Near my place there is a spot where the ‘Yellow Stainer’ (Agaricus xanthodermus) fruits. The yellow stainer becomes yellow when you cut it, and what makes it especially interesting is that the yellow pigment is an azobenzene derivative (4,4’-dihydroxy-azobenzene). Azobenzene is very well known in the field of photochemistry because it is a light-driven switch. But, in nature, it is extremely rare. I actually only know of this specific example…

So I am very curious about what the bright yellow is in this fungus…

According to this review on fungal pigments: Pigments of Higher Fungi: A Review

It appears that the main component of the yellow pigment could be a compound called ‘gomphidic acid’

This molecule is very similar to the molecule from the lichen that you posted a few months ago, vulpinic acid, except that one of the phenyls has 1 hydroxide group and the other contains 3 hydroxides.

This is the structure of vulpinic acid, for comparison:

I still don’t understand why Gomphidius has a yellow base, what about the metabolism of fungi makes them choose vulpinic acid-like molecules as pigments, and whether there is a functional reason why the yellow stainer uses an azobenzene derivative and this one a vulpinic acid… My current guess is that the metabolism to produce vulpinic acid evolved and is often recycled for pigment production, and that the yellow’s stainer is using the azobenzene as some form of defense mechanism (it would be very cool if it turns out to be a phototoxic one) and the yellow color is merely accidental in that case.

Wow. This is really magnificent work!! I just had a look through the Wikipedia article of Platynereis dumerilii and I can see from the citation list that you have quite a story with these guys 😁 It is very neat to see how you were figuring out this worm’s phototaxis in 2008 and by now you have figured out a map of the whole thing.

Looking at the movie and the paper I am very intrigued and also a bit intimidated by the complexity! I would really like to get five minutes to experience this worm through your eyes. I will set some time to go through this paper carefully and try to benefit a little bit from your insight.

Thanks a lot for sharing this here, it really is a privilege! Very very cool stuff.