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 <antoniorosarodrig...@gmail.com> 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 <mmar...@math.u-szeged.hu> >> >> Hi Eric, >> >> On Fri, Sep 2, 2011 at 9:34 AM, Eric Decker <cire...@gmail.com> wrote: >> > >> > >> > On Fri, Sep 2, 2011 at 12:06 AM, antonio rosa >> > <antoniorosarodrig...@gmail.com> 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 <cire...@gmail.com> >> >>> >> >>> 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 >> >>> <mmar...@math.u-szeged.hu> >> >>> 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 >> >>>> <antoniorosarodrig...@gmail.com> 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 <antoniorosarodrig...@gmail.com> >> >>>> >> >> >>>> >> 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 <sal...@isis.vanderbilt.edu> >> >>>> >>> >> >>>> >>> 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 >> >>>> >>> <antoniorosarodrig...@gmail.com> 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 <sal...@isis.vanderbilt.edu> >> >>>> >>> >> >> >>>> >>> >> 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 >> >>>> >>> >> <antoniorosarodrig...@gmail.com> 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 >> >>>> >>> >> > Tinyos-help@millennium.berkeley.edu >> >>>> >>> >> > >> >>>> >>> >> > >> >>>> >>> >> > >> >>>> >>> >> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> >>>> >>> >> > >> >>>> >>> > >> >>>> >>> > >> >>>> >> >> >>>> > >> >>>> > >> >>>> >> >>>> _______________________________________________ >> >>>> Tinyos-help mailing list >> >>>> Tinyos-help@millennium.berkeley.edu >> >>>> >> >>>> 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 >> > Tinyos-help@millennium.berkeley.edu >> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> > > > _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
