96boards Nitrogen


Steve Brown
 

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. Same results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does transmit. There
is no console output because a different uart is used, but the beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked at the
errata and didn't see anything obvious.

I'm waiting for a reply from Seeed as to what they use to test the ble
functionality of the devices before they ship.

As a last resort, I'll try Nordic's SDK and see if I get the same
results.

Thanks,

Steve


eden candelas <e.candelas@...>
 

Hello, I did modified the example to work as iBeacon ( the version on the example is for an eddystone). Basically you have to update the ad[] struct with the byte array required for the iBeacon spec.

Attached to this mail you will find the main.c that I have been using to test that functionality.

Regards.



Edén Candelas
cel. +52-(81)-1729-2117


On Wed, Sep 13, 2017 at 4:37 PM, Steve Brown <sbrown@...> wrote:
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. Same results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does transmit. There
is no console output because a different uart is used, but the beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked at the
errata and didn't see anything obvious.

I'm waiting for a reply from Seeed as to what they use to test the ble
functionality of the devices before they ship.

As a last resort, I'll try Nordic's SDK and see if I get the same
results.

Thanks,

Steve

_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Ricardo Salveti de Araujo <ricardo.salveti@...>
 

On Wed, Sep 13, 2017 at 6:37 PM, Steve Brown <sbrown@cortland.com> wrote:
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. Same results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does transmit. There
is no console output because a different uart is used, but the beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked at the
errata and didn't see anything obvious.
It is supposed to just work, without any additional changes, so wonder
if this could be hw issues.

Can you check the hw revision for your Nitrogens (should be either
v0.9, v1.0 or v1.1)?

I got several from v0.9 and v1.1 and they are all functional. Just
tested the beacon sample from Zephyr 1.9 and it is working just fine.

Cheers,
--
Ricardo Salveti


Steve Brown
 

Richardo,

On Thu, 2017-09-14 at 01:47 -0300, Ricardo Salveti de Araujo wrote:
On Wed, Sep 13, 2017 at 6:37 PM, Steve Brown <sbrown@cortland.com>
wrote:
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. Same
results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does transmit.
There
is no console output because a different uart is used, but the
beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked at
the
errata and didn't see anything obvious.
It is supposed to just work, without any additional changes, so
wonder
if this could be hw issues.

Can you check the hw revision for your Nitrogens (should be either
v0.9, v1.0 or v1.1)?

I got several from v0.9 and v1.1 and they are all functional. Just
tested the beacon sample from Zephyr 1.9 and it is working just fine.

Cheers,
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/MBED gives the
following error:
"The interface firmware FAILED to parse the hex file" in FAIL.TXT

If I copy a .hex file to the MBED disk, it isn't processed and the file
remains in the folder.

Both boards exhibit identical behavior.

By comparison, copying either a .bin or .hex to the CMSIS disk on my
blenano2 works as expected.

I agree it looks like a hardware problem, but on two different rev
boards?

Is the drag/drop CMSIS interface known to work?

Thanks,

Steve


Ricardo Salveti de Araujo <ricardo.salveti@...>
 

On Thu, Sep 14, 2017 at 5:53 AM, Steve Brown <sbrown@cortland.com> wrote:
Richardo,

On Thu, 2017-09-14 at 01:47 -0300, Ricardo Salveti de Araujo wrote:
On Wed, Sep 13, 2017 at 6:37 PM, Steve Brown <sbrown@cortland.com>
wrote:
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. Same
results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does transmit.
There
is no console output because a different uart is used, but the
beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked at
the
errata and didn't see anything obvious.
It is supposed to just work, without any additional changes, so
wonder
if this could be hw issues.

Can you check the hw revision for your Nitrogens (should be either
v0.9, v1.0 or v1.1)?

I got several from v0.9 and v1.1 and they are all functional. Just
tested the beacon sample from Zephyr 1.9 and it is working just fine.

Cheers,
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.
By works as expected you mean including the BT radio?

However, copying a .bin file to /media/$USER/MBED gives the
following error:
"The interface firmware FAILED to parse the hex file" in FAIL.TXT

If I copy a .hex file to the MBED disk, it isn't processed and the file
remains in the folder.

