Data logger project

This is an opening post to introduce a project I have been developing on dark stormy nights fueled by Jameson Irish Whiskey that I plan to make availble to members here at low cost, or build yourself. I will release the firmware etc. when completed. First I would like to share the concept and features and get some input to help finalise the design.

So what is it?

• USB powered data logger
• Up to 4 x temperature sensor inputs on 3.5mm stereo jacks
• Uses the Dallas DS18B20 sensor with up to 12 bit res (0.06 degrees C)
• 1 x LPM head input (1mV per mW)
• Build in backlit LCD

Functionality:

• Works stand-alone when USB powered, detecting connected sensors and adjusting screen automatically
• Works with the free Parralax Data Log tool that integrates with MS Excel
• Sample period adjustable via PC for 5, 10, 30 & 60 seconds

This leaves you free to log to Excel easily and setup what graphing, trending and dashboard you want. I have been dialing in an old DPSS 532nm module, logging the LD TEC temp, heatsink temp and optical power which makes setup of the TEC PID control loop much easier! Make a small adjustment, go away, come back and look at the graphs. Easy.

I plan to add option to select temp in C or F. Its all mounted in a small box the size of a pack of cards.

If you dont want to log, but just the LCD data you can power it from any PC etc USB port or a plug pack USB charger like those available just about every electronics dept.

By choosing the Dallas digital sensors there is no calibration required for temperature measurements, only a single 10 turn trimmer to calibrate the ADC reference for the LPM function, currently limited to 1023mW with a resolution of 1mW but I do plan to provide 3 or 4 hardware switched ranges, ie. 1, 2, 4 & 8W.

Full details, pics, plans etc when its complete, but this will at least show some of the logging I have been doing and the dashboards I have found usefull. (next post)

Edit: target price as a DIY build is $150 USD!!!!

Screenshots of some logging I have been performing and various dashboards. The beauty of this design concept is your free to setup whatever graphing any number crunching you desire, and Excel lets you do lots of it.

Attachment 40635Attachment 40636Attachment 40637

I hope to have the hardware in a prototype enclosure completed in a few days, pics to follow.

And one last logging session, this one is a beauty, it shows comparisons of test runs with various kP, kI & kD PID loop tuning parameters, as implemented in my main RGB projector with 3 x 92mm fans and the sensor on the optic side of the main optic table. This helped me understand the system dynamics and determine optimal loop tuning constants. I am a geek with a love of numbers, trends, logs etc. I am a lot of fun at parties and available for hire to bring a unique level of sophistication to your next event. :)

Attachment 40638

Quote:

---

Originally Posted by dnar

I am a geek with a love of numbers, trends, logs etc. I am a lot of fun at parties and available for hire to bring a unique level of sophistication to your next event. :)

---

Even supplies the Jameson's, apparently. >:) Would the output be easy to parse for other tools that Excel? Sparkfun do a small logger (Logomatic) with an alternative 'Kwan' firmware that makes it better than the original, and I turned one into a GPS logger. No screen for output, but plain text and I think some other formats for data, and 8 ADC channels and a couple of serials. I only used one serial and one ADC to watch the battery, but it's been very useful to log cross-country running for years. It's one big lack is a display, but I plug it to USB and get the data out that way. I like plain text data, it's easier to parse and do other things with.

The serial stream is simple ASCII comma delimited text and you could modify the stream until the cows come home. :)

Quote:

---

Originally Posted by dnar

The serial stream is simple ASCII comma delimited text and you could modify the stream until the cows come home. :)

---

Unless the cows' udders are full of pure undiluted Jameson's they do not concern me, but the rest sounds cool. One thought: ethernet or standard RS-232 might be good to add. USB is common but a lot of engineering stuff still either sticks with RS-232, or goes with ethernet. I'm not sure if USB is actually bad from an engineering standpoint, but it has had more than its fair share of shaky reputation even in domestic PC situations.

Edit: Actually, serial on 5V, like on little GPS modules. Wouldn't even need RS-232, as there are several tiny widgets out there barely bigger than the DB9 hardware for people who want long lines of it. But either way there's a lot of good using serial and AT commands to fetch stuff or change settings.

