Sensors

[OLLYDOTDEV]

As an end-user I need ROMS to be able to detect in a variety of situations. in turn, be able to handle the information for the Sensors depending on the situation. This is so that any private/secure information is protected.

[OLLYDOTDEV]

While working out what IR sensor I was going to use for #14 I happen to run need to run some tests for this there was some test code that I produced. See https://github.com/OLLYDOTDEV/Project-Birdseye-DTX-2020/issues/14#issuecomment-649520131 for more info about what it does but this code. It is most likely that some version based on this code will be using when developing this full code for the sensors

[OLLYDOTDEV]

Here it was run a test for IR sensor it shows an issue that I should be kept strongly in mind https://github.com/OLLYDOTDEV/Project-Birdseye-DTX-2020/issues/14#issuecomment-649520131

in short to make sure that the trigger value is not a false negative I need to take an average value over a course of time to negate any false triggers

[OLLYDOTDEV]

if (IRdatacount >= IRcheckcount) {

}

So I started off looking if anyone had made the code I was looking for everyone seemed to say that is what I was looking for http://www.arduino.cc

so I have it a test

and it worked flawlessly as there is no dips in my values, am I surprised not really as this code is found on the official Arduino page

/*
  Smoothing

  Reads repeatedly from an analog input, calculating a running average and
  printing it to the computer. Keeps ten readings in an array and continually
  averages them.

  The circuit:
  - analog sensor (potentiometer will do) attached to analog input 0

  created 22 Apr 2007
  by David A. Mellis  <dam@mellis.org>
  modified 9 Apr 2012
  by Tom Igoe

  This example code is in the public domain.

  http://www.arduino.cc/en/Tutorial/Smoothing
*/

// Define the number of samples to keep track of. The higher the number, the
// more the readings will be smoothed, but the slower the output will respond to
// the input. Using a constant rather than a normal variable lets us use this
// value to determine the size of the readings array.

const int numReadings = 20;

int readings[numReadings];      // the readings from the analog input
int readIndex = 0;              // the index of the current reading
int total = 0;                  // the running total
int average = 0;                // the average

int inputPin = A3;

void setup() {

  pinMode(inputPin, INPUT);
  // initialize serial communication with computer:
  Serial.begin(9600);
  // initialize all the readings to 0:
  for (int thisReading = 0; thisReading < numReadings; thisReading++) {
    readings[thisReading] = 0;
  }
}

void loop() {
  // subtract the last reading:
  total = total - readings[readIndex];
  // read from the sensor:
  readings[readIndex] = analogRead(inputPin);
  // add the reading to the total:
  total = total + readings[readIndex];
  // advance to the next position in the array:
  readIndex = readIndex + 1;

  // if we're at the end of the array...
  if (readIndex >= numReadings) {
    // ...wrap around to the beginning:
    readIndex = 0;
  }

  // calculate the average:
  average = total / numReadings;
  // send it to the computer as ASCII digits
  Serial.println(average);
  delay(1);        // delay in between reads for stability
}

for anyone who does under here a good brack down on how it works

now that is a big change mainly from the fact that we can see that our noise floor is now above 60, therefore, increasing the reliability of the values that we receive hopefully reducing/ if not completely removing all values that would give false positives.

[OLLYDOTDEV]

it was all so considered to use a system that works on the bases of this pseudo code

first, remove key 0 of array 
shuffle all key of an array down 
add a new key with new sensor data

get a total of all the key added together 
then take a total and divide to get the average 

while in theory, this would work if I wasn't using a microcontroller with 2K of ram but I am so in the interest of to saving processing power and storage I will not be using a shuffling method also note that C++ is not made to be used dynamically but rather fixed (this decrease the needed resource overhead and means that this is great for IC ) as one an array has been made with a fixed amount of values you can't easily change the array to have less or more keys but only change the content of the data at key value.

[OLLYDOTDEV]

I had mentioned that #14 I could get a 32 cm Range but that was under lightly controlled conditions but ROMS is not going to be used in a controlled environment and hence the real-life in day to day environments are more like 3 to 8 cm as every environment is slightly different to the next to fix this the sensor could be recalculated automatically but adjusting the potentiometer, in that case, it would make sense to use a digital potentiometer that can be controlled by an atmega328p. now this would have a layer of complexity that while it would allow for the greater flexibility due to increased range as hoped for it is more practical to use a more reliable signal at the cost of range via

1. having a default setting where it is ok in most environments or also having the option
2. to configure the IR sensor manually if better range is needed

