Haha I hear you! Oh nono I have my own code to fight with ;D
1 Like
And you both have made a great point… I have been trying to help this ‘character’ since the beginning, but it is time for me to give up on him. He is now fixating on non-relevant things like radio signals in a vacuum and completely ignoring everything important to his request. 
Not to mention bad language!
I am also removing the notification flag so I don’t have to watch this mudslide anymore. But I will see you two again in a better thread 
1 Like
thanks for your “help?!”
detachInterrupt()
Description
Turns off the given interrupt.
Syntax
detachInterrupt(interrupt)
detachInterrupt(digitalPinToInterrupt(pin));
detachInterrupt(pin) (Arduino Due, Zero only)
Parameters
interrupt: the number of the interrupt to disable (see attachInterrupt() for more details).
pin: the pin number of the interrupt to disable (Arduino Due only)
See also
attachInterrupt()attachInterrupt()
Description
Digital Pins With Interrupts
The first parameter to attachInterrupt is an interrupt number. Normally you should use digitalPinToInterrupt(pin) to translate the actual digital pin to the specific interrupt number. For example, if you connect to pin 3, use digitalPinToInterrupt(3) as the first parameter to attachInterrupt.
Board Digital Pins Usable For Interrupts
Uno, Nano, Mini, other 328-based 2, 3
Mega, Mega2560, MegaADK 2, 3, 18, 19, 20, 21
Micro, Leonardo, other 32u4-based 0, 1, 2, 3, 7
Zero all digital pins, except 4
MKR1000 Rev.1 0, 1, 4, 5, 6, 7, 8, 9, A1, A2
Due all digital pins
101 all digital pins
Note
Inside the attached function, delay() won’t work and the value returned by millis() will not increment. Serial data received while in the function may be lost. You should declare as volatile any variables that you modify within the attached function. See the section on ISRs below for more information.
Using Interrupts
Interrupts are useful for making things happen automatically in microcontroller programs, and can help solve timing problems. Good tasks for using an interrupt may include reading a rotary encoder, or monitoring user input.
If you wanted to insure that a program always caught the pulses from a rotary encoder, so that it never misses a pulse, it would make it very tricky to write a program to do anything else, because the program would need to constantly poll the sensor lines for the encoder, in order to catch pulses when they occurred. Other sensors have a similar interface dynamic too, such as trying to read a sound sensor that is trying to catch a click, or an infrared slot sensor (photo-interrupter) trying to catch a coin drop. In all of these situations, using an interrupt can free the microcontroller to get some other work done while not missing the input.
About Interrupt Service Routines
ISRs are special kinds of functions that have some unique limitations most other functions do not have. An ISR cannot have any parameters, and they shouldn’t return anything.
Generally, an ISR should be as short and fast as possible. If your sketch uses multiple ISRs, only one can run at a time, other interrupts will be executed after the current one finishes in an order that depends on the priority they have. millis() relies on interrupts to count, so it will never increment inside an ISR. Since delay() requires interrupts to work, it will not work if called inside an ISR. micros() works initially, but will start behaving erratically after 1-2 ms. delayMicroseconds() does not use any counter, so it will work as normal.
Typically global variables are used to pass data between an ISR and the main program. To make sure variables shared between an ISR and the main program are updated correctly, declare them as volatile.
For more information on interrupts, see Nick Gammon’s notes.
Syntax
attachInterrupt(digitalPinToInterrupt(pin), ISR, mode); (recommended)
attachInterrupt(interrupt, ISR, mode); (not recommended)
attachInterrupt(pin, ISR, mode) ; (not recommended Arduino Due, Zero, MKR1000, 101 only)
Parameters
interrupt: the number of the interrupt (int)
pin: the pin number (Arduino Due, Zero, MKR1000 only)
ISR: the ISR to call when the interrupt occurs; this function must take no parameters and return nothing. This function is sometimes referred to as an interrupt service routine.
mode:
defines when the interrupt should be triggered. Four constants are predefined as valid values:
LOW to trigger the interrupt whenever the pin is low,
CHANGE to trigger the interrupt whenever the pin changes value
RISING to trigger when the pin goes from low to high,
FALLING for when the pin goes from high to low.
The Due board allows also:
HIGH to trigger the interrupt whenever the pin is high.
(Arduino Due, Zero, MKR1000 only)
Returns
none
Example
const byte ledPin = 13;
const byte interruptPin = 2;
volatile byte state = LOW;
void setup() {
pinMode(ledPin, OUTPUT);
pinMode(interruptPin, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(interruptPin), blink, CHANGE);
}
void loop() {
digitalWrite(ledPin, state);
}
void blink() {
state = !state;
}
[Get Code]
Interrupt numbers
Normally you should use digitalPinToInterrupt(pin), rather than place an interrupt number directly into your sketch. The specific pins with interrupts, and their mapping to interrupt number varies on each type of board. Direct use of interrupt numbers may seem simple, but it can cause compatibility trouble when your sketch is run on a different board.
However, older sketches often have direct interrupt numbers. Often number 0 (for digital pin 2) or number 1 (for digital pin 3) were used. The table below shows the available interrupt pins on various boards.
so now i going this way
give a interrupt for normal
and detachInterrupt if virtuall pin (accelerometer) changes …
will this work ???
I’m not sure how this will work. I can’t really see how an interrupt will help you here. The funtion of interrupt is, as it says, to interrupt the normal program routine and start doing something else.
I’m not even sure if interrupts can be used with virtual pins. I think it’s not even possible since interrupt is hardware based and a virtual pin is software based.
ok wrong way .
question is how to stop pin3 if virtual pin 1 stops changing values
Usually you do that if a pin (virtual or otherwise) changes once. E.g. from 0 to 1 or the other way around. This is all very difficult. If the vPin is either 0 or 1 (for example) the program is fine, but if it’s changing within a certain amount of time, something is wrong. You are gonna have to do something with simpletimer I think, but I still can’t see how to do this in practice.
I was wondering though, is this really a problem? We are trying to figure out how to stop the robot, but is it really needed to do so? Did you ever encounter problems with lost connections?
no just if i simulate a connection failure or close app and holding the joystick in a moving position wile driving
maybe all 10s a reset from the output values
I’d just leave it be until it really becomes a problem to be honest. If you are making this into a big thing before it even becomes a problem it’s just a waste of time if you ask me 
I can see it could be a problem, but as long as it’s not, why bother writing VERY complicated code to prevent it?
why not because i have to prepare …
i will drive my robot outside maybe in to the wood or just miles away .During which I stay in the house
For now I just see no solution because there is no way you can check from the hardware side if the phone is offline. I am however at this moment struck by the flu, so my brain is not functioning within normal parameters. There could be a solution, but at this point I see none.
Thanks anyway for decent responses, even if I can not speak perfect English
I posted a link to Connection Management very early on in the thread and it refers to changing the heartbeat to 5s would give a timeout of 11s (a factor of 2.3 x heartbeat). Not much good for a RC vehicle but it defines the parameters.
RC vehicles is not my thing and I only normally produce code for things I, or my clients have an interest in, but I wanted to check how it might work.
I didn’t want to spend too long on the coding but the following simulation seems to work. It’s not quite how I was expecting the code to turn out but those with RC vehicles can now take it on for further refinement.
With the code as it is the LED on the WeMos actually flashes on and off at a steady heartbeat, this was not intentional but Serial Monitor shows the rapid connect and disconnects etc.
As soon as I press the remote control on my RF transmitter that is tied to our secondary router the LED stops flashing i.e motors would stop on the RC. Response time is immediate. Refinements would be to do all this without the constant connect and reconnect etc but that should just be trial and error with the parameters and further analysis of the libraries.
/**************************************************************
FailSafeV2.ino by Costas 23 Feb 2017 for http://community.blynk.cc/t/i-need-a-fail-safe/11648
Line 180 of BlynkProtocol.h changed 1000UL to 200UL and from 3 to 1
Line 32 of BlynkConfig.h changed from 10 to 1
Line 37 of BlynkConfig.h changed from 2000UL to 400UL
Previous hack for quick connections line 209 of BlynkConfig.h from 5000UL to 500UL
**************************************************************/
#define BLYNK_PRINT Serial // Comment this out to disable prints and save space
#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>
#include <SimpleTimer.h>
#define LEDpin 2 // WeMos builtin LED, active LOW
char auth[] = "xxxxx";
char ssid[] = "xxxxx";
char pass[] = "xxxxx";
char server[] = "xxxxx";
SimpleTimer timer;
bool lastResult = true;
void setup()
{
pinMode(LEDpin, OUTPUT);
digitalWrite(LEDpin, HIGH); // active LOW so LED off
Serial.begin(115200);
Serial.println("\nConnecting to Blynk");
Blynk.begin(auth, ssid, pass, server);
Serial.println("Connected to Blynk");
digitalWrite(LEDpin, LOW); // active LOW so LED on
timer.setInterval(100, checkServer); // 'ping' server every 100ms
}
void checkServer(){
Blynk.virtualWrite(V1, millis()); // send 'ping' data to server
bool result = Blynk.connected();
if(result != lastResult){ // to ensure control action is just done once
lastResult = result;
if(result == false){
digitalWrite(LEDpin, HIGH); // active LOW so LED off, NOT CONNECTED!!!
Serial.println("Disconnected from server");
// code here to stop all motors on RC vehicle etc
}
else{
digitalWrite(LEDpin, LOW); // active LOW so LED on, CONNECTED!!!
Serial.println("Reconnected to server");
// code here to start all motors on RC vehicle etc
}
}
}
void loop()
{
Blynk.run();
timer.run();
}
Just to repeat, as previously stated in this thread, the fix has to be on the ESP and not in the app. The very nature of disconnects means a change to the app would never work.
thank you . 
my new board just arrived and i can test it .