Function of the accelerometer in the badge

[jope...@hotmail.com]

The badge has an accelerometer and one of the papers did mention what kind of functions it would have but I don't think there is a mention of it in the analysis code. Is this tied to the proximity code and not just mentioned or is it mostly unused component and there is no code for it? There is a test for it when you program the badge so you would know it works but other than that I haven't found a hint how it is used.

This is just so I can better describe the capabilities of the badge to others.

[Oren Lederman]

Ah yes, the accelerometer. We had worked on it for a while, and got to the point where the newest version of the firmware supports it (v3.0), but the support stops there. Version 3.0 implements (among many other improvements) two protocols - the "old" protocol, which is what the python hub and server support, and the "new" protocol, which is only supported by the tests and the python protocol libraries that are part of the main repository. 

We never got to switch to the new protocol and start collecting accelerometer data, so you don't see it anywhere else. That would probably require a re-write of the python-hub code (which is so, so badly written) and parts of the server. The good news are that the new python library for communicating using the new protocol is pretty good. There was a group from Technical University of Delft that started looking into that, but I'm not sure what's the status of their work.

Hope this helps. Let me know if you have any more questions

Cheers,

Oren

On Wed, Sep 16, 2020 at 11:32 PM jope...@hotmail.com <jope...@hotmail.com> wrote:

The badge has an accelerometer and one of the papers did mention what kind of functions it would have but I don't think there is a mention of it in the analysis code. Is this tied to the proximity code and not just mentioned or is it mostly unused component and there is no code for it? There is a test for it when you program the badge so you would know it works but other than that I haven't found a hint how it is used.

This is just so I can better describe the capabilities of the badge to others.

--
You received this message because you are subscribed to the Google Groups "Rhythm Badges" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rhythm-badge...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rhythm-badges/04db2352-3b84-49ad-a54c-6fe308fd815an%40googlegroups.com.

[jope...@hotmail.com]

I do have one other question about the voltage in the data. In our data (both proximity and audio), the voltage is 0.0 in all data packets but in the analysis examples it is constantly changing (for example 2.8821115493774414). Is this intended feature (of the newer firmware?) or could there be problems with our badges. Otherwise they seem to work fine and atleast the audio data seems to be accurate.

[jope...@hotmail.com]

Also, do you know what group in Delft was working on it and do you have their contact information?

[oren.l...@gmail.com]

Sorry, just realized I missed that. I thought I answered. The 0.0 voltage means that you are running the latest version (v3, I think) of the badge firmware. It's a complete re-write, and has a lot of benefits, but in this version the voltage is stored separately from the audio and proximity data. Because of that, when you run v3 with the old protocol (the one supported by the python hub), it can't send you the voltage. You have two options:
1. Switch to an 2.X version of the firmware (check out a different release)

2. Turn on the new protocol in v3, and rewrite the hub and server code. Not a great option unless you have significant resource