180 rgb led strip, driven by the sap velocity sensor
The context is an art installation for the Laab (http://laab.ovh.org, in french).
As I ran out of free sockets, I had to move some sensors to a DL40 module (thanks to taylorza’s DL40IO firmware), which is the white permaboard to the left. The front one is an homemade sap velocity sensor, design based on the thermocouple sensor but not quite. Everything else is standard gadgeteer modules, save for the ledstrip interface using one MOSI pin for (fake)-SPI driving (search for ws2811 ledstrip in codeshare).
On a technical note, I struggled a LOT with the RTC, because my soldering skills couldn’t achieve the needed replacement of the capacitors (guys, those smt caps are SMALL), so I just did the crystal. And if you don’t replace the capacitors you have to be extra-cautious with everything you will use on socket 5 because of the RTC’s XI32/XO32 pins which are pin 3 and 6 on socket 5. Even if you don’t use those pins, just gadgeteer cables on socket 5 longer than 5cm will block the RTC, for example (I suppose it is due to the added extra capacitance of the wires which are too much for the RTC pins). Also using RTC pretty much seal off socket 5 use because almost all modules use pin 3 or 6.
I’m always interested in sensors like this, so I’d love to know more about the hardware you used and the interfacing you needed to do, for things like anemometer/vane/rain gauge.
Nice project idea. One possible RTC solution would be to use an iButton RTC. The DS1904 is a self contained RTC. Once you set it, you can forget about needing to set it again until DST. It won’t provide an alarm even unfortunately. If you can get your hands on a DS1994, that would be an self contained alarming RTC solution.
I built an analog anemometer + wind vane for the science fair in high school many moons ago. I have a soft spot in my heart for these type of projects. I don’t know what ever became of that project but I’d love to still have it.
anemometer and rain gauge are interrupt based so I counted interrupts over a measured time interval to get wind speed and rainfall. Wind direction is a bunch of resistors in parallel, you measure the voltage and you can map the calculated resistance to an the interval angle of the vane.
I considered having the three sensors on one socket, but as I needed two interrupt pins, and each socket got only one I moved them to DL40 + DL40IO firmware.
@ gus, I will ! code is still in the unpolished side, and at the moment I have t to finalize two more art installations involving gadgeteer stuff this week : one with two DMX led tubes and the other with a bunch of philips hue replacing the original lighting in a musuem
@ ianlee74 -
Do you know if we can chain another i2c gadgeteer module (like the barometer sensor) with the DFRobot RTC module ? If so, this is the solution, I guess.
Someone was working on an I2C hub module that you could use for that purpose. I can’t remember now who it was. Maybe it’ll show up in the new Community Creations page. Otherwise, you could probably do it with some hackery and a custom driver.
So, let’s suppose I want to make DFRobot RTC module and the Seed’s barometer module work on the same I2C socket I. Each one is using pin three as a GPIO so I have to :
connect sda and scl pins of both modules
rewire one of the module’s P3 to another unused pin (6 for example)
modify one of the the module code to :
1/ use this rewired pin on the motherboard socket
2/ add the other module I2C related part to the main module code
Maybe… I think the problem is going to be that pin #3 is the interrupt pin. So, using another pin for the other module may not give the expected result if the driver is using events. You’ll have to investigate in that regard.
@ ianlee74 : you’re right, so I investigated both modules code : none of them is using the interrupt capability of the extra pin. The barometer module is using the extra pin to switch to the local eeprom i2c space to collect calibration data at init time. The DSFRobot extra pin module could use the interrupt capability for alarms but none of the code (and even the arduino sample) is using it (and I don’t need it). I can alltogether forget about pin3 rewiring for the clock module and just connect the barometer module to the mainboard via an extender, and then wire sda/scl to the clock module.
“Fusing” the modules code by adding the i2c config of the second module to the first one should be “straightforward”. Will test this in a few.
There’s no problem in chaining I2C modules, even when using INT, as far as INT wont tell you which module triggered it, but will only tell you that one of you modules did…
There 3 main things to take in account when chaining I2C modules :
Use pull-up resistor on the last chained I2C wires SDA and SCL ( 2x10K to the 3.3V will be ok for your purpose where distance is not to much between modules),
Never use 2 modules which will have the same Address on the bus,
Do not put to much modules as the 3.3V supply will often not ensure sufficient current delivery if many modules are to be chained…
In my lab project, I chained several PCF8575 and one SENSIRION SHT… to deal with I/O and environmental, without problem. The only lake is the SENSIRION is not addressable, so that I can not have multiple SHT on the same bus…
In Codeshare, you’ll find a topic on ‘I2CBus’ that is a very useful implementation to drive I2C in a thread safe manner with multiple modules.
I solved all my RTC problems in the most inexpected way : I asked my wife to do the soldering : replacement of the capacitors c10/c11 + crystal… I knew she was a soldering goddess but I didn’t dare (or was it in pride?) to ask. So she did it in ten minutes top and now it works flawlessy, even with long cables attached to socket 5.