Bristol Digest, Vol 579, Issue 1

Send Bristol mailing list submissions to
bristol@mailman.lug.org.uk

To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.lug.org.uk/mailman/listinfo/bristol
or, via email, send a message with subject or body 'help' to
bristol-request@mailman.lug.org.uk

You can reach the person managing the list at
bristol-owner@mailman.lug.org.uk

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bristol digest..."


Today's Topics:

1. Re: Bristol Digest, Vol 578, Issue 4 (Sean Finney)
2. Programming Pi For Use With DHT 11 Sensor (Peter Hemmings)
3. Re: Programming Pi For Use With DHT 11 Sensor (david)
4. Re: Programming Pi For Use With DHT 11 Sensor (David Smith)
5. Re: Programming Pi For Use With DHT 11 Sensor (Peter Hemmings)


----------------------------------------------------------------------

Message: 1
Date: Sun, 30 Nov 2014 12:33:57 +0000
From: Sean Finney <msfin303@yahoo.co.uk>
To: bristol@mailman.lug.org.uk
Subject: Re: [bristol] Bristol Digest, Vol 578, Issue 4
Message-ID: <547B0EB5.60108@yahoo.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed

I have a chromecast
And I have to be honest for netflix etc... its faultless....
if you try and use it outside what its for, it is glitchy, for everyday
stuff I think its real good

Sean

On 30/11/14 12:00, bristol-request@mailman.lug.org.uk wrote:
> Send Bristol mailing list submissions to
> bristol@mailman.lug.org.uk
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailman.lug.org.uk/mailman/listinfo/bristol
> or, via email, send a message with subject or body 'help' to
> bristol-request@mailman.lug.org.uk
>
> You can reach the person managing the list at
> bristol-owner@mailman.lug.org.uk
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bristol digest..."
>
>
> Today's Topics:
>
> 1. Re: OT: Chrome cast (Ioan Loosley)
> 2. Re: OT: Chrome cast (Keith Edmunds)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 29 Nov 2014 13:48:41 +0000
> From: Ioan Loosley <legit.ioangogo@gmail.com>
> To: Bristol and Bath Linux User Group <bristol@mailman.lug.org.uk>
> Subject: Re: [bristol] OT: Chrome cast
> Message-ID:
> <CAJaRfonreHOwxnTiTqVsPgCwaXzNKewCK000p84Dkat2=7HvfA@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I wonder if in main land eruope the tv's don't have different hrz because
> its cheaper for tv sold in England to have the us standard on it as well
> PAL so they don't have 2 different devices with the same language on.
>
> On 28 November 2014 at 20:17, James Cownie <jcownie@cantab.net> wrote:
>
>> Chromecast video on UK, Euro TVs hertz so badly it makes us judder ? but
>> Google 'won't fix''Very hard' problem, devs claim
>> By Neil McAllister <http://www.theregister.co.uk/Author/2665>, 27 Nov 2014
>>
>>
>> Google disappointed fans of its priced-like-a-pizza Chromecast TV dongle
>> this week, when it said it won't be fixing an annoying video quirk that has
>> some European customers' eyes twitching.
>> http://www.theregister.co.uk/2014/11/27/chromecast_judder_issue/
>>
>>
>> -- Jim
>> James Cownie <jcownie@gmail.com>
>> Mob: +44 780 637 7146
>> http://skiingjim.blogspot.com/
>>
>>
>>
>>
>> On 28 Nov 2014, at 16:21, Chris <cshorler@googlemail.com> wrote:
>>
>> Just bought one of the for 20 quid in PCWorld, seems like a good deal!
>>
>>
>> _______________________________________________
>> Bristol mailing list
>> Bristol@mailman.lug.org.uk
>> https://mailman.lug.org.uk/mailman/listinfo/bristol
>>
>>
>>
>> _______________________________________________
>> Bristol mailing list
>> Bristol@mailman.lug.org.uk
>> https://mailman.lug.org.uk/mailman/listinfo/bristol
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://mailman.lug.org.uk/mailman/private/bristol/attachments/20141129/0a2319ab/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 29 Nov 2014 13:58:52 +0000
> From: Keith Edmunds <kae@midnighthax.com>
> To: bristol@mailman.lug.org.uk
> Subject: Re: [bristol] OT: Chrome cast
> Message-ID: <20141129135852.207d51be@ws.the.cage>
> Content-Type: text/plain; charset=US-ASCII
>
> On Sat, 29 Nov 2014 13:48:41 +0000, legit.ioangogo@gmail.com said:
>
>> I wonder if in main land eruope the tv's don't have different hrz because
>> its cheaper for tv sold in England to have the us standard on it as well
>> PAL so they don't have 2 different devices with the same language on.
> When you send an email to a list (or anywhere, really), you have a choice.
> You can either take sufficient time and care over the composition of the
> email so that readers can understand it easily, or you can write it
> quickly and expect each and every reader to invest the exra time necessary
> to understand your point.
>
> I think, in this case, you've made the wrong choice.




