search

Decawave / mynewt-dw1000-apps

[DEPRECATED] Use https://github.com/Decawave/uwb-apps for new designs.
Apache License 2.0
29 stars 22 forks source link

What causes these periodic transmission sleeps? #21

Closed acebrianjuan closed 5 years ago

acebrianjuan commented 5 years ago

Dear Decawave Dev Team,

A week ago I posted this question in the Decawave Tech Forum, but we haven't got any answer so far.

For this reason, I am opening an issue here.

We are basing our work on the twr_nranges_tdma application.

We have noticed that our tag experiences short interruptions (sleeps) in the reception of range measurements from the anchors every 2 minutes approximately. This symptom is shown in the next image:

dw1000-sleep-1 Note: The JSON frames visible in the image are a custom implementation that sends time, node IDs and ranges.

The red arrows are about 2 min 15 sec apart, and each of the sleep events lasts for roughly 5 seconds.

We have also detected that when these sleep events occur, two special JSON objects with a "msg" field appear in our UART console, as shown in the following image:

dw1000-sleep-2

Our particular use case requires a constant uninterrupted feed of ranging measurements, so we cannot afford having interruptions like these.

What causes these periodic sleeps? Would it be possible to configure the network to transmit uninterruptedly to avoid these sleeps?

This is the configuration we are using for the network:

Master node configuration:

newt target create master_node
newt target set master_node app=apps/twr_nranges_tdma
newt target set master_node bsp=@mynewt-dw1000-core/hw/bsp/dwm1001
newt target amend master_node syscfg=PANMASTER_ISSUER=1
newt run master_node 0.1.0

Slave nodes configuration:

newt target create slave_node
newt target set slave_node app=apps/twr_nranges_tdma
newt target set slave_node bsp=@mynewt-dw1000-core/hw/bsp/dwm1001
newt target amend slave_node syscfg=NRANGES_ANCHOR=1
newt run slave_node 0.1.0

Tag configuration:

newt target create tag
newt target set tag app=apps/twr_nranges_tdma
newt target set tag bsp=@mynewt-dw1000-core/hw/bsp/dwm1001
newt target set tag build_profile=debug
newt target amend tag syscfg=NRNG_NNODES=16:NRNG_NFRAMES=32:NODE_START_SLOT_ID=0:NODE_END_SLOT_ID=15
newt run tag 0.1.0

Thank you very much.

Álvaro

ncasaril commented 5 years ago

Hi Álvaro,

I have a few suspicions as to what may be going on. On the tag, can you run the command stat pan in the console? It should tell you if the tag's slot lease runs out before it has had time to renew it's lease. Look for the expired stats.

The other thing that may be affecting you is that the tag doesn't get the CCP packet and therefore miss a superframe. The later versions of the same app should have a check at the start of each tdma-slot (checking if the ccp->sem is taken) making sure that the tdma isn't lagging behind for some reason and therefore interfering with the receiving of the CCP packet reception.

Kind regards, Niklas

ncasaril commented 5 years ago

Hi again,

An overflowing variable caused the master node / anchor to reset the network every 128s. I've checked in a fix for this now (5f7b3f7). See if that fixes it for you.

Cheers, Niklas

acebrianjuan commented 5 years ago

Hi Niklas,

Thank you very much for your response.

I have cloned the mynewt-dw1000-apps repository in its latest version and have tried making a fresh build of the master branch, but after creating the tag target successfully, I get a runtime error when running the newt run tag 0.1.0 command:

$ newt run tag 0.1.0

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x5e5206]

