Ah – maybe I should embrace slow-cooking on the BBQ

Ah – WHO seems to give me a good argument for my BBQ computer – the ability to slow-cook at low temperatures : 

What is processed meat? – BBC News: “Suspected carcinogenic chemicals can form during meat processing. These include N-nitroso compounds and polycyclic aromatic hydrocarbons. Cooking the meat at high temperatures, especially on a barbecue, can also produce these dangerous chemicals. However, the WHO’s experts admit that the cancer risk is ‘not yet fully understood’.”

(Via.)

Dust in the air in our livingroom

This is the real graphs taken in our living room today

NewImage

The 3 graphs are for 

– Red –  concentration of PM10  in ug per cubic metre of air

– Blue – concentration of PM2.5 in ug per cubic meter of air

– Green – concentration of PM1 in ug per cubic meter of air

From Wikipedia :

The IARC and WHO designate airborne particulates a Group 1 carcinogen. Particulates are the deadliest form of air pollution due to their ability to penetrate deep into the lungs and blood streams unfiltered, causing permanent DNA mutationsheart attacks, and premature death.[4] In 2013, a study involving 312,944 people in nine European countries revealed that there was no safe level of particulates and that for every increase of 10 μg/m3 in PM10, the lung cancer rate rose 22%. The smaller PM2.5 were particularly deadly, with a 36% increase in lung cancer per 10 μg/m3 as it can penetrate deeper into the lungs.[5]

NewImage

My experiences with PM2.5 laser dust sensor SKU:SEN0177

I’m at the moment writing the code to get the new laser-based particle sensor connected to the home automation system in our house.

I’m at this stage hoping the sensor itself is better than the previous sensors – but finding some anomalies in the documentation. The serial based protocol is supposed to look like this :

NewImage

And when I’m reading the serial stream I’m getting this :

Byte_array_bytes =>[66, 77, 0, 28, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 1, 56, 0, 88, 0, 8, 0, 1, 0, 0, 0, 0, 0, 0, 1, 75, 66, 77]

The last 2 bytes is just to make sure I’ve read the whole frame, as this is supposed to be fixed at 24 bytes. What I’m getting is slightly different, at 32 bytes. There seem to be 6 null bytes inserted between the last sensor reading and the data checksum. Hm! Btw. the Frame Length integer seems to say that the frame itself is 28 bytes, which together with the first 4 bytes (Start + frame length integer) should add up to 32 bytes.

So I think the documentation is slightly out of date.

I obviously need to experiment a bit more.