 can everyone see this? Okay, yeah, hi everyone. So, yeah, so I'm here to present Trace Sigma. This is a team effort by Team Better. So we can check out our website. There's nothing much right now. It's really a placeholder. And I want to talk a bit about like our journey and some technical in-depth on like our design decisions and how we came about wanting to do this. So just to talk a bit about Better, it is a, I just created this team like about a few months ago. It's a bunch of people who come together and we decide that we want to actually build open source projects to actually like open source projects which are well engineered. Right, so a bit about team. Our goal is to build open source projects with good engineering practices, which means that we have proper design and planning, code reviews, continuous integration, you know, and continuous testing. Of course, not everything is implemented at the moment, but you know, I often draw like lessons from my past experience or even as my, yeah, don't worry about the screen translation because of the different aspect ratio. Yeah, yeah. So as my experience as a software engineer, okay, the team has a couple of people, it is pretty distributed. Like I think three people are in Singapore, the first three are in Singapore and the last three are here in the US. Okay, our goal for Trace Sigma is to really to build an open source reference hardware to eight standalone contact tracing applications. For example, like today when we want to do contact tracing on the standalone piece of hardware, there are not many designs out there, you know, where you can just take and modify. No, they probably have different goals as well. So the direction we approach this is that we want people around the world, okay, to be able to easily source components later you'll see why easy sourcing of components is important. It has to be easily reproducible, right? So, you know, we talk about having a 3D printer or some simple molding facilities, you should be able to create the mechanical case, for example. By extensibility, we sacrifice size, it is not particularly tiny, but it also has a lot of capability, especially when we choose to use the ESP32 platform, right? It's not a particularly power energy efficient platform, but it does come with a lot more compute resources. Initially, so this is our goal for Trace Sigma, right, the V0 version is it kind of like looks like pager, you know, the goals, the design goals were to have it purely self-contained, no mobile app should be required, right? It should be like a belt clip where let's say someone who is working in healthcare or construction would just like clip it on the belt and go about doing their work, right? You know, it has a decent runtime of about seven days, right? Definitely, we wouldn't have a great runtime of, let's say, five or six months, right, of the trace we are token, but we, seven days is pretty, is a good goal for a start. Data retention, 21 days. The benefit here is that we actually have like Wi-Fi and optional GPS and by being completely compatible with OpenTrace and the ability to have custom apps and add-ons, it really gives the users a lot of freedom to like extend this to their own use cases, right? For example, if let's say we want to have this device, let's say, I don't know, like someone who needs to log temperatures of, let's say, staff at an entrance, right? This could be embedded with a NCRR module and it becomes a handheld temperature logging device, right? So we started back in, I think, around April or so. I was talking to a couple of friends who were working on trace together, the app, and there was about the time when they were proposing that, hey, iOS had these issues of being able to keep the app in the foreground, hardware solution was, potentially, would solve their problem. Now, I was looking around, and I basically saw this device called the M5 Stick C and I was pretty, like, intrigued. Like, it has like so many things squeezed in a small form factor and it only costs 10 bucks, right? The downside is that that device has, like, almost no battery. I think it has like an 80mAh battery in it, but yeah, it's as good as nothing. So we, there's basically some add-ons sold by the company. Now, I was evaluating this, all right? I have one on my table over here as well and I was thinking, hey, this could work. There's a 2000mAh LiPo cell in there, right? And so it looks like a stick, right? So I call it a trace stick. But after like some brief evaluation, I'll talk to some friends, right? They're saying, hey, this is kind of large, you know, could we do better? Right? And I agree that we potentially could, you know, have something more integrated. There's actually a lot of airspace within this off-the-shelf prototype. So, you know, I want to increase the battery run time, right? By increasing the battery run time, it means that we can beacon at a more frequent rate. So version 0.2 here basically uses pouch cells. It's closer to the 3D rendered model over here. Downside is that when I was sourcing pouch cells, I came to realize that it is not that readily available. Like people don't sell this on eBay a lot. You try to purchase from China. They'll say, hey, you need to buy like this many units, right? And second thing is that it has wires. So it's really not that ideal in terms of like trying to integrate everything. And if you think about the assembly line, right, having like wires over here wouldn't be very good. Yeah. Right. So 0.3 that I have not as I completed the mechanical design will basically use the 21700 cell, 5,000 milliamp hours. It only costs a couple of bucks. And the main reason why, like this is like a sweet spot for lipo cells. Okay. In general, instead, these cells are actually used in EVs, for example, like Tesla vehicle. They use thousands of 21700 cells. I'm not sure what today, but in the past they did. Right. And they also use in many other equipment, like your battery-powered tools, et cetera. Right. And they're really easily sourced. And the power density is really a lot better than the pouch cells or even your supposedly common 18650 cell. Right. These actually have 18650 kind of cap out around like 2000, 2005 milliamp hours. So this basically gives like double the amount of energy with a like a two millimeter, a three millimeter increase in length. Yeah. So, you know, potentially I could improve on the previous iteration by wrapping a case around this. Right. And looking in future, right, of course, we can't put, we can't possibly, I mean, having a M56C-based design is great. But, you know, we could also improve on this, right, by having a purely custom PCB, because like you can see the, I did a brief tear down of the M56C. Right. There are many unrequired components in there. There's like microphone, there's like IR transmitter. And we don't really need all those things. We really want to keep the screen. All that screen is great. And we want to be able to increase the flash from like format to like 16 meg. Right. And the current design, you can see users like for their two layer PCB, we could potentially shrink it down a lot into like a four layer PCB as well. Yeah. And without the external orange case, orange is a really ugly color. But, you know, we work with what we have. Right. Yeah. So let me talk a bit about the software architecture as well. So unlike many other hobby projects out there, we set out to engineer this well from a software point of view. Right. Which means layers, layers and more layers and modules. Right. We use the Arduino ESP32 instead of the IDF because it's just a bit more accessible to the maker community. Okay. We implement the open trace V2, VLE in there. And we have like three tasks running. Right. There's like a little, what do you call it, real time RTOS system in there. We have specific tasks to run the user interface and the command line interface loops. And on top of this custom applications could actually ride on top of the user interface loop to, for example, I could implement a step counter. Someone else could implement Pokemon or Digimon. Right. Those like simple games in the early days. Yeah. And the over here, we will take a look at like the other various modules we have. If you look at the code base, you'll be able to see like, it's kind of like arranged in this manner. Right. We have the UI, finite state machine. We have open trace V2 implemented in C++. It wasn't fun converting Kotlin. Kotlin is the Android implementation of open trace into C++. Power state machine basically allows us to have like different power states, which I'll describe later. IO, handling event driven, interrupt driven buttons and screen. Storage is pretty interesting. We have like four or two megabytes of accessible flash for custom data. For example, like the encounters. Right. Yeah. So the command line interface here, we sought out to design it to be, to support automation because our test drivers will be using the command line interface to customize the device to run tests, to run commands like say, I don't know, probably like activate Wi-Fi or something like that. Right. So having a command line interface over serial is useful not only for automation, but also for potentially administrators or technical users could configure it for their non-technical friends or users. Extensibility, which means that custom applications can just add commands in there. This uses the ESP32 command line framework. So extending this is not tedious. The user interface, you know, this actually has a RGB OLED screen, but I don't really care about that at the moment. Right. What I really like about this screen is that it, I can turn it off. I can turn it off, I can dim it. So we actually implemented all of those on our initial version. In the low power mode, you know, if the user chooses to turn on the screen, it turns off automatically. You know, you could have custom brightness levels as well. Right. Because I think there's like seven levels of brightness they can choose from. Yeah. And also the user interface has, we do like event-driven refresh. So if there's no animation, if there's no action, no compute power is spent refreshing, redrawing the screen. Yeah. In terms of storage, now I kind of like underestimated this part on my end, like initially when I sought out, you know, I was thinking like, hey, storing encounters, let's say, you know, if I walk past another guy with a Trace Together app on the phone, I thought that storing encounters is easier. People are just talking about like, hey, just log all the messages in flash and you realize that it's stupidly inefficient. Right. So we, it's inefficient, not only in total space, but also in terms of ride cycles. Now, Flash has a limited number of ride cycles. You don't want to write every single thing you hear on radio. So we have to cache. Okay. So we took it, we take a look at the right side over here. When we appear, appear is basically like an encounter. The first level of cache basically holds it purely in memory. And we define a encounter, right, as anything, any peer we observe for more than five minutes. So which means that we drop encounters which are less than five minutes consecutively. And if the appear is observed for more than five minutes, we'll actually put it in the second level cache, which creates a mapping on Flash. You look at the code, there's like a two level mapping of like 10 IDs to, Luther, I thought it was 15 minutes. Yeah. Oh right, it is 15 minutes. Sorry. Yeah. I just go through this really quickly. Yeah. It has like different levels of cache. In terms of power states, you know, I have multiple power states in order to conserve energy. In terms of battery, we try, we try to optimize the cell life by capping the maximum and minimum voltage they operate within. Yeah. I also have plans to set up like a test farm where we will get up with GitHub to basically do CI CD over here. In terms of beaconing, the key differences is that we scan really often at least once a minute, but we transmit every two seconds. We may increase transmit frequency. So what happens is that we can't really observe clients more in a more timely manner. Yeah. Any questions from the public? No. Sorry, right at the end, you're talking about five seconds every 600 to listen. Yeah. That's the second one percent. Have you done modeling on likelihood of an encounter being detected? For, we've like a two-second interval of transmission. Yeah. Not really, not really. I mean by, I'm sorry, I'm sorry, I misread. No, see what's wrong. The token is 10 seconds of every 300. Still lower than what you're doing. But yeah, it's a 3% duty cycle. Sorry, I misread your thing, but that was the token, not your product. So the processing of the token is 10 seconds of every 300. It transmits every half-second. Yes. Oh, okay. So 10 seconds can every five minutes? Every five minutes, yeah. What I'm asking is, so you are transmitting a quarter frequently, but you're scanning 10 times as much of the time. Have you modeled the likelihood of an encounter being detected by Bluetooth? Not really. I mean, I purely did like tabletop tests. I have like five devices over here. Yeah. There's a lot more technical details into it, including like the overhead time because the trace-together V2 protocol is pretty time inefficient where you need to do like connections and exchange. Yeah. So, so... Thank you for that, V2. Yeah. So the other issue is that the V2 token doesn't use V2. It's a separate protocol. Yeah. Okay. Yeah. Sorry, that actually answered the question. You can't possibly do what the token is doing if you're doing the whole V2. Okay. Yeah. Thank you. I will read the rest on your website. We'll obviously wear the card. Yeah. Any more questions, interests? So what are the limitations of your system, not limitations, but kind of what is the weakest point of those gadgets? Because you are developing it as a gadget for people to develop, right? But all this stack and the display, etc., and even having an SP32 in there is actually over-engineered, no? I mean, this is my... I see it as an over-engineered solution. If... It all depends on the angle. I mean, I understand it. It's like a maker kind of push to develop those kind of gadgets. But if, first of all, I haven't read the open... If you go back to your slides already, the protocol, I haven't read how quick a communication can be with this trace app or something like that. So I don't know the kind of aspects, but I always felt like even when I look at those... like Roland, you know, the hacker session when you open all this stuff, is it... Are these gadgets not over-engineered even as a real minimum? The issue here is to have a piece of electronics that can, whatever is close to you. Like what I say is this... What is the probability that if I go from here to work and come back, do I stay two seconds within a certain distance of someone else? Does that event must be captured or is the likelihood of not catching that from that person or something is actually minimum? And then afterwards, when I look at those things, is that if I have a gadget, I mean a gadget, I call it the gadget as a system, every day I can plug it when I come back home anyway. So it's a bit like, you know, for me, all of this is over-engineered for the task. Yeah, it really depends what your use case is. I agree that there's a lot of features. The goal is that we actually start with a super set so that when we want to trim it down, it would be much easier because over here we are not really going with like the minimum cable, minimum possible product. For example, like Trace Token is an example of a minimum design product which has like minimum possible features. Of course, the battery life would be a lot more. I'm actually trying to stick as close to the original OpenTrace protocol as possible purely because it's open. And basically allow people to customize what they want. For example, like if you don't want a screen, you don't need many features, you could remove those hardware components, you could remove those code. In the stack, you mentioned this putting something in the C++ for that microcontroller. Is that stack is actually very, very complicated or is it the OpenTrace V2? Is it like... Maybe I need to read some of these. The protocol is BlueTrace. OpenTrace is the open tool specifically out. BlueTrace is about as simple as it's possible to do so long as you are connection oriented. It's nothing more than the exchange of capability information. The two devices, one is the central one, the peripheral one detects the other and they change roles that will sign with their iPhone. As soon as they decide to connect, you get one capability message each way that contains all of the information required for the epidemiological use case and that's it, they disconnect. There's nothing else involved. The big challenge for it's... Sorry, I know this is James' presentation but I looked at this closely and I was blindsided by what GavTech had actually done. The big problem with BlueTrace is that an adversary can control your power use which means that the battery life becomes a target for tomorrow's service. What the tokens change is an adversary cannot control your battery use. The token uses exactly the same amount of battery if it's in a faraday cage or if it's in a room with 10,000 people. It's exactly the same amount of power consumption. So it's a very different threat model if you do or don't have a rechargeable battery. But there's also a huge usability thing. The elderly people don't use phones or small children can't be relied upon to recharge their devices. So the two protocols are both very minimal but they solve different problems. Yeah, by sticking to the OpenTrace V2 protocol, that's why we have Wi-Fi to be able to communicate, to get the temp IDs and transmit the encounters, that sort of thing. Sorry, just one question. Have you considered is there a need for encryption when two deep devices are communicating between each other? Well, the OpenTrace V2 protocol didn't call for encryption but encryption is possible on this device. So actually two devices are close to each other, one receive and one emit and then suddenly they capture some tag or some signature from another one. So we assume that that signature or that message has to be... Sorry, sorry, Ovia, we are running way over time here. Can you please leave your questions after the session? Yeah, okay, sorry. Thank you. Okay, so next up also fighting the good fight again.