I am using serial over USB with the FTDI chip. Ethernet is easy, its already considered, in fact there is code space to implement a web server with custom web pages. As I am using an Arduino board, the options are endless, hence my choice. RS232, RS485, RS422, WiFi, Bluetooth, packet radio, all simple to add in.

Hm, udders full of pure Jamesons... Good idea, let me work on that.

Quote:

---

Originally Posted by dnar

I am using serial over USB with the FTDI chip. Ethernet is easy, its already considered, in fact there is code space to implement a web server with custom web pages. As I am using an Arduino board, the options are endless, hence my choice. RS232, RS485, RS422, WiFi, Bluetooth, packet radio, all simple to add in.

Hm, udders full of pure Jamesons... Good idea, let me work on that.

---

Really does sound good now. (Udderly fantastic, even). I think the Logomatic was related to the Arduino, but anyway... Web server could be really good because you can use the client with JavaScript to render graphs in any browser capable of it.

I thought of bluetooth, but didn't mention it. Now that you did, it could be worth exploring, because it's fairly secure, can go to 100m with the right antenna, uses serial as a base 'profile'. I read somewhere that the EU loves Bluetooth, but the US barely used it. It's very good though, so that might change.

Lots of options might mean a need to whittle it down to the vitals. Opinions will vary wildly on that, but my suggestion would be to keep ethernet with web, Bluetooth, and raw (TTL) serial, and USB. I suspect there are standard converters from those to most of the rest.

How big will the board be? The one big strength of that Logomatic was that it's tiny.

