Artemis Example8_BLE_LED does not respond to sent alerts

Development Boards Artemis
1

Hello,

I’m using Readboard Artemis, the built-in example Example8_BLE_LED, and the nRF connect app on my iPhone. I’ve uploaded the example and connected to the Artemis from my phone.

According to the documentation, sending 1 or 2 should turn on the LED; sending 0 would turn it off. However, when I send 1 or 2 nothing happens.

When I connect from my phone, the serial monitor shows debug messages, so that part seems active. However when I send an alert, no additional debug messages appear.

I added a debug_printf() at the top of tagAlert() (outside of the #ifdef DEBUG just to make sure), and my debug message never appears, so it’s as if tagAlert() is not being called. tagAlert() seems to be called by tagIasWriteCback(), which also doesn’t appear to be called. tagIasWriteCback() is registered in NusStart() which DOES appear to be called at startup. That’s about as far as my understanding goes.

What am I doing wrong?

Here are the messages I get upon startup, connecting, and writing the alert level:

Apollo3 Arduino BLE Example. Compiled: 12:26:48
fm: NusHandlerInit, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1047
fm: NusStart, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1131
fm: tagAttCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 385
fm: NusHandler, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1091
fm: tagProcMsg, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 913
pMsg->hdr.event: 0x0052
fm: tagDmCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 351
fm: NusHandler, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1091
fm: tagProcMsg, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 913
pMsg->hdr.event: 0x0020
fm: tagDmCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 351
fm: tagSetup, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 556
fm: tagDmCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 351
fm: NusHandler, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1091
fm: tagProcMsg, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 913
pMsg->hdr.event: 0x0021
fm: tagDmCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 351
fm: NusHandler, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1091
fm: tagProcMsg, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 913
pMsg->hdr.event: 0x0022
fm: tagDmCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 351
fm: NusHandler, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1091
fm: tagProcMsg, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 913
pMsg->hdr.event: 0x0021
fm: tagDmCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 351
fm: NusHandler, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1091
fm: tagDiscCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 818
fm: tagDiscCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 818
fm: tagProcMsg, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 913
pMsg->hdr.event: 0x0027
fm: tagOpen, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 467
fm: tagAttCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 385
fm: NusHandler, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1091
fm: tagDiscCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 818
fm: tagProcMsg, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 913
pMsg->hdr.event: 0x0003
fm: tagDmCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 351
fm: NusHandler, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1091
fm: tagProcMsg, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 913
pMsg->hdr.event: 0x0040
fm: tagAttCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 385
fm: NusHandler, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1091
fm: tagProcMsg, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 913
pMsg->hdr.event: 0x0011
fm: tagCccCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 412
fm: NusHandler, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1091
fm: tagProcMsg, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 913
pMsg->hdr.event: 0x0010
fm: tagDmCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 351
fm: NusHandler, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1091
fm: tagProcMsg, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 913
pMsg->hdr.event: 0x0051
fm: tagDmCback, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 351
fm: NusHandler, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 1091
fm: tagProcMsg, file: /tmp/arduino_build_772799/sketch/nus_main.c, line: 913
pMsg->hdr.event: 0x0029
2

I am having the same problem!

I’ve noted a few things that are (probably) relevant to our problem:

I’m using nRF Connect version 2.3.2, build 59 (which is apparantly “current”). (I’m also using an iPhone.)

The documentation at the front of the example says it’s using “Immediate Alert” (which is UUID 1802). However, the nRF Connect is NOT allowing read or write access to this service. It is, however, allowing read and write access to “Alert Level” (UUID 2A06) – but this is NOT THE SAME as “Immediate Alert”.

As an aside, I would really like to see the setup() messages to the Serial Monitor include the Artemis’s MAC address. (My ultimate goal is to have the Artemis talk to a Raspberry Pi 4B using MQTT-SN over BLE via a UART service.)

3

Hi

The bad news: Example8 BLE_LED was sort of a band-aid in the core. It was meant to provide a starting point for adventurous people who wanted to use BLE before it was truly supported in the Arduino core. Its origins are from within the AmbiqSuiteSDK, but beyond that I am not even terribly familiar with it. Therefore I can’t offer any useful assistance.

The good news: we are releasing the v2.0.0 version of the Arduino core soon (Aug 27th) which fully supports the ArduinoBLE library. This should make it far easier to develop BLE applications with the Artemis / Apollo3 - keep your eyes out!

4

Before I saw the above message from liquid.soulder I decided to take a look at the github repository just now to make sure I had the “latest and greatest” version. When I looked at https://github.com/sparkfun/Arduino_Apo … s/examples I noticed that Example8_BLE_LED was “conspicuous by its absence”, however, there is a new (20 days ago) Example9_ResetsAndWatchdog (which I have not looked at). When I looked at the history, I didn’t see anything indicating remove of Example8_BLE_LED, though.

I’m sort of wondering if there has been a change to nRF Connect since the example was first written… unfortunately I haven’t been able to figure out how to get “older versions” out of the Apple App store. :frowning:

Side comment: The Example8_BLE_LED shows why the Arduino IDE developers’ stubborn [several explitives deleted] refusal to give “expert” users more control is so frustrating. There are many places where there are “#ifdef DEBUG” statements – rather than “hardwiring” it with a “#define DEBUG” this is a case where the advanced end user SHOULD be allowed to add a “-DDEBUG” compiler agrument if desired. Grrr… I may be switching to using the arduino-cli for some purposes as it at least (apparently) has a “work-around” that will allow this.

5

Example8_BLE_LED only exists on the “core-ble” branch, because it was never accepted as “the way we wanted to support ble” - every release since then has been a “pre-release” based on that branch (that branch would be merged with master to make sure updates came through)

I can’t agree with you more about Arduino’s opinions on what users should and should not be doing. Have you tried using the AmbiqSuiteSDK directly? We provide our board definitions and some additional examples

https://github.com/sparkfun/AmbiqSuiteSDK

https://github.com/sparkfun/SparkFun_Ap … Suite_BSPs

6

Thanks for the suggestion – I’ll look at the AmbiqSuiteSDK a bit more, though where I really run into Arduino’s refusal to support the commandline -D option is for a project involving multiple ESP8266 units. Each unit has a few things that are unique to that unit (e.g., name, fixed IP address, particular sensors attached), but the vast majority of code is the same. It’s a real pain even having to do a one-line edit on the source code between them (e.g., “#define UNIT_03”) – for one thing, it changes the timestamp on the source code file.

Another gripe about the Arduino IDE is its total lack of any “single step” mode – I’ll agree that it can be a REAL PAIN to implement for something like an ATmega328, though it is do-able – along with “watch” of variables. This feature on practically every other IDE I’ve used or been abused by since about 1980 is a HUGE “teaching feature” for the raw beginner to understand what’s actually going on in the program (and FAR easier to use, not to mention far less error prone, than the “whiteboard simulation” methods we used in college in the mid-1970s to understand what’s going on).

7

When using the SDK you will be using good 'ol makefiles so you should be pretty comfortable supplying your own command line -D flags. For single step debugging I recommend using Visual Studio Code with the Cortex Debug extension and a SEGGER J-Link debugger. Works great.

8

"The good news: we are releasing the v2.0.0 version of the Arduino core soon (Aug 27th) which fully supports the ArduinoBLE library. This should make it far easier to develop BLE applications with the Artemis / Apollo3 - keep your eyes out!

any news on the Arduino core ? I have been watching https://github.com/sparkfun/Arduino_Apollo3