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? 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. 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. 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. > > 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