Incidentally, the Logomatic had a need to flush to SD card prior to power off to prevent SD card borkage. And if power failed suddenly, the card got borked anyway, and it could be permanent. I don't know if your board can benefit from the trick I used to fix that, but in case it can, here goes...
(This is a bit vague as I can't find any of my documentation on it.) The Logomatic has a Li-ion power input and an LDO regulator for 3.3V, and a STOP line that when grounded caused flush to SD card followed by shutdown. I used an aerogel (or electric double layer) capacitor at 1 farad per amp of load current, connected from load side of 3.3V regulator to ground, and an LED with 1.8Vf in series with a 2K2 resistor from the Li-ion side of the regulator to trigger the stop line if the supply failed by pulling it to ground with 10K, and the few hundred milliseconds of supply in the cap were enough to safely flush to SD and prevent damage to it. Even if the code accidentally pulled the stop line low, no harm results, it would just light that LED. It's a bit fiddly to get the right balance of voltage so it stays up when power is there, regardless of the slight variations in Li-ion dischage voltage curve, and reliably triggers proper shutdown on breaking power supply. It works though, and in a projector if the supply is more constant, this idea is even easier to make reliable than it was for me. The main advantage of the scheme is that's it's passive, tiny, and very cheap, barring that cap. But what you spend on caps you more than save in time and effort. Bad shutdowns can and will happen, and this method absolutely protects the SD card, so you could justify making it inaccessible if you wanted to, for easier case design.

I can add SD card buffering easy, with Bluetooth and can monitor my projector temps on my Pebble watch. That's geeky, mid show 'hey look, my KTP crystal is temperature locked at 28.5 degrees' (looking at watch).

You raise some good ideas. I have TTL serial available on the board now, you can drop in 232 or 485 transceiver to suit your needs.

I am using the Freetronics 'Twenty Ten' version of the Arduino Duemilanove which I like as it includes enough on board proto area to mount the reference circuit and calibration trim pot plus the pull up required for the Dallas bus.

http://www.freetronics.com/products/...n#.UmuUo-YZ7bU

The board is small.

Attachment 40639

Freetronics have a model EtherTen that includes 10/100 Ethernet and an SD slot on the same size board while also being 100% compatible with Arduino (Its just like an Arduino with the Ethershield added, yet its a single board solution... I have one of them so that can be done next. No proto area, but that's OK.

Attachment 40640

When I release the open source code, anyone can tweak to suit their needs, add functions etc.

That single board idea might do for production. I'm not sure, but if it can, you might get to save a lot, and displace a lot of the difficulty into code. If your sight gets anything like mine as you get older, you won't regret doing that. :)

About SD card buffering, would it be secure against power failure? As far as I know, there is always a chance that a break occurs during a write no matter how pre-emptive timing and code might be. And if it does, all bets are off. Hence my notion for a passive store of energy that guarantees to persist a while after the main power loss triggers the flush to card. Maybe better schemes exist, but SD cards don't have a lot of controller on them to play it safe. The details went over my head anyway so I decided a crude electronic fix would sort it best.

That watch idea is cool, no doubt about it. Every time I wore a watch, or even had one, it broke down early somehow, no exceptions over several years. But if they'd survived and I'd got into the habit (and could actually see the tiny details well enough) that Pebble thinger sounds like a Good Thing. If a laser looks like going weird during a show it would be useful to know what can be done to prevent it before it happens.

I have a TON of experience with the DS18B20 sensor. I developed some hardware that makes use of one and talks to a microcontroller without a native 1-wire interface or enough horsepower to bitbang 1-wire (cost and size reasons), all while doing a bunch of other stuff.

If you don't want to handle the 1-wire protocol in software, Maxim makes some cool 1-wire bridge chips. The Maxim DS2483 is a pretty nifty (and inexpensive!) 1-wire to i2c master bridge.

FWIW, here's how you talk to the DS18B20 THROUGH a DS2483, assuming you only have one DS18B20 on a given 1-wire bus. These are the i2c commands to setup the bridge for communication and then 1-wire commands for the sensor wrapped in i2c:

where 0x30 is the i2c write address for the bridge chip and 0x31 is the read address,

[i2c start] 0x30 0xb4 [repeated start] 0x30 0xa5 0xcc [repeated start] 0x30 0xa5 0x44 [i2c stop] #Take temperature measurement (temp conversion)

...this next chunk of commands is a little rough, but it only looks that way because you need to repeat the command sequence to set the read pointer on the bridge chip to the data register before each 1-wire "data" byte is returned. Here I don't read the entire scratchpad memory of the DS18B20 because I only care about the first two bytes (temperature) and don't really need a CRC.

[i2c start] 0x30 0xb4 [repeated start] 0x30 0xa5 0xcc [repeated start] 0x30 0xa5 0xbe [repeated start] 0x30 0x96 [repeated start] 0x30 0xe1 0xe1 [repeated start] 0x31 (returns the first temperature byte) [repeated start] 0x30 0x96 [repeated start] 0x30 0xe1 0xe1 [repeated start] 0x31 (returns the second temperature byte)[i2c stop]

If anyone has a need to go super low-level with these chips, I can translate these command strings into "ENGlish"...or you can reference the datasheets *retardo

I have all the code running already, the Dallas 1 wire protocol is a no-brainer. I changed the design from a single bus for all 4 sensors, to using a dedicated port per sensor. This made it easier to arrange the sensors as you wished, so they appear on any channel you like simply by moving the plugs... Coding in C++ makes this a breeze, I simply have 4 one instances of the wire protocol driver, one for each input.

Here are some late night pics of the completed prototype. Ended up adding a second analog input. I might set this 2nd input up for 0-5V.

Attachment 40644Attachment 40645Attachment 40646Attachment 40647Attachment 40648Attachment 40649Attachment 40650

In the LCD screen with data:
1 = Temperature Sensor 1
2 = Temperature Sensor 2
L = Laser Power Meter
P = Peak LPM mW

If you connect a 3rd temp sensor, you loose the Peak reading. Connect a 4th and you loose the LPM readout, although these are always reported in the serial stream for logging.

LED's above the USB connector are:
Green = Requesting/Reading temperatures from the Dallas sensors (takes a second at 12 bit resolution!!!!)
Red = Transmitting serial stream via USB (or serial or Network).
So the green led blips for a second, followed by the red. Read / Transmit.

I really like 16 char by 2 line displays. :) It's not exactly a fetish, but I'm serious. I think it's a result of hours spent programming a DX7. And various Psion Organiser XP's. They all use them. That is a good looking prototype too, even with the cut corners. :) (Literal..) I like those metal boxes. Bit of hammer finish silver-grey paint though, does wonders.. Here, we can buy them like that ready made.

