Show Posts
Pages: 1 ... 37 38 [39] 40 41 ... 48
571  Using Arduino / Sensors / Re: DHT22 accuracy on: February 01, 2012, 06:59:09 am
Not strange at all if there is an element of self-heating going on. How do the temperatures compare?

From what I recall (and memory = leaky) the DHT may be using a resistive humidity sensor that requires (among other things) a 1kHz alternating signal to be applied to it. The resulting output has to be run through an op-amp (or a sensitive ADC) and temperature-compensated. It wouldn't surprise me if this humidity sensor and the thermistor providing the correcting temperature are self-heating at different rates depending on the voltage input. Have you tried blowing a fan across the DHT22?

BTW, I don't think the unit is supposed to be run at 6V.
572  Using Arduino / Microcontrollers / Re: Current Logic Analyzer Choices... on: February 01, 2012, 06:53:35 am
Hi Skyjumper,
If I had a bigger budget, buying 'separates'  would have been the way to go. Sort of like stereo systems... But for now, the QA seems to offer a very nice package and the forums seem to be well-supported also. 
573  Using Arduino / Sensors / Re: increasing flow of a water flow sensor on: January 31, 2012, 07:17:08 pm
No, don't drill the case. I just seemed to recall a bunch of those drill pumps having clear cases, which would make a visible-light approach possible.
574  Using Arduino / Sensors / Re: increasing flow of a water flow sensor on: January 31, 2012, 06:58:35 pm
A ratiometric approach may certainly work. The drill pump is a good idea also. You may be able to skip the hall effect sensor and use a infra-red system as well if the vanes are visible. Such a sensor might be easier to mount and more rugged.
575  Using Arduino / Sensors / Re: DHT22 accuracy on: January 31, 2012, 06:55:04 pm
He'd be getting errors if he was trying to read faster than the allowed 2s/cycle rate, no? At least that's what I remember happening to me when I did it accidentally.
576  Using Arduino / Sensors / Re: increasing flow of a water flow sensor on: January 31, 2012, 03:41:48 pm
Watermeters.com offers nice bronze units with 1pulse/gallon, see datasheet here. They are not cheap, but any water meter with any sort of accuracy at this port size (i.e. low restriction) is expensive. That's still not the world's best resolution but better than nothing (i.e. ~8lb / pulse).