------------------------------

Message: 2
Date: Mon, 01 Dec 2014 10:02:57 +0000
From: Peter Hemmings <peter@hemmings.eclipse.co.uk>
To: bristol@mailman.lug.org.uk
Subject: [bristol] Programming Pi For Use With DHT 11 Sensor
Message-ID: <547C3CD1.4020508@hemmings.eclipse.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

I have another project and would appreciate any advice as (at 71!) am
quite a novice to programming.

Background
I have recently had a problem with dampness around chimney in the loft
and have re-pointed it but it still persists. I am not sure if it is
due to high humidity in the roof space or leaking chimney and need some
way to monitor temperature/humidity over time.
As I have a Pi and found some information on a DHT 11 sensor, I decided
to make a recorder to see if I could resolve my problem.

I have looked at various blogs and found I can use "wiringPi" to
interface the Pi's GPIO's, use cron to log output over time and use
"DyGraph" to display graphs on a webpage:

https://chrisbaume.wordpress.com/2013/02/10/beer-monitoring/

The "Plan"
I have ordered a sensor and will make a breadboard to connect to the Pi.
I will then compile the program and check it works before running it
with cron.
If all goes well I will create a display on a webpage.



Because I might need to "Tweak" the program I also need to learn some
programming which is my weak point. I did do some "basic" programming
many many years ago but not "C" or "HMTL"!

The DMT 11 uses it's own protocol and I need to learn some C syntaxes to
find out exactly how the program interprets its output.

http://www.rpiblog.com/2012/11/interfacing-temperature-and-humidity.html

I would appreciate any links to good basic "C" tutorials so I can first
understand exactly how the program sorts the data.

I have not yet studied the above link but my main problem is going to be
the last half of the C code.

If I get to understand how this all works, it will also help with my
other (shelved) project with remote power plugs!!!

FWIW I am using Pi with Raspian atm.

Regards
--
Peter H



------------------------------

Message: 3
Date: Mon, 01 Dec 2014 10:55:33 +0000
From: david <david@avoncliff.com>
To: bristol@mailman.lug.org.uk
Subject: Re: [bristol] Programming Pi For Use With DHT 11 Sensor
Message-ID: <547C4925.7090100@avoncliff.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 01/12/14 10:02, Peter Hemmings wrote:
> Hi,

> The DMT 11 uses it's own protocol and I need to learn some C syntaxes to
> find out exactly how the program interprets its output.
>
> http://www.rpiblog.com/2012/11/interfacing-temperature-and-humidity.html
>
> I would appreciate any links to good basic "C" tutorials so I can first
> understand exactly how the program sorts the data.
>
> I have not yet studied the above link but my main problem is going to be
> the last half of the C code.
>
Peter
There are plenty of C tutorials on the web, Just avoid the ones that are
C++ ( that is for later!). The first one I found is
http://www.learn-c.org which looks a reasonable place to start.
The only bit it misses is using GCC to compile and that is covered by
http://www.network-theory.co.uk/docs/gccintro/gccintro_9.html
David




------------------------------

