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

Member Since: August 8, 2008

Country: United States


Prof Ted Herman, University of Iowa

  • I wonder does this module have direction-finding capability (see https://www.silabs.com/documents/public/data-sheets/bgm220p-datasheet.pdf). Depends on which version of the BGM220P and possibly on antenna configuration. The datasheet does mention BGM220PC22HNA and that seems to be the model which supports direction-finding.

  • I see that there has been something about connecting this camera to an Arduino - https://github.com/sparkfun/SparkFun_HM01B0_Camera_ArduinoLibrary What setup is used to do that? Is there some kind of adapter hardware?

  • I'm having trouble getting this board to work.

    Context: my app needs the latest version (at least SDK 15.3) from Nordic, which so far the current Adafruit bootloader doesn't support, so far as I know. (I can update later to show the message when trying to program softdevice using the current bootloader on the Sparkfun nRF52840 Mini.)

    More Context: I am old school, being used to programming an nRF52840 with a JLink debugger and the SWD header.

    So I already attached a header to the back of this SparkFun Pro nRF52840 Mini, and JLink was happy to flash both Softdevice and the app (made sure to use the new customized CFLAGS += -DBOARD_SPARKFUN_NRF52840_MINI in the Makefile).

    But, nothing happens and the DFU loader is wiped.

    There are two courses of action I suppose.

    • (1) One would be to flash a new DFU loader, namely an updated version of Adafruit's DFU loader for SDK 3.0 -- do you know if the procedure on Adafruit Github is valid for this? Right now, the Sparkfun board is bricked - but in principle, burning on the right code will restore things.
    • (2) The alternative is just to bypass the bootloader. That doesn't seem to be working. Although the flash appears to work (according to nrfjprog messages), no /dev/ttyACM0 appears and the code doesn't seem to be running.

    What would be recommended?

    Update: Compiling and flashing the usual Blinky, flashed using normal nrfjprog (with no Softdevice) does work - the LED blinks. Also an example using USB serial works. So the toolchain seems sound.

    Second Update. I got the Adafruit bootloader source to compile, but when I specified sparkfun_nrf52840_mini for the board, there were errors such as "at least two buttons required in the BSP" - possibly the unmodified github code is not aware of the two-button trick for this Sparkfun mini? I guess there would be a different branch or some other way to deal with this? Any pointers on what/where that might be?

  • The bootloader doesn't seem to work for the latest softdevice version (which I need for my application). The adafruit conversion of nrfutil may be outdated and the notes on nrfutil suggest that a newer bootloader might be needed for new versions of softdevice (due to size). Is there a procedure to update the bootloader?

  • I'm running into frustration trying to get this board working. I'm not using an Arduino -- just programming a TI CC2530 using C to work with this board. The easy part was hookup and getting I2C working: it's straightforward writing and reading registers, even R/W with multiple registers works fine (able to confirm writes to config parameters reading them back). However, the program gets stuck trying to start ranging -- the board doesn't respond by actually doing the ranging. That is, after writing 0x01 to SYSRANGE_START, repeated reading of RESULT__INTERRUPT_STATUS_GPIO doesn't post the sample ready bit. Naturally, I suspected that something I failed to set up properly was the cause. I tried for some hours variations of adding some busy-waits for microseconds here and there, repeating the writes, and so on, hoping to luck in to a resolution. Here's the fun part: sometimes (nondetermistically, I haven't found a pattern yet) the device does actually complete the range, and it looks like a reasonable number of millimeters. Invariably the single range is stuck at its one-time range thereafter (until poweroff and restart). Had it not been for these rare cases where ranging works, I would suspect some parameter error. As it is, either there is a timing problem, a power problem, or the unit is flaky. Is there some way to make progress on this? Is the only answer that one simply has to use a duino?

No public wish lists :(