Both boards exhibit identical behavior.
Yeah, this looks like an issue in the firmware flashed in LPC11U35.
Talking with Seeeds, it seems they originally flashed
https://github.com/xiongyihui/CMSIS-DAP/tree/arch_ble, but I didn't
yet investigate to see why this is currently broken. Maybe it assumes
the user will flash softdevice compatible fw by default, not sure.

Cheers,
--
Ricardo Salveti


Steve Brown
 

Ricardo,

On Thu, 2017-09-14 at 14:49 -0300, Ricardo Salveti de Araujo wrote:
On Thu, Sep 14, 2017 at 5:53 AM, Steve Brown <sbrown@cortland.com>
wrote:
Richardo,

On Thu, 2017-09-14 at 01:47 -0300, Ricardo Salveti de Araujo wrote:
On Wed, Sep 13, 2017 at 6:37 PM, Steve Brown <sbrown@cortland.com
wrote:
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. Same
results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does
transmit.
There
is no console output because a different uart is used, but the
beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked
at
the
errata and didn't see anything obvious.
It is supposed to just work, without any additional changes, so
wonder
if this could be hw issues.

Can you check the hw revision for your Nitrogens (should be
either
v0.9, v1.0 or v1.1)?

I got several from v0.9 and v1.1 and they are all functional.
Just
tested the beacon sample from Zephyr 1.9 and it is working just
fine.

Cheers,
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.
By works as expected you mean including the BT radio?

However, copying a .bin file to /media/$USER/MBED gives the
following error:
"The interface firmware FAILED to parse the hex file" in FAIL.TXT

If I copy a .hex file to the MBED disk, it isn't processed and the
file
remains in the folder.

Both boards exhibit identical behavior.
Yeah, this looks like an issue in the firmware flashed in LPC11U35.
Talking with Seeeds, it seems they originally flashed
https://github.com/xiongyihui/CMSIS-DAP/tree/arch_ble, but I didn't
yet investigate to see why this is currently broken. Maybe it assumes
the user will flash softdevice compatible fw by default, not sure.

Cheers,
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 the expected console output.
The radio doesn't work.

I've ordered another 2 from Digikey and will see how they behave. When
I ordered them from Seeed, I never thought to check if they were
available locally.

I wonder if they got zapped during customs inspection. They probably x-
ray the small boxes. I hope the customs inspector wears a film badge.
If anybody from Nordic is listening, maybe they have an opinion.

Steve


Chettimada, Vinayak Kariappa
 

Hi Steve,

Yes, we (for myself) are listening ;-)

You say beacon hex flashed to ble nano2 works (advertises).

1. Does hello world sample work (print out on UART)?
2. Does the samples/basic/blinky  work (flash LED) ?

Lets proceed with these.

Regards,
Vinayak



On 14 Sep 2017, at 21:03, Steve Brown <sbrown@...> wrote:

Ricardo,

On Thu, 2017-09-14 at 14:49 -0300, Ricardo Salveti de Araujo wrote:
On Thu, Sep 14, 2017 at 5:53 AM, Steve Brown <sbrown@...>
wrote:
Richardo,

On Thu, 2017-09-14 at 01:47 -0300, Ricardo Salveti de Araujo wrote:
On Wed, Sep 13, 2017 at 6:37 PM, Steve Brown <sbrown@...

wrote:
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. Same
results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does
transmit.
There
is no console output because a different uart is used, but the
beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked
at
the
errata and didn't see anything obvious.

It is supposed to just work, without any additional changes, so
wonder
if this could be hw issues.

Can you check the hw revision for your Nitrogens (should be
either
v0.9, v1.0 or v1.1)?

I got several from v0.9 and v1.1 and they are all functional.
Just
tested the beacon sample from Zephyr 1.9 and it is working just
fine.

Cheers,

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.

By works as expected you mean including the BT radio?

However, copying a .bin file to /media/$USER/MBED gives the
following error:
"The interface firmware FAILED to parse the hex file" in FAIL.TXT

If I copy a .hex file to the MBED disk, it isn't processed and the
file
remains in the folder.

Both boards exhibit identical behavior.

Yeah, this looks like an issue in the firmware flashed in LPC11U35.
Talking with Seeeds, it seems they originally flashed
https://github.com/xiongyihui/CMSIS-DAP/tree/arch_ble, but I didn't
yet investigate to see why this is currently broken. Maybe it assumes
the user will flash softdevice compatible fw by default, not sure.