Depending on how sensitive your pumps are to dead-heading, the flow restriction is not an issue - review the pump curve. Thus, if speed is not an issue (i.e. you're OK with waiting 2x+ longer than usual) you may be able to use those cheapie sensors you referenced. I wouldn't use such hardware below the water line, however.

A less expensive option (open-loop) is to put a current switch on the pump. Measure the length that the pump has been running, multiply by a known flow rate (and that has to be verified with the local head conditions!) and voila. Current switches are cheap, Current Magnetics is one company that sells them.
577  Using Arduino / Microcontrollers / Re: Current Logic Analyzer Choices... on: January 31, 2012, 02:46:35 pm
I looked those up... thanks. In the end, I went with something more obscure, the QuantAsylum QA100. Not cross-platform but 100MHz sampling rate, very nice ADC resolution (10bit), waveform generator, and 12-channel logic analyzer. I can see why RuggedCircuits would prefer a standalone oscilloscope, but one thing I am after is being able to have both signals on one screen to see what the analog inputs are doing and what the CPU is doing in response. The cost of this solution (~$350) is also a factor, the Salae logic analyzer 16 only does LA... though very pretty and well-thought out LA, for sure.

My point of comparison was adding up the cost of a Rigol DS1102E, Salae16, and a Waveform generator for similar functionality. 2x-3x the cost... Not a fair comparison, but the QA100 is offering a lot of capability for the money.
578  Using Arduino / Sensors / Re: Current Sensing on: January 31, 2012, 02:12:38 pm
If getting an accurate kWh measurement is important, this approach will not work for you.  You would be far better off using a chip designed for this purpose: Can't beat that price, right?  It's a simple serial communication with Arduino, and voila!  You get really accurate energy measurement! On the other hand, you can try to simulate what it does with the Hall effect sensor and code - you will get close for purely resistive loads, but you'll be way off for inductive/capacitive loads.

I tried going that route. For example, Olimex offers a shield with a like chip to do the work. They even have a library that should making measurements easy. However, the devil is in the details.

Not as simple as I would have hoped, the calibration methods are difficult at best unless you have a nice benchtop power supply that can (among other things) provide voltage and power out of phase with each other. In the end, I stuck with the Arduino ADC. Simple to understand, easy to debug, easy to calibrate via the openenergy software. If the power signal is steady enough you can even take advantage of decimation to increase your power measurement accuracy to close to 16 bits with the measurements you can make across a second of time (20MHz Atmel, 128:1 pre-scaler, using direct analog reads = 5,500+ samples per second on each channel).

If I ever want to go to something more sophisticated/accurate, I'll opt for a dedicated ADC instead, the MAX1169 is one example of a easy-to use I2C device that gets me 58ksps with 16 bit resolution. Put a 2 channel MUX in front and you get over 24ksps per channel and you still have a input that is drop-in ready for the openenergymon routines. With this sort of ADC, you can get a theoretical 22bit resolution through decimation if you need the data on a second-by-second basis (i.e. sample 24k => average six times of 4096 samples = base ADC resolution + 6 bits).  
579  Using Arduino / Sensors / Re: DHT22 accuracy on: January 31, 2012, 07:02:52 am
There may be an element of self-heating at play here that in turn influences the readings - the DHT manufacturer may be using a thermistor in there to help establish the actual humidity. Turning the chip on and off may help with that thermistor experiencing too much self-heating.  If the offset is consistant and constant, the easiest approach may be to simply map the differences and code an offset instead.

Keep in mind that the accuracy of the DS18B20 is only +/- 0.5*C per the datasheet.

Turning the DHT22 on and off is likely permissible, but I'd check with the manufacturer to be sure. Using the Arduino in this fashion is likely OK as well, but I'd verify that the Atmel CPU can handle the required currents at all times (also consider all other external loads, there is a hard limit for the Atmel chip). If the CPU can do it and you have oodles of remaining power handling capacity, fine. Otherwise, consider switching the power on and off with an external transistor.
580  Using Arduino / Microcontrollers / Current Logic Analyzer Choices... on: January 30, 2012, 10:42:24 pm
... if you were to buy a good entry level logic analyzer, which would it be? So far, I am aware of two apparently good choices that come in sturdy enclosures and which offer cross-platform compatibility, i.e. the
The Salae appears to have a slightly nicer UI, but the bitscope also offers a waveform generator. Thoughts?
581  Using Arduino / Microcontrollers / Re: Chinese clones on: January 30, 2012, 10:07:27 am
Patents have their place and are an important part of pushing science forward by creating a financial incentive to pursue all sorts of research with the hope that something will come of it. Some companies now derive 100% of their value from patents - see Kodak and Nortel, for example. IIRC, Micron Technologies sold off its entire IP portfolio to a patent troll to monetize it.

That said, allow me to disagree a bit with your statement that not only the big guys benefit. A good friend of mine was sued in patent court, left penniless, before the other side dropped all charges before a judgement would be rendered (because they would have lost). A small inventor has no hope of prevailing against the big guns unless he/she can enlist the help of a patent troll with their resources (though for a pretty commission, I am sure). It comes down to not only being able to claim a patent but also to defend it.

This is yet another instance where I wish the US would feature the 'loser pays' policy for civil trials used in the EU to keep frivolous suits out of the courts and to level the playing field between big and small parties at the negotiating table. In the US, if the stakes are high enough, it simply pays to bankrupt a smaller opponent through court costs rather than pay for the royalties. A perversion of justice for sure but a daily reality also.
582  Using Arduino / Microcontrollers / Re: Chinese clones on: January 30, 2012, 07:00:34 am
"Chinese clone" is more of a statement about lax adherence to intellectual property law (and custom) than a statement about quality...

Spot on. That said, the extremes to which special interests have been able to pervert copyright law (120 years?) and patent law (business models, software?) in the west is not healthy either.

Note how the titans of the tech industry now pursue an oligopolistic system where they cross-license all sorts of patents as a means of limiting market entry by others who are not in 'the club', i.e. non-tariff barrier to entry. Patent trolls are thriving, owning a lot of IP, but not making any attempt to actually manufacture something.

But, as long as it's as cheap as it is to buy votes in Congress with money in the right places and some tearful testimony and/or a healthy dose of testilying, special interests will continue to make end-runs around the interests of the public. Unlike limited, and hence notable exceptions, I haven't seen anyone demonstrate in public re: perversions like ACTA, SOPA, PIPA, etc. So, copyrights will keep getting extended to keep Mickey Mouse out of the public domain an as a result, stagnation will set in.
583  Using Arduino / Microcontrollers / Re: Chinese clones on: January 30, 2012, 01:21:10 am
Just have to add something here.  It's crazy when people use "Chinese" to imply low-quality products, especially regarding electronics.  The fact is, China is the worldwide center of excellence for electronics manufacturing.  If you missed it, see the NY Times' article, How the U.S. Lost Out on iPhone Work.  Yes there are low-quality counterfeit products to be had from China.  It's a big country.  We shouldn't tar the whole country's industry on the basis of the bad actors.
I couldn't agree more. Manufacturing is a passion of mine and I see no reason why location has to determine anything re: quality. It's all about the people, the systems they are given, the quality of the design, suppliers, etc. not the country it's made in. Otherwise, we'd be seeing things in the USA like differential sticker pricing based on whether a Toyota was made in the USA or Japan. (That used to be the case for VW, BTW). Even 'small' car brands like Porsche can have multiple, multi-national manufacturing sites and the only clue re: origin is the VIN number.

But let me use a better example, one that many of us are familiar with, PCB manufacturing. I've used DorkBot PDX and Iteadstudio. Which of the two do you suppose allows you to run smaller lines, gaps, and holes? Which is the faster service? You'd think the locals would have the advantage here, and they don't. I don't even mind the significant $/in^2 upcharge on a per-board basis, this is prototyping after all, but the slower service is starting to get to me.

I have nothing but the highest respect for Laen for running this service of his, but two boards I submitted weeks ago still have not even garnered a response from him while the folks at iTeadstudio replied within minutes even though their New Year celebrations are going on. Granted, the boards won't be made until Feb 1, but at least they will be made. It's hard to stay in business if you don't respond to customers. Nuts.
584  Using Arduino / Sensors / Re: DS18S20 giving slightly to high readings on: January 30, 2012, 01:07:31 am
I need a temperature sensor for my project with a resolution of 0.1°C (actually I only need it between 0-80 Degrees, to be honest even less, but it should cover this area) and found this 1-Wire Digital Sensors and decided to try out the DS18S20.
As I recall, the output of the S series is 9 bit and the B series is 12bit. Are you accounting for that in your code? There are encapsulated versions of the series out there... easy enough to stick one of those into a ice/boiling bath of water to establish some goal posts.

Lastly, it wouldn't surprise me if your room thermostats are off, none of the thermostats I have looked at used such nice sensors... too expensive.
585  Using Arduino / Sensors / Re: Preferable Thermistor Configuration on: January 29, 2012, 02:32:41 pm
So I took a look at the outputs out of a Wheatstone bridge vs. a Unipolar design in Excel. The conclusion I come to is that either design can work, it really depends on whether the ADC is of the unipolar bipolar type. The latter definitely benefits from a Wheatstone bridge - otherwise you're throwing away a bit of resolution for no good reason.

The resolution at low temperatures for the resistor values I chose (4k7x2 and 2k2 on the Wheatstone and 11k for the Unipolar design) and the 2k2 precision thermistor from US Sensors is gargantuan when it comes to 0-50*C measurements which are the mainstay of our expected temperature measurements. (I never expect measurements below zero *C, that would require a different kind of sensor.)

The differences are more pronounced at the high end of the temperature scale, however, where the linearization of the Wheatstone tends to decompress the steps a bit. To cite an extreme, the number of bit 'steps' from 110*C to 120*C for the Bipolar/Wheatstone approach is 542 while the Unipolar design makes it to 392.

So, you gain a bit of resolution at the high end of the temperature scale with the Bipolar design while enjoying fewer steps at the low end of the temperature scale.  To put that in perspective, the 0-10*C range enjoys 17k steps in the unipolar design and 'only' 12k steps in the bipolar design. But either approach is offering up 10x the theoretical resolution of the Arduino. And 10k+ steps should allow me to characterize the temperature rather well.

To properly get to temperature measurements in between stated data points, I decided to create a lookup table that uses a ln(x) function between each published data point for interpolation. The results match up to beyond 3 digits after the dot, which is good enough for me. I plan on dumping these floats  into ProgMem as an array and using them in a ln approximation function as a function of the integer that the ADC is reporting.

I derived the offset and multiplier through an iterative approach in Excel. The nice thing about all that work is knowing that I can now convert directly from the long integer values reported by the ADC into a temperature. See below:



Temp (*C)ADC Integer Valueln(x) multiplierln(x) Offset constant
1201045-22.27923662274.880177
1101637-24.95192121294.6597015
1002444-26.56710287307.2603658
903561-27.61393547315.8211499
805115-28.17896062320.6464267
707294-28.51382449323.6249762
6010358-28.86768587326.8966067
5014646-29.47440202332.716181
4020562-30.6152316344.0459878
3028505-32.1216923359.4990127
2533306-33.62930719375.1985497
2038645-36.90097385409.7544579
1050674-44.05057072487.2072436
063588-56.60933954626.1094879
                              
         
To get at the offset and gain issues inside the ADC, I am considering the following: Use a 8 channel multiplexer with 3 precision resistors to create a linear offset. Every time the MUX inputs are cycled for all the channels, these resistors are sampled also. Then, the offset is calculated and added as function of the integer that the ADC is responding with on later measurements. So that takes care of offset and hopefully gain errors also.

At the 15 samples per second rate that this ADC supports in 16 bit mode, I may even elect to do two measurements of the other analog input channels (i.e. 10 samples altogether) and average them for ever second time-slice I am interested in.

Last but not least, I expect that no matter how well the thermistors are calibrated up front that they will need to be calibrated once they're on the ADC. The test with least damage potential is ice water, as thermistors apparently do not like prolonged exposure to temperatures above 90*C. But I might try both an ice water and a boiling pot of water, just to 'bound' the ADC range.
Pages: 1 ... 37 38 [39] 40 41 ... 48