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
