That is done automatically, since there we call Ieee154PacketLayerP. Miklos
On Fri, Sep 2, 2011 at 11:32 AM, antonio rosa <[email protected]> wrote: > 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
