Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Streaming throughput slows after a few seconds #18

Open
felipecocco opened this issue Mar 13, 2016 · 10 comments
Open

Streaming throughput slows after a few seconds #18

felipecocco opened this issue Mar 13, 2016 · 10 comments
Labels

Comments

@felipecocco
Copy link

I'm running your example accelerometer code on a MBP, and it streams wonderfully at first. However, after a few seconds, the stream noticeably slows down and I get maybe two updates a second, instead of the flurry of updates that I get at the beginning. If disconnect and reset, I again get the great stream throughput but always get the slowdown afterwards.

@brainexe
Copy link
Owner

I can't verify your issue on my MetaWear Pro device.

I ran the examples/accellerometer.js script for ~5 minutes and the output stream is constant. (at 50hz)
Are you using the most recent firmware on your device?

Can you please start the script in debug mode and post the output directly after starting the script and after the slowdown.

DEBUG="noble-device" node examples/accelerometer.js
discovered device f9:d5:4f:...
were connected!
Start accelerometer with 50hz ang +-2g
noble-device +3s send LOGGING <Buffer 0b 0b 00>
noble-device +2ms send LOGGING <Buffer 0b 01 01>
noble-device +1ms send ACCELEROMETER <Buffer 03 03 27 03>
noble-device +0ms send ACCELEROMETER <Buffer 03 04 01>
noble-device +0ms send ACCELEROMETER <Buffer 03 02 01 00>
noble-device +0ms send ACCELEROMETER <Buffer 03 0d 04 0a>
noble-device +0ms send ACCELEROMETER <Buffer 03 0a 00 14 14 14>
noble-device +0ms send ACCELEROMETER <Buffer 03 03 27 03>
noble-device +0ms send ACCELEROMETER <Buffer 03 07 07 30 81 0b c0>
noble-device +1ms send ACCELEROMETER <Buffer 03 01 01>
x: 0.0380859375 y: -0.18890380859375 z: -1.01226806640625
noble-device +28ms received ACCELEROMETER 4 <Buffer 03 04 70 02 e9 f3 37 bf>
x: 0.0389404296875 y: -0.18768310546875 z: -1.0125732421875
noble-device +13ms received ACCELEROMETER 4 <Buffer 03 04 7e 02 fd f3 32 bf>
noble-device +14ms received AMBIENT_LIGHT 3 <Buffer 14 03 00 00 00 00>
x: 0.03887939453125 y: -0.187255859375 z: -1.01287841796875
noble-device +15ms received ACCELEROMETER 4 <Buffer 03 04 7d 02 04 f4 2d bf>
x: 0.03887939453125 y: -0.1861572265625 z: -1.01214599609375
noble-device +16ms received ACCELEROMETER 4 <Buffer 03 04 7d 02 16 f4 39 bf>
x: 0.03875732421875 y: -0.1876220703125 z: -1.013916015625
noble-device +29ms received ACCELEROMETER 4 <Buffer 03 04 7b 02 fe f3 1c bf>

...after 5 minutes:

noble-device +15ms received ACCELEROMETER 4 <Buffer 03 04 85 02 ec f3 1e bf>
x: 0.0367431640625 y: -0.187744140625 z: -1.01361083984375
noble-device +15ms received ACCELEROMETER 4 <Buffer 03 04 5a 02 fc f3 21 bf>
x: 0.0384521484375 y: -0.1883544921875 z: -1.01275634765625
noble-device +45ms received ACCELEROMETER 4 <Buffer 03 04 76 02 f2 f3 2f bf>
x: 0.038330078125 y: -0.1873779296875 z: -1.013916015625
noble-device +1ms received ACCELEROMETER 4 <Buffer 03 04 74 02 02 f4 1c bf>
x: 0.03863525390625 y: -0.18792724609375 z: -1.0126953125
noble-device * +14ms* received ACCELEROMETER 4 <Buffer 03 04 79 02 f9 f3 30 bf>
x: 0.0379638671875 y: -0.18756103515625 z: -1.01165771484375
noble-device +30ms received ACCELEROMETER 4 <Buffer 03 04 6e 02 ff f3 41 bf>
x: 0.03924560546875 y: -0.18817138671875 z: -1.01324462890625

@felipecocco
Copy link
Author

Yes, I'm running the latest firmware on my Metawear. Here's a little clip showing you exactly the behavior I'm seeing. This happens very time I run it. Also, unless I do a soft reset of the metawear device, it stays in that "slowed down" mode from the outset if I run the script again. Also, when I get the stream data using the Metawear App, I don't notice this reduced throughput.

streamable.com/9uu6

@brainexe brainexe added the bug label Mar 14, 2016
@yowakita
Copy link

yowakita commented Apr 27, 2016

@felipecocco : I noticed the same thing with my macbook pro (late 2014 model running El Capitan) I am wondering if it has to do with one of Node-Metawear's dependent libraries and their interaction with OSX or a limitation of OSX itself because I tested some code on my MBP and got the same ~1000ms choppiness, and then tested the same code on my raspberry pi B+ and an Ubuntu desktop and didn't run into any choppiness issues.
@brainexe what devices/OS do you run your applications on?

@alanhortz
Copy link
Collaborator

Just for the record ... I had exactly the same problem with my MBP (El Capitan 10.11.3), no issue on Yocto. Until now I gave up digging into the problem on the MBP to focus on the logging.

@alanhortz
Copy link
Collaborator

Does anybody have update on this ?

@adebiyi422
Copy link

I am having the same issue on an Ubuntu desktop.

@alanhortz
Copy link
Collaborator

@felipecocco : Which version FW,HW and Model number for your device ? We have updated the dependencies. Do you confirm you still encounter the same problem ?

@felipecocco
Copy link
Author

felipecocco commented Nov 20, 2016

@alanhortz I seem to encounter a different problem now.

The stream no longer halts after a while; now from the start I seem to get output that is roughly on a +130ms delay followed by 0/1ms delays at regular intervals.

When I first run the command to test out the accelerometer, it does give me this warning now, though:
image

HW Rev: 0.2
FW: Rev. 1.2.5

Model Number: 2

@alanhortz
Copy link
Collaborator

@felipecocco So if I do understand you correctly, the original issue is gone but you now see a potential leak alert given by the underlying EventEmitter, is that right ?

Regarding the EventEmitter, this is something I personally encountered, but didn't had time to investigate it .... Any help is welcome ;)

I will create a new issue, with the potential memory leak ...

Alan

@alanhortz
Copy link
Collaborator

alanhortz commented Nov 21, 2016

@yowakita could you confirm the same problem you encountered on side is also solved ?

Thanks,

Alan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants