Miklos, I think that also, you should include it in the command command bool AMPacket.isForMe(message_t* msg) provides by ActiveMessageLayerP on library /tos/chips/rf2xx/layers.
2011/9/2 Miklos Maroti <[email protected]> > Ok, I have checked in a fix: isForMe now checks the group id, and now > it is compatible with 1.x. Miklos > > On Fri, Sep 2, 2011 at 9:52 AM, antonio rosa > <[email protected]> wrote: > > I think that in a classroom or a building with several apartments per > > florr( like a WPAN or BAN), if every apartments has a WSN maybe two o > more > > networks can share the same radio channel and this could be a problems > for > > the applications of the nodes. > > > > 2011/9/2 Miklos Maroti <[email protected]> > >> > >> Hi Eric, > >> > >> On Fri, Sep 2, 2011 at 9:34 AM, Eric Decker <[email protected]> wrote: > >> > > >> > > >> > On Fri, Sep 2, 2011 at 12:06 AM, antonio rosa > >> > <[email protected]> wrote: > >> >> > >> >> Hi to all, > >> >> > >> >> I think that put parallel networks on different radio channels is > >> >> better > >> >> because it avoids collisions , but if you only use the radio > channel, > >> >> it is > >> >> not scalable (15 different networks) solution > >> > > >> > I see your point. And this would certainly be true if you put the > >> > networks > >> > in the same propagation area. But why would you do that? > >> > >> In general, I agree that group IDs is not a very good solution. > >> However, if you have a classroom or conference demo session > >> environment, and you do not want to mess with different frequencies, > >> then you can better isolate the networks (or add another level of > >> protection). > >> > >> > To handle the scaling of 15 channels for a large deployment one would > >> > have > >> > to design the propagation field and use frequency hopping. The > problem > >> > then become additional cost because special node would be needed to > >> > bridge > >> > the different frequencies together. > >> > >> Frequency hopping does not need bridges, all nodes hop synchronously. > >> > >> > Scaling a network that has increasing collisions as the scale goes up > >> > (which > >> > would be the case if one were using group id and as more node were > >> > added) > >> > doesn't scale in a different way. And as the collisions and > >> > retransmissions > >> > go up so does power consumption. You end up with a deployment where > >> > the > >> > nodes burn their power because of excessive retransmissions and > >> > collisions. > >> > At least with designing the propagation and frequency use pattern you > >> > have a > >> > reasonable chance. > >> > >> All true in a real deployment. What if every student in a school has a > >> private body attached sensor network? > >> > >> >> and you need other field (with field Group, you can have 256 networks > >> >> for > >> >> each radio channel) > >> > > >> > I still don't see the use given actual deployment problems and it > adds > >> > complexity. > >> > But if one is going to use it, it should be implemented properly. > >> > I just see how it is worth the effort. > >> > eric > >> >> > >> >> TinyOS-1.x filters nets by group, and snoop the trafic of any node > >> >> with > >> >> any group. > >> > >> This is a good observation. This is quite easy to do, but completely > >> separating the groups (not even snooping) has some benefit as well. > >> > >> Miklos > >> > >> >> > >> >> 2011/9/2 Eric Decker <[email protected]> > >> >>> > >> >>> In practice, how often are parallel nets using group id to > >> >>> differentiate > >> >>> implemented. How useful is this really. Note that > >> >>> any node that is listening burns the energy to receive these packets > >> >>> that > >> >>> they then throw away. > >> >>> It is much better to put parallel nets on dfifferent frequencies. > >> >>> So how useful is the group id concept anyway? > >> >>> So either fully implement its symantics or deprecate it and use its > >> >>> position for something else, perhaps making the len field be 16 bits > >> >>> instead > >> >>> of 8 bits. > >> >>> just some thoughts. > >> >>> eric > >> >>> > >> >>> On Thu, Sep 1, 2011 at 5:53 PM, Miklos Maroti > >> >>> <[email protected]> > >> >>> wrote: > >> >>>> > >> >>>> Hi Antonio, > >> >>>> > >> >>>> That is a good catch. I think the isForMe should be fixed. It is > also > >> >>>> a good question whether messages with DIFFERENT group id should be > >> >>>> snooped. I think those messages should be dropped (that way you can > >> >>>> separate different apps completely, even if they use the same > >> >>>> services). What do you guys think? > >> >>>> > >> >>>> Miklos > >> >>>> > >> >>>> On Wed, Aug 31, 2011 at 12:14 PM, antonio rosa > >> >>>> <[email protected]> wrote: > >> >>>> > Hi Janos, > >> >>>> > > >> >>>> > I have been that the component ActiveMessageLayerP of > >> >>>> > rflink/layers > >> >>>> > library > >> >>>> > provides interface Receive[am_id_t id]. The event > >> >>>> > SubReceive.receive > >> >>>> > that > >> >>>> > signal Receive.receive event not filter the group, and this > >> >>>> > produces > >> >>>> > that > >> >>>> > any node with the same id but different group can receive the > >> >>>> > messages > >> >>>> > without snooping. > >> >>>> > > >> >>>> > I think a node should filter group when isn't snooping, adding > this > >> >>>> > lines: > >> >>>> > if (call AMpacket.isForMe(msg) == TRUE && call > AMPacket.group(msg) > >> >>>> > == > >> >>>> > call > >> >>>> > ActiveMessageAddress.amGroup()) > >> >>>> > signal Receive.receive[id](msg, payload, len); > >> >>>> > else > >> >>>> > signal Snoop.receive[id](msg, payload, len); > >> >>>> > > >> >>>> > 2011/8/31 antonio rosa <[email protected]> > >> >>>> >> > >> >>>> >> Hi Janos, > >> >>>> >> > >> >>>> >> I have updated the Adc Atmega1281 with the TinyOS Trunk and the > >> >>>> >> problem is > >> >>>> >> result, > >> >>>> >> > >> >>>> >> Thanks for all, Antonio Rosa. > >> >>>> >> > >> >>>> >> Maybe I will send you some questions about others topics, that I > >> >>>> >> think > >> >>>> >> there is problems o bugs. > >> >>>> >> > >> >>>> >> 2011/8/30 Janos Sallai <[email protected]> > >> >>>> >>> > >> >>>> >>> Antonio, > >> >>>> >>> > >> >>>> >>> I have been able to replicate this. Interestingly, only the > first > >> >>>> >>> sample should be bad after a channel/vref change according to > the > >> >>>> >>> data > >> >>>> >>> sheet, unless we're switching to a differential channel, where > it > >> >>>> >>> may > >> >>>> >>> take up to 125us for the stage to stabilize. I did observe, > >> >>>> >>> however, > >> >>>> >>> that the second reading was bad, too, when switching to > >> >>>> >>> ATM128_ADC_SNGL_1_23. > >> >>>> >>> > >> >>>> >>> I checked in the fix. Please get the latest sources from google > >> >>>> >>> code. > >> >>>> >>> > >> >>>> >>> Thanks for reporting this. > >> >>>> >>> > >> >>>> >>> Janos > >> >>>> >>> > >> >>>> >>> On Tue, Aug 30, 2011 at 11:18 AM, antonio rosa > >> >>>> >>> <[email protected]> wrote: > >> >>>> >>> > Hi Janos, > >> >>>> >>> > I understand you. I use the ReadNow interface of the > >> >>>> >>> > AdcReadNowClient > >> >>>> >>> > component, but the source of the problem is that when I do > two > >> >>>> >>> > consecutive > >> >>>> >>> > reading of diferents channels of ADC, if the first reading is > a > >> >>>> >>> > channel > >> >>>> >>> > different of ATM128_ADC_SNGL_1_23 channel (internal voltage > on > >> >>>> >>> > IRIS) > >> >>>> >>> > the > >> >>>> >>> > value is correct, and the seconds readings is the > >> >>>> >>> > ATM128_ADC_SNGL_1_23 > >> >>>> >>> > channel the value is wrong. > >> >>>> >>> > Also, If I read only the ATM128_ADC_SNGL_1_23 channel the > >> >>>> >>> > value > >> >>>> >>> > is > >> >>>> >>> > correct, > >> >>>> >>> > but when I read other channel in the same application, the > read > >> >>>> >>> > of > >> >>>> >>> > ATM128_ADC_SNGL_1_23 channel is wrong. I have guess that when > >> >>>> >>> > you > >> >>>> >>> > read > >> >>>> >>> > the > >> >>>> >>> > internal voltage of Atmega1281, the first time the reading is > >> >>>> >>> > wrong, > >> >>>> >>> > the > >> >>>> >>> > second time the reading si correct. > >> >>>> >>> > > >> >>>> >>> > In short, if you make several readings of different ADC > >> >>>> >>> > channels, > >> >>>> >>> > you > >> >>>> >>> > must > >> >>>> >>> > do two consecutive read internal voltage channel and discard > >> >>>> >>> > the > >> >>>> >>> > first > >> >>>> >>> > reading because it is wrong, yet the latter is correct. > >> >>>> >>> > > >> >>>> >>> > > >> >>>> >>> > > >> >>>> >>> > read the ATM128_ADC_SNGL_1_23 channel, > >> >>>> >>> > > >> >>>> >>> > 2011/8/30 Janos Sallai <[email protected]> > >> >>>> >>> >> > >> >>>> >>> >> Antonio, > >> >>>> >>> >> > >> >>>> >>> >> I have a guess what can be wrong. I assume you're using > either > >> >>>> >>> >> the > >> >>>> >>> >> Atm128AdcSingle or Atm128AdcMultiple interface. While the > >> >>>> >>> >> dataReady > >> >>>> >>> >> event is slightly different in these two interfaces, in each > >> >>>> >>> >> cases it > >> >>>> >>> >> has a bool parameter, not an error_t. Notice that the value > of > >> >>>> >>> >> the > >> >>>> >>> >> SUCCESS constant is 0, which happens to be the value of > FALSE. > >> >>>> >>> >> That > >> >>>> >>> >> is, when you think that the dataReady event came back with a > >> >>>> >>> >> SUCCESS, > >> >>>> >>> >> it is, in fact, coming back with a FALSE. > >> >>>> >>> >> > >> >>>> >>> >> Let me know if this was the issue. > >> >>>> >>> >> > >> >>>> >>> >> Janos > >> >>>> >>> >> > >> >>>> >>> >> On Mon, Aug 29, 2011 at 7:37 AM, antonio rosa > >> >>>> >>> >> <[email protected]> wrote: > >> >>>> >>> >> > Hello all, > >> >>>> >>> >> > I have a problem with the IRIS platform. When I do > readings > >> >>>> >>> >> > of > >> >>>> >>> >> > different > >> >>>> >>> >> > channels of ADC reading the microcontroller's internal > >> >>>> >>> >> > voltage > >> >>>> >>> >> > (channel > >> >>>> >>> >> > ATM128_ADC_SNGL_1_23) the event (dataReady) is SUCCESS but > >> >>>> >>> >> > the > >> >>>> >>> >> > reading > >> >>>> >>> >> > (data) is erroneous. I have cheked that if I make two > >> >>>> >>> >> > consecutive > >> >>>> >>> >> > readings > >> >>>> >>> >> > of the same channel ADC, everything is correct. However, > if > >> >>>> >>> >> > I > >> >>>> >>> >> > previously > >> >>>> >>> >> > do > >> >>>> >>> >> > a reading from a channel different than used to read the > >> >>>> >>> >> > internal > >> >>>> >>> >> > voltage > >> >>>> >>> >> > and then read channel internal voltage, the value returned > >> >>>> >>> >> > by > >> >>>> >>> >> > the > >> >>>> >>> >> > adc is > >> >>>> >>> >> > wrong (superior the voltage of the batteries). > >> >>>> >>> >> > > >> >>>> >>> >> > In TinyOS.1.x with Moteworks, doesn't ocurrs this > problem. > >> >>>> >>> >> > I > >> >>>> >>> >> > have > >> >>>> >>> >> > reviewed > >> >>>> >>> >> > the TinyOS-2 driver 1.1 for the module Adc Atmega1281, > and > >> >>>> >>> >> > I > >> >>>> >>> >> > think > >> >>>> >>> >> > the > >> >>>> >>> >> > problem may be related to reading different channels that > >> >>>> >>> >> > aren't > >> >>>> >>> >> > managed > >> >>>> >>> >> > properly. > >> >>>> >>> >> > > >> >>>> >>> >> > Regards, Antonio Rosa. > >> >>>> >>> >> > _______________________________________________ > >> >>>> >>> >> > Tinyos-help mailing list > >> >>>> >>> >> > [email protected] > >> >>>> >>> >> > > >> >>>> >>> >> > > >> >>>> >>> >> > > >> >>>> >>> >> > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > >> >>>> >>> >> > > >> >>>> >>> > > >> >>>> >>> > > >> >>>> >> > >> >>>> > > >> >>>> > > >> >>>> > >> >>>> _______________________________________________ > >> >>>> Tinyos-help mailing list > >> >>>> [email protected] > >> >>>> > >> >>>> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Eric B. Decker > >> >>> Senior (over 50 :-) Researcher > >> >>> > >> >>> > >> >> > >> > > >> > > >> > > >> > -- > >> > Eric B. Decker > >> > Senior (over 50 :-) Researcher > >> > > >> > > >> > > >> > _______________________________________________ > >> > Tinyos-help mailing list > >> > [email protected] > >> > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > >> > > > > > >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
