Show Posts
Pages: [1] 2 3
1  Using Arduino / Sensors / Re: DS18B20 self heating or what? on: January 30, 2014, 10:38:23 am
I think that if you want calibrated temperature readings, you need to use an offset value for each individual sensor. I think that the 'standard' sensor is not calibrated for an offset, so it will read consistently for itself within 0.5 degrees as per spec, but the reading is not guaranteed to be within a certain deviation from a standard temperature. So sensors from different manufacturing batches would maybe all read the same, but not the same as a different batch.

That is why I always talked about comparing two or more sensors with each other. That way the error is meaningless.
2  Using Arduino / Sensors / Re: DS18B20 self heating or what? on: January 29, 2014, 03:10:52 pm
jremington, could you please explain the following:

- reading the same sensor again and again gives (almost) the same results. There is no variation anywhere near +-0.5 °C. See my data, it is at maximum at about +- 0.1 °C at a given sensor.

- comparing two sensors gives a (almost) constant difference between two sensors when exposed to the same environment situation. again this difference follows the before observation.

Why should two given sensors suddenly behave different when one is exposed to a different environment (blowing fan...)?

I'm totally with you if you talk about a prediction of unknown sensors. But here I have existing sensors whose behavior I can measure and compare...
3  Using Arduino / Sensors / Re: DS18B20 self heating or what? on: January 29, 2014, 02:37:59 pm
So we agree that a single DS18B20 has a (more or less) constant offset to the real temperature. So if I have a row of DS18B20 is see different temperatures on each sensor, but (more or less) constant for each sensor. (the later shows my data from last posting.)

Right?

This does not explain why there is a difference of about 1 °C between "with fan" and "no fan" regardless which sensor I use. If I swap sensors I get (more or less) the same results.
4  Using Arduino / Sensors / Re: DS18B20 self heating or what? on: January 29, 2014, 01:00:48 pm
data1 is just one measurement every second (or so). As far as I interpret it, it shows the room temperature sinking and that consecutive measurements are almost const. Sensor noise (is this the correct description?) is less than 0.1 °C.

data2 is holding my solder iron to the to-92 for some seconds, remove it and measure every second (or so).

It all doesn't say anything about real room temperature, only what the sensors thinks. But the difference between both seems to be constant +- 0.1 °C at maximum.
5  Using Arduino / Sensors / Re: DS18B20 self heating or what? on: January 29, 2014, 12:10:41 pm
Data sheet reading can be difficult!

I would be with you if I could see the values vary within the range of +-0.5. But they don't. They are more or less stable. I currently get

#2 62  Temperature = 20.69 Celsius,
#3 D4  Temperature = 20.31 Celsius,
#4 98  Temperature = 19.56 Celsius,
#4b 24  Temperature = 19.56 Celsius,
#4c 3C  Temperature = 19.56 Celsius,

for a really long time, vary within occasional jumps +-0.1 at maximum.

I would interpret the data sheet value of 0,5 °C as theoretical maximum constant offset value of accordance between real temperature and what the sensors gives. On page 19 Maxim writes about a "Thermometer Error", in figure 17 they give a mean error of 0.2 °C. It is not very clear.

There is nothing in the data sheet that says anything about the error between two consecutive measurements. At least I didn't find anything. As far as I see in reality, the consecutive measurements are quite stable (and don't jump +-0,5 °C).

And yes, I swapped sensors. Same game, same results.

6  Using Arduino / Sensors / Re: DS18B20 self heating or what? on: January 29, 2014, 11:15:54 am
I had the same suspicion.

By adding parallel DS18B20 to the fan #4 (so we have a #5 and #6) I see almost exact values for those DS18B20:

#2 62  Temperature = 20.75 Celsius,
#3 D4  Temperature = 20.56 Celsius,
#4 98  Temperature = 19.81 Celsius,
#4b 24  Temperature = 19.69 Celsius,
#4c 3C  Temperature = 19.62 Celsius,   

It is significant different. So: no, sorry, it is not the accuracy error.
7  Using Arduino / Sensors / DS18B20 self heating or what? on: January 29, 2014, 10:08:16 am
The self heating of the DS18B20 is a topic with a lot of things said about, GIYF. Yesterday I thought I had a bad case of self heating so I tried to explore it a little bit.

I wired up four DS18B20 on a breadboard. Two are on one bus, one of those is powered directly the other is powered in parasite mode. The parasite one got an additional cosy casing to try to keep all the heat. The third one has its own bus, powered directly via a PIN on the Arduino. Idea is to completely turn off the power during idle phases. The fourth one is like the third one with the difference of half a meter cable and a fan blowing mildly at the TO-92 package.

