Homini Complete Room Sensor Module?

[Samuel235]

@scalz It seems you have beat me to it with creating a breadboard friendly breakout board for them. If you're confident in the use of this sensor could you double check my schematic and let me know if i have connected it correctly please?

I might get a breakout board for breadboard friendly use designed if you're too busy yourself. Not sure how much call there is for them though.

[scalz]

@Samuel235 it's few months I did this. like I said I make breakout boards for testing, so I have a small collection now!
This was a breakout with opt3001 and si7021, regulator onboard (with smd jumper to power directly with 3.3v), and few pullups. Same pinout as common chinese sensor boards + interrupt pin for ambiant light:

I will upload at openhardware asap ;) that's lot of things to upload lol!

[Samuel235]

0_1462204198812_capturedvideo.MOV

Currently prototyping the optical smoke sensor. I have the buzzer circuit working fine, i also have the circuitry for the optical sensor working. But i can't get it to reflect its IR Light off of smoke and onto the phototransistor.

Waiting on some feedback regarding the Figaro sensor and using with a mosfet from another forum, will post updates when recieved.

[Samuel235]

UPDATE!

Figaro TGS5042 Electrochemical Carbon Monoxide Sensor - Working.

Prototype work complete for the carbon monoxide sensor, using the OP AMP style measurement system which includes just 1 Resistor, 1 Capacitor, an OP AMP (Model featured above) and the Sensor itself.

Improvements?

Currently reading through the appnotes given by Figaro for this sensor, heck its a long but interesting read! While it would be great to run with this current setup of 4 components for this circuit, there are things like polarity precautions on the sensor to be taken into consideration. So, with this being said, I'm currently in the process of maybe adding another OP AMP or just a resistor to the keep the sensor shorted out incase the device is isolated from power for any reason. Then there is the accuracy to take into account...

Question

I'm very tempted to amplify the sensors output enough to get to a PPM that is dangerous and then send the alarm off, meaning that at 5v out of the OP AMP it would be enough to send the sensor off and therefor we have a much a higher accuracy between safe and dangerous readings but it would not be able to go over what would be deemed as 'unsafe' levels. OR would you rather me have it so it can read to quite high CO levels despite the 'dangerous' level being around 2/3v out rather than 5v? So, would you rather a high range of readings but lower accuracy or a more accurate but lower range, still enough to detect the dangerous level?

I will be posting images and schematics for the completed parts of the module ASAP for you guys to check out.

[epierre]

@Samuel235 said:

IONISATION METHOD

I'm very tempted to just use a MQ2 sensor with its circuit on my board rather than a separate board.

MQ2 consumes a lot of energy as every MQ. Also don't rely on your life on this kind of sensors...

Have you tried the bottle of perfume around ?

[Samuel235]

@epierre, you're correct in thinking they are pretty high energy and inaccurate. Would you advise any other sensor at all for this method? I'm currently working on my own custom made optical smoke sensor unit using a IR LED and Phototransistor, but i would like a ionisation method sensor as well.

[epierre]

@Samuel235 the ionisation for smoke ensor was the old method with radioactive elements.

maybe a particle sensor but you would need to simulate a smoke to set levels, compared to a dusty room I think. Maybe a barbecue test (beware of greasy dusts !)

[Samuel235]

I'm encountering some issues regarding my MOSFET enabled PIR sensor. I'm currently using a n-channel MOSFET in a high side switching setup. The issues that i'm getting are that while the gate is pulled low, the sensor is alternating between a HIGH and LOW output, false triggering and when the gate is 5v, high, it is not powering at all.

I'm attempting to get my hands on a p-channel MOSFET to put in a low side switching application to attempt to fix this. I'm assuming that its acting like this because its producing false triggers while the GND is not connected through to ground. I've tried to connect a 10k resistor from drain to gate to eradicate the 'floating' connection, no hope either. If anyone has a link to any p-channel MOSFET that i can get in the UK that would be much appreciated.

[Samuel235]

There is currently discussions going on over on the forums at allaboutcircuits.com with myself and a few others regarding this OP AMP and the sensor output readings. I thought i would let you guys know in case you're interested in following the build.

[Samuel235]

Once i have the smoke detection worked out and the carbon monoxide circuit more 'suited' i feel we're on the straight and narrow. Adding in things like signing, EEPROM, headers, temp sensors, is all easy and no configuration on the hardware level is needed. So over the next week or two i will be working to get the two sensors correctly working and optimized to the best suited adaptions with this device, then its a case of adding in any functionality that we feel is needed. I would like some feedback from you guys with what features you feel are appropriate for this module, EEPROM, Flash, signal LEDs, security signing, anything at all!

[Samuel235]

UPDATE!

The sensor circuitry is now complete to give me a baseline voltage of 0.93V. This will allow for any variation in the sensor and the offset created by the op amp. I have used a double op amp system, the second op amp is performing a voltage follower role to remove any current interference from the voltage divider i have put in place to create the baseline to allow for errors to occur. The below schematic is for this section of the module. Getting close to getting the hardware side complete now. Just a few little things to iron out.

Currently completed hardware:

Carbon Monoxide Sensor
Motion Sensor
Voltage Regulation
Buzzer
Radio
Programming Headers

Currently working on:

