Rename project with consistent rhythm namespace #114
Comments
|
Most of the current rhythm-* projects aren't mine, but i'll see if my colleague can change them. @dcalacci, what do you think? The names will make more sense if you use a more descriptive prefix for the online/web projects. To maintain consistency, I prefer to have rhythm-badge-* for everything that is purely badge related. So: Note that the analysis package will be more difficult to change since it requires renaming the package itself and everything that points to that package (including many private analysis projects that I have). But it's doable. I'll try to allocate time for this sometimes soon. |
|
Ok sound good! Thanks! Might you or someone else be able to sketch on a scrap of paper the relations between the projects above, and post that here? Unless I'm missing something, it's hard to understand how they relate (both over time with deprecation, and within rhythm ecosystem). The more detail on relationship, the better :) |
|
Fair enough (and I should update the readme..). You should be able to see
some of it in this paper (might be behind a pay-wall) -
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8259434
In general, these are the main repos:
openbadge <-> hub-py (or mobile) <-> server
People wear the badges. When turned on , the badges only broadcast their id
and wait to be activated by the system (by the hub). Once activated, they
collect and store data locally until the a hub request it). A unique case
of badge is a "beacon" - a badge we use only as a location beacon. These
badges simply broadcast their id. You can use ibeacons instead, but this
feature hasn't been tested that much, and not well documented. Also, when
you use a badge as a beacon, the system will configure it for you, keep
track of it's voltage, and make sure it's still active.
The hub gets the list of badges (and beacons) from the server, and
continuously look for badge and beacons. You can have multiple hubs (they
synchronize their work via the server). The hub will do a scan, then
connected to the badges it has been, one after the other. The hub will
activate badges that haven't been activated yet (for example, after
changing batteries), set their internal clock, and set the id and project
id that they broadcast (an optimization for how we track proximity). The
hub then request data from the badges, and store them locally. Every now
and then, the hub sends the data to the server.
The server contains the list of badges in each project, aggregates all the
data collected, and provide monitoring for the system's health (especially
with our new dashboard, yay!).
Besides that, there is the analysis library. You can use it to read our
JSON data format into python pandas, and then create the basic data
structures we use for analysis. The pipeline for proximity data is much
more mature and clean compared to the audio code. There are examples for
how to use them in the examples repo (which is currently messy, but it's
all there).
Hope this helps.
…On Wed, Nov 14, 2018 at 1:53 PM Patrick Connolly ***@***.***> wrote:
Ok sound good! Thanks! Might you or someone else be able to sketch on a
scrap of paper the relations between the projects above, and post that
here? Unless I'm missing something, it's hard to understand how they relate
(both over time with deprecation, and within rhythm ecosystem). The more
detail on relationship, the better :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#114 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAWUCR-ZU88q7yzx7QhLhgDP8-xDSYn_ks5uvGalgaJpZM4YdeF6>
.
|
|
This is so unbelievably helpful! Thanks Oren. I might try to synthesize it into a Google Drawing file that we could render in the README overview repo |
Oren mentioned that a rename of the project was overdue: #109 (comment)
Ok, so doing a quick inventory.
openbadgerhythm-badgerhythm-rtcrhythm-serverrhythm-server-jsopenbadge-serverrhythm-server-pyopenbadge-hub-pyrhythm-hub-pyopenbadge-hubrhythm-hub-mobileopenbadge-analysisrhythm-badge-analysisopenbadge-analysis-examplesrhythm-badge-analysis-examplesopenbadge-analysis-test-badgerhythm-badge-analysis-test-badgeopenbadge-rfduinorhythm-badge-rfduinorhythm-cradlerhythm-landing-pagerhythm-meeting-mediatorrhythm-clientrhythm-dashboardI've still got some other summary I'm hoping to do, like getting active/inactive status, and which prices work together, but curious to hear more about how the ecosystem works :)
Once we have this sorted, I'm happy to put together some PRs to get the name change finalized and ready to go
The text was updated successfully, but these errors were encountered: