Kevin Vermeer

Member Since: January 5, 2010

Country: United States

  • You want an enclosure with a clear cover, that is waterproof, and that has 3mm thick sidewalls? That's going to cost you a lot more than $7.95!

    Hoobert's cutting, clear plastic, and hot glue suggestion will work in a pinch (no guarantees on the durability of the hot glue under UV exposure, though...). If you want a more professional solution, Hammond's 1544 series has a clear cover but no flanges. It does have externally accessible mounting holes, though. Everest appears to have similar products.

  • I highly recommend Debugging by David Agans as a source of troubleshooting wisdom (not knowledge). It doesn't focus on, say, how to design a PCB to be debuggable or how to architect a piece of software to be easy to fix, but those are rather application-specific.

    If, however, Sparkfun or anybody else published some tutorials, blog posts, or whitepapers about designing for testability, I'd probably read them!

  • Whoa! Geocities? That takes me back a ways...

  • Why? This thing is huge, and would be super easy to solder. If you want to put it into a piece of protoboard, cut off the plastic mounting pegs and glue it down.

  • You wrote since almost every sensor or driver is available in an I2c version, the only reason to design and solder a dedicated board is due largely to the lack of sufficient adoption of an I2c phy spec. I understand your idea, but I think your reasoning is insufficient. There are physical reasons why i2c cannot be used (too fast, simultaneous access needs, power requirements), historical reasons (UARTs, for example, are the old standard for some areas), and mental reasons (more familiar with another protocol, NIH syndrome, etc.). Every protocol has its merits and demerits. However, no protocol has all the merits and none of the demerits.

    I see you're a fan of i2c/SMBus/TWI. That's a great protocol, with the following advantages:

    • It supports chaining of many devices without needing extra wires for each device
    • It's moderately fast (quicker than a UART, for sure), with 100 kHz, 400 kHz, and up to 5 MHz speeds
    • It's simple and cheap to implement in silicon for small microcontrollers and sensors

    However, it has a few disadvantages.

    • Requires more wires than some alternatives (LIN and One-Wire)
    • Not as low-power as some alternatives
    • Not as EMI resistant (both generating and receiving) as some alternatives
    • Not as fast as some alternatives (USB, Ethernet, PCIe, SPI, parallel)
    • Not as simple as some alternatives

    You can argue that it's the best compromise for your purposes, but it's unlikely that as long as engineers are choosing the best spec for their individual purpose (which will save money when produced in large quantities) that this will ever see the mass adoption of USB.

  • Yes, this is true. Check TI's official wiki, which says under the development software heading:

    Although there are many other compiler and integrated development environments for MSP430 including the Rowley Crossworks, MSPGCC and MSPGCC4, the two main options supporting the eZ430-Chronos are IAR Embedded Workbench KickStart and Code Composer Studio. Both IAR and CCS have free code-limited versions supporting the Chronos. The projects for Chronos are delivered in both full source and pre-compiled library options to avoid any code size restrictions.

    It's nice that they provided 'pre-compiled library options' for users of the free versions, but it's really rather pointless for hacking on because it means you can't modify the core. Further, 'the two main options' actually means there's no support in the code for other compilers. One other issue not mentioned there is the use of a proprietary BlueRobin binary blob in the firmware, which takes up a lot of space and isn't open.

    There is, however, mspgcc, which is not code size limited. Note: this isn't mspgcc4, that page says 'mspgcc4 is no longer supported. All contributions have been incorporated into mspgcc, which has newer versions of all components'.

    mspgcc can be used to build the Openchronos-ng and Openchronos projects, which are much better IMO. Based on a comparison of the project commits-per-month stats at Ohloh (Openchronos stats, Openchronos-ng stats), I'd recommend using the Openchronos-ng project going forward. It's under active development, and once you get the development environment set up it's very easy to add your own apps, called 'modules', to the watch.

    It's not as easy to use or as open as an Arduino or Beagleboard. If I were in your shoes, I'd add a link to openchronos-ng, mspgcc, and a tutorial on setting that up. I'd avoid adding links to the code-limited compilers and default projects; that just leads to would-be hackers buying this watch and running the stock firmware because they can't change it.

  • Which is the most convoluted definition of '30m waterproof' possible. But that's standard for watches and other devices.

    I can say that I've had this watch for about a year now and have worn it swimming, running in the rain, and in the shower dozens of times without damage. Occasionally, I'll notice that I'm getting condensation within the watch, so I take it apart, let it dry, and re-seat the O-ring behind the metal back plate with a bit of dielectric grease.

    Watch water proofness codes are, as the Wikipedia article says, not intended to actually mean they're waterproof to a given depth:

    An indication of the test pressure in terms of water depth does not mean a water resistant watch was designed for repeated long-term use in such water depths. For example, a watch marked 30 metres water resistant cannot be expected to withstand activity for longer time periods in a swimming pool, let alone continue to function at 30 meters under water. This is because the test is conducted only once using static pressure on a sample of newly-manufactured watches.

    but it seems that everything you get nowadays is 30m. I buy cheap Timex Ironman watches (and this one, for doing neat stuff like running openchronos-ng apps) and use them in the water. Haven't lost any to water intrusion yet, but I wouldn't be in danger (ie, no scuba diving) or in financial trouble if I did.

  • This device is very sensitive to parasitic capacitance. To fully utilize its capabilities, you'd place it and the capacitance to be sensed on the same PCB.

    Plugging this into a breadboard and connecting it to a capacitance source with some hookup wires would be pointless; you'd end up measuring the capacitance of the breadboard and wires.

  • What incoherent data are you getting? You should see values that change when you twist the part about the axes indicated on the silkscreen.

    This is an analog part, so you can probably get some useful information about what you should be seeing simply by hooking it up to an oscilloscope and waving it around a bit.

    In the absence of an oscilloscope, print the value of the ADC reading over the serial connection at, say, 10 Hz, and wave it around.

    I find that actually watching the output with this sort of instant feedback gives me a much quicker familiarity with the device than an hour of reading the datasheet, appnotes, and schematic. Of course, reading is required later, but to get a quick understanding of whether or not it's working there's nothing like immediate feedback.

  • There were a bunch of comments that addressed this, an SE employee confirmed that the wrong capacitors were soldered in and the kit ships with stubby caps.

    Unfortunately, those comments seem to have been deleted.