Please see all COVID-19 updates here as some shipments may be delayed due to CDC safety and staffing guidelines. If you have an order or shipping question please refer to our Customer Support page. For technical questions please check out our Forums. Thank you for your continued support.


Member Since: August 20, 2013

Country: United States

  • Perfect example of why I hate Qwic. I get that this system makes it easy to get started but, it has a serious drawback - there are only four wires. One of the main reasons for having a real time clock is for alarms which are typically expressed as interrupts which enable the microprocessor to sleep or do other things while the clock counts time. But you can't do this with Qwic because they - for some reason - chose to make it only four wires! BTW, this is true for all manner of devices such as accelerometers, magnetometers, thermometers. It would have added next to nothing to make Qwic a 5 or 6 wire connector. Why reduce the functionality and utility of these sensors?

  • All, There are two different versions of this device - the APA102 2020-256-8 and the APA102 2020-256-6 and this is causing confusion. The footprint on this board has 6 pins but the data sheet linked shows 8 pins. Since the two extra pins are Vcc and GND which are redundant with the 6 pin layout, it may not matter. However, I am a believer in following the datasheet and I created a EAGLE footprint for the 8-pin version that matches the datasheet on this page.

  • I understand and applaud this new set of offerings from Sparkfun. I look forward to seeing what comes next.

    This is a general comment and perhaps a call for some help. I am looking for sensors which can be used in real world - battery powered - uses. The libraries and sketches provided seem to be focused on a minimally viable product approach but they almost never take advantage of one of the key features on these devices - the ability to set and trigger an interrupt. The hardware folks almost always provide access to the interrupt pin on the breakout but the software folks almost always ignore it. Why? Interrupts enable the development of power efficient solutions where the controller can "wake" when the reading changes by more than a certain amount.

    I guess the help part is to understand what would be required to add interrupt capabilities to these libraries? Since so few of the provided libraries have interrupt support, there are very few examples.

    Thanks, Chip

  • Why do you include interrupts on the boards and in the product description but not in the libraries, tutorials or example sketches? Is there an issue with interrupts on Arduino for 3.3V devices using Wire? Is there anyone who has taken advantage of these capabilities on the Arduino?

  • Awesome article and spot on for my current project. I am using one of your sensors to count the number of folks using one of our local parks here in Raleigh. Everything works perfectly in my apartment but, install it in the park where the AT&T signal strength is a little weaker and...failure. I have spent the last month finding the latest way the device could fail to send its data wirelessly - fail to get GSM, fail to get GRPS, fail to get an IP address, fail to connect to Ubidots (my IOT provider).... By definition there is only one way to succeed, but there seems to be endless ways to fail. And yet, there is a great deal of satisfaction each time I find an answer to the latest failure. And I am hopeful that there is a happy ending to this story - someday....

  • Great board but it has some I2C compatibility issues. I downloaded the example code but was surprised to see it did not use the standard Wire library. I was able to rewrite the code to use Wire but learned about an issue this board has with the Wire.endTransmission() function. Unlike other devices, the MMA8452 (and some other I2C devices as well) need a flag to keep the I2C connection alive during a read sequence. The issue is described here: http://arduino.cc/en/Reference/WireEndTransmission When I used Wire.endTransmission(false), it fixed the problems I was having with the standard wire library.

    However, there is still one major limitation if you plan to use this device with an ATTiny device (as I had). The TinyWireM library does not implement the false flag in its TinyWireM.endTransmission() so, until that feature is added, you can't use this board with ATTiny devices - a serious bummer. If anyone has a workaround - please let me know.

No public wish lists :(