I took the "DS18x20_Temperature" example and modified it so that #1 and #2 are constantly polled while #3 and #4 are only polled once a minute. After 15 minutes I got the following results (almost stable on every read, within about +-0.2 °C or so):

#1 parasite+foam F3  Temperature = 20.69 Celsius
#2 self powered  62  Temperature = 20.87 Celsius
#3 power on measure D4  Temperature = 20.62 Celsius
#4 power on measure + fan 24  Temperature = 19.56 Celsius

So what it the conclusion? I'm not sure.

If I do some math, I end at the thermal resistance of a TO-92 with about 160 to 210 °C/W, depending on whom you ask. Maximum energy consumption of DS18B20 is about 5 mA at 5 V. Gives 25 mW or a deltaT of 5,25 °C. Taking only the "active" current of 1 mA it gives 1 °C.

The "1 °C" look so promising and it feels so wrong.

So, again, any conclusions?
8  Using Arduino / Project Guidance / Re: ATtiny85, delay() and TIMER0_COMPA_vect on: January 19, 2014, 09:58:58 am
Thanks Erni,

it really works.

Could you explain what happens? I read the PDF but I don't see the reason....

Thanks!
9  Using Arduino / Project Guidance / Re: ATtiny85, delay() and TIMER0_COMPA_vect on: January 19, 2014, 04:26:04 am
Does not change anything. I removed all sei()/cli().

Without setupisr(); I get something about 0,5 Hz at Pin 1 and nothing at Pin 0

Adding setupisr(); I get about 15 Hz at Pin 1 and about 30 Hz at Pin 0.

Disabling Timer1 gives the expected 30 Hz at Pin 0 and (of course) nothing on Pin 1.
10  Using Arduino / Project Guidance / ATtiny85, delay() and TIMER0_COMPA_vect on: January 18, 2014, 06:24:21 pm
Hi!

I use ATtiny from https://code.google.com/p/arduino-tiny/ (http://code.google.com/p/arduino-tiny/downloads/detail?name=arduino-tiny-0100-0018.zip) and try to implement a timer interrupt. This small test program shall blink on pin 1 with 0,5 Hz and do some higher frequent stuff on pin 0. Hardware is ATtiny85 at 8 MHz. Bootlooader burned.

It works really fine if I don't do the "setupisr();". Blinks like a charm. If I do it, all hell breaks lose on Pin 1 and 0.

Code:
/*
 "Burnbootloader" burned
 */

#include <avr/io.h>
#include <avr/interrupt.h>

const byte PinLEDgreen = 0;
const byte PinLEDblue = 1;

void setupisr() {
  cli();

  TCCR0A = 0;
  TCCR0B = 0;

  // set up Timer 0
  TCCR0B |= bit (CS00) | bit (CS02);    // Prescaler  1024
  TCCR0A |= bit (WGM01);                // Timer 0 in CTC mode
  OCR0A = 127;                          // CTC Compare value (count up to 128)
  TIMSK = (1<<OCIE0A);

  sei();
}

ISR(TIMER0_COMPA_vect)
{
  cli();
  digitalWrite(PinLEDgreen, ! digitalRead(PinLEDgreen));
  sei();
}

void setup()
{
  pinMode(PinLEDgreen, OUTPUT);
  pinMode(PinLEDblue, OUTPUT);

  setupisr();
}

void loop(){

  digitalWrite(PinLEDblue,HIGH);
  delay(1000);
  digitalWrite(PinLEDblue,LOW);
  delay(1000);
}

Anyone sees my error? Any hints? Any ideas?

(Goal is to get the OneWire lib running on ATtiny85 and have timer interrupts...)

Thanks!
11  Development / Other Software Development / Re: [MOD] Arduino Enhanced Release 1.0.5 for Windows (installer, drivers, etc) +SRC on: January 09, 2014, 04:30:35 pm
Ok, my current list of things with 1.0.5.

-- no real simple way to structure a project [1]
-- no way to organize the sketchbook [2]
-- shitty auto format (last post is only the tip of the iceberg)
-- library limits

- old gcc
- chaotic device management [2]

1: long story. in short it should work like that: use tabs, have all the declarations (vars/functions etc.) of a logical group at one tab. no need to "forward" declare on "main" tab etc.

