Embedded rust: reading temperature and humidity using a AHT10 sensor and a CortexM0

[@glebvlasov9573]

Can you make a series of RTOS embassy tutorials?

[@mehrdadanvar8518]

Hi Andri, I just found your channel. perfect content and though complicated for beginners like me. I have a question for you

[@embedded-rust]

Hi, this is a very late reply, however what is the question? (i.e. consider nohello.net/en/ since this communication channel is very async)

[@mehrdadanvar8518]

@@embedded-rust I don't understand the website

[@embedded-rust]

@@mehrdadanvar8518 I meant "please ask your question" without me prompting :) since you originally said "I have a question for you" but you did not seem to elaborate

[@mehrdadanvar8518]

Imagine that ee want to hypothetically design a system in industrial places which are often remote areas with harsh working conditions like oil rigs. this system is supposed to gather information on where the personnel are around the ship or around the rig, in case of an emergency like a fire, or toxic gas release. imagine that we have sensors like smartwatches around the wrists of our personnel and a bunch of receivers or modems around the workplaces. These modems or devices can constantly send signals or receive signals from smartwatches. How can we consolidate all of them in one server which reads data from multiple sources? what programming language or frameworks do we use for such purposes. How can we match our hardware with software that can read live sensor data and analyze it in real-time? In the case of web programming, for instance, we can write a server that is listening for incoming HTTP connections, but I do not understand how we achieve this with the above scenario!

[@embedded-rust]

That question probably has very non-trivial answers. I would start by trying to decompose each requirement. The sensors seem to be embedded devices that need to be very reliable and predictable, so probably some RTOS/embedded device that is highly specialised. Next you need to figure out how these embedded devices communicate with the outside world and this will probably depend on the embedded device constraints (some devices may be plugged in/on the wall, others may require to be battery operated) - wifi is easy but power hungry, then there are things like thread that are less power hungry. You would probably want some consolidated sever to receive the data and the forward it. You will have to solve any caching, redundancy and maybe notifications if sensors are down. Overall I would try to decouple the "sensors communicating to a server" from "server processing data, consolidating ,reporting, notifying". You could try to solve the sensor communication first. If you pick say thread, make sure the MCU you picked can talk thread, setup a thread border router and get the MCU to send packets to a server running on a linux machine. The sensors could at first send unencrypted "ID + sensor+reading" packets and once you see that working, you can start worrying about what to do from there (getting a real protocol working, maybe encryption, over-the-air updates, start building up server side consolidation). So once you define the radio you want to talk, you have to figure out what microcontroller to use and get a development kit and try it out to see if it works for you (and if there are several choices - there usually are - pick based on features/cost/availability) In terms of scaling, I think a small linux machine can hande a LOT of mcu data, so you just need to worry about redundancy / failover.