Message: 4
Date: Mon, 1 Dec 2014 11:14:28 +0000
From: David Smith <David.Smith@imgtec.com>
To: Bristol and Bath Linux User Group <bristol@mailman.lug.org.uk>
Subject: Re: [bristol] Programming Pi For Use With DHT 11 Sensor
Message-ID:
<15A9D35B5490FC49AC0524AE3A085F0874F259@BRMAIL01.br.imgtec.org>
Content-Type: text/plain; charset="us-ascii"

> -----Original Message-----
> From: bristol-bounces@mailman.lug.org.uk [mailto:bristol-
> bounces@mailman.lug.org.uk] On Behalf Of Peter Hemmings
> I have another project and would appreciate any advice as (at 71!) am quite a
> novice to programming.
>
> Background
[snip]
> I would appreciate any links to good basic "C" tutorials so I can first
> understand exactly how the program sorts the data.

I've not looked at it in detail, but the below site looks reasonable

http://www.cprogramming.com/tutorial/c-tutorial.html

> I have not yet studied the above link but my main problem is going to be
> the last half of the C code.
>
> If I get to understand how this all works, it will also help with my
> other (shelved) project with remote power plugs!!!


Here's the code with a load of added comments (preceeded by "//") to help you understand it :)

// Include various libraries to help
#include <wiringPi.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
// define some constants
#define MAX_TIME 85
#define DHT11PIN 7
//Declare an array of 5 integers to hold the data we're going to receive from the sensor
int dht11_val[5]={0,0,0,0,0};

void dht11_read_val()
{
uint8_t lststate=HIGH;
uint8_t counter=0;
uint8_t j=0,i;
float farenheit;
//Initialise the "received data" array to all-zero
for(i=0;i<5;i++)
dht11_val[i]=0;
// Initiate the data transfer process by putting the pin into output mode and driving it low for 18 ms then high for 40 us
pinMode(DHT11PIN,OUTPUT);
digitalWrite(DHT11PIN,LOW);
delay(18);
digitalWrite(DHT11PIN,HIGH);
delayMicroseconds(40);
// Put the pin into input mode so that the sensor can drive it
pinMode(DHT11PIN,INPUT);
for(i=0;i<MAX_TIME;i++) // Do this code MAX_TIME times
{
counter=0;
while(digitalRead(DHT11PIN)==lststate){ // Keep reading the DHT11 pin once every microsecond until it changes state or we've read it for 255 times
counter++;
delayMicroseconds(1);
if(counter==255)
break;
}
lststate=digitalRead(DHT11PIN); // Store the current state of the DHT11 pin as the "last state"
if(counter==255) // If we aborted out of the previous loop, then abort out of the main one as well
break;
// Ignore the first 4 transitions, and all odd-numbered transitions too (which means we only look at the falling transitions because lststate was initialised to HIGH, so transition 0 would have been HIGH->LOW, transition 1 would have been LOW->HIGH, etc...)
if((i>=4)&&(i%2==0)){
dht11_val[j/8]<<=1; //Shift the bits in the result record left by one. Using j/8 gives us the byte number (j is the bit number, and integer division discards the decimal part)
if(counter>16)
dht11_val[j/8]|=1; // If it took us more than 16 iterations to get from the last (rising) edge to this (falling) edge, then the "high" pulse must have indicated a '1', so set this in bit zero of the result.
// I'm not sure why it's using 16 iterations here - there is only a 1us delay in the loop, so ignoring the loop overhead, that would mean that the threshold between a '1' and a '0' would be 16 us, and the threshold should be at least 28 us.
// Maybe there's a big loop overhead.
j++; // Increment the bit number
}
}
// verify cheksum and print the verified data
if((j>=40)&&(dht11_val[4]==((dht11_val[0]+dht11_val[1]+dht11_val[2]+dht11_val[3])& 0xFF))) // If we think we've received enough bytes (i.e. we didn't abort at any point) and the fifth byte is equal to the sum of the first four bytes, then
{
farenheit=dht11_val[2]*9./5.+32; // convert the celcius reading into Fahrenheit (using "9." and "5." here forces the C compiler to interpret them as floating-point numbers and use "proper" arithmetic operations for better accuracy rather than just integer ones.
// Note that the decimal part of the celcius temperature has been ignored in the C-F conversion
printf("Humidity = %d.%d %% Temperature = %d.%d *C (%.1f *F)\n",dht11_val[0],dht11_val[1],dht11_val[2],dht11_val[3],farenheit); // Print the result
}
else
printf("Invalid Data!!\n");
}