[OLLYDOTDEV]

So something I have found is that old light bulbs happen to give off IR light off that means that I can no longer to option one and I need to have a setup config mode as one of my relevant implications functionality in this case functionality is being flexible to work and multiple locations without restrictions

[OLLYDOTDEV]

So while the IR sensor I am using does have an ADC onboard I am not happy with the value that it considers a low and high therefor I am reading the raw sensor data and give me the ability to control what is considered a 0 or 1here is the code I used next is to add a configuration mode where rather to sending out values it calibrates self

[OLLYDOTDEV]

the calibration function has been now implemented the variable calibration_trigger controls whether or not the sensor will stay with local environment to set the IR sensors sensitivity or. it will pass on the signal to the relay 1 = calibration mode on | 0 = calibration mode off

to calibrate the sensor put ROMS the desired Max distance a value under 12 cm is good then turn the potentiometer on the sensor clockwise till it can be turned clockwise no more next slowly turn anticlockwise to indicator LED turns off then turn clockwise again just enough for the led to turn back on DONE the sensor is calibrated for the environment

[OLLYDOTDEV]

example on how to calibrate is shown here https://youtu.be/vRiN55FDCng

[OLLYDOTDEV]

This issue and #13 have been moved to milestone 4 (sprint 4) as the time need to complete them undercalulated and they needed to be moved to the next sprint as they at what provides the move value.

[OLLYDOTDEV]

here is the sensor subsystem. it has been making to keep working and send keep send data so that whenever that when if the atmega328p does error out when it comes back up it the sensor all ready power on while this does have the drawback of some power loss due to Quiescent Current. the trade-off is worth it as 3 seconds mean all the difference. When fist started off I had thought to try and minimize quiescent Current to try and maximize the battery life but in this latter version I am just keeping parts like the PIR and IR sensor powered so that as soon as the control IC is online we will be in back to business is is acceptable as the sensors picked in #13 and #14 both have low Quiescent Current.

[OLLYDOTDEV]

with the hardware for here sorted it is time for being.

I need to bring the software together that sets a state of being triggered which then can later be detected with #17.

[OLLYDOTDEV]

in short this stage sorta just take parts from my test code and mergers in together.

so my taking pir_test.ino, IR_Sensor_Conf.ino, and SMOOTH_DATA.ino (all off these files can be found here in the Project-Birdseye-DTX-2020/CODE/TESTING)

code from pir_test.ino will be used to control the input from the PIR sensor

from this here is what needs to be done

• [x] add boolean for whether the PIR sensor has been triggered or not
• [x] adapt IR code to use a boolean
• [x] make SMOOTH_DATA.ino into a class

[OLLYDOTDEV]

explain more on the smooth data. it is what I am using on the IR sensor to make my reading more accurate by taking an average over an amount of time. The base of this code was found open-source here http://www.arduino.cc/en/Tutorial/Smoothing

starting to I need to make it function. todo this need to first make it so that values to be pass to the function to latter have an output return the smooth data

[OLLYDOTDEV]

here is the basis of a function.

so I'm my case for the parameters I am using are is readings is all that would need to be passed

[OLLYDOTDEV]

change of plan instead of making a function I will be using object-oriented programming and uses a class to make a blueprint as such as needed for the likes of 2.7 for NCEA but it also has the added benefit of allow me to reuse this class on more then one sensor if needed in the future keeping my options open for later development or for future developers spick up and continue the project as this is open source as accessibility in open source and just general availability to everybody as one of my implications

[OLLYDOTDEV]

while testing on how to get class's to work I have moved this testing into a new file called Smoothing_class_test.ino once this is working I can copy the working parts of the code i need into the main full test file

[OLLYDOTDEV]

here you will find my test file.

in short, the point of it is test was to see how the structure for the copy for a c++ class would integrate into my project. Gudies online prooved mainly unhelpful with assisting this it was found to be more useful to take the example code and reverse engineer. Due to not having access to my hardware, I can't test if this code produces the same desire output. this will be done latter tonight

[OLLYDOTDEV]

and here we have with a working version off data smoothing as found on http://www.arduino.cc/en/Tutorial/Smoothing but rather in the manipulated into a form of a class to increase for future flexibility for me for other developers. to check that that the code had been correctly converted to be used as a class i am using TDD or otherwise known as test-driven development.

[OLLYDOTDEV]

so with this get up there is an example of how the class works.

to make a object for it is a easy as