I also like that compromise for the four readings depending on what's plugged in. It's one I could live with rather than one that would annoy me. When you make them for sale, you've got a buyer already.

What's the prognosis for a fast sample rate? Like 5Hz, maybe? While many functions don't need it, it's the kind of thing that might find problems wanting solving later. Like the invention of lasers... Serious speeds are best handled by sound card ADC's DC coupled, probably, but those rarely go below 2KHz sample rate. That Logomatic does allow fast logging (my GPS modules are 5Hz updaters so I wanted the speed). A differentiator accelerated thermopile reading might benefit from rates as fast as 20 Hz. That way you can analyse slopes by eye to gauge things not directly measurable except by much faster devices.

Anything above 20Hz can even be coupled as audio, AC coupled via a 'chopper' circuit to make a faster AC representation, then rectified in software, but there is a unique 'window' of rates up to that point that is not covered by most things, which are either meant to be a lot faster, or a lot slower.

DX7 - now your showing your age. I had forgotten about them until now. Great! BTW, I had a hand on with the new Roland Jupiter while at Music China recently.... Orgasmic flash-backs, prolific pockets of polyphony and frolicking in forests of azure! (better than drugs).

My intended purpose was setting up systems with high thermal mass and relatively slow rates of change.

The PID controller I developed to control the fans cooling the optic table in my projectors uses NTC sensors, with a system resolution of 0.03c. Reading temperature is fast, in fact "over-sample" by averaging 20 readings. This reduces noise (which throws the Derivative stage of a PID loop into spasms and drives the engineer tuning the loop nuts). I was going to add streaming output to that design, however the ATtiny13 doesn't have the IO for serial, and it's code space (1k) is full to the undies running a PID loop so I can't even bit bang...

The etherten is a awesome bit of kit! I have been working on a little java app to talk to the etherten from the PC..

Quote:

---

Originally Posted by dave

The etherten is a awesome bit of kit! I have been working on a little java app to talk to the etherten from the PC..

---

What ya cooking good lookin?

Quote:

---

Originally Posted by dnar

DX7 - now your showing your age. I had forgotten about them until now. Great! BTW, I had a hand on with the new Roland Jupiter while at Music China recently.... Orgasmic flash-backs, prolific pockets of polyphony and frolicking in forests of azure! (better than drugs).

My intended purpose was setting up systems with high thermal mass and relatively slow rates of change.

The PID controller I developed to control the fans cooling the optic table in my projectors uses NTC sensors, with a system resolution of 0.03c. Reading temperature is fast, in fact "over-sample" by averaging 20 readings. This reduces noise (which throws the Derivative stage of a PID loop into spasms and drives the engineer tuning the loop nuts). I was going to add streaming output to that design, however the ATtiny13 doesn't have the IO for serial, and it's code space (1k) is full to the undies running a PID loop so I can't even bit bang...

---

I only recently taught myself C (and Win32 API) so while I managed to make a phase modulation synth engine that aims to emulate the DX7 and extend it, I never did get into all the small microprocessor boards. A bewildering variety of them, and a lack of knowing code at the time they started, put me off, I stayed with small analog designs. But having seen what Dieter Doepfer can do with PIC chips convinced me to remain interested, even if passively. I think I know what bit banging is, using a PWM type idea and filtering output to get a proportional signal out of one signal line.

My small GPS logger sort of oversamples, at least, I wanted the extra samples so I could thin them out optionally later. (If constructing real distances by great circle calculations (the only good way to do it) you can have too many samples, and noise or deviations in altitude can contribute to illusory extended distances. :) But at least this way I get the choice, and can choose thinning that shows an accurate track in terms or time, accurate position, and distance, so long as the RF signals were good to start with. I have no control of those.

Roland building a new Jupiter is like NASA building a new Saturn. Ok, difference in scale, but very very interesting. Digitally controlled analog seems to be an ideal way to go. No aliasing, for one thing. In my code I'm always dealing with one kind of discontinuity or another, in an effort to make a MIDI controlled digital synth sound as smooth and fast in response as analog gear.

