Hey, this is part of the code I modified for debouncing:
It does not show anything on serial monitor when I removed BT part and the app does not show any difference, I assume it is the code I wrote that is somehow wrong...
It does not show anything on serial monitor when I removed BT part and the app does not show any difference, I assume it is the code I wrote that is somehow wrong...
PS: (about the exact same app that did not work), wow they really are right when they say if it does not work, turn it off and on again, new app works now!
Yep, hardware reset sometimes helps 
(...let me check the debounce code....)
I realized the problem arises after I try to put the image on the layout where the list picker is, after I put the image there are no devices shown
uskiara ou Bruno vcs sabem como fazer para usar o bluetooth em várias telas sem ter q desconectar e na outra tela ter que conectar novamente
The answer remains the same:
Nesse link achei apenas utilização do notificador em várias telas não o bluetooth
OK, let's do it different.
do the following changes:
move the NewInput variable as global
Add this function:
Modify the loop as per image below:
.
The rationale of the debounce (extra simple !) is in the comments.
Hope it works for you.
Don't wanna jinx myself but it works perfectly, thanks!
1 Like
Dear @UserName123,
first of all, please open a new topic, since this one is not related to the use of multiple screen and BT.
Moreover, what @Ramon has already said, the BT cannot work with a multiple screen structure (it disconnects every time you pass from one screen to another).
The solution is to use the virtual screens instead (i.e. by using Horizontala and Verstical arrangements making them visible/hidden as they were different screens)
For sake of easy-finding you can take the annexed .aia as an example.
MultipleScreen.aia (849.0 KB)
Anyway, many more topics can be found on this matter in the community.
.
I don't know how to describe it but its like the app needs time to adapt so it can change those ones and zeros correctly. Yesterday after you wrote the code I tried it and everything worked perfectly, now I do it and after few repeated changes it just randomly starts changing those ones and zeros. Is it normal since I clicked microswitch to often and after some time states get mixed? I mean, should I ignore it since I won't need it to change it fast(it will be kept clicked unless door opens)
Dear Bruno,
the debounce "filter" that I gave you is just a "poor" filter.
More complex ones can be written, for sure, and I believe that you'll find them on the web (i.e. on Arduino forums).
A microswitch, like relays, can have a stabilisation time that lasts up to 2 or 3 hundreths of milliseconds. In other words, within that time window the signal can have glitches, that can lead to a wrong status evaluation. To have a more robust solution you can add a HW filter, an RC net for example. One "free of charge" step is to use the INPUT_PULLUP feature of the input port (but, as far as I remember, you already use that feature, aren't you ?)
If your real use is to acquire the status of a door, you can do in a completely different way: after the input has changed, you wait seconds before reading it again. If the two readings have the same value (HIGH+HIGH or LOW+LOW) you can reasonably assume that the true value is what you have read both. If the values differ, you shall throw them away and do nothing. This is because the bouncing, if any, will be surely ended after a couple of seconds.
Obviously this assumes that you can wait 2 seconds before deciding if the door has been opened or closed.
Yes, I use internal pull up. Well I think 2 seconds my be to lomg, especially since I have a dog which can utilize those 2 seconds of advantage:grin:
I have a question about the global variable(can I have 2 of them and define what input data is stored to the first and what to the second.
OK, I agree, 2 seconds could be too much for your dog...
So, you can try to find a better solution (a smarter filter, based on some hundreths of milliseconds instead).
To this purpose you'd better dig the Arduino forum: for example I found rich of solutions the following link
Give it a sight.
Thanks for providing me with a link. I will dig into it and try it out. About the global variable part, can I use 2 of them in MIT app inventor and define what received data each of them should store, if you get me?
Honestly I couldn't get you ...
...do you mean that you want to have 2 variables to store 2 input values (from BT) to implement the filter on AI2 ?
I believe it is that. Well here it is, I want to know(to show on screen if bt module gets disconnected physicaly. I read that it is not possible unless I constantly send data to the app. And since I already have ones and zeroes to receive I want to somehow filter them for different purposes. Please don't give a solution this time, I would like to try it myself:rofl:
Ah ah ah,
ok I will not tell you that to avoid the disconnection my solution (it is already retrievable from the FAQ) is to make the Arduino sending periodically a "live" character (i.e. a '$'), for example every 1 minute. The app, when receives a '$', resets a timeout clock whose period is, for example 2 minutes. If, at the next period of 2 minutes, the clock fires without having received the $, this means that the BT has diconnected (no $ => no BT communicatoin active). At that moment the app retries a re-connection.
Of course every time you receive a '1' or a '0' the app timeout clock shall be reloaded as well.
This is the most simple, but reliable, way to discover a disconnection. Now is up to you to implement it
PS in other words: at every character received (i.e. '1' or '0' on event and '$' periodically), the timeout clock is stopped, its period is reloaded to 2000, then it is restarted. So it shall never fire. If it fires, this means that the BT has ceased to receive.
I tried the method they said was their favourite for debouncing and change it for my purposes but it does not print 0 after I click the switch, I used just Serial.print to see where is the problem. Here is the full so you canmore easily read:
#include <SoftwareSerial.h>
#define TxPin 11 // required by SoftwareSerial (PWM capabilities needed)
#define RxPin 10 // required by SoftwareSerial (PWM capabilities needed)
#define el_magnet 7
#define command 8
#define debug // comment it out at the end of the debug phase (no Serial Monitor Tx)
bool el_magON= false;
unsigned long prethodno_vrijeme=0;
const long interval=3000;
SoftwareSerial BTSerial(RxPin,TxPin); // instantiate the library
char state = ' '; // define input buffer as char (not empty but a blank)
const int stepPin = 4;
const int directionPin = 2;
unsigned long T1 = 0, T2 = 0;
uint8_t TimeInterval = 5; // Time interval for debounce mechanism (in milliseconds)
uint16_t BtnStates = 0;
int previousState = -1; // Variable to store the previous state of the button pin
//-----------------------------------------------------------------------------------------------
void zatvori()
{
digitalWrite(directionPin,HIGH); //npr zatvori
StepperActuate();
}
//-----------------------------------------------------------------------------------------------
void otvori()
{
digitalWrite(directionPin,LOW); //npr otvori
StepperActuate();
}
//-----------------------------------------------------------------------------------------------
void StepperActuate()
{
for(int x = 0; x < 50; x++)
{
digitalWrite(stepPin,HIGH);
delayMicroseconds(500);
digitalWrite(stepPin,LOW);
delayMicroseconds(500);
}
}
//===============================================================================================
void setup() // done once at reset
{
pinMode(el_magnet,OUTPUT);
digitalWrite(el_magnet,LOW);
pinMode(command,INPUT_PULLUP);
pinMode(stepPin,OUTPUT);
pinMode(directionPin,OUTPUT);
// not necessary, already set into the library => pinMode(RxPin,INPUT); // to be connected to Tx pin of HC05
// not necessary, already set into the library => pinMode(TxPin,OUTPUT); // to be connected to Rx pin of HC05
BTSerial.begin(9600); // supposed baudrate of HC05 (38400 ?)
Serial.begin(9600); // Used to echo on PC monitor the data received on BT
}
//===============================================================================================
void loop() // repeated forever
{
T2 = millis();
if( (T2 - T1) >= TimeInterval )
{
BtnScan();
T1 = T2; // Update T1 after BtnScan() is called
}
static char character = 'A'; // Character to print (static to retain its value across loop iterations)
static unsigned long lastPrintTime = 0; // Variable to store the last time character was printed
unsigned long currentTime = millis(); // Get the current time
if (currentTime - lastPrintTime >= 60000) { // Check if 2 seconds have elapsed
Serial.println(character); // Print character
lastPrintTime = currentTime; // Update last print time
}
// while((millis()-now) <100UL) ; removed because the BT tx is done only when the input changes
if (BTSerial.available()) // any char from BT ?
{
state = BTSerial.read(); // yes, get it
#ifdef debug
Serial.print("Received : "); // echoes it on the PC screen only if the debug flag is defined (see header)
Serial.println(state);
#endif
if(state=='2') //npr zatvori
{
zatvori();
}
if(state=='3') //npr otvori
{
otvori();
}
if(state=='4') {// the received char to switch on the led
digitalWrite(el_magnet,LOW);
el_magON=false;
}
if(state=='5') {
if (!el_magON) {
digitalWrite(el_magnet, HIGH);
el_magON=true;
prethodno_vrijeme=millis();
}
}
}
unsigned long trenutno_vrijeme=millis();
if (el_magON && (trenutno_vrijeme-prethodno_vrijeme>=interval)){
digitalWrite(el_magnet, LOW);
el_magON=false;
}
}
void BtnScan(void) {
int currentState = digitalRead(command);
int SumStates = 0;
BtnStates <<= 1;
BtnStates |= currentState;
SumStates = __builtin_popcount(BtnStates);
if(SumStates >= 10)
{
if (currentState != previousState) {
Serial.println(currentState);
previousState = currentState; // Update the previous state
}
BtnStates = 0;
}
}