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

Clarification on sending/receiving epochs #2

Open
natevw opened this issue Jun 3, 2015 · 2 comments
Open

Clarification on sending/receiving epochs #2

natevw opened this issue Jun 3, 2015 · 2 comments

Comments

@natevw
Copy link

natevw commented Jun 3, 2015

Each epoch is capable of a max throughput of 120bps, or a total of
16k over the full epoch period (about 18 minutes). Every mote has at
least one receiving epoch and one sending epoch per link to another
mote, and will often have multiple epochs with other motes to
increase the bandwidth available.

I'm not sure what this is saying. From the glossary I sort of expected motes to communicate via knocks during windows. What does it mean that a mote has "at least one receiving epoch"? Should this read "receiving window per epoch" and likewise for sending?

@natevw
Copy link
Author

natevw commented Jun 3, 2015

As I read further, this is becoming a bit more clear — I think!

Additional MAC-only packet types are defined for exchanging the current set of epochs active between any two motes.

and:

Each mote should actively make use of multiple epochs with more efficient options to optimize the overall energy usage.

…help me [re-]interpret the previous discussion of epoch. I was assuming the whole network would "be in" an epoch for 18 minutes. But now it's becoming a bit more clear that an epoch is [perhaps?] more of a virtual channel, one-way, between exactly 2 motes active for ~18 minutes.

@natevw
Copy link
Author

natevw commented Jun 29, 2015

A bit of update in f779a9b

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

No branches or pull requests

1 participant