VERY nice looking build!

The stereo jacks for the temperature sensor are a great idea! Did you go with parasitic power or do you use each of the t-r-s terminals for gnd-data-vcc?

Quote:

---

Originally Posted by CountFunkula

VERY nice looking build!

The stereo jacks for the temperature sensor are a great idea! Did you go with parasitic power or do you use each of the t-r-s terminals for gnd-data-vcc?

---

Thanks.

Yeah each sensor is 3 wire connected. I did not see any point with the parasitic power method, it's slower by a country mile and using 3 wires is easy. I used 5 meter 3.5mm stereo hifi cables, each cut in half. I'll post some pics of the sensors later, they are mounted on/in an aluminum lug that can be screwed to any metal surface such as optic tables, heatsinks etc.

Here are some pics of the various sensors I have built for this LEXILOGGER.

To suit optical base plate or large heatsink mounting, these have a relatively high thermal mass compared to the bare sensor so they are only suitable for base plate mounting with the entire bottom surface in contact with the surface to be monitored. Hand machined from ali angle, the sensor and JST 2.00mm socket is potted with Araldite. The sensor is first coated in thermal compound and in contact with the ali bracket before plugging the ends with Bluetac and potting. Each lead is colour coded to match graph colours. Mounting is via a single M3 fastener. I made a few of these.

Attachment 40676Attachment 40677Attachment 40678Attachment 40679

To suit smaller contact areas such as LD blocks in DPSS modules I used a ring crimp connector and simply crimped the sensor into the ferule section. Low thermal mass, small contact area to suit small monitoring surfaces.

All leads are 5M with 3.5mm TRS plug for the Logger end, JST (Japan Solderless Terminal) 2.00mm crimp connector at the sensor end.

Here is my test layout, looking at the thermal performance of my Fan PID controller, regulating from a sensor located near the Red Dichro (sort of central to the 3 laser modules and optics - I want to minimise walking in this area).

Attachment 40680

