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

Clarify how the node-setup example should be used #29

Open
yschroeder opened this issue Oct 29, 2014 · 2 comments
Open

Clarify how the node-setup example should be used #29

yschroeder opened this issue Oct 29, 2014 · 2 comments
Labels

Comments

@yschroeder
Copy link

In 1290333 the NODE_ID was dropped from being used.

The examples in examples/inga/node-setup/README.md still tells how to set a new NODE_ID.

In my scenario I have two nodes that need the link addresses 1 and 2 (for Rime). Until now I always have set the NODE_IDs to 1 and 2. What should I do with the support of the NODE_ID parameter being dropped?

For now I just set the PAN_ADDR instead of the NODE_ID. Is that a valid approach? If yes, then the README.md should be updated to reflect that.

@ejoerns
Copy link

ejoerns commented Oct 29, 2014

I'm sure I've reworked the Readme, maybe it's still pending in my work queue with some other fixes, will check this later. In the wiki it should be partly updated.

About the difference between NODE_ID and PAN_ADDR in our current implementation:
The PAN_ADDR is exactly what IEEE802.15.4 say it is and refers to as 'short address'. In most real-world scenarios this ID would not be preconfigured but assigned by a PAN coordinator.
Thus we focus more on the EUI-64 also referred to as 'extended address' as a unique identifier for our nodes. In general it is sufficient to set this! If not PAN_ADDR was set manually the pan address will be automatically derived from the EUI-64 by a simple cumulating algorithm.

Now, the NODE_ID has a different role on top of the behvaior described above. It is for testing scenarios, and only for this! :) Setting a NODE_ID both hard sets the pan address and the EUI-64.
Cooja for example uses the node ID to distinguish between the created motes. Setting the NODE_ID for debugging and testing is a valid approach. But this is not and should not be supported by the settings manager. You can passs the NODE_ID as flag during node compilation.

@yschroeder
Copy link
Author

I think we need an example that shows a first time user (or someone lost like me 😄) how to implement a wireless link (via rime?) between two nodes, when only the EUI-64 is known.

Usually I have two nodes that should communicate but have different processes to run. To be able to use the same code on both nodes I implement a node choosing process that compares the linkaddr and starts one process or the other. Then, as the linkaddresses are known one of the nodes can send data to the other.

Also we should think of how the user can find the EUI-64 of his node. It is output during boot, but as far as I remember the EUI-64 should be generated from the FTDI serial number. Maybe we need a function so that the user can input the serial number of his node (that is printed on its back) and gets the EUI-64 and the default linkaddress. This way the user can setup a link between two nodes with only the serial number printed on their backs known.

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

2 participants