Data logger project

[CountFunkula]

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

[dnar]

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.



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.

[The_Doctor]

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.

[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...

[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..

[dnar]

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?

[The_Doctor]

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.

[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?

[dnar]

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.

[dnar]

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.



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).



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.



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.



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.