Hi , Klaus_ww  please tell me some information about hysteresis its new concept for me thanks. 

Hysteresis is where there is a dead band in your logic, for instance you could switch on at a reading of 590 and switch off at say 610 giving a dead band of +-10. Your original code could be rewritten as follows:

Code:

int reading;
int deadband = 10;
int setpoint = 600;
reading = analogRead(0);
if(reading < (setpoint - deadband)){
digitalWrite(12, LOW);
} else if(reading > (setpoint + deadband)){
digitalWrite(12, HIGH);
}

Note: untested code...

Probably.

I am more optimistic and would say yes. If you also want to measure each LDR resistance, wire each one as a voltage divider.

You are using a multiplication factor on what I assume is the direct ADC reading (0 - 1023).  This is proportional to the way you have configured your voltage divider. An alternative correction would be to assume the sensitivities of the different LDR's are the same, but there are constant factor offsets between the different LDR resistance values.  This method is a bit more involved since it requires you to convert the ADC reading into the corresponding LDR resistance.  If I assume you have configured your voltage divider as follows: Vcc - LDR - measuring point - fixed resistor - ground then your ADC reading would be related to the LDR resistance as follows:
ADC reading = R_fixed / (R_LDR + R_fixed) * 1023

It then follows that a fixed percentage offset of the LDR resistance would lead to a non-constant percentage change in the ADC reading.  To assign a constant calibration factor to the LDRs you have to convert the ADC reading back to a resistance, then apply a correction factor, e.g.:
R_LDR = (R_fixed*1023 /(ADC reading) - R_fixed) * correction_factor

Of course if you do this your control logic will have to reverse, since the R_LDR and ADC values are inversely proportional.  Or you have to convert your corrected R_LDR back to a corrected ADC reading, but this is unnecessary in my opinion.

Further, it seems as if your fixed resistors are of 5% tolerance, this may also contribute to different voltage divider ratios if the different resistors have noticeably different values.

The DHT protocol provides a communication error check. It transmits two bytes for humidity, two bytes for temperature and one byte which is the sum of the previous four bytes.  If the values received adds up to the fifth byte then there isn't (statistically speaking) a communication error.  A less technical error check is if the received humidity and temperature values are vaguely believable there probably isn't a communication error. I've found that I get reliable communication with a DHT11 over about 5 meters of CAT5 network cable using only the internal pull-up of the atmega enabled on the data pin.

I suspect you are simply seeing the inherent inaccuracy of the sensor.  I've also compared the DHT11 temperature reading with an LM35 and a thermistor.  The DHT11 was not as accurate as the other temperature sensing elements.  I regard the DHT11 temperature reading as optional information, if you really want to measure temperature to better than +-2°C accuracy use another sensor.  Also remember the +-2 °C stated accuracy is approximate and the reading gets truncated or rounded to an integer value so the accuracy of individual sensors may vary by as much as +- 3°C.

ok, I see now, the timing is out. I uploaded blink to both the arduino and the tiny. then powered them up at the same time.  They slowly go in and out of sync.

how do I "read them back and verify them?"?

Is this the next step I have to take?

The internal oscillators are not very accurate.  To improve the accuracy of the internal oscillator, you can change the OSCCAL register until a timed event (say flashing an LED every 1 second) actually results in a flash every 1 second.  You could change for example the blink sketch by changing the OSCCAL value in setup:

Code:

OSCCAL = OSCCAL + 1;

Timing the flashes with a stop watch should tell you whether the oscillator is running fast or slow, increase the OSCCAL value more if it is slow, decrease it if too fast.

It seems as if the Tiny Tuner code varies the OSCCAL value to match the expected bit pattern of a serial transmission of the character 'x'. It is a good automatic procedure, but you need to hook up a serial line that transmits the expected value.  Of course in your case what you really want to do is calibrate the oscillator to give reliable serial transmissions, so the Tiny Tuner is probably the most appropriate method for your situation.

Hy,

I wounder if someone could help me with this one: I´m planning to build a joystick with 4 pots, 7 buttons and one POV hat (hat switch). I would like to use only one Atmega8 for the project, but I have no clue how I could communicate with my computer. One option would be to use the arduinos built in serial-to-usb chip, but I would like to only use an Atmega8. How can I do that, or is it even possible to do so?

Do you want to build a serial or USB based joystick?  Serial would be relatively easy to build, you just need to add something like a MAX232 or equivalent chip to translate from the Atmega's 5V to the required +- 12V as required for serial communication. This is probably a dead end though since serial ports are quite scarce on modern computers.

