Has anyone had success with samples/bluetooth/beacon on this device? Even the nitrogen_beacon.hex file from 96boards.org won't transmit. The console messages are as expected, but nothing on the air. S

Richardo, The boards are: v1.0 build date 09/19/2016 v1.1 build date 02/16/2017 The nitrogen build uses pyOCD to flash the device. This works as expected. However, copying a .bin file to /media/$USER/

Ricardo, Thanks for the info on the CMSIS firmware. I'm not using it, but thought that it might be connected to my radio problem. From your comments, it's not. pyocd-flashtool flashes the device with

Hi Vinayak, Hello and blinky work. BT does not. And, yes nitrogen_beacon.hex from http://builds.96boards.org/releases/n itrogen/zephyr-1.8/ flashed to the nano2 advertises. There's no console output a

Vinayak, I found tests/bluetooth/shell. I also found my wispy toy spec analyzer. With "scan on", I receive advertisements. So, the 32Mhz xtal is ok. With "advertise on", I observe rf on 3 freq's. The

More These tests were run using tests/bluetooth/shell. I found and fired up an ubertooth. The 3 advertising freqs are spot on. Whatever is on the air isn't decoded by ubertooth-btle or bluez w/ a CSR

Vinayak, The identity address is persistent across power resets. I'll report on the behavior of the 2 units arriving this week. If they also show compatibility issues, I'll continue to investigate. Th

Hi Vanayak, I've got some more information. I converted the SDK's radio_test to run on both the nano2 and the nitrogen. The nano2 is transmitting continuous carrier (test "c") on 2402 and the nitrogen

Has anybody been able to provision samples/bluetooth/mesh with v1.0.2? I get the following error below on my RedBear Nano2. Steve Kernel stacks: main (real size 512): unused 280 usage 232 / 512 (45 %)

Johan, That was it! I disabled OOB and it's working. The Invalid Tx Enqueue error is gone too. Thanks, Steve

Hi Vikrant, I assume you built the bluez 5.47 from source. The json files live in bluez/mesh. You either have to run meshctl in that directory or point to it with the "-c" option. Once in meshctl, the

It looks like you have some kind of problem on the bluez end. I get the following on the same board. [meshctl]# discover-unprovisioned on set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb Set

Hi Ashish, The board name is nrf52840_pca10056 That works on my boards. Steve

Hi Ashish, If the target of heartbeat publish is 0077 (meshctl's unicast address), it will display the returned status. Steve

Hi Ashish Steve

Hi Vikrant, I looked at this too. Provisioning seems to complete, but the proxy service isn't discovered. Meshctl just seems to hang waiting for the discovery to succeed. While this is happening, if I

#bluetoothmesh #meshctl

Hi Vikrant, I tracked this down to Zephyr and bisected the problem to commit d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6 Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV Steve

#bluetoothmesh #meshctl

Hi Johan, I think the patch exposes a problem with meshctl. Vikrant offers that the SILABS App works fine and also uses GATT for provisioning and configuration. Meshctl provisions fine, but hangs on d

#bluetoothmesh #meshctl

Hi Johan, Some more detail. I added some instrumentation to parse_service_data and parse_mesh_service_data. The data type that gets passed to parse_mesh_service_data in data[0] is 0x00 while the funct

#bluetoothmesh #meshctl

Hi, I had a chance to look at this further. More at the bottom. It doesn't appear that bt_mesh_proxy_identity_enable() gets called in prov.c:proxy_data(). The earlier call to bt_mesh_provision() close

#meshctl #bluetoothmesh