goroutine 1 [running]:
mynewt.apache.org/newt/newt/parse.Eval(0x0, 0xc4205f4f90, 0x0, 0x0, 0x0)
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/newt/parse/parse.go:474 +0x26
mynewt.apache.org/newt/newt/parse.ParseAndEval(0x0, 0x0, 0xc4205f4f90, 0xf, 0x0, 0x0)
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/newt/parse/parse.go:574 +0x1aa
mynewt.apache.org/newt/newt/syscfg.(*Cfg).restrictionMet(0xc4207aa0d0, 0xc420015d60, 0xf, 0x1, 0x0, 0x0, 0xc4205f4f90, 0xc4203c7d01)
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/newt/syscfg/restrict.go:202 +0xe5
mynewt.apache.org/newt/newt/syscfg.(*Cfg).detectViolations(0xc4207aa0d0)
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/newt/syscfg/syscfg.go:684 +0x1a5
mynewt.apache.org/newt/newt/syscfg.(*Cfg).DetectErrors(0xc4207aa0d0, 0xc4207e4c90, 0x980d20, 0x0, 0x0, 0x0, 0x0, 0x0)
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/newt/syscfg/syscfg.go:1063 +0x39
mynewt.apache.org/newt/newt/resolve.ResolveFull(0x0, 0x0, 0x0, 0xc4207e4f60, 0x4, 0x6, 0xc4207e4f30, 0xc4207e4c90, 0x980d20, 0x0, ...)
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/newt/resolve/resolve.go:674 +0xf49
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).ensureResolved(0xc420348f50, 0x3, 0x8030103)
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:176 +0x16a
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).PrepBuild(0xc420348f50, 0x1, 0xffffffffffffffff)
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:260 +0x61
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).Build(0xc420348f50, 0xc4207d8a50, 0xc420348f50)
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:433 +0x2f
mynewt.apache.org/newt/newt/cli.runRunCmd(0xc420177900, 0xc4200a06c0, 0x2, 0x2)
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/newt/cli/run_cmds.go:86 +0x1e8
mynewt.apache.org/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420177900, 0xc4200a0600, 0x2, 0x2, 0xc420177900, 0xc4200a0600)
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/vendor/github.com/spf13/cobra/command.go:766 +0x2c1
mynewt.apache.org/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200f2280, 0xffffffffffffffff, 0x3, 0x78b3f3)
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/vendor/github.com/spf13/cobra/command.go:852 +0x30a
mynewt.apache.org/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200f2280, 0x78b3f3, 0x3)
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/vendor/github.com/spf13/cobra/command.go:800 +0x2b
main.main()
    /tmp/mynewt.9GAEpuA3ss/src/mynewt.apache.org/newt/newt/newt.go:170 +0x187

It looks like this is caused by Apache Mynewt, but I don't know exactly where to look at. I would like to test your fix and report back the results to you.

Cheers, Álvaro

ncasaril commented 5 years ago

Try deleting your bin directory before the newt run command. You may also need to update the mynewt-dw1000-core repo: 

cd repos/mynewt-dw1000-core;git pull;cd -
acebrianjuan commented 5 years ago

I deleted the bin directory, made sure I had mynewt-dw1000-core in its latest version and then ran newt run tag 0.1.0, but I keep getting the same runtime error.

pkettle commented 5 years ago

Hi Álvaro, I believe this is related to by the inclusion of the bleperh pkg, which is a known problem on the OSX. I have now removed this from the default configuration. Can you try comment out the bleprph from your pkg.yml.

# - "@mynewt-dw1000-apps/lib/bleprph"

acebrianjuan commented 5 years ago

Hi Paul,

Thank you very much for your response.

I was able to build the project successfully after disabling bleprph, as you instructed. I see that you have submitted this change in commit https://github.com/Decawave/mynewt-dw1000-apps/commit/a6eee641d8c791e378e487c81dcf2c2edfaf67ea.

Álvaro

acebrianjuan commented 5 years ago

Niklas, Paul,

I am back with the results.

We have tested the fix in https://github.com/Decawave/mynewt-dw1000-apps/commit/5f7b3f746fb5f1effe10d52795faa950d292e4f1 and we can confirm that it solves the problem of the periodic interruptions, as evidenced by the following image:

dw1000-monitor_109

In fact, we have been monitoring the UWB network for an hour and it has been transmitting uninterruptedly. We have not observed any interruptions whatsoever.

In addition, during these past weeks we had been experiencing capacity issues in the network when trying to connect more than 7 nodes. A few weeks ago I posted this other question in the forum describing the problem. But now in our test we have been able to connect all the units in our MDEK1001 Development Kit (11 nodes + 1 tag), so apparently the new fix you submitted also solved this problem :)

The following image shows 11 nodes in operation:

dw1000-monitor_119

Thank you very much.

Best regards, Álvaro

ncasaril commented 5 years ago

Glad to hear it works for you! I'm a bit surprised that you were able to squeeze that many anchors into a single slot without having them bleed into and upsetting the next slot. We're working on a few updates to squeeze the guard delays further but that's for the future. Cheers, Niklas