WEBVTT 00:00.180 --> 00:05.370 Now that you have seen the Bonds problem happen in a real application, I'm going to explain to you 00:05.370 --> 00:06.740 why we have this problem. 00:07.230 --> 00:10.050 Let's have a look at the signal from the button. 00:10.210 --> 00:16.050 OK, let's say the signal is low first and then you press the button and everything goes well. 00:16.200 --> 00:17.670 The signal will go higher. 00:17.760 --> 00:21.250 And you know that the button has been priced when you monitor it. 00:21.780 --> 00:27.060 Now, when you release the button, if everything goes well, the signal will go to low. 00:27.210 --> 00:30.190 And that's quite what you would expect from the button. 00:30.260 --> 00:36.110 OK, and that's what you had in most of the cases in the previous experimentation. 00:36.300 --> 00:40.170 So you press the button again, the signal goes to high and then you release. 00:40.170 --> 00:47.040 And what is happening here, as you can see when you release the button, this time the signal is bouncing 00:47.040 --> 00:52.760 from low to high and high to low a few times before finally going to low. 00:53.190 --> 00:59.340 It can happen here when you release the button, as in this example, but it can also happen when you 00:59.340 --> 01:06.900 press it so easy on this part of the signal, either when you realize or when you press it. 01:07.200 --> 01:10.380 So this is what happens when the button bounces. 01:10.740 --> 01:14.440 This is purely a physical issue from the button sensor. 01:14.800 --> 01:21.060 OK, when you press the button, the hardware part that connects the wire together can bounce a few 01:21.060 --> 01:22.620 times before being stable. 01:23.190 --> 01:25.560 That's when you read the button state in your code. 01:25.800 --> 01:32.880 You also see these buttons and the number of buttons is going very K can be zero bouncing in a good 01:32.880 --> 01:38.970 situation or just one, two, three, etc. and this can lead to behavior you don't want. 01:39.360 --> 01:44.190 For example, if you want to increase a counter whenever you release the button, then we have to bounce. 01:44.430 --> 01:50.070 The content may be incremented by more than one every time you release the button, which makes your 01:50.070 --> 01:52.320 application not working correctly. 01:52.770 --> 01:57.060 Or if you want to toggle an entity, which is an application we do later in the section. 01:57.420 --> 01:59.480 And I just talked about it a little bit before. 01:59.640 --> 02:04.520 Well, imagine that the button bounces three times like here on the screen. 02:05.010 --> 02:10.740 In this case, after being told a few times very quickly, the state of the editing would be the same 02:10.740 --> 02:12.750 as it was before you released the button. 02:13.500 --> 02:18.540 Note that there are some applications where you don't really need to worry about the button bouncing. 02:18.870 --> 02:24.480 For example, in the previous activities, we have made a project where an entity will be pulled on 02:24.630 --> 02:27.270 if the button is priced and proud of. 02:27.340 --> 02:32.910 If the button is not pressed, well, the buttons will still happen, but it will not modify the behavior 02:32.940 --> 02:33.840 of your project. 02:34.050 --> 02:40.170 The real problem is when you need to do something and the trigger for that is the change on the signal, 02:40.380 --> 02:42.110 not the signal itself. 02:42.420 --> 02:45.330 Fortunately, there is a solution to that issue. 02:45.780 --> 02:50.430 By modifying the code a little bit, we will be able to remove the balance effect. 02:50.800 --> 02:52.410 The principle is quite easy. 02:52.710 --> 02:58.620 After we noticed that there is a change of state, we are going to simply ignore all of the changes 02:58.620 --> 02:59.910 for a given amount of time. 03:00.280 --> 03:05.820 So here on the diagram, you can see that when we have the balance problem, if we ignore all changes 03:05.820 --> 03:11.460 for this amount of time here with the Green Arrow, then we don't take into account all the bounces 03:11.460 --> 03:12.000 that happen. 03:12.720 --> 03:17.220 The period during which we ignore changes is called the DBMS delay. 03:17.820 --> 03:22.890 In your application, you will be able to choose to increase or decrease the delay so you can make sure 03:22.890 --> 03:28.070 you don't get any bumps in your code, but also that you don't miss any real change in the signal. 03:28.470 --> 03:34.170 And of course, to ignore the changes for the short duration, we are not going to use the delay function, 03:34.530 --> 03:37.750 but instead the time functionalities that you have just discovered. 03:38.340 --> 03:41.820 Now let's see how to write the code for this Diebold's functionality.