About the SQLite database on SD card. I would try hard to not use this approach if not necessarily need. Because SD cards tend to degrade quickly and then what ... can the device work without it? Do I need to go to the customer to replace it?
Things are not black or white. The action I took was a necessary requirement at the time. I utilized the resources available to me, as I needed a quick solution for dissatisfied customers. Prior to the changes I made, I had an SD card with SQLite on it. So I didn't need to develop drivers or to do integration. At the end of the day, I performed several tens of writes daily. Therefore, if you do the math, you’ll find that you have more time than the expected hardware lifespan of 7 years.
@34:11 : Can somebody explains me how generating 10-50 fake frames simulates the long distance ? The data transmission rate (throughput) theoritically doesn't change based on distance. The amount of data sent in a given time frame would be the same, regardless of whether the distance is short or long. In other words : What are the nuances to consider in long-distance wireless communication that can justify a simulation like the one Miss Kamma is conducting ? The only thing I see is that the latency and propagation time increases. This leads to an increased buffering. But that's not clear to me. I work with wireless communication and never had such a Thing. @community : would you be nice to explain this to me ? Regards
I agree, you also need to incluye link and system level simulators which account for the propagation channel, antena, and RF chains. Of course, this demands an HPC setup to properly validate latency and reliability. Not trivial at all. And many companies tend to outsource simulation overseas, which in turno also subcontracts until no one knows exactly whose responsibility is.
It makes sense if "meter" is not the 'unit of measurement' but a 'measuring device'. In other words, 5000 measuring units reporting to this device, rather than 5km distance.
My aim wasn’t to simulate either long or short distances. My main focus was on simulating the load on the software. I chose to do this through software, as it’s cost-effective and quick. The RF hardware wasn’t the issue, the software was the bottleneck, particularly in managing and transmitting the necessary data. When I simulated the reception of additional frames, it created a load on my software. Instead of managing 300 meters, it had to handle 10,000 meters. As a result, the processes took more time and required more space, proportional to the number of meters involved.
If you venture back to 7:26 you will see that the presenter is talking about two things. One is the measuring unit which the presenter refers to as "meters" and it collects measurements in distances in the unit meter. So when the presenter says "built to work with 1000 meters" I honestly believe that it means "built to work with 1000 measuring units". Which, if true, means that when we head back to 34:11 it is essentially just adding more data at the point in time. My assumption is that this simply is a load problem, not a distance problem.
@vladimir0rus The concept here is that we identify the start of the message using a prefix. After that, we read the length and then verify that all the content matches the CRC at the end of the message. If the prefix appears in the middle of the message, it doesn’t matter because we only look for the prefix when we start searching for a new message. Let’s consider the worst-case scenario: we don’t see the prefix at the start of the stream, so we go over the byte until we find it. Then, we search for a valid message. If it’s not valid, we discard the prefix we found and start looking for a new message again. The likelihood that it will resemble a valid message but isn’t is pretty rare.
Wonderful presentation, I consider watching this video should be a mandatory task for the first or second lecture in an embedded systems course.
6:25 thread.
12:14 hardware layer seperation.
18:05 network
19:00
29:00 simulator 35:13
43:40
Great talk !!!
Thank you for great common sense talk!
45:00 In a case of monitoring it is better to have metrics/telemetry instead of logs. You need logs for investigation of production issues.
About the SQLite database on SD card. I would try hard to not use this approach if not necessarily need. Because SD cards tend to degrade quickly and then what ... can the device work without it? Do I need to go to the customer to replace it?
Things are not black or white. The action I took was a necessary requirement at the time. I utilized the resources available to me, as I needed a quick solution for dissatisfied customers. Prior to the changes I made, I had an SD card with SQLite on it. So I didn't need to develop drivers or to do integration.
At the end of the day, I performed several tens of writes daily. Therefore, if you do the math, you’ll find that you have more time than the expected hardware lifespan of 7 years.
You right, but mitigation is using large SD card and wear leveling filesystem. Then replace it regularly.
@34:11 : Can somebody explains me how generating 10-50 fake frames simulates the long distance ? The data transmission rate (throughput) theoritically doesn't change based on distance. The amount of data sent in a given time frame would be the same, regardless of whether the distance is short or long. In other words : What are the nuances to consider in long-distance wireless communication that can justify a simulation like the one Miss Kamma is conducting ?
The only thing I see is that the latency and propagation time increases. This leads to an increased buffering. But that's not clear to me. I work with wireless communication and never had such a Thing.
@community : would you be nice to explain this to me ?
Regards
I agree, you also need to incluye link and system level simulators which account for the propagation channel, antena, and RF chains. Of course, this demands an HPC setup to properly validate latency and reliability. Not trivial at all. And many companies tend to outsource simulation overseas, which in turno also subcontracts until no one knows exactly whose responsibility is.
It makes sense if "meter" is not the 'unit of measurement' but a 'measuring device'. In other words, 5000 measuring units reporting to this device, rather than 5km distance.
I just don't understand why multiplicated frames simulates sites with long distances.
My aim wasn’t to simulate either long or short distances. My main focus was on simulating the load on the software. I chose to do this through software, as it’s cost-effective and quick. The RF hardware wasn’t the issue, the software was the bottleneck, particularly in managing and transmitting the necessary data.
When I simulated the reception of additional frames, it created a load on my software. Instead of managing 300 meters, it had to handle 10,000 meters. As a result, the processes took more time and required more space, proportional to the number of meters involved.
If you venture back to 7:26 you will see that the presenter is talking about two things. One is the measuring unit which the presenter refers to as "meters" and it collects measurements in distances in the unit meter. So when the presenter says "built to work with 1000 meters" I honestly believe that it means "built to work with 1000 measuring units". Which, if true, means that when we head back to 34:11 it is essentially just adding more data at the point in time. My assumption is that this simply is a load problem, not a distance problem.
Very interesting talk. She is also a fantastic speaker - very good at communicating simply and maintaining engagement.
Very useful talk.
38:00 Why do you need any real HW to simulate lots of messages? It should be possible to use SW simulators and integrate them to CI/test pipeline.
Great talk! Thanks for sharing
Great talk, thanks.
Thank you for the talk, it is very useful and easy to understand.
28:00 What if data will contain a sequence equal to prefix? Or even worse if a part of the header will form such sequence?
@vladimir0rus The concept here is that we identify the start of the message using a prefix. After that, we read the length and then verify that all the content matches the CRC at the end of the message. If the prefix appears in the middle of the message, it doesn’t matter because we only look for the prefix when we start searching for a new message.
Let’s consider the worst-case scenario: we don’t see the prefix at the start of the stream, so we go over the byte until we find it. Then, we search for a valid message. If it’s not valid, we discard the prefix we found and start looking for a new message again.
The likelihood that it will resemble a valid message but isn’t is pretty rare.
very intresting, i work in roobotics and we have similar issues just more complex
same! i am looking at you, rosserial!
Wonderful talk.