Class name object name (of you choice) AnalogSmooth IRsensor;

now that we have a object name we just need to call that object name + the method we want to use

so IRsensor.Smooth_setup(); and BAM the IR sensor is set up and ready to have its input be smoothed and have some of the extra noise removed.

this page will show the brake down on the layers to a class

[OLLYDOTDEV]

next step is to take this smoothing code and add it into the main testing code as talked about here https://github.com/OLLYDOTDEV/Project-Birdseye-DTX-2020/issues/12#issuecomment-660609183

[OLLYDOTDEV]

well adding the smooth class to the header file went smoothly and there was no issue with it. but having a reliable data source revealed that the logic for the code was floored and needed to be revamped. eg i missed name a variable and was when it was looking if a status went high it would loop as once it was toggle high there was no method and plays for it to be reset

so started off I have added a part just for debugging to allow me to find issues with more ease with developing this code

verbose debug

otherwise here is the heart of it

// IR code 
IR_DATA = IRsensor.Smooth(IR_OUT);

if(IR_DATA < IR_Threshold){
// if this if statement activates that means that the sensor has been triggered  
IR_Status = 1;
}else{
IR_Status = 0;  
}

// pir code
Pir_Data = digitalRead(Pir_Out);
if(Pir_Data == 1){ // if PIR sensor actavated then set the alert status to active (true)
Pir_Status=1;
}else{
Pir_Status=0;  
}

if(Pir_Status || IR_Status == 1){
Alert_Status = 1;
// then send out alert to relay 
// sensors have been triggered
}else{
Alert_Status = 0;
// no sensor actived no nothing
}

this just allows the atmega328 work out that sensors have been triggered.

it all works all and great as if either of the sensors gets activated the alert status is activated that will in time link into the #17

but it has one issue and that is the fact on startup IR Data is all way at the around of value of 110 see pastbin for full log. but in short, it starts at a low value and slowly fills up the array smooth before stabilizing. further investigation will be conducted tomorrow.

[OLLYDOTDEV]

So first off before I can fix the issue I must work out what is the cause of the issue. The issue was found by looking at the output of the variables that get utilize with averaging in the smooth.h file

the point where the error was found was here _average = _total / _numReadings; this line of code takes the total of the past x reading and calculates the average value (hence the class name analogsmoothing)

So ways to counter this there was a handful of options considered.

1. change the values of assisted variables. In this case, the only variables that have an effect on the average value are _total and _numReadings and editing these would brake the rest of the system there for this rules out this option,

2. fully rewrite the logic of the averaging system. the rest of the system is just fine so no need to remake the whole thing to just get this small part to work so I won't be using this.

3. wait for x time (eg 10sec ) worth of data to pass be for allowing the alert system to be activated. Yes is an option that can work but I reckon I can find a quicker more time-efficient method.

4. once x amount has values have pasted then allow alerts to be sent. I have decided to go with a variation of this sort of design.

[OLLYDOTDEV]

my first attempt at this I thought I worked but with more testing, it found that it still had flaws within the code. the approach I had to take was to wait until _ValuecCount was great then _StartSkip but the issue was that it still need to return some value so I set it to so with getting to the first value to takes it is most likely to work most of the time but the issue is that it doesn't handle any broader cases of say if the sensor starts off in an activated state.

if(_ValuecCount < _StartSkip){

 Serial.print("Skipping start value number:");
 Serial.println(_ValuecCount);
 _ValuecCount++;
 // give temp output value of first reading
  return(_readings[0]);
}else{
  // return value of object
  return(_average);
  }

code found in Smooth.h

[OLLYDOTDEV]

so do counter these border cases I need to change the point of intercept. seeing that the intercepting at the point where data end I then started to investigate the other end the input within the main code.

so If I adapt the code I just used for this end of the system there is a good chance that I should have a working fix to 8 unreliable values.

if(_ValuecCount < _StartSkip){
  IRsensor.Smooth(IR_OUT); // triggers method but doesnt assign output to variable
 Serial.print("Skipping start value number:");
 Serial.println(_ValuecCount);
 _ValuecCount++;
}else{
IR_DATA = IRsensor.Smooth(IR_OUT); // triggers method and assign output to variable
}

and just like that it work and is able to hand the external border case allow for a more robust code and outcome

[OLLYDOTDEV]

and with this complete, I need to work on is transmitting the signal to a relay so that pi zero knows that the alert status has been triggered on ROMS. this can be followed with #16