Well, we use it a lot, since there's only a limited number of frequencies and you never know when someone's neighbours decide to buy one of our systems as well. However, with an 8-bit group ID, we were quickly running out of groups if we wanted to give every deployment its own group, so we switched to 32-bit addresses with netmasks, effectively giving us 16- or 24-bit group IDs at the cost of slightly larger headers. So - group IDs are useful, but if you're creating a lot of different networks, 8 bits is not a whole lot.
My 2 cents :) Michiel From: [email protected] [mailto:[email protected]] On Behalf Of Eric Decker Sent: vrijdag 2 september 2011 7:18 To: Miklos Maroti Cc: [email protected] Subject: Re: [Tinyos-help] Problems with ADC to perform two consecutive readings on IRIS Mote 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
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