2: this results in the stupid design idea of growing menus that could bend multiple times around the monitor. Its so backward '80 style of GUI design... And it is used for everything and its mother, sketchbook, examples, boards, Menues grow and grow and grow...

For the sketchbook, which I find highly useful, I wish I had an option to make a top level project with sub levels. Like "Alarm Clock" is top and "v1", "v2", "v3" etc as sub projects.

If I see the serial monitor of 1.5.5 I will stay with 1.0.5 ER for sure.
12  Development / Other Software Development / Re: [MOD] Arduino Enhanced Release 1.0.5 for Windows (installer, drivers, etc) +SRC on: January 09, 2014, 09:59:47 am
1.5.5 fixes the problem, so there is nothing to suggest. :-)

I assume that once the 1.5.x/2.0?-path has stabilized that your other enhancements and fixes will move into the final version, too.

Exposing the formatter interface to fiddle around with it might not be worth the work. The way 1.5.5 exposes the formatter interface is a good way to add individual changes. If it works (and 1.5.5 seems to work) and there is a way to fix the errors, so shall it be. There are other areas that could need work... and 1.5.5 still has the 5+ years old gcc.
13  Development / Other Software Development / Re: [MOD] Arduino Enhanced Release 1.0.5 for Windows (installer, drivers, etc) +SRC on: January 09, 2014, 05:54:42 am
Another problem, I don't know whom to blame. I have this nicely layouted part of code.

Code:
const unsigned int sigs[7][3] = // namepart, signature, prgmode
// Attiny Sig
{
  { 13, 0x9007, 1 },    // L: 0x6A, H: 0xFF             8 pin
  { 24, 0x910B, 2 },    // L: 0x62, H: 0xDF, E: 0xFF   14 pin
  { 25, 0x9108, 2 },    // L: 0x62, H: 0xDF, E: 0xFF    8 pin
  { 44, 0x9207, 2 },    // L: 0x62, H: 0xDF, E: 0xFFF  14 pin
  { 45, 0x9206, 2 },    // L: 0x62, H: 0xDF, E: 0xFF    8 pin
  { 84, 0x930C, 2 },    // L: 0x62, H: 0xDF, E: 0xFFF  14 pin
  { 85, 0x930B, 2 }
};  

If I press Ctrl-T for autoformat it comes out really ugly. I could live with that (I would prefer less ugly, but ok...) BUT there are space added in front of the closing curly bracket.

There are other instances where things inside comments are changed. I think this is a no-no-no.

What I really miss in this situation is to allow me to fine tune the formatting to my personal demands.

(Created a issue on github, too)
14  Development / Other Software Development / Re: [MOD] Arduino Enhanced Release 1.0.5 for Windows (installer, drivers, etc) +SRC on: December 02, 2013, 07:56:24 am
I came across it by looking around after some gcc improvements. Before that I didn't notice the age of it. Then I learned that there are some discussions about the toolchain, but honestly, I was to lazy to follow all the threads and extract any official words. I downloaded a nightly 1.5 build and it has an old winavr, too.

As far as I see, only the error message has changed (the IDE doesn't place the cursor at the approximate error position... f*ck C).

Some problems are on the libraries side. gcc dropped prog_* types, I found some usage scanning my libraries path. So those files won't compile any more. Mostly adafruit-stuff.

If it makes any sense in doing the work, it would be a nice addition to parse the error messages. And adding a note somewhere, how to manually update the toolchain.

I don't know.  smiley
15  Development / Other Software Development / Re: [MOD] Arduino Enhanced Release 1.0.5 for Windows (installer, drivers, etc) +SRC on: November 28, 2013, 11:57:12 am
Just for information and our all enjoyment... :-)

I moved from WINAVR to "MHV AVR Tools - A WinAVR Replacement". Code size of a random project changed from 12720 bytes to 11926 bytes. And as far as I see, everything works as before only with a current gcc toolchain.

Move is easy:
1. download http://www.makehackvoid.com/sites/default/files/MHV_AVR_Tools_20131101.exe
2. install somewhere, remember the folder name
3. after install, copy this folder to your desktop and rename it to avr
4. uninstall "MHV AVR Tools - A WinAVR Replacement" (installed in step 2. open folder, run uninstall)
5. open your Arduino-IDE folder, go to hardware\tools
6. rename "avr" to "avr org"
7. move the folder from step 3 to this folder
8. delete avrdude.conf in folder avr\bin
9 copy avrdude.conf from avr org\etc to avr\etc
Pages: [1] 2 3