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 #182792

Member Since: December 26, 2010

Country: United States

  • I believe I have solved this. The earlierst firmware revision I have for this device was dated in 2010 [using the breakout module from Sparkfun], and it did NOT exhibit this behavior. I added extra filter capacitors onto the board containing the module, similar to 10uF up/downstream capacitors on the Sparkfun module, and there was no change in behavior [so it's not filtering]. As it turns out, it is caused by the command mode processing and appears to be an RN-42 FIRMWARE BUG. To make the problem go away, disable command mode via "ST,0" and you should be able to transfer data without disconnects. It works for me. I would guess that you might have allowed 'command mode' filtering to time out when you did your filter capacitor testing, and that's why it 'worked' with the capacitor.

  • This board worked really well for prototyping with an ATxmega64D4

  • Yes, other xmega chips would be both useful and desirable. As an example, I used a 44 TQFP breakout with an ATxmega64D4 to prototype a design that replaces an ATmega328 with the xmega [the 44-pin TQFP breakout was both awesome and inexpensive, but I had to order the CPUs separately from someone else]. A minor tweek to that might have the ATxmega64D4 (or similar) pre-soldered onto the board to make this easier and more convenient. Even better, pre-wire up the Vcc and GND connections with bypass caps so I don't have to use 'blue wires of salvation' to wire them up, and then have to solder on the capacitors by hand. OK I guess that makes it a 'different board' but still... it's a want.

  • getMotion9 has bugs in it (I commented earlier). One of the things it's doing wrong is every! single! call! enables! the! alternate! I2C! communication!. If you do this ONCE during your initialization, you shouldn't have to do it again. (set bit 1 in that one control register, basically). It also sets the REST of the bits to zero, which is a bit ignorant of anything ELSE you might have configured. THEN, of course, it enables the magnetometer readings. I'm not convinced that THIS step needs to be done every! single! time! either. So you might experiment with this, write your own overloaded getMotion9 call (I did, change 'private' to 'protected' in the class def first, another complaint I made already). And don't forget to fix the byte-swap on the magnetic data (it's LOW endian, not high endian - see the register docs - everything else is high endian, though).

  • the 9150 is somewhat difficult to solder by hand though an automated process would simplify this a bit. Small quantity assembly could be a bit expensive. And if demand is high (but not TOO high) with the price 'as-is' you leave the price where it is. Business 101.

  • After I downloaded the 'example code' for this device, I noticed that the compass information was a bit strange. It turns out it is LOW ENDIAN, and not HIGH ENDIAN. So 'getMotion9' returns wrong information. OK you get what you pay for (free open source lib has bugs). Additionally, the code needs a serious review and re-factor. Hasn't anyone heard of "struct"? Using individual byte array indices is primitive and hard to read. And passing 9 integer pointers uses up a LOT of code on an Arduino. Try passing a structure pointer instead. You'll still need room for an SD library if you want to log data, after all, and the structure can be an integral part of the data you log. And using byte indices also obfuscates the fact that the magnetic values were incorrectly byte-swapped. And use 'protected', not 'private', so that people can easily derive a custom class without editing the library first ['private' should have NEVER been invented for C++]. OTHER THAN THIS, I'm happy with the 9150 (I'm doing some contract work related to that chip). It solves a lot of problems. And, of course, the breakout board lets you experiment with it. 'SO WHAT' if you need to write a program to integrate the information. At least you can collect the data without compensating for chip positions on the board. One thing worthy of note, is that it appears that the only way to get the motion interrupt to work is to EXACTLY follow the flowchart example in the data sheet. Otherwise you seem to get 'data ready' interrupts all the time. If you want to wake something up if it's moved, you'll need to use the low power accelerometer only mode with periodic wakeups, and tolerate one or two 'false hits' at the beginning of your sleep state. Then it works JUST fine. So thanks, Sparkfun, for making this available.

  • I connected mine the way "Member #254181" described it above, and no problems except that the current draw required me to put a heat sink on the 5V regulator for the 'Arduino clone' board I was using with a breadboard, as it was feeding a 3.3v regulator that supplied the Wiznet (I built a simple plug-in adaptor board to make this work with the 3.3v regulator and breadboard-friendly pins). It seems that the current draw (according to the Wiznet spec sheet) can be 150ma or so while connected to ethernet. I thought I'd mention that ahead of time. I don't see that as a problem, but it did make the regulator heat up without a heat sink, enough to get my attention when my finger touched it while unplugging DC power from the clone board.

No public wish lists :(