Cheers,

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 the expected console output.
The radio doesn't work.

I've ordered another 2 from Digikey and will see how they behave. When
I ordered them from Seeed, I never thought to check if they were
available locally.

I wonder if they got zapped during customs inspection. They probably x-
ray the small boxes. I hope the customs inspector wears a film badge.
If anybody from Nordic is listening, maybe they have an opinion.

Steve


_______________________________________________
Zephyr-users mailing list
Zephyr-users@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Steve Brown
 

Hi Vinayak,

On Thu, 2017-09-14 at 19:14 +0000, Chettimada, Vinayak Kariappa wrote:
Hi Steve,

Yes, we (for myself) are listening ;-)

You say beacon hex flashed to ble nano2 works (advertises).

1. Does hello world sample work (print out on UART)?
2. Does the samples/basic/blinky  work (flash LED) ?

Lets proceed with these.

Regards,
Vinayak



On 14 Sep 2017, at 21:03, Steve Brown <sbrown@cortland.com> wrote:

Ricardo,

On Thu, 2017-09-14 at 14:49 -0300, Ricardo Salveti de Araujo wrote:
On Thu, Sep 14, 2017 at 5:53 AM, Steve Brown <sbrown@cortland.com
wrote:
Richardo,

On Thu, 2017-09-14 at 01:47 -0300, Ricardo Salveti de Araujo
wrote:
On Wed, Sep 13, 2017 at 6:37 PM, Steve Brown <sbrown@cortland
.com
 wrote:
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.
Same
results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does
transmit.
There
is no console output because a different uart is used, but
the
beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I
looked
at
the
errata and didn't see anything obvious.
It is supposed to just work, without any additional changes,
so
wonder
if this could be hw issues.

Can you check the hw revision for your Nitrogens (should be
either
v0.9, v1.0 or v1.1)?

I got several from v0.9 and v1.1 and they are all functional.
Just
tested the beacon sample from Zephyr 1.9 and it is working
just
fine.

Cheers,
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.
By works as expected you mean including the BT radio?

However, copying a .bin file to /media/$USER/MBED gives the
following error:
"The interface firmware FAILED to parse the hex file" in
FAIL.TXT

If I copy a .hex file to the MBED disk, it isn't processed and
the
file
remains in the folder.

Both boards exhibit identical behavior.
Yeah, this looks like an issue in the firmware flashed in
LPC11U35.
Talking with Seeeds, it seems they originally flashed
https://github.com/xiongyihui/CMSIS-DAP/tree/arch_ble, but I
didn't
yet investigate to see why this is currently broken. Maybe it
assumes
the user will flash softdevice compatible fw by default, not
sure.

Cheers,
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 the expected console
output.
The radio doesn't work.

I've ordered another 2 from Digikey and will see how they behave.
When
I ordered them from Seeed, I never thought to check if they were
available locally.

I wonder if they got zapped during customs inspection. They
probably x-
ray the small boxes. I hope the customs inspector wears a film
badge.
If anybody from Nordic is listening, maybe they have an opinion.

Steve


_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users
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 as I explained previously.

I'm now more convinced that the devices somehow got damaged in transit
from Seeed.

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


Chettimada, Vinayak Kariappa
 


Hello and blinky work. BT does not.
Ok, so the CPU and UART works :-)
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/releases/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.
Very unlikely (and likely based on conditions), I use nRF51 dongles 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'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.
I think Seeed need to contact our support (I am just a software guy).


The shipment didn't seem to have been opened. I'm pretty ESD conscious
at my end.

Steve


Steve Brown
 

Vinayak,

On Thu, 2017-09-14 at 19:54 +0000, Chettimada, Vinayak Kariappa wrote:

Hello and blinky work. BT does not.
Ok, so the CPU and UART works :-)
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/releas
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. 
Very unlikely (and likely based on conditions), I use nRF51 dongles
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'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.
I think Seeed need to contact our support (I am just a software guy).


The shipment didn't seem to have been opened. I'm pretty ESD
conscious
at my end.

Steve
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 wispy doesn't seem
to calibrate properly, so I don't know the exact freqs, but they are
the same as the nano2. The difference is that "hcitool lescan" receives
the nano2 advertisements, but nothing from the nitrogen.

Next, I will try to see what is actually on the air. I'll also try to
get accurate freqs for the advertisements.