int main(void) // The "main" function is always the one that
{
printf("Interfacing Temperature and Humidity Sensor (DHT11) With Raspberry Pi\n");
if(wiringPiSetup()==-1)
exit(1);
while(1) // Do this code forever
{
dht11_read_val(); // Call the above-declared "dht11_read_val" function
delay(3000); // Wait for 3 seconds
}
return 0;
}

Personally, I'm not sure I'd use a RPi for the interfacing itself, given the timing-critical nature of the pin transitions. There's always a risk that your (user-mode) program could get timesliced out at the wrong point and for that to screw things up. I guess if you don't mind that the possibility of the odd bad reading (you can take account of this in your programming by looking out for stupid-looking readings), then you can do it directly with a RPi, but if you wanted better reliability, you could use a cheap Arduino to do the bus protocol and then send the result via a serial port to the RPi. I think there's a way of preventing your code from being timesliced out on the RPi, but it's not something I've tried.

If you're doing it on the RPi, you might prefer to program in something like Python rather than C (although I'm not sure what Python's real-time bit-banging performance is either).

It's probably too late now, but there are also I2C temperature and humidity sensors available from RS that would be easier to interface to the Pi (which has dedicated I2C hardware so wouldn't need the timing-sensitive IO port manipulation).



------------------------------

Message: 5
Date: Mon, 01 Dec 2014 11:31:42 +0000
From: Peter Hemmings <peter@hemmings.eclipse.co.uk>
To: Bristol and Bath Linux User Group <bristol@mailman.lug.org.uk>
Subject: Re: [bristol] Programming Pi For Use With DHT 11 Sensor
Message-ID: <547C519E.4070006@hemmings.eclipse.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed



