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
