Re: 96boards Nitrogen
Steve Brown
More
On Thu, 2017-09-14 at 19:54 +0000, Chettimada, Vinayak Kariappa wrote:
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 (0a12:0001) dongle.
So, I tried your iOS nRF connect app. It picks up the advertisements. I
can also connect from my iPhone.
All 3 applications function with the nano2.
Next I tested with a rpi3. It sees the advertisements and can also
connect to the nitrogen. Curiously, ubertooth picks up the SCAN_REQ
from the rpi3, but not the responses from the nitrogen. All the devices
are within 1 meter of each other.
So, I have 2 apps (nRF connect & rpi3) that see what the nitrogen puts
on the air and 2 apps (ubertooth & x64 w/ bluez & CSR dongle) that do
not.
Versions
ubertooth:
Firmware version: 2017-03-R2 (API:1.02)
ubertooth 2017-03-R2 (dominicgs@hydrogen) Mon Mar 13 16:09:02 MDT
2017
x64 w/ bluez: V5.47
nRF Connect: V1.7.5
rpi3: raspbian Linux raspberrypi 4.9.43-v7+ w/ bluez V5.43
Can you think of any possible explanation?
Steve
On Thu, 2017-09-14 at 19:54 +0000, Chettimada, Vinayak Kariappa wrote:
These tests were run using tests/bluetooth/shell.Ok, so the CPU and UART works :-)
Hello and blinky work. BT does not.
And, the 32KHz clock domain works, hence the blinks.
Now, CPU can run from internal High Frequency RC or External crystal.
If your 32MHz crystal on the board has dry solder (or what ever has
happened), then most probably internal RC remains to clock the SoC.
But 2.4GHz radio will not be 2.4GHz.
Zephyr v1.9 has Radio Direct Test Mode implementation, hci_uart
sample can be used with DTM HCI commands to test the radio. The DTM
HCI commands will fail to respond if the HF clock cannot source from
a stable crystal.And, yes nitrogen_beacon.hex from http://builds.96boards.org/releasVery unlikely (and likely based on conditions), I use nRF51 dongles
es/n
itrogen/zephyr-1.8/ flashed to the nano2 advertises. There's no
console
output as I explained previously.
I'm now more convinced that the devices somehow got damaged in
transit
from Seeed.
over 5 years now, carry it around in bare hands, worst I have done is
to have my 32KHz crystal go out of its spec. but BLE operational
using the 32KHz RC.
I think Seeed need to contact our support (I am just a software guy).
I'll report when I get the ones I ordered from Digikey. I expect
them
to work just fine.
If you are curious about what happened to the radios, I'd be glad
to
send you the 2 I got from Seeed.
The shipment didn't seem to have been opened. I'm pretty ESD
conscious
at my end.
Steve
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 (0a12:0001) dongle.
So, I tried your iOS nRF connect app. It picks up the advertisements. I
can also connect from my iPhone.
All 3 applications function with the nano2.
Next I tested with a rpi3. It sees the advertisements and can also
connect to the nitrogen. Curiously, ubertooth picks up the SCAN_REQ
from the rpi3, but not the responses from the nitrogen. All the devices
are within 1 meter of each other.
So, I have 2 apps (nRF connect & rpi3) that see what the nitrogen puts
on the air and 2 apps (ubertooth & x64 w/ bluez & CSR dongle) that do
not.
Versions
ubertooth:
Firmware version: 2017-03-R2 (API:1.02)
ubertooth 2017-03-R2 (dominicgs@hydrogen) Mon Mar 13 16:09:02 MDT
2017
x64 w/ bluez: V5.47
nRF Connect: V1.7.5
rpi3: raspbian Linux raspberrypi 4.9.43-v7+ w/ bluez V5.43
Can you think of any possible explanation?
Steve