You could build a USB based mouse by implementing the HID interface for a mouse using the V_USB library (http://www.obdev.at/products/vusb/index.html).  An Arduino port of this library can be found at http://code.google.com/p/vusb-for-arduino/.  This will be a little bit more tricky and will require some internet searching for examples to adapt.  Some examples can be found at http://www.obdev.at/products/vusb/prjhid.html but are not specifically adapted to the Arduino environment.

Not even can burn a bootloader now ><

Looking at the error message seems to suggest that the bootloader file is not found.  Check that the bootloader hex file is in the path that avrdude is searching, this is printed as part of the output at the bottom of the screen.

The following line seems strange:

Code:

atmega328bb.build.core=arduino:arduino

The other entries shipped with my Arduino environment have the following form:

Code:

atmega328bb.build.core=arduino

You may also have to provide the path to the bootloader:

Code:

atmega328bb.bootloader.path=atmega

This plus johnwasser's suggestion should give you a working boards.txt file.

I don't think you need a 16MHz crystal on the new chip when burning the bootloader.  What errors do you see?

I assume you are using the non-inverting circuit?  If so I guess the only thing you need to consider is the leakage current of the input pin.  In the wiki link you sent there is a circuit where a resistor is connected to the inverting input specifically to limit the impact of leakage current on the inverting input voltage.  Not sure this will help when connected to a voltage divider since there will be an additional voltage drop over this resistor.  Perhaps just make sure that the current through the voltage divider is much larger than the input leakage current of the op amps.

This will fail, because optiboot.c has a bug. Fortunately, the bug was fixed -- just grab the patched code from http://code.google.com/p/optiboot/source/browse/optiboot/bootloaders/optiboot/optiboot.c?spec=svn5ec3f2030308441365fe4e9aebf7ebeb8939fae8&r=5ec3f2030308441365fe4e9aebf7ebeb8939fae8 and then you can proceed to run the command again to compile your custom bootloader.

Thanks for sharing tylernt.  I ran into this bug when trying to compile optiboot for low baud rates.

void startConversion()
{
  ADMUX = (B01000000 | currentAdcChannel);   // Vcc reference, select current channel
  delayMicroseconds(5);    // only needed if using sensors with source resistance > 10K
  ADCSRA = B11001111;   // ADC enable, ADC start, manual trigger mode, ADC interrupt enable, prescaler = 128
}
...
BTW using a delay inside an isr should generally be avoided, however very short delays to allow hardware to settle are OK.

I'm trying to understand what the delay will do to the ADC process, but my understanding of the manual isn't great. I've reread the manual on ADC several times but I cannot make sense of statements such as:

An analog source applied to ADCn is subjected to the pin capacitance and input leakage of that pin, regardless of whether that channel is selected as input for the ADC. When the channel is selected, the source must drive the S/H capacitor through the series resistance (combined resistance in the input path).

Does this imply that the ADC circuit starts charging once a channel is selected in ADMUX but before the ADCSRA ADSC bit is set?  Elsewhere the manual states that the sample & hold of a channel only starts after the ADSC bit in ADCSRA is set, so a delay before setting ADCSRA shouldn't affect the charging of the ADC cap?

That didn't do anything. I've tried burning the bootloader with the Adruino IDE, I've even tried running AVRDude from command prompt just sending the erase command. Is there something I can do to test my programmer to make sure it is even working? Like I said before Windows 7 detects it fine and the drivers are installed.

You could ask AVRDUDE to list some signatures of the chip:

Code:

avrdude -p m328p -c usbasp -U lock:r:lock.txt:h -U efuse:r:efuse.txt:h -U hfuse:r:hfuse.txt:h -U lfuse:r:lfuse.txt:h -U signature:r:signature.txt:h

I'm not sure whether you need to specify the port for a USB device (-P usb).

I've done it in the recent past.  I added the following to the boards.txt file:

Code:

##############################################################
atmega8u.name=ATMEGA8
atmega8u.upload.protocol=arduino
atmega8u.upload.maximum_size=7680
atmega8u.upload.speed=115200
atmega8u.bootloader.low_fuses=0xff
atmega8u.bootloader.high_fuses=0xcc
atmega8u.bootloader.path=optiboot
atmega8u.bootloader.file=optiboot_atmega8.hex
atmega8u.bootloader.unlock_bits=0x3F
atmega8u.bootloader.lock_bits=0x0F
atmega8u.build.mcu=atmega8
atmega8u.build.f_cpu=16000000L
atmega8u.build.core=arduino
atmega8u.build.variant=standard
##############################################################

The only other trick is to get a programmer or another Adruino board that you can use as a programmer.  I've had success with the parallel programmer described elsewhere on this site, it is a lot cheaper than the commercial programmers. Of course it will only work if your PC has a parallel port.  A USB type programmer is a bit easier to work with though.

1) Do not directly connect an Arduino board to line voltage (110 or 220 Volt AC). As you correctly suspects, it will be fried.  It is also (more importantly) a shock hazard.  If you still want to use an Arduino to switch 220V on/off, use a switching device such as a mechanical or solid state relay or a triac.  It is good practice to also add an isolation device between the low power device and the 220V side, such as an opto-isolated diode or triac.  You need to research this a lot more before you should attempt to experiment with 220V.

2)You can use an online calculator such as http://ledcalc.com/.  You need to know the voltage drop across the LED (check datasheet of LED, else assume 2V) and the target current (this determines brightness of LED).  I think something like 20mA is plenty for an LED, anything between 5 - 20 mA should be visible.

The colour coding on resistors can be found online (e.g. http://www.elexp.com/t_resist.htm) or in an electronics textbook.  I can't remember the coding so I use my multimeter to measure resistance.

Quite late in this discussion, but I have found an Arduino port of V-USB here: http://code.google.com/p/vusb-for-arduino/downloads/list
It seems as if RancidBacon has wrapped the exported functions as follows to make them compatible with Arduino's C++ environment:

Code:

#ifdef __cplusplus
extern "C"{
#endif
USB_PUBLIC void usbInit(void);
USB_PUBLIC void usbPoll(void);
#ifdef __cplusplus
} // extern "C"
#endif