And here are the results after running a 40 minute "test" show, that includes 10 minuted of idleness at the start to ensure everything is stable before the test. I use this cue created from the timeline to ensure repeatability for any retesting as required when tweaking PID kP, kI and kD gains. I settled on 27c for the base plate, as I can maintain this temperature in the hottest environments I now I face, and its around the ideal 25c to suit the lasers. There is no way to air cool and maintain 25c when the intake air could be 24 - 25c (I wont lase above this as it's uncomfortable for me!!!) without resorting to TEC's and more heat sinking. I want to keep it a simple as possible.

Attachment 40681

As you can see, I have achieved good control via PID at the area near the red dichro (black trace) with no oscillation, minimal over and undershoot. PID loop cycle time is 15 seconds. Cooling is via 3 x 92mm fans on the other side blowing directly on the electronic side of the optic plate/table.

Note the temperature adjacent to the scan amps is close to the control point near the Red Dichro, although it does follow the scanner heat pattern. Note the area directly adjacent to the DT30 scanners varies considerably as the cues vary in complexity, size and speed. The scanners clearly contribute most of the heat to the optic table. Measurements taken at each laser module are similar to the black trace although temperatures at each module vary with the colour modulation as you would expect.

I think the optic table temperature gradients are minimal in reality, being < 2 deg Celsius, and now I have regulated the table temperature around the lasers and dichros I am hoping the need to tweak alignment will be greatly reduced, while also assisting Solid State modules and of course the DPSS module too, which with it's own PID control loop will achieve tighter loop control with a more stable optic table (heatsink) temperature.

BTW, the Dallas logging sensor mounted with the PID control NTC resistor is now a permanent fixture, terminated on a 3.5mm socket on the rear of the case so I can plug in and check/log temps at any time, even at a gig.

Attachment 40682

I thought this analysis might interest someone here, it interests me and I enjoy analysing systems such as these. I am available for hire to bore your guests at your next dinner party BTW.

Are those LM335CZ or whatever the number is? Small temperature sensors based on temperature coeffecient, but redesigned to exploit that, and calibrated to 10mV per degree C? Anyway, I like them. But it's been too long since I used one, I even forgot the exact number.

If you need fast reaction time and very consistent swappable sensors for pre-calibrated sicruits, PT100 is nice. Bare elements about 15 quid, likely a lot less in quantity. They can stand the condensation that build up on coolers better than most stuff, but they're originally intended for heat. I like them for fast response and very low thermal mass, and very efficient thermal coupling.

Once you have bored the guests, don't forget to insert little thermistors into the holes. >:)

Quote:

---

Originally Posted by The_Doctor

Are those LM335CZ or whatever the number is? Small temperature sensors based on temperature coeffecient, but redesigned to exploit that, and calibrated to 10mV per degree C? Anyway, I like them. But it's been too long since I used one, I even forgot the exact number.

If you need fast reaction time and very consistent swappable sensors for pre-calibrated sicruits, PT100 is nice. Bare elements about 15 quid, likely a lot less in quantity. They can stand the condensation that build up on coolers better than most stuff, but they're originally intended for heat. I like them for fast response and very low thermal mass, and very efficient thermal coupling.

Once you have bored the guests, don't forget to insert little thermistors into the holes. >:)

---

Nope. Much smarter, they are Dallas single-wire DS18B20 digital programmable sensors with 12 bit resolution (0.06c). Slow, but fine for a logger logging at 5, 10, 30 or 60 seconds. Benefit? Accurate and no calibration.

I have used LM35 before, 10mV/C requires an amplifier so for fast analog applications I still prefer NTC resistors. I do a little trick with the Atmel MCU's, I set the ADC ref to 1V1 and operate the NTC divider from 5V0 with no amplifier required (simple, low cost, no drift). Provides "more gain" giving 32 values per degree celsius which is usable with PID (given correct cycle time, derivative can operate correctly).

Ok. I just thought the Dallas things would be bigger, not sure why...

In the last post I managed to miss out that it was the tempco of voltage references that led to the LM35. I like weird inversions or transpositions of an idea like that. (A similar one occurred to me just two days ago: that 'noiseprint' based noise reduction seems to be based on an inversion of the old 'Vocoder'. Maybe not exactly, but just pondering stuff like that is totally interesting at times.) And things like your trick of resetting a different voltage ref in a ADC, I like that one too. (And have been known to use asymmetrical supply rails in op-amps for getting zero-setting and wide voltage range to increase resolution).

One thing: I only have a vague memory, but isn't temperature control one of those things that will work just as well if you omit the I or the D (I forget which) from PID? At least, I remember that there was something I was told worked just as well with PD when I asked about PID sometime back on usenet.

It depends what your trying to achieve.

P gets you in the ballpark, although alone a steady state error remains.
I removes said error.
D is the prediction of what is going to happen based on rate of change. It reduces overshoot and undershoot.

On some systems P is enough, and for fan cooling with slow rates of change is passable. I want to regulate within +/-0.3c so I is required. Without D I have too much under/overshoot.

Some systems work fine with PI. That's all part of the fun. Model the system with just P and determine what is best to achieve your DEFINED requirement.

Quote:

---

Originally Posted by dnar

Model the system with just P and determine what is best to achieve your DEFINED requirement.

---

Well, that's what I do.. Even when not for a control by closed loop servo, it has a use, like the thermopile meter provides the P in the circuit, the I in the slow response of the pile, but the rate of change combined with a differentiator gets the D (which leaves me wondering how interchangeable 'derivative' and 'differentiator' actually are). The result of boosting the D signal and mixing with the main signal is a fast response (it twicthes strongly if you pass a hand fast across the input beam), in a meter that otherwise takes at least 40 seconds to settle. Mine settles in a few milliseconds and does not deviate more than a very few percent when transiting from D signal to main. Which is good because not many laser power meters are rated for better than 5% anyway. With coaxing, I think it might do 2% or better.


Btw, what's the steady state error? I thought the main purpose of I was to integrate, i.e. low pass filter, to remove noise on some defined time scale. Noise isn't steady state, as such.. One characteristic of my meter circuit is that some noise is inherent to the acceleration, but it's a small price to pay as it reduces on a rapidly declining exponential curve after any step change in input. This is an open loop thing though, nothing's being controlled, only observed.