Old news: 2009
2009-12-20, 23:25 CET
Schiesstakt: Developed this device without any Blog entries, it seems... It has been the usual cycle, and quite quickly: First schematic was about correct, breadboarded and developed the firmware, layed out a printed circuit board, etched it and stuffed the components, and had some fun with case integration... Last week, I took the bare board to the shooting range for a beta test (I had not bought the case back then), and it worked quite well - currently, the device is in its plastic box, but the "mode" button and power switch are not yet here, I expect that order to be delivered next week.
2009-08-27, 21:55 CEST
PhotoLightBox: Breadboarded and tested the aforementioned PWM controller, though without the I2C programming interface so far. However, the circuit works in principle - it outputs two square waves and can be fed two values 0..100, which control how much of the (48Hz) square wave will be "on".
2009-08-06, 23:00 CEST
PhotoLightBox: Designed a dual-channel PWM controller for the halogen bulbs, capable of controlling laps up to 50V, 40A per output. This should be quite enough for the lamps I intend to use... Which will be more like 12V, 20W. Next step will be testing that configuration.
2009-07-11, 19:05 CEST
PhotoLightBox: As can be seen from the last update's date, summer has started in town. Therefore, I am much more outside and enjoying nature around Hamburg, or inside some heavy-duty-concrete building, documenting the remains of a WW2 bomb shelter.
However, bound to $HOME by being on-call this weekend, I started work on the portable lighting box today. Having bought some plywood last thursday, I started sawing the inner walls of the box, and mounted one. Furthermore, the top sheet was sawn, and some holes made - while which I decided that the box will be microcontroller driven, because I made room for a LC display now. This will have the advantage of storing some light settings, and recalling them if similar situations arise later - I think this might come handy...
However, before continuing, I need at least one (of two currently planned) batteries (12V 7Ah lead-gel-cell), hinges, and a handful of switches and other electronics stuff. So, chances are high that this will have to wait until after summer vacation...
Oh, of course I can design the controller schematic, and write the firmware - but for that, I finally (after avoiding that already for the AlarmClock project) have to find some digitally attached pulse-width modulation controller for the RGB LEDs and other dimmable stuff... Toggling all (currently 22) outputs that quickly directly eats too many I/O pins on the controller, and probably would be way too CPU intensive.
2009-04-29, 23:15 CEST
FreeBSD_on_ThinkPad_W500: Documented some findings on "unusual" hardware.
2009-03-27, 00:05 CET
GpsLogger: Started working on the schematic design.
2009-03-26, 01:10 CET
GpsLogger: The EM-408 GPS module, ordered from the same supplier, received and tested today, gives data with five meters accuracy when tested in front of our house in the street - surrounded by "urban canyons", using the built-in patch antenna (it also has a connector for an external antenna). So this one is the way to go...
2009-03-19, 23:45 CET
GpsLogger: The GPS module has arrived. I hooked it up to 3.3V power supply and a UM232R serial-to-USB module and went outside with my laptop... The good part: the module sends several NMEA datagrams, just as it should. However, in five minutes it did not acquire a lock on satellites, which means I got no coordinates out of the thing. Furthermore, I tried to configure the update rate of the datagrams sent by the module (you are supposed to configure it through the serial interface, too), and got no response from the module at all - neither did it react to my biddings, nor did it issue any error message. Seems to need more investigation - Sparkfun says they do test every unit for satellite locking before shipping them, so I currently assume that the device should work.
http://forum.sparkfun.com/viewtopic.php?t=13580 sounds not too good regarding this module, though.
2009-03-10, 11:00 CET
GpsLogger: Ordered a GPS receiver module based on the Micro Modular Technologies MN5010HS SiRFstarIII 20-channel receiver. Current consumption is documented to be <37mA at 3.25-5.5V, with a power-saving mode at 25uA. Together with power-managing electronics, that might be a usable part for this project. Cost was 69 EUR plus shipping.
2009-03-02, 21:50 CET
PcbProduction: Took a photo of the SMD microcontroller adapter.
|
|
2009-03-01, 16:30 CET
I2cDebugger: Decided against tin coating the board and assembled it with only some protective coating, made mostly of colophonium: I2cDebugger/ID-B01
2009-03-01, 01:00 CET
PcbProduction: Produced three experimental adapter boards for the AT90USB162 controller, which comes in a TQFP32 package. This worked quite well using my new board production workflow. One of the boards is soldered now, with 2x16 pinhead connectors and the controller soldered on top.
I2cDebugger: The ID-B01.02 is drilled now, but I am still wondering whether to use it as plain copper board or with tin coating.
2009-02-26, 11:30 CET
I2cDebugger: Etched a ID-B01.02 PCB, as the hardware design seems final now. Next step will be drilling and coating, then soldering.
2009-02-15, 00:05 CET
I2cDebugger: Changed the firmware from polling to using the USI interface and its interrupts -- and it looks like all the packets on the bus are actually captured now. For example, one AlarmClock RTC query now looks like this (in the user interface interpreting the data on a PC):
[START] [To: 0xd0, write][ACK] [0x00 ( 0)][ACK] [START] [To: 0xd0, read][ACK] [0x22 ( 34)][ACK] [0x33 ( 51)][ACK] [0x23 ( 35)][ACK] [0x06 ( 6)][ACK] [0x14 ( 20)][ACK] [0x02 ( 2)][ACK] [0x09 ( 9)][ACK] [0x10 ( 16)][ACK] [0x42 ( 66)][NACK] [STOP]
I consider this quite readable already. Now that the hardware and low-level functions seem to work, some effort should go into the user interface...
2009-02-05, 22:15 CET
I2cDebugger: Further simplification of the MC-to-host protocol, now sending CRLF only after STOP condition has been detected. I get always the same message when sniffing my AlarmClock's I2C bus, but I still do not see the correct and full datagrams being transmitted... A current "sniff" looks like this (please see the project page for information on the protocol):
S:<0x80>RAD<0x00>AS:<0x80>WAD(AD<0x00>N. S:<0x80>RAD<0x00>AS:<0x80>WAD<0xc0>AD<0x00>N. S:<0x80>RAD<0x00>AS:<0x80>WAD<0x80>AD<0x00>N. S:<0x80>RAD<0x00>AS:<0x80>WAD^XAD<0x00>N. S:<0x80>RAD<0x00>AS:<0x80>WAD<0xa8>AD<0x00>N. S:<0x80>RAD<0x00>AS:<0x80>WAD@AD<0x00>N. S:<0x80>RAD<0x00>AS:<0x80>WAAD<0x00>N. S:<0x80>RAD<0x00>AS:<0x80>WAD<0x98>AD<0x00>N. S:<0x80>RAD<0x00>AS:<0x80>WAD0AD<0x00>N. S:<0x80>RAD<0x00>AS:<0x80>WAD<0xc0>AD<0x00>N. S:<0x80>RAD<0x00>AS:<0x80>WAD<0x88>AD<0x00>N. S:<0x80>RAD<0x00>AS:<0x80>WAD^XAD<0x00>N. S:<0x80>RAD<0x00>AS:<0x80>WAD<0xb0>AD<0x00>N.
The "<0x..>" numbers are unprintable characters (this is the raw output from the USB, gathered with tip |& tee). The actual I2C address of the RTC chip is 0xD0. Currently, only 8-bit addresses are supported (the address is transmitted in one byte for now, which differs from the protocol description). The trace was taken around 2104-2106 CET (which is what is transmitted here).
2009-02-01, 17:00 CET
I2cDebugger: Testing around with firmware to sniff on the I2C bus, but there are issues with data sampling as it seems.
2009-01-23, 21:00 CET
PileOfThings: Soldered the 74X14 SMD IC to a piece of stripeboard with the stripes cut along their middle to get the 0.127" spacing of the IC package, and attached wires to the board for more physical stability when playing with it. This was also the first SMD soldering I have ever done (with hot air, actually, so it was not that hard after all the stripe pieces were tinned). There are photos.
2009-01-20, 17:00 CET
AnalogSynth: Ordered four analog joysticks some time ago - they have arrived at home today (though I have not yet been there to unpack them). So perhaps, this project will be worked on soon...
2009-01-18, 22:40 CET
I2cDebugger: Built the first circuit on breadboard, still a very basic one. This shall be used for first experiments with timing and sampling rates for the I2C bus measurements.
2009-01-12, 23:30 CET
EosRemote: Built a 3.5mm plug into the EOS 10D remote control. It still works, and now I can build timers, sound release circuits, and whatnot.
2009-01-10, 00:50 CET
I2cDebugger: Started designing a schematic, and created the firmware source code repository (with some source, of course).
2009-01-01, 22:30 CET
PileOfThings: Browsed through my hardware storage and found a 7414 hex Schmitt-trigger inverter (of some logic class I don't remember now and am too lazy to walk over for looking it up) on an old notebook mainboard -- just the device I was missing for quite some time, because I wanted to fool around with it, making an audio frequency oscillator of it... Just for this one toy thing, I did not want to place an order, so I postponed the idea for when I find one, and today, I found it. Worked well, with 4.7M as "feedback resistor" and a 4.7u capacitor output-to-ground. Had 2V DC offset on 1.5Vpp signal, so I attached a small speaker through 100nF, and it beeped happily. After this proof of concept, I set the thing aside for now, happy to have finally done this.
Older entries
Last year's news are in ProjectsBlog/ProjectsBlog2008.
THIS DATA IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DATA, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
All product and brand names mentioned on there pages and in the source code are registered names and/or trademarks of the respective owner and are mentioned for identification purposes only.
For a full copyright notice, please see this link. For imprint and contact information, please see http://www.thiemo.net/.