From TinyOS Wiki
Jump to: navigation, search

Attendance: Phil (P), Om (O), Kyle (K), Sukun (S), Geoffrey (G), Joe (J)

P: There are two basic items in agenda. One is about dissemination as in the mail: If you disseminate with a special case sequence number, it can reset the entire network, which may not be a good idea. We can snoop on sequence number: pinging the node can be one possibility. What do people think about solving it?

O: When pinging a node, sequence number can change by the time you send a message.

P: It is true. And it is generally true for other cases. Two nodes far away, can have the same problem. So tie breaking mechanism was needed.

G: We can identify packets from UART rather than with a special sequence number.

P: Pinging (querying) or implicitly putting a special sequence number?

O: I don’t like query.

G: I agree.

K: What would be the common case? One PC sends out the message. So PC would know it.

P: It is a common case, but not an overwhelming case. Should you be able to query a sequence number?

O: What could we do with the information?

P: We can know whether node’s information is up to date.

K: As a debugging feature.

O: What if dissemination works on UART also?

P: When there are multiple base station, and inject packets on multiple base stations? If only node generates sequence number, can we do that?

G: I don’t have strong opinion, it is easy to have automatic update of sequence number on mote. It would be easier to use.

O: Even in the other case (PC query sequence number), programmer (at the upper layer) would not have to deal with sequence number.

P: We can have a middle ground of both. You can put a sequence number from PC (using a query). And you can also put a special sequence number: if a node receives a packet with a special sequence number, it automatically generates a sequence number.

K: With a special sequence number, what if two tier-2 try to send the same message?

P: There is a tie break mechanism.

O: What is the difference between this (PC query sequence number) and not specifying sequence number?

P: It can disseminate a consistent sequence number. The tier-2 might not support this option (querying sequence number), but nodes do not exclude the option.

G: It sounds good.

P: Second item on the agenda: Collection.

O: Update on link estimator status

K: Test application compiles correctly, but hasn’t been run yet.

O: Discussion on an insert

P: A bunch of people volunteered testing. It would be good to test on different environments.

K: I can test on Mica2 testbed.

S: I can test on Telosb testbed (Omega).

O: Are we duplicating efforts running on different places?

P: What about sharing experience through mailing list, so that people know how things are going.

O: I will test on Tmote testbed.

G: I can test when I get back to the town.

P: I will ask Rodrigo whether he can test on Mirage MicaZ testbed. What would be a good test strategy?

G: I will update tools when I get back to the town.

P: What is the test itself? What kind of test do we want to explore?

O: Rodrigo said he will test the path quality. How deep down do we have to go?

P: We can verify they work reasonably well. How we can test it? High rate or low rate?

O: We have to do different rates, different densities.

P: Different rate, different transmission power?

O: We are just looking at it as a black box.

P: You have been doing a unit test.

K: We can start with 2~3 nodes, and increase the number of nodes.

P: What is the first axis to test? number of node, power level, rate?

K: At first, with small number of nodes and low rate, just see wiring is done correctly.

O: It may be good to enumerate test ideas in mails.

O: What is the schedule for beta release?

P: it is not set now. There are a couple of items people are working on.

P: I will make a PC side tool for testing, which can set sampling rate, etc.