Just finished building a quick GE G-35 light project for a friend of mine. The project used 2 sets of GE lights driven by an Arduino with Sparkfun's Spectrum Shield. If you have all the materials on hand when starting I think even a beginner should be able to complete the build in under 4 hours, most of which time will be spent splicing cables.
The Arduino sketch is a continuation of the GE G-35 code built last year by Darco, Scott Harris and others in the DIY Christmas forums along with MSGEQ7 code. There are 16 different effect “programs” in the sketch, the current effect to play is handled by the eqmode variable the value of which is changed by button presses. It’s fairly straightforward, the main loop performs basic operations on each pass and hands off to functions where necessary.
FYI - I was looking up how to monitor batteries in series and happened to link to a spec sheet from Linear Technology for an IC called the LTC6802-2 - Multicell Addressable Battery Stack Monitor...
The LTC6802-2 is a complete battery monitoring IC that includes a 12-bit ADC, a precision voltage reference, a high voltage input multiplexer and a serial interface. Each LTC6802-2 can measure 12 series connected battery cells, with a total input voltage up to 60V. The voltage on all 12 input channels can be measured within 13ms.
Many LTC6802-2 devices can be stacked to measure the voltage of each cell in a long battery string. Each LTC6802-2 has an individually addressable serial interface, allowing up to 16 LTC6802-2 devices to interface to one control processor and operate simultaneously.
The related LTC6802-1 offers a serial interface that allows the serial ports of multiple LTC6802-1 devices to be daisy chained without opto-couplers or isolators
Wonder how to handle 2 or more new nodes on the network? Ie. two zeros, would they collide? Maybe one will answer first etc... I think I would still prefer to use a 1-wire thermometer and "steal" the unique ID number for use as an ID on the serial bus.
On the isolation issue I have a newb question. I know the issues surrounding surrounding AC/DC isolation, but what is the risk that needs to be avoided in this DC/DC situation? It's 12VDC on the battery and 5VDC on the 1-Wire bus, but using the voltage divider the 12V could be reduced to <5V (not sure how the current is affected). Is the risk the potential current in the (huge) batteries jumping across to the bus to another battery or the console etc..
Tilt switches are usually very sensitive to the ball jiggling around inside the can. In that respect it's a little different from a pushbutton. Imagine when the object with the tilt switch attached is in motion it's the same as someone continuously hitting a pushbutton switch.
Try turning it upside down (end without wires facing down) and fix it to something so you aren't touching it. While it is in this position the circuit should be open and you should get a LOW reading from the Arduino. Now stand it right side up (end without wires facing up) and fix it so you aren’t touching it. Now the circuit should be closed and you should get a HIGH reading. Both of these should be steady either HIGH/LOW. Now experiment by moving it around and the flicker will return.
To get rid of the flickering you need to increase the delay to smooth over the "button pushes" the ball is making while it is moving around in the can. So, just try adding more delay!
I was thinking the chip + voltage divider would essentially be all you need for each monitor. It would take care of measuring the voltage, temperature, provide a unique ID and provide a mechanism for communication over a long distance to the master/"console", which would be an Arduino/PC etc...
Forgive me as I am still learning a lot of this stuff, but I would think the 1-Wire bus should be isolated somehow from the rest of the circuit since the purpose of the chip is to monitor batteries. Before I posted the last message I did look at the datasheet to see if the measurement side was isolated from the 1-Wire bus, but I couldn't see anything that indicated it was.
CrossRoads, After looking at the schematic you posted earlier to see what (IC) you were planning to use to measure the voltage. I see it's a voltage divider being measured by the ADC on the ATTiny. Then the thought dawned on me - why not just use a voltage divider to cut the 12V+ from the battery to <10V and send it into the input of the DS2438 Smart Battery Monitor I mentioned earlier in the thread? The DS2438 has all the "support" built into it to do everything else I think the OP would need to create a network of monitors...
The DS2438 Smart Battery Monitor provides several functions that are desirable to carry in a battery pack: a means of tagging a battery pack with a unique serial number, a direct-to-digital temperature sensor which eliminates the need for thermistors in the battery pack, an A/D converter which measures the battery voltage and current, an integrated current accumulator which keeps a running total of all current going into and out of the battery, an elapsed time meter, and 40 bytes of nonvolatile EEPROM memory for storage of important parameters such as battery chemistry, battery capacity, charging methodology and assembly date. Information is sent to/from the DS2438 over a 1-Wire interface, so that only one wire (and ground) needs to be connected from a central microprocessor to a DS2438. This means that battery packs need only have three output connectors: battery power, ground, and the 1-Wire interface.
The DS2438 can either be powered by the battery itself or the 1-wire bus (parasite power), so even if the battery voltage were to fall below the level to operate the monitor (+2.4V) it would still be up and running.
I haven't used the DS2438 to monitor a battery, but I have used it just as a general purpose ADC that is able to communicate on the 1-Wire network, which is another use for it. In this case the extra ADC could maybe even be used to read a potentiometer or resistor/dipswitch combo setup as a position indicator.
Do you think there is any reason why the voltage divider wouldn't work for the input?
The 1-Wire protocol takes care of enumerating devices on the bus, then you can address the devices individually. On the mapping I'm thinking if the destination is PC/Server then the software could handle it. For a stand alone system then maybe storing the IDs in the Arduino EEPROM memory (not sure of the space) or adding an off board (I2C) EEPROM... Your would of course need some interface to do the mapping LCD etc...
But before that I was working a wireless solution, that just proved too difficult from scratch. Since then the Weather Station Data Logger group created the Weather shield that simplifies connecting Oregon Scientific wireless sensors to their open source weather software. Check it out at:
Dont know if it helps, the error occurs ~ every 3-4 days. Anny comments on improved robusteness by adding delays?
Shouldn't - I believe the DallasTemperature library already adds a 750ms delay on the request.
I too am wondering how long your runs are and the topology you are using to connect them ie. Star, Linear, Stubbed. FYI - My network currently consists of about 200 feet of cable split between 5 nodes on a star topology and has been working fine for months.
Also, the 5V supply for each sensor has me puzzled, you typically would just send the 5V down the line connectecting the sensors to the Arduino.
FYI - Just found this serial# only option < $1 in quantity according to Maxim.
DS2411 - TSOC, SOT23-3, and Flip-Chip Surface-Mount Packages
The DS2411 silicon serial number is a low-cost, electronic registration number with external power supply. It provides an absolutely unique identity that can be determined with a minimal electronic interface (typically, a single port pin of a microcontroller). The DS2411's registration number is a factory-lasered, 64-bit ROM that includes a unique 48-bit serial number, an 8-bit CRC, and an 8-bit family code (01h).
Would you really need or want the units to be self-enumerating though? It would suggest you'd always be counting down "from the top" to reach battery #20.. and things get confusing when you're taking batteries in and out of service.
If you hard-program each monitor to a certain ID then inventory control would be a lot easier. You're going to want the historical data for each physical battery and having its ID changing even once in its lifetime would just make things confusing.
I think they are just two different viewpoints - manage the monitors by device with an ID on each unit or manage them from the "console" by updating the enumeration code. I'm not opposed to the ID idea, I just think managing the programming of the unique ID into the code running on each monitor would get ugly/old fast.
A thought! - If you used a Dallas 1 wire temperature sensor for the thermometer you could use the "Unique ID Factory-Lasered in Each Device" as the monitor's ID, that way your code on the monitor could always be the same.
What are the values being returned when you report device disconnected? You should be checking if the value returned = -127 to determine if there was an error. Maybe it's just really cold in your basement lately?
From the commnents in the library (DallasTemperature.cpp):
// returns temperature in degrees C or DEVICE_DISCONNECTED if the // device's scratch pad cannot be read successfully. // the numeric value of DEVICE_DISCONNECTED is defined in // DallasTemperature.h. It is a large negative number outside the // operating range of the device float DallasTemperature::getTempC(uint8_t* deviceAddress)
The definition of DEVICE_DISCONNECTED in DallasTemperature.h:
I wonder if you could hack it to bypass the button and constantly scan? Thinking something along the lines a fixed scanner that can scan objects with barcodes as they pass by? Not sure if this is possible with that type of scanner...