Smoke Sensors (Optical and ionization, i may switch to particle detection though)
Temperature
Humidity
Ambient Light
AC Power connection
DC Power connection

Recommendations - Does anyone have anything else they would to see included onto this module?

Atsha204 signing?
External Flash?
EEPROM?
Status LEDs?

[scalz]

@Samuel235
good job ;) sorry for not being more active, actually busy :confused:
if you have things which needs security or "anti hacking" like pir for instance, I would add atsha. But it depends of pir usage too.
Eeprom, as you want, but still useful.
Led is always nice when you have enough room. for debug and indicators.
I'm not sure if temp/hum sensor location is best at ceiling...during heating season, I think this is not representative of what we feel...but why not, perhaps in some case it can be useful. So, I prefer to have mine at the middle, not near a door or heater etc...
humm, that make me think I need to hack my smoke sensors too..not done yet :blush:

[Samuel235]

@scalz, I think i will be adding in what i can with the space, so i'll try and get it all included, EEPROM, ATSHA and if i have any pins left, i will get some debugging LEDs on, not holding my breath though.

As you have experience in using the I2C components i'm using here, could you have a quick look at the following at just let me know that they are okay and will not be conflicting on the I2C lines. I have looked into the addressing and i hope i have done accordingly.

If the Temp reading is completely off the accuracy due to its location i will just use it to compensate for the temp on the Carbon Monoxide sensor.

[Samuel235]

Because i'm clueless on the software sides of this, i'd like to ask someone from the @Code-Contributor group to give me their opinion on whether or not i would need some external memory on this module. The code will be including:

• Carbon Monoxide Sensor
• Smoke Sensor
• Optical Sensor
• Ambient light
• Temperature and humidity
• Radio
• PIR Motion Sensor
• ATSHA security IC.

[scalz]

for example, I would use an eeprom for:

• dualoptiboot ota option
• events or datalogging option
• etc

but I'm not sure if you really need it for datalogging here..

[Samuel235]

@scalz, I was just worried about the size of the software to be honest. I initially wanted this to have 'modes', a day and a night mode. But this is only really for the use of the PIR Motion detector. So, I'm now thinking of having a option/switch inside of OpenHAB where i can manually toggle it or have the clock toggle this switch which would then turn the motion sensor on (the mosfet that is acting as a switch).

So after considering my alterations, i think for now as i'm opting for the manual switch option, i won't need any extra EEPROM as the on-board amount of the Atmega328p should be more than enough for my needs. In terms of the bootloader, i'm thinking of going for a branch of Optiboot normal. Then if i do switch my controller to MYScontroller i will switch the bootloader over to that of MYSbootloader to allow for OTA software updates.

I'm still toying with the option of adding a USB/FTDI IC on-board to be done with the FTDI header for the 'new guys' to be able to just plug straight into a usb port as i plan on making these if anyone wants them and then therefor i will be bootloading and fuse setting myself, then they wouldn't need to have access to the ISP port that way either... So a nice handy little USB port on the side of the module casing would be all they need access too, and the AC input terminals obviously.

Did you get a chance to have a look at my I2C components above?

[scalz]

@Samuel235
I have looked a bit.

For your i2c sensors, if you want you can add a 10k pullup on light int pin. That's all, but not really mandatory, internal pullups works ..nothing fancy. that should work ;)

Your opamp circuit, seems ok, but I can't tell more as these things need testing, simulation. as you noticed analog is not as easy as it appears lol :) btw simulation circuit tools are nice for checking and understanding concept or circuit (like spice, isis etc..). careful with copy of block sch, it's better to understand, for debug then ;)

Last notes, I would add some debug points for analog parts so you can measure voltage easily during debug phase. because it's possible that things change a bit, breadboard vs pcb, as your sensor is in mV range.

Keep up the good work, can't wait to see your device :)

[Samuel235]

@scalz, 10k Pullup has been implimented. I did have it in and for some reason I now remember deleting it, not too sure why i did such a thing. I will get some pads added on the analog lines like you advise to enable easy testing, do you advise to just add some pads on the lines that i would like to test?

[Samuel235]

The last sensor to be configured and to actually even get working now is the optical smoke sensor. I'm currently having some issues and troubles with even getting the concept of the reflective IR optical sensor to work. Been attempting for days now, hopefully will get this issue sorted ASAP as this is the really holding the module still now. Once this is done, i have a little work on the external powering to do but that shouldn't be too trivial and we can get the board sent off to the board house for manufacturing then.

[Samuel235]

Optical Sensors

While we're on the topic of optical sensors, all the market research that i am doing currently regarding these types of sensors just shows how many products are using optical sensors in the reflective setup, where the smoke causes the IR light to be reflected from the LED into a phototransistor and then therefor change the analog reading of the transistor. They seem to be choosing this over the 'Interrupt' method of having a IR LED shining into a Phototransistor and then smoke interrupting the light rays and therefor changing the properties of the transistor.

Can anyone see an advantage from this other than i would personally feel it is less likely to produce false triggers?

If this is the only reason it would be more beneficial to use the reflective method, i'm thinking about attempting to overcome the false triggers as the 'interrupt' setup method uses a much lower area on the board. If we could work around these false triggers i feel that it would benefit this setup much more.

I'm pretty sure that the power usage is the same because the LED would be permanently on at the same level for both methods.