On 01/12/14 11:14, David Smith wrote:
>> -----Original Message----- From: bristol-bounces@mailman.lug.org.uk
>> [mailto:bristol- bounces@mailman.lug.org.uk] On Behalf Of Peter
>> Hemmings I have another project and would appreciate any advice as
>> (at 71!) am quite a novice to programming.
>>
>> Background
> [snip]
>> I would appreciate any links to good basic "C" tutorials so I can
>> first understand exactly how the program sorts the data.
>
> I've not looked at it in detail, but the below site looks reasonable
>
> http://www.cprogramming.com/tutorial/c-tutorial.html
>
>> I have not yet studied the above link but my main problem is going
>> to be the last half of the C code.
>>
>> If I get to understand how this all works, it will also help with
>> my other (shelved) project with remote power plugs!!!
>
>
> Here's the code with a load of added comments (preceeded by "//") to
> help you understand it :)
>
> // Include various libraries to help #include <wiringPi.h> #include
> <stdio.h> #include <stdlib.h> #include <stdint.h> // define some
> constants #define MAX_TIME 85 #define DHT11PIN 7 //Declare an array
> of 5 integers to hold the data we're going to receive from the
> sensor int dht11_val[5]={0,0,0,0,0};
>
> void dht11_read_val() { uint8_t lststate=HIGH; uint8_t counter=0;
> uint8_t j=0,i; float farenheit; //Initialise the "received data"
> array to all-zero for(i=0;i<5;i++) dht11_val[i]=0; // Initiate the
> data transfer process by putting the pin into output mode and driving
> it low for 18 ms then high for 40 us pinMode(DHT11PIN,OUTPUT);
> digitalWrite(DHT11PIN,LOW); delay(18); digitalWrite(DHT11PIN,HIGH);
> delayMicroseconds(40); // Put the pin into input mode so that the
> sensor can drive it pinMode(DHT11PIN,INPUT); for(i=0;i<MAX_TIME;i++)
> // Do this code MAX_TIME times { counter=0;
> while(digitalRead(DHT11PIN)==lststate){ // Keep reading the DHT11
> pin once every microsecond until it changes state or we've read it
> for 255 times counter++; delayMicroseconds(1); if(counter==255)
> break; } lststate=digitalRead(DHT11PIN); // Store the current state
> of the DHT11 pin as the "last state" if(counter==255) // If we
> aborted out of the previous loop, then abort out of the main one as
> well break; // Ignore the first 4 transitions, and all odd-numbered
> transitions too (which means we only look at the falling transitions
> because lststate was initialised to HIGH, so transition 0 would have
> been HIGH->LOW, transition 1 would have been LOW->HIGH, etc...)
> if((i>=4)&&(i%2==0)){ dht11_val[j/8]<<=1; //Shift the bits in the
> result record left by one. Using j/8 gives us the byte number (j is
> the bit number, and integer division discards the decimal part)
> if(counter>16) dht11_val[j/8]|=1; // If it took us more than 16
> iterations to get from the last (rising) edge to this (falling) edge,
> then the "high" pulse must have indicated a '1', so set this in bit
> zero of the result. // I'm not sure why it's using 16 iterations
> here - there is only a 1us delay in the loop, so ignoring the loop
> overhead, that would mean that the threshold between a '1' and a '0'
> would be 16 us, and the threshold should be at least 28 us. // Maybe
> there's a big loop overhead. j++; // Increment the bit number } } //
> verify cheksum and print the verified data
> if((j>=40)&&(dht11_val[4]==((dht11_val[0]+dht11_val[1]+dht11_val[2]+dht11_val[3])&
> 0xFF))) // If we think we've received enough bytes (i.e. we didn't
> abort at any point) and the fifth byte is equal to the sum of the
> first four bytes, then { farenheit=dht11_val[2]*9./5.+32; // convert
> the celcius reading into Fahrenheit (using "9." and "5." here forces
> the C compiler to interpret them as floating-point numbers and use
> "proper" arithmetic operations for better accuracy rather than just
> integer ones. // Note that the decimal part of the celcius
> temperature has been ignored in the C-F conversion printf("Humidity =
> %d.%d %% Temperature = %d.%d *C (%.1f
> *F)\n",dht11_val[0],dht11_val[1],dht11_val[2],dht11_val[3],farenheit);
> // Print the result } else printf("Invalid Data!!\n"); }
>
> int main(void) // The "main" function is always the one that {
> printf("Interfacing Temperature and Humidity Sensor (DHT11) With
> Raspberry Pi\n"); if(wiringPiSetup()==-1) exit(1); while(1) // Do
> this code forever { dht11_read_val(); // Call the above-declared
> "dht11_read_val" function delay(3000); // Wait for 3 seconds }
> return 0; }
>
> Personally, I'm not sure I'd use a RPi for the interfacing itself,
> given the timing-critical nature of the pin transitions. There's
> always a risk that your (user-mode) program could get timesliced out
> at the wrong point and for that to screw things up. I guess if you
> don't mind that the possibility of the odd bad reading (you can take
> account of this in your programming by looking out for stupid-looking
> readings), then you can do it directly with a RPi, but if you wanted
> better reliability, you could use a cheap Arduino to do the bus
> protocol and then send the result via a serial port to the RPi. I
> think there's a way of preventing your code from being timesliced out
> on the RPi, but it's not something I've tried.
>
> If you're doing it on the RPi, you might prefer to program in
> something like Python rather than C (although I'm not sure what
> Python's real-time bit-banging performance is either).

Somewhere in the referenceswas mention that C was quicker than Python.

>
> It's probably too late now, but there are also I2C temperature and
> humidity sensors available from RS that would be easier to interface
> to the Pi (which has dedicated I2C hardware so wouldn't need the
> timing-sensitive IO port manipulation).
>
> _______________________________________________ Bristol mailing list
> Bristol@mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/bristol
>

Thanks for all the info chaps, I was going to look into the above before
asking for some explanation, but you've done it before being asked!

I need to study the above, look at tutorials then come back with any
progress/queries after I have the sensor.

Regards

--
Peter H



------------------------------

_______________________________________________
Bristol mailing list
Bristol@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/bristol

End of Bristol Digest, Vol 579, Issue 1
***************************************