Any ideas?

Steve


Steve Brown
 

More

On Thu, 2017-09-14 at 19:54 +0000, Chettimada, Vinayak Kariappa wrote:

Hello and blinky work. BT does not.
Ok, so the CPU and UART works :-)
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/releas
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. 
Very unlikely (and likely based on conditions), I use nRF51 dongles
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'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.
I think Seeed need to contact our support (I am just a software guy).


The shipment didn't seem to have been opened. I'm pretty ESD
conscious
at my end.

Steve
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 (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


Vinayak Kariappa
 

Hi Steve,

Good. You have clarified that indeed radio h/w is live and kicking.

May be something around the antenna matching is bad that only some peer see the transmissions.

I can be suspicious that the Factory Configuration Information is probably erased (like a full erase done using nrfjprog). You can check if the identity address printed on  "init" in shell application remains same after power resets, if so, then I have no more ideas.

Few of us are available at #zephyrproject on freenode.net, in case you prefer to IRC.

- Vinayak

On Fri, Sep 15, 2017 at 7:27 PM, Steve Brown <sbrown@...> wrote:
More

On Thu, 2017-09-14 at 19:54 +0000, Chettimada, Vinayak Kariappa wrote:
> >
> > Hello and blinky work. BT does not.
> >
>
> Ok, so the CPU and UART works :-)
> 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/releas
> > 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. 
>
> Very unlikely (and likely based on conditions), I use nRF51 dongles
> 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'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.
>
> I think Seeed need to contact our support (I am just a software guy).
>
> >
> > The shipment didn't seem to have been opened. I'm pretty ESD
> > conscious
> > at my end.
> >
> > Steve
> >
>
>

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 (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





_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Steve Brown
 

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.

Thanks for your help.

Steve

On Mon, 2017-09-18 at 05:04 +0200, Vinayak Kariappa wrote:
Hi Steve,

Good. You have clarified that indeed radio h/w is live and kicking.

May be something around the antenna matching is bad that only some
peer see the transmissions.

I can be suspicious that the Factory Configuration Information is
probably erased (like a full erase done using nrfjprog). You can
check if the identity address printed on  "init" in shell application
remains same after power resets, if so, then I have no more ideas.

Few of us are available at #zephyrproject on freenode.net, in case
you prefer to IRC.

- Vinayak

On Fri, Sep 15, 2017 at 7:27 PM, Steve Brown <sbrown@cortland.com>
wrote:
More

On Thu, 2017-09-14 at 19:54 +0000, Chettimada, Vinayak Kariappa
wrote:

Hello and blinky work. BT does not.
Ok, so the CPU and UART works :-)
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/re
leas
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. 
Very unlikely (and likely based on conditions), I use nRF51
dongles
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'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.
I think Seeed need to contact our support (I am just a software
guy).


The shipment didn't seem to have been opened. I'm pretty ESD
conscious
at my end.

Steve
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 (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





_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Steve Brown
 

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 on 2426. TX power is -4 dBm. The data rate is 1M.

The attached sample was from ubertooth-specan-ui. Lots of jitter at
2426 with both nitrogen boards.

Steve

On Mon, 2017-09-18 at 05:04 +0200, Vinayak Kariappa wrote:
Hi Steve,

Good. You have clarified that indeed radio h/w is live and kicking.

May be something around the antenna matching is bad that only some
peer see the transmissions.

I can be suspicious that the Factory Configuration Information is
probably erased (like a full erase done using nrfjprog). You can
check if the identity address printed on  "init" in shell application
remains same after power resets, if so, then I have no more ideas.

Few of us are available at #zephyrproject on freenode.net, in case
you prefer to IRC.

- Vinayak

On Fri, Sep 15, 2017 at 7:27 PM, Steve Brown <sbrown@cortland.com>
wrote:
More

On Thu, 2017-09-14 at 19:54 +0000, Chettimada, Vinayak Kariappa
wrote:

Hello and blinky work. BT does not.
Ok, so the CPU and UART works :-)
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/re
leas
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. 
Very unlikely (and likely based on conditions), I use nRF51
dongles
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'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.
I think Seeed need to contact our support (I am just a software
guy).


The shipment didn't seem to have been opened. I'm pretty ESD
conscious
at my end.

Steve
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 (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





_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users