Re: [Tinyos-help] timing problem on rfa1

[Miklos Maroti]

Hi Elena,

I do not quite remember where RTC_TIMER_HZ is actually used, maybe
that is a value you can/should use when you start your timer and no
kernel code is using it. The real problem is that the 62500 HZ timer
is running at that speed no matter what, and nothing is going to
translate that timestamp to a 32768 Hz (or any other format). TinyOS
is set up to translate timer values only by power of twos (that is why
TMilli is supposed to be 1024 Hz), and there is no infrastructure to
change a timer by a fractional amount. So I am afraid you have to
manage this time discrepancy within your time sync service manually.

Best,
Miklos

On Thu, Jul 6, 2017 at 10:56 AM, Elena Chervakova
 wrote:
> Thank you for your fast answer. The problem is, we use sntp time 
> synchronisation
> and get therefore wrong time stamps. Is it good idea just to change 
> RTC_TIMER_HZ
> or it would cause more another problems?
> Best,
> Elena
>
> On 06.07.2017 10:41, Ugo Maria Colesanti wrote:
>> The TimerMilliC in RFA1 is connected to the 62500Hz Symbol Counter which is 
>> not
>> a power of 2. You need to multiply 5120 by 62500 and multiply it by 65535 
>> which
>> should give you 4883 after rounding.
>>
>> Ugo
>>
>> On 6 July 2017 at 10:18, Elena Chervakova > > wrote:
>>
>> Hi all.
>> We work on some experiments with TinyOS timers on RFA1 and RFR2 
>> platforms. In
>> both cases, there is a significant time deviation from the set timer 
>> interval
>> and the actual time.
>>
>> To analyze the behaviour, we set a timer to 5 seconds using the 
>> TimerMilliC
>> component by calling:
>>
>> call Timer.startPeriodic( 5120 );
>>
>> for this we have a constant error of 0.25 seconds per timer event. This 
>> results
>> in a deviation of 0.5 seconds per 10 seconds which is too much for our
>> application.
>>
>> The deviation was measured by toggling a GPIO pin at each timer.fired 
>> event:
>>
>> event void Timer0.fired() {
>> call Leds.led0Toggle();
>> }
>>
>> and measuring the resulting signal via a scope. The behaviour happens 
>> with the
>> default TinyOS implementation of atm128rfa1 (tos/chips/atm128rfa1/timer) 
>> on
>> multiple platforms among them the ucmini. All show the same offset. In 
>> contrast
>> the same test with atmega1281-module result error <0.01s per 10s.
>>
>> Do you have any idea what might cause this behaviour?
>>
>> Best regards,
>> Elena
>>
>>
>> ___
>> Tinyos-help mailing list
>> Tinyos-help@millennium.berkeley.edu 
>> 
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>> 
>> 
>>
>>
>
> --
>
> Dipl.-Ing. Elena Chervakova
> Embedded Software Development
> System Design
>
> IMMS Institut für Mikroelektronik- und Mechatronik-Systeme gemeinnützige GmbH
> Ehrenbergstraße 27
> D–98693 Ilmenau
>
> Achtung – das IMMS Ilmenau hat neue Telefonnummern:
> Tel.: +49.3677.87493.58
> Fax: +49.3677.87493.15
> E-Mail: elena.chervak...@imms.de
> Internet: http://www.imms.de
>
> Geschäftsführer: Prof. Dr. Ralf Sommer -  Dipl.-Ing. Hans-Joachim Kelm
> Aufsichtsratsvorsitzender: Robert Fetter
> Sitz: Ilmenau - Rechtsform: Gesellschaft mit beschränkter Haftung
> Registergericht: Amtsgericht Jena HRB 303807
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
> erhalten
> haben, informieren Sie bitte sofort den Absender und vernichten Sie diese 
> Mail.
> Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht
> gestattet.
>
> This e-mail contains confidential and/or privileged information. If you are 
> not
> the intended recipient (or have received this e-mail in error) please notify 
> the
> sender immediately and destroy this e-mail. Any unauthorised copying, 
> disclosure
> or distribution of the material in this e-mail is strictly forbidden.
> ___
> 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

Re: [Tinyos-help] timing problem on rfa1

[Miklos Maroti]

Hi Elena,

The RFA1 has a symbol counter timer which runs at 62.5 KHz. It also
has the RTC timer which is sourced from the 32768 external crystal. If
I remember correctly, then the RTC clock can only be used with the
8-bit Timer0 which has lots of bugs. So instead the TMilli is sourced
from the symbol counter clock. So the error you are seeing is the
deviation between the 62500 vs 65536, their quotient is 1.048576 which
gives you 0.5 sec error in 10 seconds.

Now the big question is how to configure it right. You should read the
README and especially the TimerConfig.h from here

https://github.com/tinyos/tinyos-main/tree/master/tos/chips/atm128rfa1/timer

It might be enough to change/redefine the RTC_TIMER_HZ value, but I am
not sure, you need to experiment and read the code.

Best,
Miklos


On Thu, Jul 6, 2017 at 10:18 AM, Elena Chervakova
 wrote:
> Hi all.
> We work on some experiments with TinyOS timers on RFA1 and RFR2 platforms. In
> both cases, there is a significant time deviation from the set timer interval
> and the actual time.
>
> To analyze the behaviour, we set a timer to 5 seconds using the TimerMilliC
> component by calling:
>
> call Timer.startPeriodic( 5120 );
>
> for this we have a constant error of 0.25 seconds per timer event. This 
> results
> in a deviation of 0.5 seconds per 10 seconds which is too much for our 
> application.
>
> The deviation was measured by toggling a GPIO pin at each timer.fired event:
>
> event void Timer0.fired() {
> call Leds.led0Toggle();
> }
>
> and measuring the resulting signal via a scope. The behaviour happens with the
> default TinyOS implementation of atm128rfa1 (tos/chips/atm128rfa1/timer) on
> multiple platforms among them the ucmini. All show the same offset. In 
> contrast
> the same test with atmega1281-module result error <0.01s per 10s.
>
> Do you have any idea what might cause this behaviour?
>
> Best regards,
> Elena
>
>
> ___
> 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

Re: [Tinyos-help] rfa1 acknowledgements

[Miklos Maroti]

Hi Elena, If it occurs in both directions, then I think it is not HW
ack related. Of course you can test it: if it works if SW acks on the
RF230 then it is indeed a HW ack issue. Miklos

On Mon, Oct 13, 2014 at 9:40 AM, Elena Chervakova
elena.chervak...@imms.de wrote:
 Hi Miklos,

 exactly, I have relatively high packet loss. But maybe this has to do with bad
 chip antenna.

 Best regards,
 Elena Chervakova


 Am 10.10.2014 13:53, schrieb Miklos Maroti:
 Hi Elena,

 I think the SW ack for the RFA1 is fast enough for the HW ACK of the
 RF230. Do you see unacknowledged packets in both directions?

 Best,
 Miklos



 On Fri, Oct 10, 2014 at 11:11 AM, András Bíró andras.b...@ucmote.com wrote:
 Hi Elena,

 On Thu, Oct 9, 2014 at 11:06 AM, Elena Chervakova elena.chervak...@imms.de
 wrote:

 Hi András,
 thank you for the answer. Is my guess right that timing of hw acks can be
 different  from sw-acks? i.e. can this cause the problem of
 interoperability
 between iris with hw acks and rfa1-based motes with sw-acks?


 I don't think so. Theoretically it is possible that the hw ack mote doesn't
 wait enough for the sw ack, but I don't think the sw ack is that slow.
 Miklos probably knows this better, I've added him to this thread.



 Also I think about adjustments are necessary to use sw acks with blip1/2


 Blip2 doesn't work with rfxlink, therefor it doesn't work with rfa1 or
 rf230. However I've seen some blip2/rfxlink patch that worked, and it didn't
 needed hwack driver.

 Andris


 Best regards,
 Elena Chervakova


 Am 08.10.2014 17:53, schrieb András Bíró:
 Hi Elena,

 You're right, there's no hw-ack driver for the rfa1. There's no specific
 reason behind it, we just didn't really need it when we ported the rf230
 driver for rfa1. But it should be quite easy to do this with the help of
 the existing soft-ack driver. If you want to do this, please share the
 results with the community (e.g. create a pull request on github).

 Best, Andras Biro

 2014-10-06 14:41 GMT+02:00 Elena Chervakova elena.chervak...@imms.de:

 Hi all,

 I'm looking at the rfa1-port, is it true, that hardware
 acknowledgements
 are not implemented/cannot be used? Is there a specific reason for
 that?

 Best regards, Elena Chervakova


 --

 Dipl.-Ing. Elena Chervakova Wissenschaftliche Mitarbeiterin System
 Design

 IMMS Institut für Mikroelektronik- und Mechatronik-Systeme
 gemeinnützige
 GmbH Ehrenbergstrasse 27 D - 98693 Ilmenau

 Tel.  : +49.3677.6955.58 Fax   : +49.3677.6955.15 E-Mail:
 elena.chervak...@imms.de WWW   : http://www.imms.de

 Geschäftsführer: Prof. Dr. Ralf Sommer -  Dipl.-Ing. Hans-Joachim Kelm
 Aufsichtsratsvorsitzender: Dr. Jörg Prinzhausen Sitz: Ilmenau -
 Rechtsform: Gesellschaft mit beschränkter Haftung Registergericht:
 Amtsgericht Jena HRB 303807

 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
 Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
 E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
 Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
 die
 unbefugte Weitergabe dieser Mail sind nicht gestattet.

 This e-mail contains confidential and/or privileged information. If you
 are not the intended recipient (or have received this e-mail in error)
 please notify the sender immediately and destroy this e-mail. Any
 unauthorised copying, disclosure or distribution of the material in
 this
 e-mail is strictly forbidden.
 ___ Tinyos-help mailing
 list
 Tinyos-help@millennium.berkeley.edu

 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help



 --

 Dipl.-Ing. Elena Chervakova
 Wissenschaftliche Mitarbeiterin
 System Design

 IMMS Institut für Mikroelektronik- und Mechatronik-Systeme gemeinnützige
 GmbH
 Ehrenbergstrasse 27
 D - 98693 Ilmenau

 Tel.  : +49.3677.6955.58
 Fax   : +49.3677.6955.15
 E-Mail: elena.chervak...@imms.de
 WWW   : http://www.imms.de

 Geschäftsführer: Prof. Dr. Ralf Sommer -  Dipl.-Ing. Hans-Joachim Kelm
 Aufsichtsratsvorsitzender: Dr. Jörg Prinzhausen
 Sitz: Ilmenau - Rechtsform: Gesellschaft mit beschränkter Haftung
 Registergericht: Amtsgericht Jena HRB 303807

 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
 Informationen.
 Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
 erhalten haben, informieren Sie bitte sofort den Absender und vernichten
 Sie
 diese Mail.
 Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind
 nicht
 gestattet.

 This e-mail contains confidential and/or privileged information.
 If you are not the intended recipient (or have received this e-mail in
 error)
 please notify the sender immediately and destroy this e-mail.
 Any unauthorised copying, disclosure or distribution of the material in
 this
 e-mail is strictly forbidden.



 --

 Dipl.-Ing. Elena Chervakova
 Wissenschaftliche Mitarbeiterin
 System Design

 IMMS Institut für Mikroelektronik- und Mechatronik-Systeme

Re: [Tinyos-help] rfa1 acknowledgements

[Miklos Maroti]

Hi Elena,

I think the SW ack for the RFA1 is fast enough for the HW ACK of the
RF230. Do you see unacknowledged packets in both directions?

Best,
Miklos



On Fri, Oct 10, 2014 at 11:11 AM, András Bíró andras.b...@ucmote.com wrote:
 Hi Elena,

 On Thu, Oct 9, 2014 at 11:06 AM, Elena Chervakova elena.chervak...@imms.de
 wrote:

 Hi András,
 thank you for the answer. Is my guess right that timing of hw acks can be
 different  from sw-acks? i.e. can this cause the problem of
 interoperability
 between iris with hw acks and rfa1-based motes with sw-acks?


 I don't think so. Theoretically it is possible that the hw ack mote doesn't
 wait enough for the sw ack, but I don't think the sw ack is that slow.
 Miklos probably knows this better, I've added him to this thread.



 Also I think about adjustments are necessary to use sw acks with blip1/2


 Blip2 doesn't work with rfxlink, therefor it doesn't work with rfa1 or
 rf230. However I've seen some blip2/rfxlink patch that worked, and it didn't
 needed hwack driver.

 Andris


 Best regards,
 Elena Chervakova


 Am 08.10.2014 17:53, schrieb András Bíró:
  Hi Elena,
 
  You're right, there's no hw-ack driver for the rfa1. There's no specific
  reason behind it, we just didn't really need it when we ported the rf230
  driver for rfa1. But it should be quite easy to do this with the help of
  the existing soft-ack driver. If you want to do this, please share the
  results with the community (e.g. create a pull request on github).
 
  Best, Andras Biro
 
  2014-10-06 14:41 GMT+02:00 Elena Chervakova elena.chervak...@imms.de:
 
  Hi all,
 
  I'm looking at the rfa1-port, is it true, that hardware
  acknowledgements
  are not implemented/cannot be used? Is there a specific reason for
  that?
 
  Best regards, Elena Chervakova
 
 
  --
 
  Dipl.-Ing. Elena Chervakova Wissenschaftliche Mitarbeiterin System
  Design
 
  IMMS Institut für Mikroelektronik- und Mechatronik-Systeme
  gemeinnützige
  GmbH Ehrenbergstrasse 27 D - 98693 Ilmenau
 
  Tel.  : +49.3677.6955.58 Fax   : +49.3677.6955.15 E-Mail:
  elena.chervak...@imms.de WWW   : http://www.imms.de
 
  Geschäftsführer: Prof. Dr. Ralf Sommer -  Dipl.-Ing. Hans-Joachim Kelm
  Aufsichtsratsvorsitzender: Dr. Jörg Prinzhausen Sitz: Ilmenau -
  Rechtsform: Gesellschaft mit beschränkter Haftung Registergericht:
  Amtsgericht Jena HRB 303807
 
  Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
  Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
  E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
  Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
  die
  unbefugte Weitergabe dieser Mail sind nicht gestattet.
 
  This e-mail contains confidential and/or privileged information. If you
  are not the intended recipient (or have received this e-mail in error)
  please notify the sender immediately and destroy this e-mail. Any
  unauthorised copying, disclosure or distribution of the material in
  this
  e-mail is strictly forbidden.
  ___ Tinyos-help mailing
  list
  Tinyos-help@millennium.berkeley.edu
 
  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
 
 

 --

 Dipl.-Ing. Elena Chervakova
 Wissenschaftliche Mitarbeiterin
 System Design

 IMMS Institut für Mikroelektronik- und Mechatronik-Systeme gemeinnützige
 GmbH
 Ehrenbergstrasse 27
 D - 98693 Ilmenau

 Tel.  : +49.3677.6955.58
 Fax   : +49.3677.6955.15
 E-Mail: elena.chervak...@imms.de
 WWW   : http://www.imms.de

 Geschäftsführer: Prof. Dr. Ralf Sommer -  Dipl.-Ing. Hans-Joachim Kelm
 Aufsichtsratsvorsitzender: Dr. Jörg Prinzhausen
 Sitz: Ilmenau - Rechtsform: Gesellschaft mit beschränkter Haftung
 Registergericht: Amtsgericht Jena HRB 303807

 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
 Informationen.
 Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
 erhalten haben, informieren Sie bitte sofort den Absender und vernichten
 Sie
 diese Mail.
 Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind
 nicht
 gestattet.

 This e-mail contains confidential and/or privileged information.
 If you are not the intended recipient (or have received this e-mail in
 error)
 please notify the sender immediately and destroy this e-mail.
 Any unauthorised copying, disclosure or distribution of the material in
 this
 e-mail is strictly forbidden.



___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Async Timer in sleep mode

[Miklos Maroti]

Hi,

Why do you need to have it fired in async mode? Why do you want to use
something else than the Timer.fired()?

Miklos

On Sun, Dec 29, 2013 at 8:13 PM, Roadstar Runner redstripe...@gmail.com wrote:
 Hi,
 I am trying to  move all my communication tasks to a high priority task
 queue. I have already tweaked the scheduler so that it can handle  2
 priority levels.
 One of the tasks used by the low power listening module
 (LowPowerListeningLayerP.nc) relies on a Timer task(Timer.fired() event ) to
 schedule/change the radio states. Since only TImer0 runs in sleep mode, i
 cannot use the AlarmMicro32C component since they (Timer1,2,3)  will prevent
 the micro from sleeping.
 Is there any way to have a timer/alarm that can run in sleep mode and
 provide an async event.
 Please advise.
 Thanks


 Platform Iris

 ___
 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

Re: [Tinyos-help] Iris Low power listening radio lockup

[Miklos Maroti]

Hi!

The original radio stack makes sure that the RadioAlarm is never used
by two components simultaneously. So this lockup with the stock
software should not happen. Did you see this with the standard stack?

Best,
Miklos

On Fri, Dec 6, 2013 at 10:44 PM, Roadstar Runner redstripe...@gmail.com wrote:

 I have been experiencing intermittent lockups with the radio stack Iris
 modules. After some debugging i figured that the problem starts in the
 routine SubReceive.receive() in the file RandomCollisionLayerP.nc.

 If for some reason  RadioAlarm is not free (used by some other module) , the
 state variable is updated (state |= STATE_BARRIER;) .
 The only way for the state variable to be reset is in RadioAlarm.fired(),
 which will not be triggered since we were unable to get hold of the
 RadioAlaram in the first place.

 Please comment if my analysis

 Thanks in advance .

 Lewis


 ___
 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

Re: [Tinyos-help] Capture thoughts

[Miklos Maroti]

Hi Eric,

On Wed, Sep 18, 2013 at 11:09 AM, Eric Decker cire...@gmail.com wrote:

 First I understand this is an Atmega HPL so there will be some machine
 dependent stuff.

The names were taken from old Atmega interfaces, so that is why some
are not optimal.

 But I'm looking for a HPL interface for across MCUs.   Basically abstract
 the useful essence of the h/w.

There is no such MCU independent interface.

 HplAtmegaCapture defines the following:

 async command size_type get();
 async command void set(size_type value);

 I'm not sure what set would get for.   What value is this?   ie.   what does
 it get used for?

This allows raw access to the hardware, and since the HW allows you to
set this register, I support it too. It will not hurt, since if it is
never called then it is optimized away. (If some driver wants to reset
the captured value to some known value for whatever reason, then it
can do it).


 /* Signalled when the captured event has occured */
 async event void fired();



 /* Tests if there is a pending captured event */
 async command bool test();

  Reasonable.  Can we come up with a better name?  If not I'm fine with test.

 /* Resets a pending interrupt */
 async command void reset();


 clear seems to in vogue in other parts of the system.   Interrupts/Flags are
 cleared.


 /* Enables the capture interrupt */
 async command void start();

  I prefer enable

 /* Disables the capture interrupt */
 async command void stop();

  ditto for disable

 /* Checks is the overflow interrupt is enabled */
 async command bool isOn();


 overflow interrupt. Doesn't this say that the capture is
 enabled/armed?


 /* Sets the input capture mode bits */
 async command void setMode(uint8_t mode);


 What modes are available?   I suspect there is something like rising,
 falling, both
 possibly level which would be 0, or 1.

The modes are completely depend on the actual implementation of the
capture register. For example, an async timer based radio SFD capture
register has different modes than something which is connected to a
GPIO. I have checked most of the Amtega family of microprocessors, and
in all of them the other functionality is present but the
initialization of the capture register depends on many factors. So
this is an opaque value, and code which needs capture functionality
should be configured with the appropriate mode value.

Best,
Miklos



 /* Returns the input capture mode bits */
 async command uint8_t getMode();

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

Re: [Tinyos-help] any documentation on tasklets?

[Miklos Maroti]

Dear Johny,

Thanks a lot for putting up on the wiki! That is a good idea to try to
keep stuff like this there.

Best,
Miklos

On Mon, Jun 10, 2013 at 10:13 PM, Johny Mattsson jmatts...@dius.com.au wrote:
 On 8 June 2013 00:46, Miklos Maroti mmar...@math.u-szeged.hu wrote:

 Think of Tasklets as a way to
 write code that you can configure to your hart content: either to be
 run as regular tasks, or to run them in interrupt context in a safe
 way. It just gives the user quite a bit of flexibility.


 Thanks for that! I guess I had hoped for a magic cure that abstracted away
 the entire radio stack in such a way I did not have to take it into
 consideration too much, but unsurprisingly the way to good software is a
 thorough understanding, as usual.



  Can I suggest it be added to the github
  wiki, or the regular doc site as well?

 Sure, would you take this task, and I will extend it as needed?


 Me and my large mouth (keyboard?)... Okay, it's up:
   https://github.com/tinyos/tinyos-main/wiki/Tasklet-design-notes


 Cheers,
 /Johny
 --
 Johny Mattsson
 Senior Software Engineer

 DiUS Computing Pty. Ltd.
 where ideas are engineered
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] any documentation on tasklets?

[Miklos Maroti]

Hi Johny,

On Thu, Jun 6, 2013 at 7:46 PM, Johny Mattsson jmatts...@dius.com.au wrote:
 On 7 June 2013 02:56, Miklos Maroti mmar...@math.u-szeged.hu wrote:

 If Tasklets are configured to run in interrupt context, then taking
 the first interrupt (A) we call Tasklet.schedule() which will call the
 Taskletr.run() command immediately, but it remembers internally that a
 tasklet is already running. When a subsequent interrupt arrives (B)
 before (A) has returned, and calls Tasklet.schedule() again, then we
 just remember that Tasklet.run() must be called again, and we
 immediatelly return from the (B) interrupt. When interrupt (A)
 returns, then we check whether there were other interrupts so whether
 we should call Tasklet.run() again.

 I'm curious - which platforms have nested interrupts enabled? In my
 experience their usage has always been discouraged (and I ended up not using
 them for my Arduino-port-in-progress).

As far as I know, all TINYOS platforms have some nested interrupts
enabled (i.e. nonatomic handlers that automatically reenable interrupt
in their first instruction). For example, the UART code is such on all
platforms as far as I know (and that is why software problems in older
versions of the serial stack would hang under high load).

 Have there been any measurements done
 in terms of performance impact of using interrupt vs TASKLET_IS_TASK? The
 typical driver approach of bottom-in-interrupt, top-in-task is after all
 designed to ensure device timing constraints are adhered to without hogging
 interrupts for too long.

A typical tinyos application can have long running tasks, for example
some signal processing. There us no way one can mandate that all tasks
should be executed in less than 1ms, because that cannot be enforced
on a global scale.

However, the radios tack with software acks should respond with an ACK
to incoming packets withing 0.3-0.6 ms, and this is NOT achievable
without handling a significant portion of the radio logic in interrupt
context. So for some applications, it makes sense to run tasklets in
interrupt context. On the other hand, if some other high priority
stuff (e.g. ADC at 40 KHz) is running, then using TASKLET_IS_TASK
makes more sense, but that has consequences (larger latency, etc).

By the way, hardware ACK is NOT the solution in general, because the
software ack makes sure that the mote has enough memory buffer to
store the incoming packet, and under hardware ACK the stack might be
forced to drop the packet before it can actually notify the AM
handler. Think about that too.

 With the tasklet stuff it seems that unless nested
 interrupts are used (and their priorities managed correctly), one either
 runs the risk of blocking other interrupts for potentially a very long time
 (as the dispatcher does not yield), or  not responding to the interrupt in
 a timely manner (if a long-running task is currently executing or scheduled
 to be executed before the tasklet task).

Of course you should enable nested interrupts when the tasklets are
running in interrupt context. You do not block other interrupts,
because tasklets never disable interrupts, they will just prevent the
same tasklet to be run concurrently. Of course running tasklets are
blocking the task scheduler, but that is expected and nothing unusual,
so yes other tasks can be blocked.

I hope this answers your questions. Think of Tasklets as a way to
write code that you can configure to your hart content: either to be
run as regular tasks, or to run them in interrupt context in a safe
way. It just gives the user quite a bit of flexibility.

 Thanks for posting the write-up! Can I suggest it be added to the github
 wiki, or the regular doc site as well?

Sure, would you take this task, and I will extend it as needed?

Best,
Miklos


 Cheers,
 /Johny
 --
 Johny Mattsson
 Senior Software Engineer

 DiUS Computing Pty. Ltd.
 where ideas are engineered
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] any documentation on tasklets?

[Miklos Maroti]

Hi Eric!

There is no internal documentation of the Tasklet interface, so let me
post it here if others would be interested.

The RFXLINK stack almost never uses atomic sections (unlike other
radio stacks) because we ensure that the stack is not reentered
asynchronously. If a (radio or timer) interrupt arrives and the
previous interrupt handler has not returned, then we do not reenter
the radio stack but remember that we have to handle this interrupt
when the previous one is finished. Similarly, if we are in the middle
of sending of a packet, then we are not going to handle an incoming
message interrupt until we have finished with the send. This
simplifies all stat transitions and the readability of the code, and
does not impose much limitations since there is usually a shared
resource (SPI, radio chip) which would prevent concurrent access
anyways (this is achieved by huge and long running atomic blocks in
other drivers).

Thus we need a task like semantics, lets call it tasklet, which allows
only one tasklet to run at a time. This tasklet scheduling domain sits
between real tasks and interrupts in a way that it can be configured
either to be regular tasks (if TASKLET_IS_TASK is defined) or will run
in interrupt context.

Tasklet can be scheduled to be executed (similar to posting a task)
and the Tasklet.run will be executed when no other tasklet is runing.
You can disable/enable the execution of tasklets with the
disable/enable commands, which is used when we want to enter the radio
stack to send a message and want to get exclusive access (no
interruption). Of course only the time critical parts of RFXLINK are
protected by tasklets.

If Tasklets are configured to run in interrupt context, then taking
the first interrupt (A) we call Tasklet.schedule() which will call the
Taskletr.run() command immediately, but it remembers internally that a
tasklet is already running. When a subsequent interrupt arrives (B)
before (A) has returned, and calls Tasklet.schedule() again, then we
just remember that Tasklet.run() must be called again, and we
immediatelly return from the (B) interrupt. When interrupt (A)
returns, then we check whether there were other interrupts so whether
we should call Tasklet.run() again. This is why you see the forever
loop in the tasklet code: the first interrupt handler acts as a
dispatcher (tasklet scheduler) for all subsequent tasklet calls.

I hope this makes sense. A similar logic is used in the fast serial
path where we prevent the reentrance of the serial interrupt driver by
bufferring subsequent received bytes in memory and later calling the
handler when the previous one has returned. In fact, I think a general
Tasklet infrastructure should be moved to the core tinyos library. It
can adapt the Tasklet from the RFXLINK library, but it should allow
the creation of independent tasklets (THE RFXLINK library has a single
one shared by all components, and everyone will be notified if someone
called schedule). Let me know if someone would like to play with such
an idea.

Best,
Miklos

On Tue, Jun 4, 2013 at 10:52 PM, Eric Decker cire...@gmail.com wrote:

 I've started looking at the rfxlib stuff and am wondering why tasklets.

 Any internal documentation that talks about why and how it works?

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

Re: [Tinyos-help] How to disable Crc in IRIS Nodes

[Miklos Maroti]

Hi Stephen,

Look at RF230DriverLayerP.nc, there you will find the check for
correct CRC in the receive path. I think the best would be to use a
specially formatted message and in RF230DriverLayerP you manually copy
the CRC correct/incorrect bit to a known location to the message and
let the message processing through. However, if the bit corruption is
somewhere in the header, then the radio stack might not signal the
message correctly to the upper layers (it might fire for a different
AM receiver). If you want complete control, the you have to write and
wire up everything by yourself. Take a look at the
apps/test/rfxlink/sniffer application how to use the driver layer
directly without all the other upper stuff.

Best,
Miklos

On Mon, Jun 3, 2013 at 9:09 AM, Stephen Sun supsol...@gmail.com wrote:
 Hi, Miklos.
 I want to disable crc in IRIS so as to let nodes receive both good packets
 and bad packets, and then analyse the link quality.
  As far as I known, there exists three crc checks : radio chip level( set a
 bit in RX register ), AM level( in RF230LayerP.nc file ) and mote-PC level
 (serial packets check). Is that right?
 Build of the expriment consists of two motes: a sender and a basestation
 connected with PC. And my task is to observe good packets and bad packets
 from PC.
 How can I finish the task?

 Thanks in advance,
 Best Regards.

 Looking forward to your reply.


 2013/5/31 Stephen Sun supsol...@gmail.com

 Hi, Miklos.
 I want to disable crc in IRIS so as to let nodes receive both good packets
 and bad packets, and then analyse the link quality.
  As far as I known, there exists three crc checks : radio chip level( set
 a bit in RX register ), AM level( in RF230LayerP.nc file ) and mote-PC level
 (serial packets check). Is that right?
 Build of the expriment consists of two motes: a sender and a basestation
 connected with PC. And my task is to observe good packets and bad packets
 from PC.
 How can I finish the task?

 Thanks in advance,
 Regards.

 Stephen SUN


___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] LPL+CTP+IRIS

[Miklos Maroti]

Hi Sofia,

Interesting. Does CTP without LPL works indefinitely for your
application on IRIS?

Miklos

On Tue, May 21, 2013 at 7:21 AM, sofia aparicio
aparicioso...@hotmail.com wrote:
 Hello,

 I have an IRIS mote with some sensors and using  CTP algorithm and it lasted
 around 2 days and a half. If I use LPL with 500 ms or 1000ms it lasted
 around 5 days. Is it possible to increase the lifetime of the motes using
 CTP protocol?

 Thank you very much.

 Yours,

 Sofia

 ___
 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

Re: [Tinyos-help] Node platform based on 128RFA1

[Miklos Maroti]

Hi Christian,

Just copy the ucmini platform, and strip everything off you do not need :).
Creating a platform is not documented, but it is not that hard. You should
look for the commit in the git history where the ucmini platform was added
to tinyos-main. There you will see everything you need to create for a new
platform.

Best,
Miklos

On Wed, Apr 3, 2013 at 9:22 AM, Christian Renner 
christian.ren...@tu-harburg.de wrote:

 Dear all,

 I have been using the Iris platform for quite a while and am about to
 switch to deRFmega modules (see the link below). They come with an
 ATmega128RFA1 (or ATmega256RFR2 as an alternative) and an antenna.

 I've seen that the UCmini node uses the same MCU (but ships with
 additional sensors). The question now is: How do I put together a new
 node platfrom for TinyOS with the mentioned MCU? (At a later point, I
 plan on adding sensors, LEDs, and an energy-harvesting power supply).


 Thanks in advance
 Christian




 http://www.dresden-elektronik.de/funktechnik/products/radio-modules/oem-derfmega/description/?L=1cHash=c9c902ccdb43164696acccf81b62b2bd
 ___
 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

Re: [Tinyos-help] Debugging IRIS motes

[Miklos Maroti]

You have LEDs and the serial line: that should be enough for all of
your debugging needs, at least that is what I use :) Miklos

On Thu, Mar 7, 2013 at 10:57 AM,  mic...@tobolewski.net wrote:
 Hello,

 recently I have read
 http://docs.tinyos.net/tinywiki/index.php/Debugging_IRIS_motes guide. I
 have checked price of mkII here in Poland and it is quite expensive for
 student's wallet. And my question is - Do I need EXACTLY mkII for IRIS
 motes or could it be, for example:

 http://www.propox.com/products/t_117.html?lang=enpropox_site_sessions=a3df4fe74bb4aa7a782ec7507bf5fd9c

 which is much cheaper.

 Best regards,
 Michał T.

 ___
 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

Re: [Tinyos-help] Debugging IRIS motes

[Miklos Maroti]

Store traces in the flash and use CTP to download it. You cannot stop
time, and interrupt/event based software might not behave the way you
think when you debug it using JTAG. Miklos

On Thu, Mar 7, 2013 at 11:09 AM,  mic...@tobolewski.net wrote:
 Hi,

 with my application that includes CTP, DelugeT2, Dissemination and
 serial communication I'am afraid that 3 leds will not be enough :)


 On Thu, 7 Mar 2013 10:59:58 -0600, Miklos Maroti
 mmar...@math.u-szeged.hu wrote:
 You have LEDs and the serial line: that should be enough for all of
 your debugging needs, at least that is what I use :) Miklos

 On Thu, Mar 7, 2013 at 10:57 AM,  mic...@tobolewski.net wrote:
 Hello,

 recently I have read
 http://docs.tinyos.net/tinywiki/index.php/Debugging_IRIS_motes guide. I
 have checked price of mkII here in Poland and it is quite expensive for
 student's wallet. And my question is - Do I need EXACTLY mkII for IRIS
 motes or could it be, for example:

 http://www.propox.com/products/t_117.html?lang=enpropox_site_sessions=a3df4fe74bb4aa7a782ec7507bf5fd9c

 which is much cheaper.

 Best regards,
 Michał T.

 ___
 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

Re: [Tinyos-help] Iris using 64 bit address filtering

[Miklos Maroti]

If you have serial working, then you can define RADIO_DEBUG_MESSAGES
which will print out the received messages via the DiagMsg protocol.
You should connect your mote to a PC, and there run the java
net.tinyos.utils.DiagMsg application. Take a look at
RF230DriverLayerP.nc line 677, you can also put some LED commands
there the verify that you get messages. The RF230 does not do any
hardware filtering, only the FCS (even snooping works, and CRC check
is done in software). Miklos

On Thu, Feb 21, 2013 at 12:20 AM, Roadstar Runner
redstripe...@gmail.com wrote:
 The data i had posted seems to have lost its formatting, so i am re posting
 the raw  data captured by the sniffer



 41 CC 11 22 00 FF FF 00 00 00 00 00 00 F8 00 00 00 00 00 00 00 3F 08 0B 03
 00 F8 00 0F 10 00 AA 01 F8 00 00 00 00 00 00 00 00 00





 ___
 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

Re: [Tinyos-help] Iris using 64 bit address filtering

[Miklos Maroti]

Hi Lou,

On Thu, Feb 21, 2013 at 10:36 AM, Roadstar Runner
redstripe...@gmail.com wrote:
 Hi Miklos,
 Thank you very much. I do not even get the interrupt from the radio if i use
 RX_AACK mode. If use the basic mode , it works fine.
 I used a TI (CC2430) sniffer and was able to see teh messages being. The
 data i included is from the sniffer.

 If i set the filter on the sniffer to 802.15.4 packets, it shows all the
 fields as i expect I have attached a screenshot of the sniffer capture.

 Does tinyos  support 64bit 802.15.4 addressing at the hardware level ?

The current ActiveMessageC for the RF230 works only with 16-bit
addresses, so that is the problem. You can try to hack every piece of
code to make it work, but that is not easy. If you decide to go ahead
with that, then I can give some pointers. Basically, you want only
64-bit addresses, so no mixing should be allowed, otherwise the
address of other fields in the packet need to be calculated
dynamically.

Miklos


 Thanks once again,
 Lou






 On Thu, Feb 21, 2013 at 11:22 AM, Miklos Maroti mmar...@math.u-szeged.hu
 wrote:

 If you have serial working, then you can define RADIO_DEBUG_MESSAGES
 which will print out the received messages via the DiagMsg protocol.
 You should connect your mote to a PC, and there run the java
 net.tinyos.utils.DiagMsg application. Take a look at
 RF230DriverLayerP.nc line 677, you can also put some LED commands
 there the verify that you get messages. The RF230 does not do any
 hardware filtering, only the FCS (even snooping works, and CRC check
 is done in software). Miklos

 On Thu, Feb 21, 2013 at 12:20 AM, Roadstar Runner
 redstripe...@gmail.com wrote:
  The data i had posted seems to have lost its formatting, so i am re
  posting
  the raw  data captured by the sniffer
 
 
 
  41 CC 11 22 00 FF FF 00 00 00 00 00 00 F8 00 00 00 00 00 00 00 3F 08 0B
  03
  00 F8 00 0F 10 00 AA 01 F8 00 00 00 00 00 00 00 00 00
 
 
 
 
 
  ___
  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

Re: [Tinyos-help] Iris using 64 bit address filtering

[Miklos Maroti]

Looks good! Let me know if you run into problems. If it works, then I
will merge it back to the mainline. Miklos

On Thu, Feb 21, 2013 at 10:54 AM, Roadstar Runner
redstripe...@gmail.com wrote:
 Hi Miklos,
 Thanks for the quick response.
 i made the following changes to support 64 bit addressing

 /*** File Ieee154PacketLayer.h*/
 typedef nx_struct ieee154_header_t
 {
 nxle_uint16_t fcf;
 nxle_uint8_t dsn;
 nxle_uint16_t destpan;
 #ifdef RF230_EXTENDED_ADDR_MODE
 nxle_uint64_t dest;
 nxle_uint64_t src;
 #else
 nxle_uint16_t dest;
 nxle_uint16_t src;
 #endif
 } ieee154_header_t;




 /** Ieee154PacketLayerP.nc**/


 enum
 {
 IEEE154_DATA_FRAME_MASK = (IEEE154_TYPE_MASK 
 IEEE154_FCF_FRAME_TYPE)
 | (1  IEEE154_FCF_INTRAPAN)
 | (IEEE154_ADDR_MASK  IEEE154_FCF_DEST_ADDR_MODE)
 | (IEEE154_ADDR_MASK  IEEE154_FCF_SRC_ADDR_MODE),

 IEEE154_DATA_FRAME_VALUE = (IEEE154_TYPE_DATA 
 IEEE154_FCF_FRAME_TYPE)
 | (1  IEEE154_FCF_INTRAPAN)
 #ifdef RF230_EXTENDED_ADDR_MODE
 | (IEEE154_ADDR_EXT  IEEE154_FCF_DEST_ADDR_MODE)
 | (IEEE154_ADDR_EXT  IEEE154_FCF_SRC_ADDR_MODE),
 #else
 | (IEEE154_ADDR_SHORT  IEEE154_FCF_DEST_ADDR_MODE)
 | (IEEE154_ADDR_SHORT  IEEE154_FCF_SRC_ADDR_MODE),
 #endif
 IEEE154_ACK_FRAME_LENGTH = 3,// includes the FCF, DSN
 IEEE154_ACK_FRAME_MASK = (IEEE154_TYPE_MASK 
 IEEE154_FCF_FRAME_TYPE),
 IEEE154_ACK_FRAME_VALUE = (IEEE154_TYPE_ACK 
 IEEE154_FCF_FRAME_TYPE),
 };



 /** RF230DriverHwAckP.nc
 ***/
temp = call ActiveMessageAddress.amAddress();
 #ifdef RF230_EXTENDED_ADDR_MODE
 writeRegister(RF230_IEEE_ADDR_0, temp);
 writeRegister(RF230_IEEE_ADDR_1, temp  8);
 #else
 writeRegister(RF230_SHORT_ADDR_0, temp);
 writeRegister(RF230_SHORT_ADDR_1, temp  8);
 #endif

 Right now i am only using the lower 2 address bytes for testing.


 Thanks,
 Lou






 On Thu, Feb 21, 2013 at 11:40 AM, Miklos Maroti mmar...@math.u-szeged.hu
 wrote:

 Hi Lou,

 On Thu, Feb 21, 2013 at 10:36 AM, Roadstar Runner
 redstripe...@gmail.com wrote:
  Hi Miklos,
  Thank you very much. I do not even get the interrupt from the radio if i
  use
  RX_AACK mode. If use the basic mode , it works fine.
  I used a TI (CC2430) sniffer and was able to see teh messages being. The
  data i included is from the sniffer.
 
  If i set the filter on the sniffer to 802.15.4 packets, it shows all the
  fields as i expect I have attached a screenshot of the sniffer capture.
 
  Does tinyos  support 64bit 802.15.4 addressing at the hardware level ?

 The current ActiveMessageC for the RF230 works only with 16-bit
 addresses, so that is the problem. You can try to hack every piece of
 code to make it work, but that is not easy. If you decide to go ahead
 with that, then I can give some pointers. Basically, you want only
 64-bit addresses, so no mixing should be allowed, otherwise the
 address of other fields in the packet need to be calculated
 dynamically.

 Miklos

 
  Thanks once again,
  Lou
 
 
 
 
 
 
  On Thu, Feb 21, 2013 at 11:22 AM, Miklos Maroti
  mmar...@math.u-szeged.hu
  wrote:
 
  If you have serial working, then you can define RADIO_DEBUG_MESSAGES
  which will print out the received messages via the DiagMsg protocol.
  You should connect your mote to a PC, and there run the java
  net.tinyos.utils.DiagMsg application. Take a look at
  RF230DriverLayerP.nc line 677, you can also put some LED commands
  there the verify that you get messages. The RF230 does not do any
  hardware filtering, only the FCS (even snooping works, and CRC check
  is done in software). Miklos
 
  On Thu, Feb 21, 2013 at 12:20 AM, Roadstar Runner
  redstripe...@gmail.com wrote:
   The data i had posted seems to have lost its formatting, so i am re
   posting
   the raw  data captured by the sniffer
  
  
  
   41 CC 11 22 00 FF FF 00 00 00 00 00 00 F8 00 00 00 00 00 00 00 3F 08
   0B
   03
   00 F8 00 0F 10 00 AA 01 F8 00 00 00 00 00 00 00 00 00
  
  
  
  
  
   ___
   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

Re: [Tinyos-help] Iris using 64 bit address filtering

[Miklos Maroti]

Ok, I have started to look into this. Do you want to use the
ActiveMessageC framework, right? How do you want to eventually handle
the 64-bit address vs the 16-bit address defined in AM.h? Maybe we
should change am_addr_t to 64-bit? Miklos

On Thu, Feb 21, 2013 at 10:59 AM, Roadstar Runner
redstripe...@gmail.com wrote:
 So far no luck :-(
 I was under the impression that this is all i should need. Are there any
 other quirks in the RF230 that might be causing a problem?



 On Thu, Feb 21, 2013 at 11:57 AM, Miklos Maroti mmar...@math.u-szeged.hu
 wrote:

 Looks good! Let me know if you run into problems. If it works, then I
 will merge it back to the mainline. Miklos

 On Thu, Feb 21, 2013 at 10:54 AM, Roadstar Runner
 redstripe...@gmail.com wrote:
  Hi Miklos,
  Thanks for the quick response.
  i made the following changes to support 64 bit addressing
 
  /*** File Ieee154PacketLayer.h*/
  typedef nx_struct ieee154_header_t
  {
  nxle_uint16_t fcf;
  nxle_uint8_t dsn;
  nxle_uint16_t destpan;
  #ifdef RF230_EXTENDED_ADDR_MODE
  nxle_uint64_t dest;
  nxle_uint64_t src;
  #else
  nxle_uint16_t dest;
  nxle_uint16_t src;
  #endif
  } ieee154_header_t;
 
 
 
 
  /**
  Ieee154PacketLayerP.nc**/
 
 
  enum
  {
  IEEE154_DATA_FRAME_MASK = (IEEE154_TYPE_MASK 
  IEEE154_FCF_FRAME_TYPE)
  | (1  IEEE154_FCF_INTRAPAN)
  | (IEEE154_ADDR_MASK  IEEE154_FCF_DEST_ADDR_MODE)
  | (IEEE154_ADDR_MASK  IEEE154_FCF_SRC_ADDR_MODE),
 
  IEEE154_DATA_FRAME_VALUE = (IEEE154_TYPE_DATA 
  IEEE154_FCF_FRAME_TYPE)
  | (1  IEEE154_FCF_INTRAPAN)
  #ifdef RF230_EXTENDED_ADDR_MODE
  | (IEEE154_ADDR_EXT  IEEE154_FCF_DEST_ADDR_MODE)
  | (IEEE154_ADDR_EXT  IEEE154_FCF_SRC_ADDR_MODE),
  #else
  | (IEEE154_ADDR_SHORT  IEEE154_FCF_DEST_ADDR_MODE)
  | (IEEE154_ADDR_SHORT  IEEE154_FCF_SRC_ADDR_MODE),
  #endif
  IEEE154_ACK_FRAME_LENGTH = 3,// includes the FCF, DSN
  IEEE154_ACK_FRAME_MASK = (IEEE154_TYPE_MASK 
  IEEE154_FCF_FRAME_TYPE),
  IEEE154_ACK_FRAME_VALUE = (IEEE154_TYPE_ACK 
  IEEE154_FCF_FRAME_TYPE),
  };
 
 
 
  /** RF230DriverHwAckP.nc
  ***/
 temp = call ActiveMessageAddress.amAddress();
  #ifdef RF230_EXTENDED_ADDR_MODE
  writeRegister(RF230_IEEE_ADDR_0, temp);
  writeRegister(RF230_IEEE_ADDR_1, temp  8);
  #else
  writeRegister(RF230_SHORT_ADDR_0, temp);
  writeRegister(RF230_SHORT_ADDR_1, temp  8);
  #endif
 
  Right now i am only using the lower 2 address bytes for testing.
 
 
  Thanks,
  Lou
 
 
 
 
 
 
  On Thu, Feb 21, 2013 at 11:40 AM, Miklos Maroti
  mmar...@math.u-szeged.hu
  wrote:
 
  Hi Lou,
 
  On Thu, Feb 21, 2013 at 10:36 AM, Roadstar Runner
  redstripe...@gmail.com wrote:
   Hi Miklos,
   Thank you very much. I do not even get the interrupt from the radio
   if i
   use
   RX_AACK mode. If use the basic mode , it works fine.
   I used a TI (CC2430) sniffer and was able to see teh messages being.
   The
   data i included is from the sniffer.
  
   If i set the filter on the sniffer to 802.15.4 packets, it shows all
   the
   fields as i expect I have attached a screenshot of the sniffer
   capture.
  
   Does tinyos  support 64bit 802.15.4 addressing at the hardware level
   ?
 
  The current ActiveMessageC for the RF230 works only with 16-bit
  addresses, so that is the problem. You can try to hack every piece of
  code to make it work, but that is not easy. If you decide to go ahead
  with that, then I can give some pointers. Basically, you want only
  64-bit addresses, so no mixing should be allowed, otherwise the
  address of other fields in the packet need to be calculated
  dynamically.
 
  Miklos
 
  
   Thanks once again,
   Lou
  
  
  
  
  
  
   On Thu, Feb 21, 2013 at 11:22 AM, Miklos Maroti
   mmar...@math.u-szeged.hu
   wrote:
  
   If you have serial working, then you can define RADIO_DEBUG_MESSAGES
   which will print out the received messages via the DiagMsg protocol.
   You should connect your mote to a PC, and there run the java
   net.tinyos.utils.DiagMsg application. Take a look at
   RF230DriverLayerP.nc line 677, you can also put some LED commands
   there the verify that you get messages. The RF230 does not do any
   hardware filtering, only the FCS (even snooping works, and CRC check
   is done in software). Miklos
  
   On Thu, Feb 21, 2013 at 12:20 AM, Roadstar Runner
   redstripe...@gmail.com wrote:
The data i had posted seems to have lost its formatting, so i am
re
posting
the raw  data captured by the sniffer
   
   
   
41 CC 11 22 00 FF FF 00 00 00 00 00

Re: [Tinyos-help] Iris using 64 bit address filtering

[Miklos Maroti]

Is the broadcast address 0xULL? Miklos

On Thu, Feb 21, 2013 at 11:20 AM, Roadstar Runner
redstripe...@gmail.com wrote:
 Hi,
 Yes i would like to use the ActiveMessageC framework.
 I hope that eventually a define in the makefile will upgrade the am address
 to  a 64 bit version   .
 Thanks,



 On Thu, Feb 21, 2013 at 12:15 PM, Miklos Maroti mmar...@math.u-szeged.hu
 wrote:

 Ok, I have started to look into this. Do you want to use the
 ActiveMessageC framework, right? How do you want to eventually handle
 the 64-bit address vs the 16-bit address defined in AM.h? Maybe we
 should change am_addr_t to 64-bit? Miklos

 On Thu, Feb 21, 2013 at 10:59 AM, Roadstar Runner
 redstripe...@gmail.com wrote:
  So far no luck :-(
  I was under the impression that this is all i should need. Are there any
  other quirks in the RF230 that might be causing a problem?
 
 
 
  On Thu, Feb 21, 2013 at 11:57 AM, Miklos Maroti
  mmar...@math.u-szeged.hu
  wrote:
 
  Looks good! Let me know if you run into problems. If it works, then I
  will merge it back to the mainline. Miklos
 
  On Thu, Feb 21, 2013 at 10:54 AM, Roadstar Runner
  redstripe...@gmail.com wrote:
   Hi Miklos,
   Thanks for the quick response.
   i made the following changes to support 64 bit addressing
  
   /*** File Ieee154PacketLayer.h*/
   typedef nx_struct ieee154_header_t
   {
   nxle_uint16_t fcf;
   nxle_uint8_t dsn;
   nxle_uint16_t destpan;
   #ifdef RF230_EXTENDED_ADDR_MODE
   nxle_uint64_t dest;
   nxle_uint64_t src;
   #else
   nxle_uint16_t dest;
   nxle_uint16_t src;
   #endif
   } ieee154_header_t;
  
  
  
  
   /**
   Ieee154PacketLayerP.nc**/
  
  
   enum
   {
   IEEE154_DATA_FRAME_MASK = (IEEE154_TYPE_MASK 
   IEEE154_FCF_FRAME_TYPE)
   | (1  IEEE154_FCF_INTRAPAN)
   | (IEEE154_ADDR_MASK  IEEE154_FCF_DEST_ADDR_MODE)
   | (IEEE154_ADDR_MASK  IEEE154_FCF_SRC_ADDR_MODE),
  
   IEEE154_DATA_FRAME_VALUE = (IEEE154_TYPE_DATA 
   IEEE154_FCF_FRAME_TYPE)
   | (1  IEEE154_FCF_INTRAPAN)
   #ifdef RF230_EXTENDED_ADDR_MODE
   | (IEEE154_ADDR_EXT  IEEE154_FCF_DEST_ADDR_MODE)
   | (IEEE154_ADDR_EXT  IEEE154_FCF_SRC_ADDR_MODE),
   #else
   | (IEEE154_ADDR_SHORT  IEEE154_FCF_DEST_ADDR_MODE)
   | (IEEE154_ADDR_SHORT  IEEE154_FCF_SRC_ADDR_MODE),
   #endif
   IEEE154_ACK_FRAME_LENGTH = 3,// includes the FCF, DSN
   IEEE154_ACK_FRAME_MASK = (IEEE154_TYPE_MASK 
   IEEE154_FCF_FRAME_TYPE),
   IEEE154_ACK_FRAME_VALUE = (IEEE154_TYPE_ACK 
   IEEE154_FCF_FRAME_TYPE),
   };
  
  
  
   /** RF230DriverHwAckP.nc
   ***/
  temp = call ActiveMessageAddress.amAddress();
   #ifdef RF230_EXTENDED_ADDR_MODE
   writeRegister(RF230_IEEE_ADDR_0, temp);
   writeRegister(RF230_IEEE_ADDR_1, temp  8);
   #else
   writeRegister(RF230_SHORT_ADDR_0, temp);
   writeRegister(RF230_SHORT_ADDR_1, temp  8);
   #endif
  
   Right now i am only using the lower 2 address bytes for testing.
  
  
   Thanks,
   Lou
  
  
  
  
  
  
   On Thu, Feb 21, 2013 at 11:40 AM, Miklos Maroti
   mmar...@math.u-szeged.hu
   wrote:
  
   Hi Lou,
  
   On Thu, Feb 21, 2013 at 10:36 AM, Roadstar Runner
   redstripe...@gmail.com wrote:
Hi Miklos,
Thank you very much. I do not even get the interrupt from the
radio
if i
use
RX_AACK mode. If use the basic mode , it works fine.
I used a TI (CC2430) sniffer and was able to see teh messages
being.
The
data i included is from the sniffer.
   
If i set the filter on the sniffer to 802.15.4 packets, it shows
all
the
fields as i expect I have attached a screenshot of the sniffer
capture.
   
Does tinyos  support 64bit 802.15.4 addressing at the hardware
level
?
  
   The current ActiveMessageC for the RF230 works only with 16-bit
   addresses, so that is the problem. You can try to hack every piece
   of
   code to make it work, but that is not easy. If you decide to go
   ahead
   with that, then I can give some pointers. Basically, you want only
   64-bit addresses, so no mixing should be allowed, otherwise the
   address of other fields in the packet need to be calculated
   dynamically.
  
   Miklos
  
   
Thanks once again,
Lou
   
   
   
   
   
   
On Thu, Feb 21, 2013 at 11:22 AM, Miklos Maroti
mmar...@math.u-szeged.hu
wrote:
   
If you have serial working, then you can define
RADIO_DEBUG_MESSAGES
which will print out the received messages via the DiagMsg
protocol.
You should connect your mote to a PC, and there run

Re: [Tinyos-help] Iris using 64 bit address filtering

[Miklos Maroti]

Take a look at this tree:

https://github.com/mmaroti/tinyos-main/commits/rfxlink-64bit

You should try it out with software acknowledgements, so RX_AACK
should be turned off. You should define RFXLINK_64BIT_ADDR macro.
Let me know how far you get with this. Once the software ack works,
then we can make the hardware ack work too.

Miklos

On Thu, Feb 21, 2013 at 11:25 AM, Miklos Maroti
mmar...@math.u-szeged.hu wrote:
 Is the broadcast address 0xULL? Miklos

 On Thu, Feb 21, 2013 at 11:20 AM, Roadstar Runner
 redstripe...@gmail.com wrote:
 Hi,
 Yes i would like to use the ActiveMessageC framework.
 I hope that eventually a define in the makefile will upgrade the am address
 to  a 64 bit version   .
 Thanks,



 On Thu, Feb 21, 2013 at 12:15 PM, Miklos Maroti mmar...@math.u-szeged.hu
 wrote:

 Ok, I have started to look into this. Do you want to use the
 ActiveMessageC framework, right? How do you want to eventually handle
 the 64-bit address vs the 16-bit address defined in AM.h? Maybe we
 should change am_addr_t to 64-bit? Miklos

 On Thu, Feb 21, 2013 at 10:59 AM, Roadstar Runner
 redstripe...@gmail.com wrote:
  So far no luck :-(
  I was under the impression that this is all i should need. Are there any
  other quirks in the RF230 that might be causing a problem?
 
 
 
  On Thu, Feb 21, 2013 at 11:57 AM, Miklos Maroti
  mmar...@math.u-szeged.hu
  wrote:
 
  Looks good! Let me know if you run into problems. If it works, then I
  will merge it back to the mainline. Miklos
 
  On Thu, Feb 21, 2013 at 10:54 AM, Roadstar Runner
  redstripe...@gmail.com wrote:
   Hi Miklos,
   Thanks for the quick response.
   i made the following changes to support 64 bit addressing
  
   /*** File Ieee154PacketLayer.h*/
   typedef nx_struct ieee154_header_t
   {
   nxle_uint16_t fcf;
   nxle_uint8_t dsn;
   nxle_uint16_t destpan;
   #ifdef RF230_EXTENDED_ADDR_MODE
   nxle_uint64_t dest;
   nxle_uint64_t src;
   #else
   nxle_uint16_t dest;
   nxle_uint16_t src;
   #endif
   } ieee154_header_t;
  
  
  
  
   /**
   Ieee154PacketLayerP.nc**/
  
  
   enum
   {
   IEEE154_DATA_FRAME_MASK = (IEEE154_TYPE_MASK 
   IEEE154_FCF_FRAME_TYPE)
   | (1  IEEE154_FCF_INTRAPAN)
   | (IEEE154_ADDR_MASK  IEEE154_FCF_DEST_ADDR_MODE)
   | (IEEE154_ADDR_MASK  IEEE154_FCF_SRC_ADDR_MODE),
  
   IEEE154_DATA_FRAME_VALUE = (IEEE154_TYPE_DATA 
   IEEE154_FCF_FRAME_TYPE)
   | (1  IEEE154_FCF_INTRAPAN)
   #ifdef RF230_EXTENDED_ADDR_MODE
   | (IEEE154_ADDR_EXT  IEEE154_FCF_DEST_ADDR_MODE)
   | (IEEE154_ADDR_EXT  IEEE154_FCF_SRC_ADDR_MODE),
   #else
   | (IEEE154_ADDR_SHORT  IEEE154_FCF_DEST_ADDR_MODE)
   | (IEEE154_ADDR_SHORT  IEEE154_FCF_SRC_ADDR_MODE),
   #endif
   IEEE154_ACK_FRAME_LENGTH = 3,// includes the FCF, DSN
   IEEE154_ACK_FRAME_MASK = (IEEE154_TYPE_MASK 
   IEEE154_FCF_FRAME_TYPE),
   IEEE154_ACK_FRAME_VALUE = (IEEE154_TYPE_ACK 
   IEEE154_FCF_FRAME_TYPE),
   };
  
  
  
   /** RF230DriverHwAckP.nc
   ***/
  temp = call ActiveMessageAddress.amAddress();
   #ifdef RF230_EXTENDED_ADDR_MODE
   writeRegister(RF230_IEEE_ADDR_0, temp);
   writeRegister(RF230_IEEE_ADDR_1, temp  8);
   #else
   writeRegister(RF230_SHORT_ADDR_0, temp);
   writeRegister(RF230_SHORT_ADDR_1, temp  8);
   #endif
  
   Right now i am only using the lower 2 address bytes for testing.
  
  
   Thanks,
   Lou
  
  
  
  
  
  
   On Thu, Feb 21, 2013 at 11:40 AM, Miklos Maroti
   mmar...@math.u-szeged.hu
   wrote:
  
   Hi Lou,
  
   On Thu, Feb 21, 2013 at 10:36 AM, Roadstar Runner
   redstripe...@gmail.com wrote:
Hi Miklos,
Thank you very much. I do not even get the interrupt from the
radio
if i
use
RX_AACK mode. If use the basic mode , it works fine.
I used a TI (CC2430) sniffer and was able to see teh messages
being.
The
data i included is from the sniffer.
   
If i set the filter on the sniffer to 802.15.4 packets, it shows
all
the
fields as i expect I have attached a screenshot of the sniffer
capture.
   
Does tinyos  support 64bit 802.15.4 addressing at the hardware
level
?
  
   The current ActiveMessageC for the RF230 works only with 16-bit
   addresses, so that is the problem. You can try to hack every piece
   of
   code to make it work, but that is not easy. If you decide to go
   ahead
   with that, then I can give some pointers. Basically, you want only
   64-bit addresses, so no mixing should be allowed, otherwise the
   address of other fields in the packet

Re: [Tinyos-help] Iris using 64 bit address filtering

[Miklos Maroti]

Thanks, I did not know. I have updated the git repo. Miklos

On Thu, Feb 21, 2013 at 12:13 PM, Roadstar Runner
redstripe...@gmail.com wrote:
 I used the broadcast address 0x since the 802.15.4 spec
 specifies the boradcast address as 0x
 I did not use the ULL postfix  cos i was just using the lower 2 bytes of the
 address

 On Thu, Feb 21, 2013 at 12:25 PM, Miklos Maroti mmar...@math.u-szeged.hu
 wrote:

 Is the broadcast address 0xULL? Miklos

 On Thu, Feb 21, 2013 at 11:20 AM, Roadstar Runner
 redstripe...@gmail.com wrote:
  Hi,
  Yes i would like to use the ActiveMessageC framework.
  I hope that eventually a define in the makefile will upgrade the am
  address
  to  a 64 bit version   .
  Thanks,
 
 
 
  On Thu, Feb 21, 2013 at 12:15 PM, Miklos Maroti
  mmar...@math.u-szeged.hu
  wrote:
 
  Ok, I have started to look into this. Do you want to use the
  ActiveMessageC framework, right? How do you want to eventually handle
  the 64-bit address vs the 16-bit address defined in AM.h? Maybe we
  should change am_addr_t to 64-bit? Miklos
 
  On Thu, Feb 21, 2013 at 10:59 AM, Roadstar Runner
  redstripe...@gmail.com wrote:
   So far no luck :-(
   I was under the impression that this is all i should need. Are there
   any
   other quirks in the RF230 that might be causing a problem?
  
  
  
   On Thu, Feb 21, 2013 at 11:57 AM, Miklos Maroti
   mmar...@math.u-szeged.hu
   wrote:
  
   Looks good! Let me know if you run into problems. If it works, then
   I
   will merge it back to the mainline. Miklos
  
   On Thu, Feb 21, 2013 at 10:54 AM, Roadstar Runner
   redstripe...@gmail.com wrote:
Hi Miklos,
Thanks for the quick response.
i made the following changes to support 64 bit addressing
   
/*** File Ieee154PacketLayer.h*/
typedef nx_struct ieee154_header_t
{
nxle_uint16_t fcf;
nxle_uint8_t dsn;
nxle_uint16_t destpan;
#ifdef RF230_EXTENDED_ADDR_MODE
nxle_uint64_t dest;
nxle_uint64_t src;
#else
nxle_uint16_t dest;
nxle_uint16_t src;
#endif
} ieee154_header_t;
   
   
   
   
/**
Ieee154PacketLayerP.nc**/
   
   
enum
{
IEEE154_DATA_FRAME_MASK = (IEEE154_TYPE_MASK 
IEEE154_FCF_FRAME_TYPE)
| (1  IEEE154_FCF_INTRAPAN)
| (IEEE154_ADDR_MASK  IEEE154_FCF_DEST_ADDR_MODE)
| (IEEE154_ADDR_MASK  IEEE154_FCF_SRC_ADDR_MODE),
   
IEEE154_DATA_FRAME_VALUE = (IEEE154_TYPE_DATA 
IEEE154_FCF_FRAME_TYPE)
| (1  IEEE154_FCF_INTRAPAN)
#ifdef RF230_EXTENDED_ADDR_MODE
| (IEEE154_ADDR_EXT  IEEE154_FCF_DEST_ADDR_MODE)
| (IEEE154_ADDR_EXT  IEEE154_FCF_SRC_ADDR_MODE),
#else
| (IEEE154_ADDR_SHORT  IEEE154_FCF_DEST_ADDR_MODE)
| (IEEE154_ADDR_SHORT  IEEE154_FCF_SRC_ADDR_MODE),
#endif
IEEE154_ACK_FRAME_LENGTH = 3,// includes the FCF, DSN
IEEE154_ACK_FRAME_MASK = (IEEE154_TYPE_MASK 
IEEE154_FCF_FRAME_TYPE),
IEEE154_ACK_FRAME_VALUE = (IEEE154_TYPE_ACK 
IEEE154_FCF_FRAME_TYPE),
};
   
   
   
/** RF230DriverHwAckP.nc
***/
   temp = call ActiveMessageAddress.amAddress();
#ifdef RF230_EXTENDED_ADDR_MODE
writeRegister(RF230_IEEE_ADDR_0, temp);
writeRegister(RF230_IEEE_ADDR_1, temp  8);
#else
writeRegister(RF230_SHORT_ADDR_0, temp);
writeRegister(RF230_SHORT_ADDR_1, temp  8);
#endif
   
Right now i am only using the lower 2 address bytes for testing.
   
   
Thanks,
Lou
   
   
   
   
   
   
On Thu, Feb 21, 2013 at 11:40 AM, Miklos Maroti
mmar...@math.u-szeged.hu
wrote:
   
Hi Lou,
   
On Thu, Feb 21, 2013 at 10:36 AM, Roadstar Runner
redstripe...@gmail.com wrote:
 Hi Miklos,
 Thank you very much. I do not even get the interrupt from the
 radio
 if i
 use
 RX_AACK mode. If use the basic mode , it works fine.
 I used a TI (CC2430) sniffer and was able to see teh messages
 being.
 The
 data i included is from the sniffer.

 If i set the filter on the sniffer to 802.15.4 packets, it
 shows
 all
 the
 fields as i expect I have attached a screenshot of the sniffer
 capture.

 Does tinyos  support 64bit 802.15.4 addressing at the hardware
 level
 ?
   
The current ActiveMessageC for the RF230 works only with 16-bit
addresses, so that is the problem. You can try to hack every
piece
of
code to make it work, but that is not easy. If you decide to go
ahead

Re: [Tinyos-help] Iris using 64 bit address filtering

[Miklos Maroti]

I never tried, I do not have the motes nor the time unfortunately. The
code is here:

https://github.com/mmaroti/tinyos-main/commits/rfxlink-64bit

Can you please try it out and see what happend? Miklos

On Thu, Feb 21, 2013 at 12:29 PM, Roadstar Runner
redstripe...@gmail.com wrote:
 did it work?
 Can i have a copy pf the modifications?


 On Thu, Feb 21, 2013 at 1:25 PM, Miklos Maroti mmar...@math.u-szeged.hu
 wrote:

 Thanks, I did not know. I have updated the git repo. Miklos

 On Thu, Feb 21, 2013 at 12:13 PM, Roadstar Runner
 redstripe...@gmail.com wrote:
  I used the broadcast address 0x since the 802.15.4 spec
  specifies the boradcast address as 0x
  I did not use the ULL postfix  cos i was just using the lower 2 bytes of
  the
  address
 
  On Thu, Feb 21, 2013 at 12:25 PM, Miklos Maroti
  mmar...@math.u-szeged.hu
  wrote:
 
  Is the broadcast address 0xULL? Miklos
 
  On Thu, Feb 21, 2013 at 11:20 AM, Roadstar Runner
  redstripe...@gmail.com wrote:
   Hi,
   Yes i would like to use the ActiveMessageC framework.
   I hope that eventually a define in the makefile will upgrade the am
   address
   to  a 64 bit version   .
   Thanks,
  
  
  
   On Thu, Feb 21, 2013 at 12:15 PM, Miklos Maroti
   mmar...@math.u-szeged.hu
   wrote:
  
   Ok, I have started to look into this. Do you want to use the
   ActiveMessageC framework, right? How do you want to eventually
   handle
   the 64-bit address vs the 16-bit address defined in AM.h? Maybe we
   should change am_addr_t to 64-bit? Miklos
  
   On Thu, Feb 21, 2013 at 10:59 AM, Roadstar Runner
   redstripe...@gmail.com wrote:
So far no luck :-(
I was under the impression that this is all i should need. Are
there
any
other quirks in the RF230 that might be causing a problem?
   
   
   
On Thu, Feb 21, 2013 at 11:57 AM, Miklos Maroti
mmar...@math.u-szeged.hu
wrote:
   
Looks good! Let me know if you run into problems. If it works,
then
I
will merge it back to the mainline. Miklos
   
On Thu, Feb 21, 2013 at 10:54 AM, Roadstar Runner
redstripe...@gmail.com wrote:
 Hi Miklos,
 Thanks for the quick response.
 i made the following changes to support 64 bit addressing

 /*** File Ieee154PacketLayer.h*/
 typedef nx_struct ieee154_header_t
 {
 nxle_uint16_t fcf;
 nxle_uint8_t dsn;
 nxle_uint16_t destpan;
 #ifdef RF230_EXTENDED_ADDR_MODE
 nxle_uint64_t dest;
 nxle_uint64_t src;
 #else
 nxle_uint16_t dest;
 nxle_uint16_t src;
 #endif
 } ieee154_header_t;




 /**
 Ieee154PacketLayerP.nc**/


 enum
 {
 IEEE154_DATA_FRAME_MASK = (IEEE154_TYPE_MASK 
 IEEE154_FCF_FRAME_TYPE)
 | (1  IEEE154_FCF_INTRAPAN)
 | (IEEE154_ADDR_MASK  IEEE154_FCF_DEST_ADDR_MODE)
 | (IEEE154_ADDR_MASK  IEEE154_FCF_SRC_ADDR_MODE),

 IEEE154_DATA_FRAME_VALUE = (IEEE154_TYPE_DATA 
 IEEE154_FCF_FRAME_TYPE)
 | (1  IEEE154_FCF_INTRAPAN)
 #ifdef RF230_EXTENDED_ADDR_MODE
 | (IEEE154_ADDR_EXT  IEEE154_FCF_DEST_ADDR_MODE)
 | (IEEE154_ADDR_EXT  IEEE154_FCF_SRC_ADDR_MODE),
 #else
 | (IEEE154_ADDR_SHORT 
 IEEE154_FCF_DEST_ADDR_MODE)
 | (IEEE154_ADDR_SHORT 
 IEEE154_FCF_SRC_ADDR_MODE),
 #endif
 IEEE154_ACK_FRAME_LENGTH = 3,// includes the FCF,
 DSN
 IEEE154_ACK_FRAME_MASK = (IEEE154_TYPE_MASK 
 IEEE154_FCF_FRAME_TYPE),
 IEEE154_ACK_FRAME_VALUE = (IEEE154_TYPE_ACK 
 IEEE154_FCF_FRAME_TYPE),
 };



 /** RF230DriverHwAckP.nc
 ***/
temp = call
 ActiveMessageAddress.amAddress();
 #ifdef RF230_EXTENDED_ADDR_MODE
 writeRegister(RF230_IEEE_ADDR_0, temp);
 writeRegister(RF230_IEEE_ADDR_1, temp 
 8);
 #else
 writeRegister(RF230_SHORT_ADDR_0, temp);
 writeRegister(RF230_SHORT_ADDR_1, temp 
 8);
 #endif

 Right now i am only using the lower 2 address bytes for
 testing.


 Thanks,
 Lou






 On Thu, Feb 21, 2013 at 11:40 AM, Miklos Maroti
 mmar...@math.u-szeged.hu
 wrote:

 Hi Lou,

 On Thu, Feb 21, 2013 at 10:36 AM, Roadstar Runner
 redstripe...@gmail.com wrote:
  Hi Miklos,
  Thank you very much. I do not even get the interrupt from
  the
  radio
  if i
  use
  RX_AACK mode. If use the basic mode , it works fine.
  I used a TI

Re: [Tinyos-help] Disabling CRC in IRIS

[Miklos Maroti]

Hi Chatura,

That is really the way to disable CRC checks, there is no other method
for the RF230 (CRC calculation is done in software while the packet is
downloaded from the SPI bus). You should move your motes very very far
away to get bit errors.

Miklos

On Thu, Feb 14, 2013 at 7:39 PM, chatura seneviratne chatu...@gmail.com wrote:
 Hi,
 We are trying to disable CRC check in IRIS nodes. So as suggested in tinyOS
 forum we commented if( crc == 0 ) line in RF230LayerP.nc file.  But we
 didn't get any corrupted packets. However, there were packet losses. We
 confirmed that by using a sequence number as the payload. Is there any other
 method to disable the CRC?
 Thank you
 Chatura


 ___
 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

Re: [Tinyos-help] FTSP + LPL + IRIS

[Miklos Maroti]

Lower time resolution, nothing else. Miklos

On Mon, Feb 18, 2013 at 2:36 PM, Gustavo Zanatta Bruno
zana...@ic.uff.br wrote:
 Miklos,

 You know me know where I can find what would be the impact of using
 Tmilli, instead of T32khz in protocol?

 2013/2/2 Gustavo Zanatta Bruno zana...@ic.uff.br:
 I changed all timers to the Tmilli, and works.
 Thanks


 2013/1/29 Miklos Maroti mmar...@math.u-szeged.hu

 The problem is that that application is written to use the 32khz timer
 which is not available on the IRIS. Most likely you should start from
 the apps/tests/TestFtsp/Ftsp application and add the LowPowerListeing
 parts from FtspLpl app (basically you need to set the remote and local
 wakeup intervals for all messages). Miklos

 On Tue, Jan 29, 2013 at 1:31 PM, Gustavo Zanatta Bruno
 zana...@ic.uff.br wrote:
  Do you remember what those changes? Even if it is only superficial for
  me
  not starting from zero.
 
  Thanks
 
 
  2013/1/29 Miklos Maroti mmar...@math.u-szeged.hu
 
  Hi Gustavo, the apps/tests/TestFtsp/FtspLpl app should work fine, but
  you need to modify it to make it compile with IRIS (if I remember
  correctly). The radio stack implements LPL and it should just work
  fine with FTSP. Miklos
 
  On Tue, Jan 29, 2013 at 12:08 PM, Gustavo Zanatta Bruno
  zana...@ic.uff.br wrote:
   Guys,
   you know why the IRIS does not support the implementation of the LPL
   (Low
   Power Listening) with ftsp (Flooding Time Synchronization Protocol).
   Not implemented, or there is some impediment of hardware?
   I have a network with 60 IRIS and I can not implement a
   synchronization
   of
   clocks. In MICAZ works well.
  
  
  
  
   --
   Atenciosamente:
   Gustavo Zanatta Bruno
  
   ___
   Tinyos-help mailing list
   Tinyos-help@millennium.berkeley.edu
  
   https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
 
 
 
 
  --
  Atenciosamente:
  Gustavo Zanatta Bruno
  Mestrando em Ciência da Computação
  Pesquisador Laboratório Tempo Sistemas de Tempo Real e Embarcados




 --
 Atenciosamente:
 Gustavo Zanatta Bruno
 Mestrando em Ciência da Computação
 Pesquisador Laboratório Tempo Sistemas de Tempo Real e Embarcados



 --
 Atenciosamente:
 Gustavo Zanatta Bruno
 Mestrando em Ciência da Computação
 Pesquisador Laboratório Tempo Sistemas de Tempo Real e Embarcados

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] FTSP + LPL + IRIS

[Miklos Maroti]

There have been various papers on this, although none of it is
integrated in to FTSP. You can try to dynamically set the transmit
interval to something much lower in the initial phase, and then switch
to back to the default. Miklos

On Mon, Feb 18, 2013 at 3:38 PM, Gustavo Zanatta Bruno
zana...@ic.uff.br wrote:
 And about time for the total time convergence of the network, do you
 think complicated to insert a mechanism to speed up this process?

 2013/2/18 Miklos Maroti mmar...@math.u-szeged.hu:
 Lower time resolution, nothing else. Miklos

 On Mon, Feb 18, 2013 at 2:36 PM, Gustavo Zanatta Bruno
 zana...@ic.uff.br wrote:
 Miklos,

 You know me know where I can find what would be the impact of using
 Tmilli, instead of T32khz in protocol?

 2013/2/2 Gustavo Zanatta Bruno zana...@ic.uff.br:
 I changed all timers to the Tmilli, and works.
 Thanks


 2013/1/29 Miklos Maroti mmar...@math.u-szeged.hu

 The problem is that that application is written to use the 32khz timer
 which is not available on the IRIS. Most likely you should start from
 the apps/tests/TestFtsp/Ftsp application and add the LowPowerListeing
 parts from FtspLpl app (basically you need to set the remote and local
 wakeup intervals for all messages). Miklos

 On Tue, Jan 29, 2013 at 1:31 PM, Gustavo Zanatta Bruno
 zana...@ic.uff.br wrote:
  Do you remember what those changes? Even if it is only superficial for
  me
  not starting from zero.
 
  Thanks
 
 
  2013/1/29 Miklos Maroti mmar...@math.u-szeged.hu
 
  Hi Gustavo, the apps/tests/TestFtsp/FtspLpl app should work fine, but
  you need to modify it to make it compile with IRIS (if I remember
  correctly). The radio stack implements LPL and it should just work
  fine with FTSP. Miklos
 
  On Tue, Jan 29, 2013 at 12:08 PM, Gustavo Zanatta Bruno
  zana...@ic.uff.br wrote:
   Guys,
   you know why the IRIS does not support the implementation of the LPL
   (Low
   Power Listening) with ftsp (Flooding Time Synchronization Protocol).
   Not implemented, or there is some impediment of hardware?
   I have a network with 60 IRIS and I can not implement a
   synchronization
   of
   clocks. In MICAZ works well.
  
  
  
  
   --
   Atenciosamente:
   Gustavo Zanatta Bruno
  
   ___
   Tinyos-help mailing list
   Tinyos-help@millennium.berkeley.edu
  
   https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
 
 
 
 
  --
  Atenciosamente:
  Gustavo Zanatta Bruno
  Mestrando em Ciência da Computação
  Pesquisador Laboratório Tempo Sistemas de Tempo Real e Embarcados




 --
 Atenciosamente:
 Gustavo Zanatta Bruno
 Mestrando em Ciência da Computação
 Pesquisador Laboratório Tempo Sistemas de Tempo Real e Embarcados



 --
 Atenciosamente:
 Gustavo Zanatta Bruno
 Mestrando em Ciência da Computação
 Pesquisador Laboratório Tempo Sistemas de Tempo Real e Embarcados




 --
 Atenciosamente:
 Gustavo Zanatta Bruno
 Mestrando em Ciência da Computação
 Pesquisador Laboratório Tempo Sistemas de Tempo Real e Embarcados

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] I2C read and write API

[Miklos Maroti]

The Atm128rfa1 has a nbew i2c implementation, which should work with
atm128. You should contact Andras Biro about it. Miklos

On Wed, Feb 13, 2013 at 3:00 AM, Eric Decker cire...@gmail.com wrote:

 oops.

 shouldn't be hard but the h/w is different.   I haven't studied the atm128
 i2c hardware so don't know.

 the key that makes the ti driver funky is the funky ti h/w.   So if the
 atm128 h/w is more straight forward and saner than the driver should be
 saner too.

 It isn't hard.   I'd recommend instrumenting the bus with a logic analyzer
 and just rewrite the driver yourself.

 Studing my driver would be useful as I heavily comment.   My driver is
 production code.


 On Tue, Feb 12, 2013 at 11:30 PM, He Dajiang (I2R) h...@i2r.a-star.edu.sg
 wrote:

 H Eric,

 Greatly appreciate your inputs.
 However, I am using micaz and its my only choice. How difficult is it to
 port ur driver to atm128?

 Best Regards

 
 From: Eric Decker [cire...@gmail.com]
 Sent: Wednesday, 13 February, 2013 1:11:21 PM
 To: He Dajiang (I2R)
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] I2C read and write API

 Without watching the bus itself it is very hard to tell what is going
 wrong.

 The original TinyOS I2C drivers as far as I know were developed without
 looking at the bus traffic.

 I've rewritten the I2C drivers for the x5 series of chips (msp430f5438a,
 6xxx, etc) and have verified under various circumstances the proper
 functioning of the driver using a logic analyzer observing the bus with the
 driver talking to various i2c devices that I'm using.

 The rewrite also includes the implementation of the I2CReg interface which
 provides a non-interrupt driven interface to accessing i2c devices that
 implement a register symantic.  Non-interrupt because for short transactions
 the overhead of interrupts isn't worth it.   Also because of the h/w
 structure of the i2c h/w, interrupts seriously complicates the proper
 functioning of the interface.   (The data path is double buffered, but the
 control path isn't, not sure what they were thinking when they designed
 that, but it is what we've got).

 I sorted out the various issues with the data and control paths using the
 less complicated I2CReg code then applies what I learned to building a
 robust interrupt driven I2CPacket code.  However, there are probable race
 conditions in a heavily loaded system that presents systemic problems for
 the interrupt code because of the fundamental h/w issues with double
 buffered data and single buffered control paths.   So I've fixed I2CPacket
 (interrupt driven) as far as I could and added a robust I2CReg interface
 that should always work.


 This driver is in the tos/chips/msp430/x5xxx/usci-v2 directory of the
 tp-master branch (default) of
 gh:tp-freeforall/prod(tp-master)https://github.com/tp-freeforall/prod.


 Porting the usci-v2 driver to the x2 chips should be reasonably easy.
 Porting to x1 (1611) will be more difficult.   See
 tos/chip/msp430/{00_Chip_Notes,01_Dependencies,02_Serial} for details about
 differences.

 Institute for Infocomm Research disclaimer:  This email is confidential
 and may be privileged. If you are not the intended recipient, please delete
 it and notify us immediately. Please do not copy or use it for any purpose,
 or disclose its contents to any other person. Thank you.

 ___
 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


 ___
 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

Re: [Tinyos-help] RAM usage of Blip 2

[Miklos Maroti]

You need to comment out components RouteCmdC in PppRouterC and
UDPEchoC. Miklos

On Tue, Feb 12, 2013 at 3:12 AM, Anton Hergenröder hergenroe...@kit.edu wrote:
 Hi,

 even if I get Blip 2 compiling for IRIS nodes, the RAM usage is 10kB
 Is there any way to reduce it?

 Best regards,
 Anton


 --
 Dipl.-Inform. Anton Hergenröder

 Institut für Telematik,  KIT   Tel +49 721 608 46394
 Zirkel 2,  D-76131 Karlsruhe   Fax +49 721 608 46789
 http://telematics.tm.kit.edu   Geb. 20.50,  Raum 106

 ___
 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

Re: [Tinyos-help] Why is TinyOS split into tinyos-main and tinyos-release?

[Miklos Maroti]

Hi Guys,

Nothing is set in stone, if the two repository approach does not work,
we can still merge them without any loss of information. Also, you can
set up your git to track BOTH repositories in the same working tree
(and cherry-pick commits to backport fixes).

Miklos

On Sun, Feb 3, 2013 at 12:07 AM, Eric Decker cire...@gmail.com wrote:


 On Sat, Feb 2, 2013 at 7:34 PM, Christopher Wilson
 cwil...@flyingcampdesign.com wrote:

 Why does the TinyOS organization on Github use two separate repositories
 for dev and release?


 Good question.  I'll answer it since I'm the culprit who set up the dual
 repository structure.   There wasn't really a lot of discussion.


 (tinyos-main and tinyos-release)  Is there a reason why there isn't just a
 single repository that uses branches and tags to record releases (instead of
 splitting them into a separate repo)?


 I've been running and watching how repositories on github work via the
 gh:tinyprod/prod and gh:tp-freeforall/prod repositories.   These have been
 tracking and will continue to track the tinyos development mainline.
 tp-freeforall is essentially a development repository and one of the things
 I noticed is it is very confusing for casual or new users of a repository
 when it contains all of the information that multiple branches and
 develoment threads are included.   Certainly some of these feed into the
 release mainline but most do not and feed into a future release.

 So one of the reasons for a release repository is to keep the branching
 structure releated to only the release explicitly.  This minimizes what
 folks have to sort through when looking at the data stored in the
 repository.

 Another associated reason is by limiting what is present in the release
 repository it reduces the amount of data that must be downloaded when the
 repository is remoted.

 Github has a mechanism for specifing the default branch for a repository.
 The default branch on tinyos/tinyos-main (the development repository) is
 master while the default branch on tinyos/tinyos-release is tinyos-2_1_2
 (the current release branch).   So when a new user clones tinyos-release
 they will always get the current release.   We are planning on doing
 interium releases (more often then once every two years).

 If we kept everything together, we'd have to tell people what to explicitly
 get and they would have to understand more about git.

 Further the SHAs on tinyos-release track with the same SHAs in tinyos-main.
 Effectively it is the same as if we'd run a release branch in tinyos-main
 but with the advantages listed above.   It just has to be managed and I'm
 paying attention to that.


 Is there a discussion available somewhere in the mailer archives that
 discusses the thinking behind the way the way the TinyOS github org was
 structured (2 repos instead of 1)?

 Thanks,
 Chris




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

Re: [Tinyos-help] FTSP + LPL + IRIS

[Miklos Maroti]

Hi Gustavo, the apps/tests/TestFtsp/FtspLpl app should work fine, but
you need to modify it to make it compile with IRIS (if I remember
correctly). The radio stack implements LPL and it should just work
fine with FTSP. Miklos

On Tue, Jan 29, 2013 at 12:08 PM, Gustavo Zanatta Bruno
zana...@ic.uff.br wrote:
 Guys,
 you know why the IRIS does not support the implementation of the LPL (Low
 Power Listening) with ftsp (Flooding Time Synchronization Protocol).
 Not implemented, or there is some impediment of hardware?
 I have a network with 60 IRIS and I can not implement a synchronization of
 clocks. In MICAZ works well.




 --
 Atenciosamente:
 Gustavo Zanatta Bruno

 ___
 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

Re: [Tinyos-help] FTSP + LPL + IRIS

[Miklos Maroti]

The problem is that that application is written to use the 32khz timer
which is not available on the IRIS. Most likely you should start from
the apps/tests/TestFtsp/Ftsp application and add the LowPowerListeing
parts from FtspLpl app (basically you need to set the remote and local
wakeup intervals for all messages). Miklos

On Tue, Jan 29, 2013 at 1:31 PM, Gustavo Zanatta Bruno
zana...@ic.uff.br wrote:
 Do you remember what those changes? Even if it is only superficial for me
 not starting from zero.

 Thanks


 2013/1/29 Miklos Maroti mmar...@math.u-szeged.hu

 Hi Gustavo, the apps/tests/TestFtsp/FtspLpl app should work fine, but
 you need to modify it to make it compile with IRIS (if I remember
 correctly). The radio stack implements LPL and it should just work
 fine with FTSP. Miklos

 On Tue, Jan 29, 2013 at 12:08 PM, Gustavo Zanatta Bruno
 zana...@ic.uff.br wrote:
  Guys,
  you know why the IRIS does not support the implementation of the LPL
  (Low
  Power Listening) with ftsp (Flooding Time Synchronization Protocol).
  Not implemented, or there is some impediment of hardware?
  I have a network with 60 IRIS and I can not implement a synchronization
  of
  clocks. In MICAZ works well.
 
 
 
 
  --
  Atenciosamente:
  Gustavo Zanatta Bruno
 
  ___
  Tinyos-help mailing list
  Tinyos-help@millennium.berkeley.edu
  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help




 --
 Atenciosamente:
 Gustavo Zanatta Bruno
 Mestrando em Ciência da Computação
 Pesquisador Laboratório Tempo Sistemas de Tempo Real e Embarcados

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] CC2420 Vs. CC2420X

[Miklos Maroti]

Hi Wasif,

On Thu, Jan 10, 2013 at 10:05 AM, wasif masood rwmas...@gmail.com wrote:

 Thanks Janos, now these stacks seem to have some relevance, see the
 histograms below:

 http://s7.postimage.org/3oh7d6gln/cc2420.png

 http://s9.postimage.org/qswev86xr/cc2420x.png


 Miklos,

 Thanks for the reply but I was referring to timestamping accuracy in Ucmini,
 so the question was does ucmini needs a separate timestamping stack like
 cc2420x or does the current implementation of it does not require that since
 timestamping already works fine on it.

The atmega128rfa1 (the MCU in the ucmini) has a built in time capture
register which is based on a 62.5 KHz 32-bit low power timer that is
always running. No extra configuration is necessary, everything works
by default.

Miklos


 Regards,
 Wasif!


 On Wed, Jan 9, 2013 at 10:45 PM, Janos Sallai janos.sal...@vanderbilt.edu
 wrote:

 Hi Wasif,

 The cc2420x stack should be straightforward to set up with the z1.
 Just follow how it's set up on the telos.

 One thing it needs is a fast SPI bit rate. My suspicion is that the
 SPI on the z1 is configured with 256 or 512 kbps bit rate, though I
 can't confirm this. You might want to take a look at the directory
 tos\platforms\telosa\chips\cc2420x\tmicro to see how I have
 reconfigured the telos clock subsistem to speed up the SPI. Most
 probably, the same has to be done with the z1. Since it has a slightly
 different MCU than the telos, the code in that directory will probably
 have to be altered a bit to work on the z1.

 Janos

 On Wed, Jan 9, 2013 at 2:28 PM, Miklos Maroti mmar...@math.u-szeged.hu
 wrote:
  Hi Wasif!
 
  Ucmini uses the atmega128rfa1 chip (and not the cc2420) and it is
  fully supported in tinyos, just type make ucmini.
 
  Miklos
 
  On Wed, Jan 9, 2013 at 11:55 AM, wasif masood rwmas...@gmail.com
  wrote:
 
  Thanks alot Janos! it seems to work now, it was a clumsy mistake on my
  side.
  Another Questions, make z1 CC2420x doesn't work. Do u ever have any
  experience with that! and also neither for UCMINI.
 
  Regards,
  Wasif!
 
 
  On Wed, Jan 9, 2013 at 4:25 PM, Janos Sallai
  janos.sal...@vanderbilt.edu
  wrote:
 
  Wasif:
 
  Regarding setting the backoff values to 1us in the cc2420x stack: this
  clearly doesn't work, because the code would schedule an alarm 1us in
  the
  future, which is simply not possible. By the time the operation of
  scheduling the alarm completes, that time instant is going to be in
  the
  past, and the alarm will fire after the counter overflows and reaches
  that
  particular value again. To put it in another way: backoff values under
  (approximately) 200 microseconds are not valid.
 
  To get rid of CSMA logic altogether, you need to remove the collision
  avoidance layer altogether and rewire the stack (CC2420XRadioC.nc) as
  I have
  described in my previous email.
 
  Janos
 
 
  On Wed, Jan 9, 2013 at 5:31 AM, wasif masood rwmas...@gmail.com
  wrote:
 
 
  Hi all,
 
  I am trying to measure the message delay on Telosb platform and now
  comparing the CC2420 stack with CC2420X stack. Below are the two
  Histograms
  showing the delay spread of Cc2420 and CC2420X stacks respectively.
  The
  experiment is perfromed for around 1 hr at the same time using two
  different
  frequency channels.
   For CC2420X I have used the TimeSyncAMSendTMicro,uint32_t
  interface
  and have calculated the delay at the receiver end as
 
  delay = call LocalTimeMicro.get() - call
  TimeSyncPacket.eventTime(msg)
 
  and for CC2420 Stack, I have used  TimeSyncAMSend with Milli sec
  precision and have calculated the delay as :
 
  delay = call LocalTimeMilli.get() - call
  TimeSyncPacket.eventTime(msg)
 
  in case of CC2420 stack CCA is disabled and for CC2420X stack, I have
  changed RandomCollisionConfig implementatoin in CC2420XRadioP module
  in such
  a way that all types of backoff values ( Initial, minimum and
  congestion)
  are now just RADIO_ALARM_MICROSEC value (because I couldn't find a
  direct
  way to disable it).
 
  Now, what I observe is a bit interesting since the two histograms
  show a
  completely different delay behaviors, ie. with the Cc2420X stack the
  delay
  ranges between 1 to 13ms, but with CC2420X stack the delay goes from
  70ms to
  150ms. Is this also what any of you experience or is there something
  I am
  missing here?
 
  here are the histograms:
 
  http://s14.postimage.org/55bs7ni0x/Telosb_CC2420x.png
 
  http://s8.postimage.org/8paur8s6d/Telosb_CC2420.png
 
 
  Regards,
  Wasif Masood
 
  ___
  Tinyos-help mailing list
  Tinyos-help@millennium.berkeley.edu
 
  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
 
 
 
 
 
  --
  Wasif Masood
 
  ___
  Tinyos-help mailing list
  Tinyos-help@millennium.berkeley.edu
 
  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
 




 --
 Wasif Masood

Re: [Tinyos-help] CC2420 Vs. CC2420X

[Miklos Maroti]

Hi Wasif!

Ucmini uses the atmega128rfa1 chip (and not the cc2420) and it is
fully supported in tinyos, just type make ucmini.

Miklos

On Wed, Jan 9, 2013 at 11:55 AM, wasif masood rwmas...@gmail.com wrote:

 Thanks alot Janos! it seems to work now, it was a clumsy mistake on my side.
 Another Questions, make z1 CC2420x doesn't work. Do u ever have any
 experience with that! and also neither for UCMINI.

 Regards,
 Wasif!


 On Wed, Jan 9, 2013 at 4:25 PM, Janos Sallai janos.sal...@vanderbilt.edu
 wrote:

 Wasif:

 Regarding setting the backoff values to 1us in the cc2420x stack: this
 clearly doesn't work, because the code would schedule an alarm 1us in the
 future, which is simply not possible. By the time the operation of
 scheduling the alarm completes, that time instant is going to be in the
 past, and the alarm will fire after the counter overflows and reaches that
 particular value again. To put it in another way: backoff values under
 (approximately) 200 microseconds are not valid.

 To get rid of CSMA logic altogether, you need to remove the collision
 avoidance layer altogether and rewire the stack (CC2420XRadioC.nc) as I have
 described in my previous email.

 Janos


 On Wed, Jan 9, 2013 at 5:31 AM, wasif masood rwmas...@gmail.com wrote:


 Hi all,

 I am trying to measure the message delay on Telosb platform and now
 comparing the CC2420 stack with CC2420X stack. Below are the two Histograms
 showing the delay spread of Cc2420 and CC2420X stacks respectively. The
 experiment is perfromed for around 1 hr at the same time using two different
 frequency channels.
  For CC2420X I have used the TimeSyncAMSendTMicro,uint32_t interface
 and have calculated the delay at the receiver end as

 delay = call LocalTimeMicro.get() - call TimeSyncPacket.eventTime(msg)

 and for CC2420 Stack, I have used  TimeSyncAMSend with Milli sec
 precision and have calculated the delay as :

 delay = call LocalTimeMilli.get() - call TimeSyncPacket.eventTime(msg)

 in case of CC2420 stack CCA is disabled and for CC2420X stack, I have
 changed RandomCollisionConfig implementatoin in CC2420XRadioP module in such
 a way that all types of backoff values ( Initial, minimum and congestion)
 are now just RADIO_ALARM_MICROSEC value (because I couldn't find a direct
 way to disable it).

 Now, what I observe is a bit interesting since the two histograms show a
 completely different delay behaviors, ie. with the Cc2420X stack the delay
 ranges between 1 to 13ms, but with CC2420X stack the delay goes from 70ms to
 150ms. Is this also what any of you experience or is there something I am
 missing here?

 here are the histograms:

 http://s14.postimage.org/55bs7ni0x/Telosb_CC2420x.png

 http://s8.postimage.org/8paur8s6d/Telosb_CC2420.png


 Regards,
 Wasif Masood

 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help





 --
 Wasif Masood

 ___
 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

Re: [Tinyos-help] IRIS SPI lockup

[Miklos Maroti]

Hi Guys,

I have committed this SPI fix today (and did the same fix for the
atmega128rfa1 chip).

Best,
Miklos

On Thu, Dec 13, 2012 at 9:12 AM, Miklos Maroti mmar...@math.u-szeged.hu wrote:
 Ok, thanks! I really would like to know how it works in your situation
 before I commit to the mainline. Miklos

 On Wed, Dec 12, 2012 at 11:36 PM, Oldrine Lewis ole...@sutron.com wrote:


 Hi Miklos,

 A few other changes I had made to my program structure, seem to almost 
 eliminiate the possibility of hitting the SPI lock situation. I will have to 
 rerun the older version, of my software to replicate the previous situation 
 to test the fix. I have a release scheduled soon and will get to the test 
 the fix asap.

 Regards,
 Lewis



 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Monday, December 10, 2012 2:55 PM
 To: Oldrine Lewis
 Cc: Eric Decker; tinyos-help@millennium.berkeley.edu; Philip Levis; Janos 
 Sallai
 Subject: Re: [Tinyos-help] IRIS SPI lockup

 Hi Lewis,

 Did you have a chance to check if this fixes your race condition? Does
 the SPI work reliably now?

 Miklos

 On Thu, Dec 6, 2012 at 12:59 PM, Miklos Maroti mmar...@math.u-szeged.hu 
 wrote:
 Excellent. Thanks! Miklos

 On Thu, Dec 6, 2012 at 12:38 PM, Oldrine Lewis ole...@sutron.com wrote:
 Hi Miklos,
 Thanks for the updates. I just downloaded the new files. Will test and 
 keep you posted.
 Thanks,
 Lewis


 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos 
 Maroti
 Sent: Wednesday, December 05, 2012 1:35 PM
 To: Eric Decker
 Cc: Oldrine Lewis; tinyos-help@millennium.berkeley.edu; Philip Levis; 
 Janos Sallai
 Subject: Re: [Tinyos-help] IRIS SPI lockup

 Dear Lewis,

 Thanks for finding this bug. Just to clarify, this happens ONLY if the
 Resource.immediateRequest is called from a task and then from an
 interrupt AND they use the SAME client id. Otherwise, the second call
 will return with fail, no? We have discussed this with Janos Sallai,
 and he says that the best option would be to initialize the SPI with
 the ResourceConfigure interface as Eric has also suggested.

 I have put together a patch that fixes this (includes some typo fixes
 in tep108):

 https://github.com/mmaroti/tinyos/commit/a45de584bd79c0be2853d011c129dc4cb4b6976c

 Lewis, can you please try this out if this works for you? (It actually
 reduces the code too)

 Best,
 Miklos

 On Sat, Dec 1, 2012 at 2:28 PM, Eric Decker cire...@gmail.com wrote:


 On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis ole...@sutron.com wrote:

 Atm128SpiP.nc seems to  make separate calls ( sequentially) to the
 ResourceArbiter and calls for  initializing the SPI.

 In case of Resource.request (), startSpi() is called before the call to
 ResourceArbiter.request(), This ensures that the SPI will always be
 initialized before Resource.granted()  is signaled.


 The problem with Atm128P is it doesn't use the configurator call out from
 the Arbiter.   The whole point behind the configurator call out is to 
 avoid
 this timing window when h/w is configured.

 The reason that the Atm128P use of request/granted works is because it
 cheats.   It looks to see if someother entity is using the device and if 
 not
 it starts the SPI.Then it calls ResourceArbiter.request.   Which means
 that it is touching the resource without really owning it.   Not exactly
 proper.

 Request/Granted should also use the configuration interface.   That is why
 it is there.   It lets the Arbiter configure the hardware properly 
 according
 to what the driver wants prior to switching the resource state to other 
 than
 RES_CONTROLLED which let's interrupts in.



 Incase of Resource.immediateRequest(), the resource is first locked and
 only if the lock succeeds, is the SPI initialized. This sometime leads 
 to an
 uninitialized SPI being used


 Thinking about this as locking the resource is kind of sideways.  It isn't
 like we are asking for a semaphore protecting the device and then if we 
 get
 proceeding.   Rather immediateRequest is responsible for checking to see 
 if
 the device (Resource) and be assigned and if so it will call the
 configurator that should be wired in.   If the device isn't available the
 configurator isn't called and immediateResource return FAIL.


 Agreed.   That is because Atm128SpiP does the startSPI after the return 
 from
 the ArbriterResource.immediateRequest.   That's broken and is what is
 causing your problem.

 ArbiterResource.immediateRequest (in tos/system/ArbiterP.nc) does a 
 callout
 to ResourceConfigure.configure.  This is done prior to setting the state 
 to
 other than RES_CONTROLLED.  It is the switch to other than RES_CONTROLLED
 that lets interrupts get to the device driver.

 Atm128SpiP when making use of immediateRequest, should also have wired in 
 a
 ResourceConfigure wiring which should contain the spiStart.

 In all cases, either after a granted or on return

Re: [Tinyos-help] IRIS SPI lockup

[Miklos Maroti]

Ok, thanks! I really would like to know how it works in your situation
before I commit to the mainline. Miklos

On Wed, Dec 12, 2012 at 11:36 PM, Oldrine Lewis ole...@sutron.com wrote:


 Hi Miklos,

 A few other changes I had made to my program structure, seem to almost 
 eliminiate the possibility of hitting the SPI lock situation. I will have to 
 rerun the older version, of my software to replicate the previous situation 
 to test the fix. I have a release scheduled soon and will get to the test the 
 fix asap.

 Regards,
 Lewis



 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Monday, December 10, 2012 2:55 PM
 To: Oldrine Lewis
 Cc: Eric Decker; tinyos-help@millennium.berkeley.edu; Philip Levis; Janos 
 Sallai
 Subject: Re: [Tinyos-help] IRIS SPI lockup

 Hi Lewis,

 Did you have a chance to check if this fixes your race condition? Does
 the SPI work reliably now?

 Miklos

 On Thu, Dec 6, 2012 at 12:59 PM, Miklos Maroti mmar...@math.u-szeged.hu 
 wrote:
 Excellent. Thanks! Miklos

 On Thu, Dec 6, 2012 at 12:38 PM, Oldrine Lewis ole...@sutron.com wrote:
 Hi Miklos,
 Thanks for the updates. I just downloaded the new files. Will test and keep 
 you posted.
 Thanks,
 Lewis


 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos 
 Maroti
 Sent: Wednesday, December 05, 2012 1:35 PM
 To: Eric Decker
 Cc: Oldrine Lewis; tinyos-help@millennium.berkeley.edu; Philip Levis; Janos 
 Sallai
 Subject: Re: [Tinyos-help] IRIS SPI lockup

 Dear Lewis,

 Thanks for finding this bug. Just to clarify, this happens ONLY if the
 Resource.immediateRequest is called from a task and then from an
 interrupt AND they use the SAME client id. Otherwise, the second call
 will return with fail, no? We have discussed this with Janos Sallai,
 and he says that the best option would be to initialize the SPI with
 the ResourceConfigure interface as Eric has also suggested.

 I have put together a patch that fixes this (includes some typo fixes
 in tep108):

 https://github.com/mmaroti/tinyos/commit/a45de584bd79c0be2853d011c129dc4cb4b6976c

 Lewis, can you please try this out if this works for you? (It actually
 reduces the code too)

 Best,
 Miklos

 On Sat, Dec 1, 2012 at 2:28 PM, Eric Decker cire...@gmail.com wrote:


 On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis ole...@sutron.com wrote:

 Atm128SpiP.nc seems to  make separate calls ( sequentially) to the
 ResourceArbiter and calls for  initializing the SPI.

 In case of Resource.request (), startSpi() is called before the call to
 ResourceArbiter.request(), This ensures that the SPI will always be
 initialized before Resource.granted()  is signaled.


 The problem with Atm128P is it doesn't use the configurator call out from
 the Arbiter.   The whole point behind the configurator call out is to avoid
 this timing window when h/w is configured.

 The reason that the Atm128P use of request/granted works is because it
 cheats.   It looks to see if someother entity is using the device and if 
 not
 it starts the SPI.Then it calls ResourceArbiter.request.   Which means
 that it is touching the resource without really owning it.   Not exactly
 proper.

 Request/Granted should also use the configuration interface.   That is why
 it is there.   It lets the Arbiter configure the hardware properly 
 according
 to what the driver wants prior to switching the resource state to other 
 than
 RES_CONTROLLED which let's interrupts in.



 Incase of Resource.immediateRequest(), the resource is first locked and
 only if the lock succeeds, is the SPI initialized. This sometime leads to 
 an
 uninitialized SPI being used


 Thinking about this as locking the resource is kind of sideways.  It isn't
 like we are asking for a semaphore protecting the device and then if we get
 proceeding.   Rather immediateRequest is responsible for checking to see if
 the device (Resource) and be assigned and if so it will call the
 configurator that should be wired in.   If the device isn't available the
 configurator isn't called and immediateResource return FAIL.


 Agreed.   That is because Atm128SpiP does the startSPI after the return 
 from
 the ArbriterResource.immediateRequest.   That's broken and is what is
 causing your problem.

 ArbiterResource.immediateRequest (in tos/system/ArbiterP.nc) does a callout
 to ResourceConfigure.configure.  This is done prior to setting the state to
 other than RES_CONTROLLED.  It is the switch to other than RES_CONTROLLED
 that lets interrupts get to the device driver.

 Atm128SpiP when making use of immediateRequest, should also have wired in a
 ResourceConfigure wiring which should contain the spiStart.

 In all cases, either after a granted or on return from immediateRequest,
 interrupt should be handled correctly.  It is assumed that the driver is
 prepared.   In the case of Atm128SpiP that isn't the case because it hasn't
 wired in the correct

Re: [Tinyos-help] Problem with different packet frames in Blip2.0 RF230/CC2420

[Miklos Maroti]

Hi Guys,

I am interested in supporting BLIP for all rfxlink platforms. Do you
have ideas why my current tree at

https://github.com/mmaroti/tinyos/tree/blip

does not work? I  particular, how did you reduce the memory/code
usage? If you have ideas how to move your tree closer to mainline,
then I am more than happy to accept patches.

Best,
Miklos

On Mon, Dec 10, 2012 at 8:54 AM, Sebastian Scheibe
sebastian.sche...@tu-ilmenau.de wrote:
 Hello Johny!



 Thank you, this patch solved my problem! Now I'm able to test heterogeneous
 networks with IRIS and Tmote nodes.



 Regards,

 Sebastian Scheibe



 Johny Mattsson jmatts...@dius.com.au wrote:

 On 8 December 2012 04:11, Sebastian Scheibe
 sebastian.sche...@tu-ilmenau.de wrote:

 1) The last byte of the 6LowPAN frame (packet of Iris node) contains zeros
 and as per Wireshark it is an ICMPv6 RPL option (1-Byte padding). Can this
 be the reason, why the base station does not receive the solicitation
 messages of the IRIS node? Why does that byte padding happen? (How) can I
 fix it?


 My bad. The fix is this:

 diff --git a/tos/chips/rf212/RF212BarePacketP.nc
 b/tos/chips/rf212/RF212BarePack
 index 3764047..51459ac 100644
 --- a/tos/chips/rf212/RF212BarePacketP.nc
 +++ b/tos/chips/rf212/RF212BarePacketP.nc
 @@ -12,12 +12,12 @@ implementation

command uint8_t BarePacket.payloadLength(message_t *msg)
{
 -return call RadioPacket.payloadLength(msg);
 +return call RadioPacket.payloadLength(msg)+sizeof(rf212_header_t);
}

command void BarePacket.setPayloadLength(message_t *msg, uint8_t len)
{
 -call RadioPacket.setPayloadLength(msg, len);
 +call RadioPacket.setPayloadLength(msg, len-sizeof(rf212_header_t));
}



 ___
 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

Re: [Tinyos-help] IRIS Radio lockup

[Miklos Maroti]

Hi Oldrine,

I think the code is correct as it is. You have to realize the meaning
of tasklet_async: it means that it is guaranteed that code protected
by tasklet_async will never execute concurrently. In the driver this
is achieved by just setting a flag when an interrupt occurs and then
calling Tasklet.schedule which either 1) calls the Tasklet.run if it
is not already running, or schedules it to be run again when the
pevious one completes, 2) or when TASKLET_IS_TASK is defined then just
posts the task that driver the same Tasklet.run event. Both of these
guarantees that only ONE of those will run at any time. This was the
interaction between interrupt context and tasklet context. You also
have to think about task and tasklet context: look at what
MessageBufferLayerP does: it calls Tasklet.suspend and Tasklet.resume
to make sure that when in the critical tasklet section then no other
code is running.

It is by design that we do not sprinkle code with a lot of atomic,
because there is much more going on than atomic access, you really do
not want to update the state of the WHOLE radio stack concurrently,
even though you could prevent the update of individual registers
concurrently. To make sure that your code works as it should, you
should compile it with both TASKLET_IS_TASK enabled and disabled. If
it gives a warning in either of these cases, then you do not use
tasklets correctly.

Please let me know if this makes sense, or I just really do not see the problem.

Miklos

On Mon, Dec 10, 2012 at 9:28 AM, Oldrine Lewis ole...@sutron.com wrote:
 I have been experiencing some lockups with the radio recently. The problem
 seems to occur when RandomCollisionLayerP::SubSend.send() is called by
 MessageBufferLayerP, but RandomCollisionLayerP  never calls
 RF230DriverHwAckP::RadioSend.send(). MessageBufferLayerP ends up waiting
 forever for SendDone() to be signaled.

 I debugged the code and it seems that the following sequence of events could
 be the likely cause

 The following sequence of events seems to be trigger

 · RandomCollisionLayerP::SubReceive.receive() is signaled by
 RF230DriverHwAckP

 · After executing the line  if( state == STATE_READY ),
 RandomCollisionLayerP::RadioSend.send() Interrupts the receive routine

 · Since state == STATE_READY ,
 RandomCollisionLayerP::RadioSend.send() proceeds and sets, state =
 STATE_TX_PENDING_FIRST

 · RandomCollisionLayerP::SubReceive.receive() resumes and overwrites
 the state ( state = STATE_BARRIER)

 · The radio is essentially locked at this moment



 Solution:

 Protect RandomCollisionLayerP::RadioSend.send() and RandomCollisionLayerP::
 SubReceive.receive() from race conditions



 tasklet_async command error_t RadioSend.send(message_t* msg)

  {

atomic

{

 if( state != STATE_READY || ! call RadioAlarm.isFree() )

 {

  return EBUSY;

 }

state = STATE_TX_PENDING_FIRST;

 }





txMsg = msg;



  call RadioAlarm.wait(getBackoff(call
 Config.getInitialBackoff(msg)));

//post DBG_Snd();

atomic bIsTxRxExec = FALSE;

return SUCCESS;

  }









 tasklet_async event message_t* SubReceive.receive(message_t* msg)

 {



 if( delay  0 )

{

 atomic

 {

 if( state == STATE_READY )

 {

  call RadioAlarm.wait(delay);

  state = STATE_BARRIER;

 }

 else

 {

  state |= STATE_BARRIER;

 }

 }

}







 I have noticed extensive use of the norace keyword, while that itself will
 not cause problems, it might fail to draw attention to variables that need
 more attention




 ___
 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

Re: [Tinyos-help] IRIS SPI lockup

[Miklos Maroti]

Hi Lewis,

Did you have a chance to check if this fixes your race condition? Does
the SPI work reliably now?

Miklos

On Thu, Dec 6, 2012 at 12:59 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote:
 Excellent. Thanks! Miklos

 On Thu, Dec 6, 2012 at 12:38 PM, Oldrine Lewis ole...@sutron.com wrote:
 Hi Miklos,
 Thanks for the updates. I just downloaded the new files. Will test and keep 
 you posted.
 Thanks,
 Lewis


 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Wednesday, December 05, 2012 1:35 PM
 To: Eric Decker
 Cc: Oldrine Lewis; tinyos-help@millennium.berkeley.edu; Philip Levis; Janos 
 Sallai
 Subject: Re: [Tinyos-help] IRIS SPI lockup

 Dear Lewis,

 Thanks for finding this bug. Just to clarify, this happens ONLY if the
 Resource.immediateRequest is called from a task and then from an
 interrupt AND they use the SAME client id. Otherwise, the second call
 will return with fail, no? We have discussed this with Janos Sallai,
 and he says that the best option would be to initialize the SPI with
 the ResourceConfigure interface as Eric has also suggested.

 I have put together a patch that fixes this (includes some typo fixes
 in tep108):

 https://github.com/mmaroti/tinyos/commit/a45de584bd79c0be2853d011c129dc4cb4b6976c

 Lewis, can you please try this out if this works for you? (It actually
 reduces the code too)

 Best,
 Miklos

 On Sat, Dec 1, 2012 at 2:28 PM, Eric Decker cire...@gmail.com wrote:


 On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis ole...@sutron.com wrote:

 Atm128SpiP.nc seems to  make separate calls ( sequentially) to the
 ResourceArbiter and calls for  initializing the SPI.

 In case of Resource.request (), startSpi() is called before the call to
 ResourceArbiter.request(), This ensures that the SPI will always be
 initialized before Resource.granted()  is signaled.


 The problem with Atm128P is it doesn't use the configurator call out from
 the Arbiter.   The whole point behind the configurator call out is to avoid
 this timing window when h/w is configured.

 The reason that the Atm128P use of request/granted works is because it
 cheats.   It looks to see if someother entity is using the device and if not
 it starts the SPI.Then it calls ResourceArbiter.request.   Which means
 that it is touching the resource without really owning it.   Not exactly
 proper.

 Request/Granted should also use the configuration interface.   That is why
 it is there.   It lets the Arbiter configure the hardware properly according
 to what the driver wants prior to switching the resource state to other than
 RES_CONTROLLED which let's interrupts in.



 Incase of Resource.immediateRequest(), the resource is first locked and
 only if the lock succeeds, is the SPI initialized. This sometime leads to 
 an
 uninitialized SPI being used


 Thinking about this as locking the resource is kind of sideways.  It isn't
 like we are asking for a semaphore protecting the device and then if we get
 proceeding.   Rather immediateRequest is responsible for checking to see if
 the device (Resource) and be assigned and if so it will call the
 configurator that should be wired in.   If the device isn't available the
 configurator isn't called and immediateResource return FAIL.


 Agreed.   That is because Atm128SpiP does the startSPI after the return from
 the ArbriterResource.immediateRequest.   That's broken and is what is
 causing your problem.

 ArbiterResource.immediateRequest (in tos/system/ArbiterP.nc) does a callout
 to ResourceConfigure.configure.  This is done prior to setting the state to
 other than RES_CONTROLLED.  It is the switch to other than RES_CONTROLLED
 that lets interrupts get to the device driver.

 Atm128SpiP when making use of immediateRequest, should also have wired in a
 ResourceConfigure wiring which should contain the spiStart.

 In all cases, either after a granted or on return from immediateRequest,
 interrupt should be handled correctly.  It is assumed that the driver is
 prepared.   In the case of Atm128SpiP that isn't the case because it hasn't
 wired in the correct configurator.   Calling startSpi after the call to
 immediateRequest introduces a timing window and as you found out you are
 catching it.


 My C$0.02

 eric




 From: Eric Decker [mailto:cire...@gmail.com]
 Sent: Friday, November 30, 2012 11:38 PM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS SPI lockup





 I thought the ResourceArbiter.immediateRequest symantic was that the
 resource in question should be fully initilized following return from the
 call.   This should follow the same symantic as a ResourceArbiter.Request
 and Granted.   Prior to interrupts being allowed and the Granted being
 signalled the resource is set up.   To be consistent,
 ResourceArbiter.immediateRequest should follow the same symantic.





 If that premise is true.   I would assert that the Atm128SpiP
 implementation has

Re: [Tinyos-help] IRIS SPI lockup

[Miklos Maroti]

Excellent. Thanks! Miklos

On Thu, Dec 6, 2012 at 12:38 PM, Oldrine Lewis ole...@sutron.com wrote:
 Hi Miklos,
 Thanks for the updates. I just downloaded the new files. Will test and keep 
 you posted.
 Thanks,
 Lewis


 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Wednesday, December 05, 2012 1:35 PM
 To: Eric Decker
 Cc: Oldrine Lewis; tinyos-help@millennium.berkeley.edu; Philip Levis; Janos 
 Sallai
 Subject: Re: [Tinyos-help] IRIS SPI lockup

 Dear Lewis,

 Thanks for finding this bug. Just to clarify, this happens ONLY if the
 Resource.immediateRequest is called from a task and then from an
 interrupt AND they use the SAME client id. Otherwise, the second call
 will return with fail, no? We have discussed this with Janos Sallai,
 and he says that the best option would be to initialize the SPI with
 the ResourceConfigure interface as Eric has also suggested.

 I have put together a patch that fixes this (includes some typo fixes
 in tep108):

 https://github.com/mmaroti/tinyos/commit/a45de584bd79c0be2853d011c129dc4cb4b6976c

 Lewis, can you please try this out if this works for you? (It actually
 reduces the code too)

 Best,
 Miklos

 On Sat, Dec 1, 2012 at 2:28 PM, Eric Decker cire...@gmail.com wrote:


 On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis ole...@sutron.com wrote:

 Atm128SpiP.nc seems to  make separate calls ( sequentially) to the
 ResourceArbiter and calls for  initializing the SPI.

 In case of Resource.request (), startSpi() is called before the call to
 ResourceArbiter.request(), This ensures that the SPI will always be
 initialized before Resource.granted()  is signaled.


 The problem with Atm128P is it doesn't use the configurator call out from
 the Arbiter.   The whole point behind the configurator call out is to avoid
 this timing window when h/w is configured.

 The reason that the Atm128P use of request/granted works is because it
 cheats.   It looks to see if someother entity is using the device and if not
 it starts the SPI.Then it calls ResourceArbiter.request.   Which means
 that it is touching the resource without really owning it.   Not exactly
 proper.

 Request/Granted should also use the configuration interface.   That is why
 it is there.   It lets the Arbiter configure the hardware properly according
 to what the driver wants prior to switching the resource state to other than
 RES_CONTROLLED which let's interrupts in.



 Incase of Resource.immediateRequest(), the resource is first locked and
 only if the lock succeeds, is the SPI initialized. This sometime leads to an
 uninitialized SPI being used


 Thinking about this as locking the resource is kind of sideways.  It isn't
 like we are asking for a semaphore protecting the device and then if we get
 proceeding.   Rather immediateRequest is responsible for checking to see if
 the device (Resource) and be assigned and if so it will call the
 configurator that should be wired in.   If the device isn't available the
 configurator isn't called and immediateResource return FAIL.


 Agreed.   That is because Atm128SpiP does the startSPI after the return from
 the ArbriterResource.immediateRequest.   That's broken and is what is
 causing your problem.

 ArbiterResource.immediateRequest (in tos/system/ArbiterP.nc) does a callout
 to ResourceConfigure.configure.  This is done prior to setting the state to
 other than RES_CONTROLLED.  It is the switch to other than RES_CONTROLLED
 that lets interrupts get to the device driver.

 Atm128SpiP when making use of immediateRequest, should also have wired in a
 ResourceConfigure wiring which should contain the spiStart.

 In all cases, either after a granted or on return from immediateRequest,
 interrupt should be handled correctly.  It is assumed that the driver is
 prepared.   In the case of Atm128SpiP that isn't the case because it hasn't
 wired in the correct configurator.   Calling startSpi after the call to
 immediateRequest introduces a timing window and as you found out you are
 catching it.


 My C$0.02

 eric




 From: Eric Decker [mailto:cire...@gmail.com]
 Sent: Friday, November 30, 2012 11:38 PM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS SPI lockup





 I thought the ResourceArbiter.immediateRequest symantic was that the
 resource in question should be fully initilized following return from the
 call.   This should follow the same symantic as a ResourceArbiter.Request
 and Granted.   Prior to interrupts being allowed and the Granted being
 signalled the resource is set up.   To be consistent,
 ResourceArbiter.immediateRequest should follow the same symantic.





 If that premise is true.   I would assert that the Atm128SpiP
 implementation has a bug and should get fixed.



 That would mean that the following as submitted is a work around and not
 an actual fix.





 thoughts?

 On Fri, Nov 30, 2012 at 12:58 PM, Oldrine Lewis ole...@sutron.com

Re: [Tinyos-help] IRIS SPI lockup

[Miklos Maroti]

Dear Lewis,

Thanks for finding this bug. Just to clarify, this happens ONLY if the
Resource.immediateRequest is called from a task and then from an
interrupt AND they use the SAME client id. Otherwise, the second call
will return with fail, no? We have discussed this with Janos Sallai,
and he says that the best option would be to initialize the SPI with
the ResourceConfigure interface as Eric has also suggested.

I have put together a patch that fixes this (includes some typo fixes
in tep108):

https://github.com/mmaroti/tinyos/commit/a45de584bd79c0be2853d011c129dc4cb4b6976c

Lewis, can you please try this out if this works for you? (It actually
reduces the code too)

Best,
Miklos

On Sat, Dec 1, 2012 at 2:28 PM, Eric Decker cire...@gmail.com wrote:


 On Fri, Nov 30, 2012 at 11:13 PM, Oldrine Lewis ole...@sutron.com wrote:

 Atm128SpiP.nc seems to  make separate calls ( sequentially) to the
 ResourceArbiter and calls for  initializing the SPI.

 In case of Resource.request (), startSpi() is called before the call to
 ResourceArbiter.request(), This ensures that the SPI will always be
 initialized before Resource.granted()  is signaled.


 The problem with Atm128P is it doesn't use the configurator call out from
 the Arbiter.   The whole point behind the configurator call out is to avoid
 this timing window when h/w is configured.

 The reason that the Atm128P use of request/granted works is because it
 cheats.   It looks to see if someother entity is using the device and if not
 it starts the SPI.Then it calls ResourceArbiter.request.   Which means
 that it is touching the resource without really owning it.   Not exactly
 proper.

 Request/Granted should also use the configuration interface.   That is why
 it is there.   It lets the Arbiter configure the hardware properly according
 to what the driver wants prior to switching the resource state to other than
 RES_CONTROLLED which let's interrupts in.



 Incase of Resource.immediateRequest(), the resource is first locked and
 only if the lock succeeds, is the SPI initialized. This sometime leads to an
 uninitialized SPI being used


 Thinking about this as locking the resource is kind of sideways.  It isn't
 like we are asking for a semaphore protecting the device and then if we get
 proceeding.   Rather immediateRequest is responsible for checking to see if
 the device (Resource) and be assigned and if so it will call the
 configurator that should be wired in.   If the device isn't available the
 configurator isn't called and immediateResource return FAIL.


 Agreed.   That is because Atm128SpiP does the startSPI after the return from
 the ArbriterResource.immediateRequest.   That's broken and is what is
 causing your problem.

 ArbiterResource.immediateRequest (in tos/system/ArbiterP.nc) does a callout
 to ResourceConfigure.configure.  This is done prior to setting the state to
 other than RES_CONTROLLED.  It is the switch to other than RES_CONTROLLED
 that lets interrupts get to the device driver.

 Atm128SpiP when making use of immediateRequest, should also have wired in a
 ResourceConfigure wiring which should contain the spiStart.

 In all cases, either after a granted or on return from immediateRequest,
 interrupt should be handled correctly.  It is assumed that the driver is
 prepared.   In the case of Atm128SpiP that isn't the case because it hasn't
 wired in the correct configurator.   Calling startSpi after the call to
 immediateRequest introduces a timing window and as you found out you are
 catching it.


 My C$0.02

 eric




 From: Eric Decker [mailto:cire...@gmail.com]
 Sent: Friday, November 30, 2012 11:38 PM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS SPI lockup





 I thought the ResourceArbiter.immediateRequest symantic was that the
 resource in question should be fully initilized following return from the
 call.   This should follow the same symantic as a ResourceArbiter.Request
 and Granted.   Prior to interrupts being allowed and the Granted being
 signalled the resource is set up.   To be consistent,
 ResourceArbiter.immediateRequest should follow the same symantic.





 If that premise is true.   I would assert that the Atm128SpiP
 implementation has a bug and should get fixed.



 That would mean that the following as submitted is a work around and not
 an actual fix.





 thoughts?

 On Fri, Nov 30, 2012 at 12:58 PM, Oldrine Lewis ole...@sutron.com wrote:

 Recently, I have been experiencing frequent lockups with the IRIS nodes. I
 discovered that the lockup occurred in Atm128SpiP.nc, looping infinitely on
 while ( !( SPSR  0x80 ) );



 This bug, manifests if a task calls Resource.immediateRequest(), and an
 interrupt occurs after the task calls ResourceArbiter.immediateRequest[ id
 ]() , but before  calling startSpi(). At this moment, the task already has
 the handle for the resource and hence the ISR can also access the resource.

 If the interrupt tries to use the 

Re: [Tinyos-help] Fwd: TinyOS Java problem in Cygwin

[Miklos Maroti]

Hi Ahmad,

I think your java does not find the tinyos.jar file. This seems like
an installation problem, check that your CLASSPATH is properly set up.
Most likely your java is a windows application (not the openjdk from
cygwin), so your CLASSPATH should contain a windows style path to the
tinyos.jar.  You can also try to specify the jar manually as a command
line argument to java.

Best,
Miklos

On Sun, Dec 2, 2012 at 10:06 PM, Ahmad Muhaimin fevernov...@gmail.com wrote:
 Hi András,

 I try to compile the tinyos.jar file because I got problem with the
 execution of java net.tinyos.tools.Listen in cygwin shell. It gives the
 following error.

 $ java net.tinyos.tools.Listen
 Exception in thread main java.lang.NoClassDefFoundError:
 net/tinyos/packet/ByteSource
 at net.tinyos.tools.Listen.main(Listen.java:53)
 Caused by: java.lang.ClassNotFoundException: net.tinyos.packet.ByteSource
 at java.net.URLClassLoader$1.run(Unknown Source)
 at java.net.URLClassLoader$1.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 ... 1 more

 Then I read guidelines in this website,
 http://www.geoffreylo.com/resources/tinyos-primer/ , step 2. It said that
 tinyos.jar need to be recompiled if I have problem with the tinyosWiki
 tutorial.

 I have append the CLASSPATH environment variable according to the website.

 export CLASSPATH=.;C:/cygwin/opt/tinyos-2.x/support/sdk/java
 export
 CLASSPATH=$CLASSPATH;C:\cygwin\opt\tinyos-2.x\support\sdk\java\tinyos.jar;.




 On Mon, Dec 3, 2012 at 5:11 AM, András Bíró andras.b...@unicomp.hu wrote:

 Hi Ahmad,

 Why would you like to compile tinyos.jar? Tinyos comes with a precompiled
 one at $TOSROOT/support/sdk/java/tinyos.jar

 Andras Biro
 Software Engineer
 Unicomp Ltd.
 http://ucmote.com




 On Sun, Dec 2, 2012 at 2:46 AM, Ahmad Muhaimin fevernov...@gmail.com
 wrote:



 When I try to compile TinyOS.jar file in
 /opt/tinyos-2.x/support/sdk/java, I got the following error, I have try a
 fresh install of Cygwin and TinyOS, still no luck.

 PrintfMsg.java:90: error: unclosed string literal
 s +=   [nx_struct printf_msg 28 100
  ^
 PrintfMsg.java:91: error: illegal start of expression
 =0x+Long.toHexString(get_nx_struct printf_msg 28 100
 ^
 PrintfMsg.java:91: error: hexadecimal numbers must contain at least one
 hexadecimal digit
 =0x+Long.toHexString(get_nx_struct printf_msg 28 100
  ^
 PrintfMsg.java:91: error: unclosed string literal
 =0x+Long.toHexString(get_nx_struct printf_msg 28 100
^
 PrintfMsg.java:91: error: ';' expected
 =0x+Long.toHexString(get_nx_struct printf_msg 28 100
  ^
 PrintfMsg.java:92: error: illegal start of expression
 ())+]\n;
  ^
 PrintfMsg.java:92: error: ';' expected
 ())+]\n;
   ^
 PrintfMsg.java:92: error: not a statement
 ())+]\n;
^
 PrintfMsg.java:111: error: ';' expected
 public static boolean isSigned_nx_struct printf_msg 28 100
 ^
 PrintfMsg.java:111: error: identifier expected
 public static boolean isSigned_nx_struct printf_msg 28 100
^
 PrintfMsg.java:111: error: illegal start of type
 public static boolean isSigned_nx_struct printf_msg 28 100
^
 PrintfMsg.java:111: error: identifier expected
 public static boolean isSigned_nx_struct printf_msg 28 100
   ^
 PrintfMsg.java:112: error: ';' expected
 () {
  ^
 PrintfMsg.java:120: error: ';' expected
 public static boolean isArray_nx_struct printf_msg 28 100
^
 PrintfMsg.java:120: error: identifier expected
 public static boolean isArray_nx_struct printf_msg 28 100
   ^
 PrintfMsg.java:120: error: illegal start of type
 public static boolean isArray_nx_struct printf_msg 28 100
   ^
 PrintfMsg.java:120: error: identifier expected
 public static boolean isArray_nx_struct printf_msg 28 100
  ^
 PrintfMsg.java:121: error: ';' expected
 () {

 I also cannot execute java net.tinyos.tools.Listen, it gives the
 following error.

 $ java net.tinyos.tools.Listen
 Exception in thread main java.lang.NoClassDefFoundError:
 net/tinyos/packet/ByteSource
 at net.tinyos.tools.Listen.main(Listen.java:53)
 Caused by: java.lang.ClassNotFoundException: net.tinyos.packet.ByteSource
 at java.net.URLClassLoader$1.run(Unknown Source)
 at 

Re: [Tinyos-help] fixes for RF230 drivers

[Miklos Maroti]

Dear Oldrine,

On Wed, Nov 7, 2012 at 5:06 PM, Oldrine Lewis ole...@sutron.com wrote:
 I have been doing some testing with the RF230 drivers (IRIS motes)  for a
 while now and ran into a few glitches.

 The drivers usually work fine, but in  a congested RF environment where
 multiple nodes might be trying to transmit at the same time, I noticed that
 quite a few few packets were lost due to buffer underruns.  This might be a
 serious issue because the transmitter will get an Ack  ( if hardware acks
 are enabled) but the receiver application will not get the message. I

This is known, that if the software cannot keep up and the hardware is
sending acks, then we loose packets. As you have mentioned, in this
situation you should not use TASKLET_IS_TASK because in this case
arbitrary time can pass before we service the radio (from task
context).

 experimented with software Acks but found that to be equally shaky in a
 congested environment.

The software ack layer makes sure that the packet passes CRC checks,
we can download it without underrun and we can store it in main memory
buffer, and only then will it issue an ack message. Can you tell why
is the software ack is flaky for you?


 I also noticed that a few  interesting features supported by the radio
 hardware were not exposed to the outside ( through defines in the Makefile),
 that might come handy

 · Frame retries

 · CSMA retries

 · MIN_BE bits in the register CSMA_SEED_1

All true. Using these would not be compatible with the cc2420 driver,
so I did not use them. Also, read all the errata about the chip where
they recommend NOT to use these features and implement it in software.


 Now, back to the original issue, in order to prevent the radio from dropping
 packets due to underruns, as soon as the IRQ interrupt is received, if the
 RF230 state was changed to PLL_ON ( as recommend in the user manual)  and
 then set to RX_AACK_ON after the last byte has been downloaded, will greatly
 reduce buffer underruns. As an added measure of safety I also added an FCS
 check if the IRQ interrupt triggered before I finished downloading the
 entire message. This means that in case an underrun occurs we only discard
 messages that got corrupted (fail the FCS check). I am still in the process
 of testing these changes to make sure that they work as   expected.

Would like to see the code when you think it is ready. Even in this
case you cannot avoid message loss, because of the hardware ack since
the mcu might be in an atomic context and cannot execute the interrupt
routine. Also, with your changes please try out the apps/LinkBench
application which will measure the performance of your changes under
various workloads. In particular, you might increase the number of
dropped packets by increasing the number of acked but not correctly
received packets.

Best,
MIklos


 All the changes are applicable to RF230DriverHwAckP.nc.



 If running in a congested RF environment I do not recommend using the flag
 TASKLET_IS_A_TASK.



 Please feel free to provide suggestions/recommendations



 Thanks,

 Lewis








 ___
 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

Re: [Tinyos-help] help

[Miklos Maroti]

Are you using tinyos-2.x? You should never change the TW_PWR_MASK that
is describing where the transmit power bits are in a register, instead
you should hange the transmit power. In tinyos-2.x you should look at
the TransmitPower interface of the ActiveMessageC component. Miklos

On Thu, Nov 8, 2012 at 11:03 PM, G Mahesh maheshgedd...@iith.ac.in wrote:
 hi sir/madam,
 I am Mahesh Geddada. I am working on iris mote. I have done successfully the
 measurement of RSSI with transmit power, TX_PWR_MASK=0x0F. However, when i
 am trying to change the TX_PWR_MASK in program, (i.e., while i'm trying to
 change the transmit power,,) i'm unable to change the value. Once if I
 change the TX_PWR_MASK value and save it, it is again setting back to the
 default value to 0x0F. I would like to change the 0x0F value to some other
 power values and test the RSSI measurements. So I kindly request you to help
 me in going through this.

 Thank you.

 regards,
 mahesh


 ___
 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

Re: [Tinyos-help] Ucmini program installation via USB

[Miklos Maroti]

Hi  Wasif,

Just compile and program your mote with the make command:

make ucmini install avr109,/dev/ttyUSB0

Best,
Miklos

On Tue, Nov 6, 2012 at 7:39 AM, wasif masood rwmas...@gmail.com wrote:

 Hi All,

 I am trying to get couple of my UCmini devices working but I am having
 problem in writing the image on the devices. I have read the tutorial given
 there:

 http://ucmote.unicomp.hu/images/uploaded/File/UCMote%20mini.pdf and
 accorinding to that, the

 avrdude -cavr109 -pm128rfa1 -P/dev/ttyUSB0 -Uflash:w:main.srec:a -b57600

 command should serve the purpose but I am always getting this error:

 Connecting to programmer: .avrdude: butterfly_recv(): programmer is not
 responding

 Though it is also explained there in the manual, but even after retrying so
 many times - which according to the manual should work, I am having the same
 error again and again.

 Am I missing something here? Can someone please share his/her experience
 here?

 Regards,
 Wasif Masood


 ___
 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

Re: [Tinyos-help] Cygwin compatible net.tinyos.tools.Listen program

[Miklos Maroti]

Yes, You should install cygwin manually, and everything works fine. Miklos

On Wed, Oct 31, 2012 at 2:45 PM, András Bíró andras.b...@unicomp.hu wrote:
 Hi Peeyush,

 I think the CD has some really-really old version of cygwin and tinyos. I
 recommend to install cygwin based on the official documentation
 (http://cygwin.com/install.html), and install the following extra packages:
 gcc
 make
 python
 perl
 rpm

 After that, you can follow the tinyos wiki with the toolchain/tinyos install
 from rpm. It is possible that I forgot one or two essential packages, I once
 wrote it down, but I can't find it.

 Andris




 On Wed, Oct 31, 2012 at 7:52 PM, Peeyush Deshpande peeyushp...@gmail.com
 wrote:

 Hey Thanks,

 I have installed the cygwin through installation CD and just followed the
 instructions.
 It got installed in C:\Crossbow\cygwin and I can see some related
 sub-directories in my C:\Crossbow\cygwin\opt\MoteWorks directory.
 These sub directories are
 apps
 make
 tools
 tos

 Some test applications are present in apps\general\
 ex. cygwin\opt\MoteWorks\apps\general\Blink

 I have tried some of these apps and tutorials. I not able to find a way
 how can I merge my Listen program with this.
 Can you please help.

 Initially I had tried to manually install the TinyOS using below link

 http://docs.tinyos.net/tinywiki/index.php/Installing_TinyOS_2.1.1

 But was not able to download the cygwin-files.zip as the link is not
 active now. So installed from the CD.

 Regards,
 Peeyush



 On Wed, Oct 31, 2012 at 1:27 AM, Miklos Maroti mmar...@math.u-szeged.hu
 wrote:

 If you have installed tinyos on cygwin sucessfully, then you can use
 the java Listen application (i have done it so many times). You need
 to install a 32-bit java even on a 64-bit windows, then get the
 tinyos-tools installed, which should install the toscomm.dll and other
 stuff at the right place. Miklos

 On Tue, Oct 30, 2012 at 2:36 PM, Peeyush Deshpande
 peeyushp...@gmail.com wrote:
  Hi all,
 
  I want to listen to the radio transmissions coming to my Base station
  (XSniffer in Cygwin) program.
  Though I am able to receive and see the data through XSniffer 1.0
  tool, I
  want to parse the data manually and use certain part of message.
 
  In linux version of tiny os we have net.tinyos.tools.Listen.java
  program
  which allows us to modify the code and use it as required, but here I
  am not
  able to find any such program.
  I would like if any one can tell me about any such code available or
  tell me
  is there any way to collect the data from XSniffer 1.0 tool and
  process it
  manually.
 
  Below link tells about Listen.java program. This Listen program makes
  use of
  certain file which are from tinyos directories, so I am not able to
  re-use
  it as well.
 
  http://docs.tinyos.net/tinywiki/index.php/Mote-PC_serial_communication_and_SerialForwarder
 
  Regards,
  Peeyush
 
 
  ___
  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



___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Cygwin compatible net.tinyos.tools.Listen program

[Miklos Maroti]

If you have installed tinyos on cygwin sucessfully, then you can use
the java Listen application (i have done it so many times). You need
to install a 32-bit java even on a 64-bit windows, then get the
tinyos-tools installed, which should install the toscomm.dll and other
stuff at the right place. Miklos

On Tue, Oct 30, 2012 at 2:36 PM, Peeyush Deshpande
peeyushp...@gmail.com wrote:
 Hi all,

 I want to listen to the radio transmissions coming to my Base station
 (XSniffer in Cygwin) program.
 Though I am able to receive and see the data through XSniffer 1.0 tool, I
 want to parse the data manually and use certain part of message.

 In linux version of tiny os we have net.tinyos.tools.Listen.java program
 which allows us to modify the code and use it as required, but here I am not
 able to find any such program.
 I would like if any one can tell me about any such code available or tell me
 is there any way to collect the data from XSniffer 1.0 tool and process it
 manually.

 Below link tells about Listen.java program. This Listen program makes use of
 certain file which are from tinyos directories, so I am not able to re-use
 it as well.
 http://docs.tinyos.net/tinywiki/index.php/Mote-PC_serial_communication_and_SerialForwarder

 Regards,
 Peeyush


 ___
 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

Re: [Tinyos-help] iris radio locked - returns BUSY forever

[Miklos Maroti]

Can you post your code too? Miklos

On Wed, Oct 24, 2012 at 12:53 PM, Oldrine Lewis ole...@sutron.com wrote:
 I have four Iris nodes and all are broadcasting (flooding the network)  a
 message. Each node after receiving a msg waits for a random period and
 re-broadcasts the msg.

 I noticed that after a few seconds the radio stack locks up and returns
 EBUSY forever.

 I put a few debug statements in RadioSend.send() (file =
 RF230DriverLayerP.nc).





 if( cmd != CMD_NONE || state != STATE_RX_ON || ! isSpiAcquired() || radioIrq
 )

 {

  FormatDbgStr(FAT : cmd=%d,st=%d,spAq=%d,rIrq=%d\r\n,cmd,
 state,isSpiAcquired(), radioIrq );

  return EBUSY;

 }

 The error log I got looked like this before the send failed.



 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 It seems that the state and cmd variable somehow get out of sync.

 Other settings in makefile

 CFLAGS += -DTASKLET_IS_TASK



 I am investigating this further and would like to know if anyone has
 experienced something similar



 Thanks in advance.




 ___
 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

Re: [Tinyos-help] iris radio locked - returns BUSY forever

[Miklos Maroti]

I am just wondering how the user level code is written, maybe the bug
is there. If you have a public repository, then I will take a look.
Basically I wanted to see how you receive and resend the message.
Miklos

On Wed, Oct 24, 2012 at 1:04 PM, Oldrine Lewis ole...@sutron.com wrote:
 Hi Miklos,
 Thanks for the speedy response. My entire project is quite large... is there 
 any specific portion/part I can extract  that would be more useful ?

 The portion of code I initially posted is from RF230DriverLayerP.nc

 tasklet_async command error_t RadioSend.send(message_t* msg)
 {
 uint16_t time;
 uint8_t length;
 uint8_t* data;
 uint8_t header;
 uint32_t time32;
 void* timesync;

 if( cmd != CMD_NONE || state != STATE_RX_ON || ! 
 isSpiAcquired() || radioIrq )
 {
 FormatDbgStr(FAT : 
 cmd=%d,st=%d,spAq=%d,rIrq=%d\r\n,cmd, state,isSpiAcquired(), radioIrq );
 return EBUSY;
 }
 ...
 ...
 ...

 }





 Thanks,
 Lewis



 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Wednesday, October 24, 2012 1:58 PM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] iris radio locked - returns BUSY forever

 Can you post your code too? Miklos

 On Wed, Oct 24, 2012 at 12:53 PM, Oldrine Lewis ole...@sutron.com wrote:
 I have four Iris nodes and all are broadcasting (flooding the network)  a
 message. Each node after receiving a msg waits for a random period and
 re-broadcasts the msg.

 I noticed that after a few seconds the radio stack locks up and returns
 EBUSY forever.

 I put a few debug statements in RadioSend.send() (file =
 RF230DriverLayerP.nc).





 if( cmd != CMD_NONE || state != STATE_RX_ON || ! isSpiAcquired() || radioIrq
 )

 {

  FormatDbgStr(FAT : cmd=%d,st=%d,spAq=%d,rIrq=%d\r\n,cmd,
 state,isSpiAcquired(), radioIrq );

  return EBUSY;

 }

 The error log I got looked like this before the send failed.



 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 It seems that the state and cmd variable somehow get out of sync.

 Other settings in makefile

 CFLAGS += -DTASKLET_IS_TASK



 I am investigating this further and would like to know if anyone has
 experienced something similar



 Thanks in advance.




 ___
 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

Re: [Tinyos-help] iris radio locked - returns BUSY forever

[Miklos Maroti]

Interesting. This seems geniune then. Can you please produce a minimal
version of the test (remove everything that is not needed to reproduce
the bug). Do you see any difference if you do not define
TASKLET_IS_TASK? Miklos

On Wed, Oct 24, 2012 at 1:17 PM, Oldrine Lewis ole...@sutron.com wrote:
 Thanks again. I will upload the critical files that deal with TX, RX.

 Another observation I forgot to mention in my previous posts - I did not 
 notice any lockups when I used hardware acks. I noticed the lockups only 
 after using software acks.





 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Wednesday, October 24, 2012 2:11 PM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] iris radio locked - returns BUSY forever

 I am just wondering how the user level code is written, maybe the bug
 is there. If you have a public repository, then I will take a look.
 Basically I wanted to see how you receive and resend the message.
 Miklos

 On Wed, Oct 24, 2012 at 1:04 PM, Oldrine Lewis ole...@sutron.com wrote:
 Hi Miklos,
 Thanks for the speedy response. My entire project is quite large... is there 
 any specific portion/part I can extract  that would be more useful ?

 The portion of code I initially posted is from RF230DriverLayerP.nc

 tasklet_async command error_t RadioSend.send(message_t* msg)
 {
 uint16_t time;
 uint8_t length;
 uint8_t* data;
 uint8_t header;
 uint32_t time32;
 void* timesync;

 if( cmd != CMD_NONE || state != STATE_RX_ON || ! 
 isSpiAcquired() || radioIrq )
 {
 FormatDbgStr(FAT : 
 cmd=%d,st=%d,spAq=%d,rIrq=%d\r\n,cmd, state,isSpiAcquired(), radioIrq );
 return EBUSY;
 }
 ...
 ...
 ...

 }





 Thanks,
 Lewis



 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Wednesday, October 24, 2012 1:58 PM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] iris radio locked - returns BUSY forever

 Can you post your code too? Miklos

 On Wed, Oct 24, 2012 at 12:53 PM, Oldrine Lewis ole...@sutron.com wrote:
 I have four Iris nodes and all are broadcasting (flooding the network)  a
 message. Each node after receiving a msg waits for a random period and
 re-broadcasts the msg.

 I noticed that after a few seconds the radio stack locks up and returns
 EBUSY forever.

 I put a few debug statements in RadioSend.send() (file =
 RF230DriverLayerP.nc).





 if( cmd != CMD_NONE || state != STATE_RX_ON || ! isSpiAcquired() || radioIrq
 )

 {

  FormatDbgStr(FAT : cmd=%d,st=%d,spAq=%d,rIrq=%d\r\n,cmd,
 state,isSpiAcquired(), radioIrq );

  return EBUSY;

 }

 The error log I got looked like this before the send failed.



 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 It seems that the state and cmd variable somehow get out of sync.

 Other settings in makefile

 CFLAGS += -DTASKLET_IS_TASK



 I am investigating this further and would like to know if anyone has
 experienced something similar



 Thanks in advance.




 ___
 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

Re: [Tinyos-help] iris radio locked - returns BUSY forever

[Miklos Maroti]

If I remember correctly, then the documentation says that the radio
can loose PLL lock and then reacquire it later. This is rare but
normal, and should not lock up the driver. Miklos

On Wed, Oct 24, 2012 at 1:51 PM, András Bíró andras.b...@unicomp.hu wrote:
 Hi Guys,

 This is probably irrelevant, but I never had the time to check it: On
 the rf212 radio with RADIO_DEBUG turned on, I get an assert sometimes:
 The driver gets a PLL_LOCK interrupt, with CMD_NONE, STATE_RX_ON, but
 it works after that.
 This bug is probably LPL related, but who knows.

 Andris

 On Wed, Oct 24, 2012 at 8:21 PM, Miklos Maroti mmar...@math.u-szeged.hu 
 wrote:
 Interesting. This seems geniune then. Can you please produce a minimal
 version of the test (remove everything that is not needed to reproduce
 the bug). Do you see any difference if you do not define
 TASKLET_IS_TASK? Miklos

 On Wed, Oct 24, 2012 at 1:17 PM, Oldrine Lewis ole...@sutron.com wrote:
 Thanks again. I will upload the critical files that deal with TX, RX.

 Another observation I forgot to mention in my previous posts - I did not 
 notice any lockups when I used hardware acks. I noticed the lockups only 
 after using software acks.





 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos 
 Maroti
 Sent: Wednesday, October 24, 2012 2:11 PM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] iris radio locked - returns BUSY forever

 I am just wondering how the user level code is written, maybe the bug
 is there. If you have a public repository, then I will take a look.
 Basically I wanted to see how you receive and resend the message.
 Miklos

 On Wed, Oct 24, 2012 at 1:04 PM, Oldrine Lewis ole...@sutron.com wrote:
 Hi Miklos,
 Thanks for the speedy response. My entire project is quite large... is 
 there any specific portion/part I can extract  that would be more useful ?

 The portion of code I initially posted is from RF230DriverLayerP.nc

 tasklet_async command error_t RadioSend.send(message_t* msg)
 {
 uint16_t time;
 uint8_t length;
 uint8_t* data;
 uint8_t header;
 uint32_t time32;
 void* timesync;

 if( cmd != CMD_NONE || state != STATE_RX_ON || ! 
 isSpiAcquired() || radioIrq )
 {
 FormatDbgStr(FAT : 
 cmd=%d,st=%d,spAq=%d,rIrq=%d\r\n,cmd, state,isSpiAcquired(), radioIrq );
 return EBUSY;
 }
 ...
 ...
 ...

 }





 Thanks,
 Lewis



 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos 
 Maroti
 Sent: Wednesday, October 24, 2012 1:58 PM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] iris radio locked - returns BUSY forever

 Can you post your code too? Miklos

 On Wed, Oct 24, 2012 at 12:53 PM, Oldrine Lewis ole...@sutron.com wrote:
 I have four Iris nodes and all are broadcasting (flooding the network)  a
 message. Each node after receiving a msg waits for a random period and
 re-broadcasts the msg.

 I noticed that after a few seconds the radio stack locks up and returns
 EBUSY forever.

 I put a few debug statements in RadioSend.send() (file =
 RF230DriverLayerP.nc).





 if( cmd != CMD_NONE || state != STATE_RX_ON || ! isSpiAcquired() || 
 radioIrq
 )

 {

  FormatDbgStr(FAT : cmd=%d,st=%d,spAq=%d,rIrq=%d\r\n,cmd,
 state,isSpiAcquired(), radioIrq );

  return EBUSY;

 }

 The error log I got looked like this before the send failed.



 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=5,st=5,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 FAT : cmd=0,st=7,spAq=1,rIrq=0

 It seems that the state and cmd variable somehow get out of sync.

 Other settings in makefile

 CFLAGS += -DTASKLET_IS_TASK



 I am investigating this further and would like to know if anyone has
 experienced something similar



 Thanks in advance.




 ___
 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

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] low power, good range, sub GHz transceivers with tinyos

[Miklos Maroti]

Hi John,

RF212 has been successfully used by Branislav Kusy in Australia for
cattle tagging and tracking. As far as I know, it was a dual radio
setup (RF230 and RF212), but you can get RF212 working together with
RFA1 too. They reported around 2 km range. You should search research
papers from CSIRO and cattle tracking.

Best,
Miklos

On Mon, Oct 1, 2012 at 7:44 AM, András Bíró andras.b...@unicomp.hu wrote:
 Hi John,

 There's no gcc support for 8051, and - as far as I know - that's a
 dealbreaker with nesc/tinyos.

 However, we're using Atmel's AT86RF212, and it's quite stable (We
 fixed some bugs in it in the last half year, with the help of Miklos
 Maroti). Unfortunatly, we're in Europe, so we can only use it on the
 868MHz band, with reduced power, but it's still better in some places
 then 2.4GHz. The rf212 is much more integrated then the CC1000 family,
 it does almost anything for 802.15.4 MAC.

 We're also experimenting with Silab's SI4432 radio, which is a low
 level radio, like the CC1000, but the driver is not quite ready yet
 (you can find it at https://github.com/mmaroti/tinyos/tree/si443x),
 but we're going to work a lot with it soon, so it will probably work
 in one-two months. We're also planning to replace it with si446x, but
 I don't know when.

 Both of these radios are using the rfxlink stack.

 Antennas:
 We're using this chip for on-board antennas:
 http://hu.farnell.com/johanson-technology/0868at43a0020e/antenna-ceramic-868mhz/dp/1885493
 Or if we need external antenna, we're usually using standard European
 GSM (900/1800/2100MHz) antennas.
 We prefer omnipolar antennas, so we don't know anything about dipoles


 Andras Biro

 Unicomp Ltd.
 ucmote.unicomp.hu


 On Sun, Sep 30, 2012 at 10:44 PM, John Griessen j...@ecosensory.com wrote:
 I'm going to be making some tinyos nodes for field biologists using
 the old telosb design slightly modified, but after that batch,
 I'd like to make something better for frequencies like the CC1101 
 transceivers use:
 315, 433, 868, and 915 MHz.  A few years ago David Moss emailed this list 
 often with
 talk about using those frequencies, but I don't see him talking lately, is 
 anyone else using
 433 or 915 MHz bands for tinyos?  I'd like to know if so.  I'm wondering how 
 difficult the testing
 and all for a folded dipole for 433 or 915 MHz is and what is out there 
 already.

 In reading about antennas, I like the folded dipole as used on CC2500 
 reference designs since
 it is matched to the transceiver output impedance so you don't need a balun 
 circuit and have
 fewer parts and inherent good coupling to the antenna for true low power.  
 So, another question
 I have is, Is there an open platform based on the cc2500, and if so, it 
 probably uses a MSP430
 for the tinyos code rather than the internal 8051 MCU of the CC2500, and if 
 so, which one?

 The msp430f5438A platform mm5t, (https://github.com/MamMark/mm.git), 
 mentions using
 the CC2420, which costs 2X as much as a CC2500, and doesn't have a folded 
 dipole ref design,
 so not as desirable...


 John Griessen
 --
 Ecosensory
 ___
 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

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] ZigBit Amp (ATZB-A24-UFL) sleep issue

[Miklos Maroti]

Yes, the async timer is running at 1024 Hz, but if you look at the
code, then you will see that its maximum sleep period is around 220
ticks (if I remember correctly), so that is why you will see these odd
times (4 times 220 then one 80) to get the 1024 ticks. Miklos

On Fri, Sep 28, 2012 at 3:01 PM, András Bíró andras.b...@unicomp.hu wrote:
 Hi Guys,

 160uA doesn't seems so much. I don't think it's the amplifier, I
 suspect the timer stack is running on your mote. As far as I remember
 the timer stack is always running on atmega128(1) based motes, and it
 consumes quite a lot of power (it's only an 8 bit counter, and the
 overflow interrupt is inaccurate, so the MCU wakes up for resetting
 the counter about 5 times in a second)
 How do you measure the power consumption? You can clearly see the
 spikes on an oscilloscope, for example this is the power consumption
 of the timer stack on iris:
 https://www.dropbox.com/s/cmidjtple52jvv5/uresj.png

 Andris

 On Tue, Sep 25, 2012 at 6:05 PM, Ugo Colesanti
 colesa...@dis.uniroma1.it wrote:
 Thanks Janos,
 I already tried to change this pin but the power consumption increases
 to approx. 5.5mA (I suppose because the amplifier is activated).
 In particular here is what I made:
 1) I first modified MotePlatformP  adding:
  DDRC = 0x02 ; PORTC = 0x02 ; - power consumption 5.5mA
  DDRC = 0x02 ; PORTC = 0x00 ; - power consumption 160uA
 2) Then I restored the MotePlatformP component and modified NullC by
 adding the same lines in Boot.booted with same results.
 3) I replace those lines with GeneralO interface (it should be the same,
 but just to be sure) and adding GeneralIO.makeOutput; GeneralIO.set() /
 clr() , again, with same results.
 No luck :(

 Ugo

 On 09/25/2012 04:55 PM, Janos Sallai wrote:
 Ugo:

 I think I had the same issue at one point.

 Try setting HplAtm128GeneralIOC.PortC1 to high. Make sure that you set
 it as an output pin first.

 Janos

 On Tue, Sep 25, 2012 at 3:58 AM, Ugo Colesanti
 colesa...@dis.uniroma1.it wrote:
 Hi all,
 I'm using two zigbit amp with tinyos based on the latest eth code found
 on the old tinyos-contrib cvs. Everything seems to work fine (I receive
 and send packets even in LPL) except for one test that I'm used to
 perform on new platforms: I burned the Null application (including the
 ActiveMessageC component as it should be done for IRIS platforms) and
 measured the current draw of the node. Based on the datasheet, the
 expected current draw should be lower than 6uA but in my case I'm not
 able to reach values below 160uA. I forced MCUSleep to return
 ATM128_POWER_DOWN as lowest state and disabled the amplifier pulling low
 the PC1 port of the cpu but nothing changed.
 I noticed that the CPS pin of the SE2413l (the front-end) stays high
 which avoids the fron-end to go in sleep mode and I think that this is
 the main reason of the unexpected power consumption. Unfortunately Atmel
 does not give the schematics of the ZigBit Amp and I have not been able
 to pull this pin low (nor I've been able to understand how bitcloud
 manages it).
 Does anybody have worked on it and could help me?

 Ugo

 p.s. Janos: I've seen an old post where you say that you've worked on
 that module, have you experienced the same issue?

 --
 Ugo Maria Colesanti
 Dipartimento di Ingegneria Informatica, Automatica e Gestionale Antonio 
 Ruberti
 Sapienza Universita' di Roma
 Via Ariosto 25, I floor, room B112
 00185, Rome
 http://wiserver.dis.uniroma1.it/cms/index.php/contacts/13-postdoc/4-ugo-colesanti
 Phone:  +39 06 77274119
 Fax:+39 06 77274002

 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help



 --
 Ugo Maria Colesanti
 Dipartimento di Ingegneria Informatica, Automatica e Gestionale Antonio 
 Ruberti
 Sapienza Universita' di Roma
 Via Ariosto 25, I floor, room B112
 00185, Rome
 http://wiserver.dis.uniroma1.it/cms/index.php/contacts/13-postdoc/4-ugo-colesanti
 Phone:  +39 06 77274119
 Fax:+39 06 77274002

 ___
 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

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] ZigBit Amp (ATZB-A24-UFL) sleep issue

[Miklos Maroti]

You have to include the radio driver even if you do not use it since
that puts the radio into sleep mode. Miklos

On Tue, Sep 25, 2012 at 3:58 AM, Ugo Colesanti
colesa...@dis.uniroma1.it wrote:
 Hi all,
 I'm using two zigbit amp with tinyos based on the latest eth code found
 on the old tinyos-contrib cvs. Everything seems to work fine (I receive
 and send packets even in LPL) except for one test that I'm used to
 perform on new platforms: I burned the Null application (including the
 ActiveMessageC component as it should be done for IRIS platforms) and
 measured the current draw of the node. Based on the datasheet, the
 expected current draw should be lower than 6uA but in my case I'm not
 able to reach values below 160uA. I forced MCUSleep to return
 ATM128_POWER_DOWN as lowest state and disabled the amplifier pulling low
 the PC1 port of the cpu but nothing changed.
 I noticed that the CPS pin of the SE2413l (the front-end) stays high
 which avoids the fron-end to go in sleep mode and I think that this is
 the main reason of the unexpected power consumption. Unfortunately Atmel
 does not give the schematics of the ZigBit Amp and I have not been able
 to pull this pin low (nor I've been able to understand how bitcloud
 manages it).
 Does anybody have worked on it and could help me?

 Ugo

 p.s. Janos: I've seen an old post where you say that you've worked on
 that module, have you experienced the same issue?

 --
 Ugo Maria Colesanti
 Dipartimento di Ingegneria Informatica, Automatica e Gestionale Antonio 
 Ruberti
 Sapienza Universita' di Roma
 Via Ariosto 25, I floor, room B112
 00185, Rome
 http://wiserver.dis.uniroma1.it/cms/index.php/contacts/13-postdoc/4-ugo-colesanti
 Phone:  +39 06 77274119
 Fax:+39 06 77274002

 ___
 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

Re: [Tinyos-help] please help me in finding the default MAC protocol in tinyos for cc2420 and rf230 transceivers.

[Miklos Maroti]

HI!

On Tue, Sep 25, 2012 at 5:38 AM, mamta_b mamtabu...@indiatimes.com wrote:

 hi,

 1) As given in TEP125 that T-Frames is for networks which don't share their
 channel with other wireless architectures, By default, TinyOS 802.15.4
 stacks use I-Frames.. so to use TFRAMES_ENABLED what comments do I need to
 write in my application's makefile?

You can enable tinyos frames by adding this to your makefile

CFLAGS=-DTFRAMES_ENABLED

But you do not want this. If you enable tinyos frames, then ONLY
tinyos frames will be received and transmitted. You want
IFRAMES_ENABLE (it could be called something different) to force the
stack to remove tinyos support. Very bad naming of constants of
course.


 2) In RF230IeeeMessageC there is written in line 27 that You cannot use
 Ieee154MessageC with TFRAMES_ENABLED defined. what does that mean?

If you enable TFRAMES_ENABLED, then only ActiveMessageC is supported.
If you enable IFRAMES_ENABLED, then only IEEE frames are supported. If
you do not enable anything, then both are supported (with added code).

 3) which extra header files do I need to include in my application's module
 file?

Nothing.

 4) If an application is using Receive interface as snoop, what to do with
 that because in RF230Ieee154MessageC there is no wiring component such as
 Receive as snoop like in RF230ActiveMessageC.

Well, snoop is not implemented, but you might be able to implement it
by yourself and modify the driver.

Miklos


 thanks.


 Miklos Maroti wrote:

 Hi!

 On Mon, Sep 24, 2012 at 12:09 AM, mamta_b mamtabu...@indiatimes.com
 wrote:

 hi,

 you mean we can use RF230Ieee154MessageC configuration file instead of
 RF230ActiveMessageC ? and interfaces Ieee154Send, Ieee154Packet instead
 of
 AMSend[am_id_t id], AMPacket etc. present in tos\platforms\iris and
 tos\chips\rf2xx\rf230.

 Yes. No changes are necessary, just use the RF230Ieee154MessageC
 component and the provided interfaces.

 so can you tell me how to use and where to wire these
 interfaces? Actually i am not understanding where to make changes if we
 want
 ieee 802.15.4 mac?

 You have to implement any Ieee 802.15.4 logic on top of
 RF230Ieee154MessageC, but that might not be very efficient because of
 delays in the RF230Ieee154MessageC components. To do anything serious,
 you need to understand how the rf230 (or rfxlink) stack is built up.
 Look at RF230RadioC, and understand what is going on there.

 Miklos

 thanks.


 Miklos Maroti wrote:

 Hi!

 You can use all rfxlink radios (rf230 included) to send IEEE 800.15.4
 frames with short addresses. Basically, it just another packet format
 but underneath it is still the same tinyos specific timing/low power
 listening mac. You can turn off LPL and packet link, then it will be a
 single shot message send or broadcast, but if the channel is very busy
 then the backup time is not the same as in the standard. However, I
 believe that you will be able to communicate with legacy devices if
 they also use the short address format. Of course no beacon mode or
 device discovery is implemented.

 Miklos

 On Wed, Sep 19, 2012 at 11:58 PM, mamta_b mamtabu...@indiatimes.com
 wrote:

 hi Janos, as we know that TKN154 supports only cc2420 transceivers but
 in
 tos/lib/rfxlink/layers i have seen some files named
 Ieee154Messagelayer,
 Ieee154Packetlayer and in tos/chips/rf230/layers too same named files.
 so
 can we change the default MAC in rf230 to IEEE 802.15.4 MAC by using
 these
 files.
 thanks.


 Janos Sallai wrote:

 The default mac for the rf230 is in tos/chips/rf230. It uses the
 rfxlink library, which is in tos/lib/rfxlink.

 Janos

 On Wed, Sep 19, 2012 at 6:21 AM, mamta_b mamtabu...@indiatimes.com
 wrote:

 hi,
 please help me in finding the default MAC protocol in tinyos. i am
 using
 iris and micaz motes. i read somewhere that if no specific MAC is
 used
 then
 default CSMA/CA method is used.. i don't know how to sort this.
 and if we are using IEEE 802.15.4 standard MAC protocol then how can
 we
 choose between the two methods i.e csma/ca or gts(guaranteed time
 slot)?
 I
 want to use IEEE 802.15.4 MAC and PHY layers therefore i need to know
 which
 MAC i am  using.
 thanks.
 --
 View this message in context:
 http://old.nabble.com/please-help-me-in-finding-the-default-MAC-protocol-in-tinyos-for-cc2420-and-rf230-transceivers.-tp34451980p34451980.html
 Sent from the TinyOS - Help mailing list archive at Nabble.com.

 ___
 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


 --
 View this message in context:
 http://old.nabble.com/please-help-me-in-finding-the-default-MAC-protocol-in-tinyos-for-cc2420-and-rf230-transceivers.-tp34451980p34455844.html
 Sent from

Re: [Tinyos-help] ZigBit Amp (ATZB-A24-UFL) sleep issue

[Miklos Maroti]

Ok, if your Null application already includes the ActiveMessageC, then
it will turn off the radio. Then it is something else. Miklos

On Tue, Sep 25, 2012 at 9:35 AM, Ugo Colesanti
colesa...@dis.uniroma1.it wrote:
 Thanks Miklos, but isn't it the ActiveMessageC component that I already
 included?

 Ugo


 On 09/25/2012 04:21 PM, Miklos Maroti wrote:

 You have to include the radio driver even if you do not use it since
 that puts the radio into sleep mode. Miklos

 On Tue, Sep 25, 2012 at 3:58 AM, Ugo Colesanti
 colesa...@dis.uniroma1.it wrote:

 Hi all,
 I'm using two zigbit amp with tinyos based on the latest eth code found
 on the old tinyos-contrib cvs. Everything seems to work fine (I receive
 and send packets even in LPL) except for one test that I'm used to
 perform on new platforms: I burned the Null application (including the
 ActiveMessageC component as it should be done for IRIS platforms) and
 measured the current draw of the node. Based on the datasheet, the
 expected current draw should be lower than 6uA but in my case I'm not
 able to reach values below 160uA. I forced MCUSleep to return
 ATM128_POWER_DOWN as lowest state and disabled the amplifier pulling low
 the PC1 port of the cpu but nothing changed.
 I noticed that the CPS pin of the SE2413l (the front-end) stays high
 which avoids the fron-end to go in sleep mode and I think that this is
 the main reason of the unexpected power consumption. Unfortunately Atmel
 does not give the schematics of the ZigBit Amp and I have not been able
 to pull this pin low (nor I've been able to understand how bitcloud
 manages it).
 Does anybody have worked on it and could help me?

 Ugo

 p.s. Janos: I've seen an old post where you say that you've worked on
 that module, have you experienced the same issue?

 --
 Ugo Maria Colesanti
 Dipartimento di Ingegneria Informatica, Automatica e Gestionale Antonio
 Ruberti
 Sapienza Universita' di Roma
 Via Ariosto 25, I floor, room B112
 00185, Rome

 http://wiserver.dis.uniroma1.it/cms/index.php/contacts/13-postdoc/4-ugo-colesanti
 Phone:  +39 06 77274119
 Fax:+39 06 77274002

 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help



 --
 Ugo Maria Colesanti
 Dipartimento di Ingegneria Informatica, Automatica e Gestionale Antonio
 Ruberti
 Sapienza Universita' di Roma
 Via Ariosto 25, I floor, room B112
 00185, Rome
 http://wiserver.dis.uniroma1.it/cms/index.php/contacts/13-postdoc/4-ugo-colesanti
 Phone:  +39 06 77274119
 Fax:+39 06 77274002

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] please help me in finding the default MAC protocol in tinyos for cc2420 and rf230 transceivers.

[Miklos Maroti]

Hi!

On Mon, Sep 24, 2012 at 12:09 AM, mamta_b mamtabu...@indiatimes.com wrote:

 hi,

 you mean we can use RF230Ieee154MessageC configuration file instead of
 RF230ActiveMessageC ? and interfaces Ieee154Send, Ieee154Packet instead of
 AMSend[am_id_t id], AMPacket etc. present in tos\platforms\iris and
 tos\chips\rf2xx\rf230.

Yes. No changes are necessary, just use the RF230Ieee154MessageC
component and the provided interfaces.

 so can you tell me how to use and where to wire these
 interfaces? Actually i am not understanding where to make changes if we want
 ieee 802.15.4 mac?

You have to implement any Ieee 802.15.4 logic on top of
RF230Ieee154MessageC, but that might not be very efficient because of
delays in the RF230Ieee154MessageC components. To do anything serious,
you need to understand how the rf230 (or rfxlink) stack is built up.
Look at RF230RadioC, and understand what is going on there.

Miklos

 thanks.


 Miklos Maroti wrote:

 Hi!

 You can use all rfxlink radios (rf230 included) to send IEEE 800.15.4
 frames with short addresses. Basically, it just another packet format
 but underneath it is still the same tinyos specific timing/low power
 listening mac. You can turn off LPL and packet link, then it will be a
 single shot message send or broadcast, but if the channel is very busy
 then the backup time is not the same as in the standard. However, I
 believe that you will be able to communicate with legacy devices if
 they also use the short address format. Of course no beacon mode or
 device discovery is implemented.

 Miklos

 On Wed, Sep 19, 2012 at 11:58 PM, mamta_b mamtabu...@indiatimes.com
 wrote:

 hi Janos, as we know that TKN154 supports only cc2420 transceivers but in
 tos/lib/rfxlink/layers i have seen some files named Ieee154Messagelayer,
 Ieee154Packetlayer and in tos/chips/rf230/layers too same named files. so
 can we change the default MAC in rf230 to IEEE 802.15.4 MAC by using
 these
 files.
 thanks.


 Janos Sallai wrote:

 The default mac for the rf230 is in tos/chips/rf230. It uses the
 rfxlink library, which is in tos/lib/rfxlink.

 Janos

 On Wed, Sep 19, 2012 at 6:21 AM, mamta_b mamtabu...@indiatimes.com
 wrote:

 hi,
 please help me in finding the default MAC protocol in tinyos. i am
 using
 iris and micaz motes. i read somewhere that if no specific MAC is used
 then
 default CSMA/CA method is used.. i don't know how to sort this.
 and if we are using IEEE 802.15.4 standard MAC protocol then how can we
 choose between the two methods i.e csma/ca or gts(guaranteed time
 slot)?
 I
 want to use IEEE 802.15.4 MAC and PHY layers therefore i need to know
 which
 MAC i am  using.
 thanks.
 --
 View this message in context:
 http://old.nabble.com/please-help-me-in-finding-the-default-MAC-protocol-in-tinyos-for-cc2420-and-rf230-transceivers.-tp34451980p34451980.html
 Sent from the TinyOS - Help mailing list archive at Nabble.com.

 ___
 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


 --
 View this message in context:
 http://old.nabble.com/please-help-me-in-finding-the-default-MAC-protocol-in-tinyos-for-cc2420-and-rf230-transceivers.-tp34451980p34455844.html
 Sent from the TinyOS - Help mailing list archive at Nabble.com.

 ___
 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


 --
 View this message in context: 
 http://old.nabble.com/please-help-me-in-finding-the-default-MAC-protocol-in-tinyos-for-cc2420-and-rf230-transceivers.-tp34451980p34470747.html
 Sent from the TinyOS - Help mailing list archive at Nabble.com.

 ___
 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

Re: [Tinyos-help] Could not find the main class: net.tinyos.nesc.wiring.WiringCheck.

[Miklos Maroti]

Ok, I see. Is it only for cygwin, or other platforms are also affected? Miklos

On Sun, Sep 23, 2012 at 8:22 PM, András Bíró andras.b...@unicomp.hu wrote:
 Hi Miklos,

 The problem is related to the java part of nesc. The nesc package has
 a jar file, which was probably compiled with jdk7 on some platforms,
 which is probably incompatible with jre6.
 If that's the case, I think we should recompile/repackage nesc.

 Andris

 On Fri, Sep 21, 2012 at 10:24 PM, Miklos Maroti
 mmar...@math.u-szeged.hu wrote:
 Hi Guys,

 So what is the real problem? Is the tinyos-tools not correct, or the
 tinyos package is not compiled with the right java? I have just
 uploaded tinyos-2.1.2-2.1.2-20120921.noarch.rpm here:

 http://tinyos.stanford.edu/tinyos/dists/cygwin/

 Miklos

 On Wed, Sep 12, 2012 at 4:18 PM, András Bíró andras.b...@unicomp.hu wrote:


 On Wed, Sep 12, 2012 at 11:15 PM, András Bíró andras.b...@unicomp.hu
 wrote:

 Hi Gary,

 On Wed, Sep 12, 2012 at 9:54 PM, Gary Helbig ghel...@inbox.com wrote:


 I'm trying to get TinyOS to work on another computer.  This is a Windows7
 machine.


 I'm using Windows 7 Pro x64 as well for cygwin testing.


 The link to cygwin on the TinyOS install page is dead.  The site that it
 linked to had an antique version of cygwin that does not run on Windows7.

 I have found four separate repositories for TinyOS with cygwin:
 http://www.tinyos.net/dist-2.1.0/tinyos/windows/
 http://www.tinyos.net/dist-2.1.0/tools/windows/
 http://tinyos.stanford.edu/tinyos/dists/cygwin/
 http://tinyos.stanford.edu/tinyos-rpms/

 There is some overlap, and some confusion about which files are current.
 It would be nice if that were straightened out.


 Agreed. But tinyos 2.1.2 just released, the documentation is not updated
 yet - so be patient. If you want the newest version, use this:
 http://tinyos.stanford.edu/tinyos/dists/cygwin/


 I made a best-guess as to which files to install.  There is a problem
 installing 'tinyos-tools-1.4.2-20120810.cygwin.i686.rpm' on Windows7 - 
 there
 is a dll (getenv.dll) that Windows will not let you overwrite, even if you
 run as administrator.


 This is one of the two JNI libs. You can live without it, only the java
 SDK needs it. You can install it anytime with tos-install-jni, if it still
 doesn't work, check what the script does, and do it manually.



 I wound up installing three copies of TinyOS - tinyos-2.x, tinyos-2.1.2,
 and tinyos-main.  The difference between 2.1.2 and main is unclear, and 
 2.x
 is the latest version that installs without complaining.


 tinyos-2.1.2 - it's the current stable. It's very similar to the current
 svn trunk, becouse we're just after release.
 tinyos-main - I guess you're refering to the tinyos svn. It's the official
 development tree, but usually it's quite stable
 tinyos-2.x - I'm not sure what is this. The problem is you're refering to
 packages with the directory names, which could be the same. For example, 
 I'm
 using a lot of development tree, and just symlink the active to
 /opt/tinyos-2.x




 At long last I try a sample build (app/Blink) to see if the install
 worked.  Nope:

 $ make micaz
 mkdir -p build/micaz
 compiling BlinkAppC to a micaz binary
 ncc -o build/micaz/main.exe  -Os -fnesc-separator=__ -Wall -Wshadow
 -Wnesc-all -target=micaz -fnesc-cfile=build/micaz/app.c -board=micasb
 -DDEFINED_TOS_AM_GROUP=0x22 --param max-inline-insns-single=10
 -DIDENT_APPNAME=\BlinkAppC\ -DIDENT_USERNAME=\gahelbig\
 -DIDENT_HOSTNAME=\2UA2061DGW\ -DIDENT_USERHASH=0x323af339L
 -DIDENT_TIMESTAMP=0x5050dfaaL -DIDENT_UIDHASH=0xa406223bL 
 -fnesc-dump=wiring
 -fnesc-dump='interfaces(!abstract())' 
 -fnesc-dump='referenced(interfacedefs,
 components)' -fnesc-dumpfile=build/micaz/wiring-check.xml BlinkAppC.nc -lm
 java.lang.UnsupportedClassVersionError:
 net/tinyos/nesc/wiring/WiringCheck : Unsupported major.minor version 51.0
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClassCond(Unknown Source)
 at java.lang.ClassLoader.defineClass(Unknown Source)
 at java.security.SecureClassLoader.defineClass(Unknown Source)
 at java.net.URLClassLoader.defineClass(Unknown Source)
 at java.net.URLClassLoader.access$000(Unknown Source)
 at java.net.URLClassLoader$1.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 Could not find the main class: net.tinyos.nesc.wiring.WiringCheck.
 Program will exit.
 Exception in thread main
 /opt/tinyos-2.1.2/support/make/avr/avr.rules:148: recipe for target `exe0'
 failed
 make: *** [exe0] Error 1


 This seems like you're using an old JRE. What exactly is your java
 version? Probably David Gay generated nesc.jar

Re: [Tinyos-help] Could not find the main class: net.tinyos.nesc.wiring.WiringCheck.

[Miklos Maroti]

Hi Guys,

So what is the real problem? Is the tinyos-tools not correct, or the
tinyos package is not compiled with the right java? I have just
uploaded tinyos-2.1.2-2.1.2-20120921.noarch.rpm here:

http://tinyos.stanford.edu/tinyos/dists/cygwin/

Miklos

On Wed, Sep 12, 2012 at 4:18 PM, András Bíró andras.b...@unicomp.hu wrote:


 On Wed, Sep 12, 2012 at 11:15 PM, András Bíró andras.b...@unicomp.hu
 wrote:

 Hi Gary,

 On Wed, Sep 12, 2012 at 9:54 PM, Gary Helbig ghel...@inbox.com wrote:


 I'm trying to get TinyOS to work on another computer.  This is a Windows7
 machine.


 I'm using Windows 7 Pro x64 as well for cygwin testing.


 The link to cygwin on the TinyOS install page is dead.  The site that it
 linked to had an antique version of cygwin that does not run on Windows7.

 I have found four separate repositories for TinyOS with cygwin:
 http://www.tinyos.net/dist-2.1.0/tinyos/windows/
 http://www.tinyos.net/dist-2.1.0/tools/windows/
 http://tinyos.stanford.edu/tinyos/dists/cygwin/
 http://tinyos.stanford.edu/tinyos-rpms/

 There is some overlap, and some confusion about which files are current.
 It would be nice if that were straightened out.


 Agreed. But tinyos 2.1.2 just released, the documentation is not updated
 yet - so be patient. If you want the newest version, use this:
 http://tinyos.stanford.edu/tinyos/dists/cygwin/


 I made a best-guess as to which files to install.  There is a problem
 installing 'tinyos-tools-1.4.2-20120810.cygwin.i686.rpm' on Windows7 - there
 is a dll (getenv.dll) that Windows will not let you overwrite, even if you
 run as administrator.


 This is one of the two JNI libs. You can live without it, only the java
 SDK needs it. You can install it anytime with tos-install-jni, if it still
 doesn't work, check what the script does, and do it manually.



 I wound up installing three copies of TinyOS - tinyos-2.x, tinyos-2.1.2,
 and tinyos-main.  The difference between 2.1.2 and main is unclear, and 2.x
 is the latest version that installs without complaining.


 tinyos-2.1.2 - it's the current stable. It's very similar to the current
 svn trunk, becouse we're just after release.
 tinyos-main - I guess you're refering to the tinyos svn. It's the official
 development tree, but usually it's quite stable
 tinyos-2.x - I'm not sure what is this. The problem is you're refering to
 packages with the directory names, which could be the same. For example, I'm
 using a lot of development tree, and just symlink the active to
 /opt/tinyos-2.x




 At long last I try a sample build (app/Blink) to see if the install
 worked.  Nope:

 $ make micaz
 mkdir -p build/micaz
 compiling BlinkAppC to a micaz binary
 ncc -o build/micaz/main.exe  -Os -fnesc-separator=__ -Wall -Wshadow
 -Wnesc-all -target=micaz -fnesc-cfile=build/micaz/app.c -board=micasb
 -DDEFINED_TOS_AM_GROUP=0x22 --param max-inline-insns-single=10
 -DIDENT_APPNAME=\BlinkAppC\ -DIDENT_USERNAME=\gahelbig\
 -DIDENT_HOSTNAME=\2UA2061DGW\ -DIDENT_USERHASH=0x323af339L
 -DIDENT_TIMESTAMP=0x5050dfaaL -DIDENT_UIDHASH=0xa406223bL -fnesc-dump=wiring
 -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs,
 components)' -fnesc-dumpfile=build/micaz/wiring-check.xml BlinkAppC.nc -lm
 java.lang.UnsupportedClassVersionError:
 net/tinyos/nesc/wiring/WiringCheck : Unsupported major.minor version 51.0
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClassCond(Unknown Source)
 at java.lang.ClassLoader.defineClass(Unknown Source)
 at java.security.SecureClassLoader.defineClass(Unknown Source)
 at java.net.URLClassLoader.defineClass(Unknown Source)
 at java.net.URLClassLoader.access$000(Unknown Source)
 at java.net.URLClassLoader$1.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 Could not find the main class: net.tinyos.nesc.wiring.WiringCheck.
 Program will exit.
 Exception in thread main
 /opt/tinyos-2.1.2/support/make/avr/avr.rules:148: recipe for target `exe0'
 failed
 make: *** [exe0] Error 1


 This seems like you're using an old JRE. What exactly is your java
 version? Probably David Gay generated nesc.jar with java 7...


 On second thought, this wasn't David's mistake, but the packager's, who was
 eigther Philip Lewis, Miklos Maroti or me. If I was the packager, I
 defenetly compiled it with newest java7.



 Andris


 Results are identical in the other two trees, and I remembered to set all
 the TOS environment variables between tries.

 Please help me get this running,
 Gary.

 (\___/)
 (='.'=) This is Bunny. Copy and paste bunny into your
 ()_() signature to help him gain world domination

Re: [Tinyos-help] please help me in finding the default MAC protocol in tinyos for cc2420 and rf230 transceivers.

[Miklos Maroti]

Hi!

You can use all rfxlink radios (rf230 included) to send IEEE 800.15.4
frames with short addresses. Basically, it just another packet format
but underneath it is still the same tinyos specific timing/low power
listening mac. You can turn off LPL and packet link, then it will be a
single shot message send or broadcast, but if the channel is very busy
then the backup time is not the same as in the standard. However, I
believe that you will be able to communicate with legacy devices if
they also use the short address format. Of course no beacon mode or
device discovery is implemented.

Miklos

On Wed, Sep 19, 2012 at 11:58 PM, mamta_b mamtabu...@indiatimes.com wrote:

 hi Janos, as we know that TKN154 supports only cc2420 transceivers but in
 tos/lib/rfxlink/layers i have seen some files named Ieee154Messagelayer,
 Ieee154Packetlayer and in tos/chips/rf230/layers too same named files. so
 can we change the default MAC in rf230 to IEEE 802.15.4 MAC by using these
 files.
 thanks.


 Janos Sallai wrote:

 The default mac for the rf230 is in tos/chips/rf230. It uses the
 rfxlink library, which is in tos/lib/rfxlink.

 Janos

 On Wed, Sep 19, 2012 at 6:21 AM, mamta_b mamtabu...@indiatimes.com
 wrote:

 hi,
 please help me in finding the default MAC protocol in tinyos. i am using
 iris and micaz motes. i read somewhere that if no specific MAC is used
 then
 default CSMA/CA method is used.. i don't know how to sort this.
 and if we are using IEEE 802.15.4 standard MAC protocol then how can we
 choose between the two methods i.e csma/ca or gts(guaranteed time slot)?
 I
 want to use IEEE 802.15.4 MAC and PHY layers therefore i need to know
 which
 MAC i am  using.
 thanks.
 --
 View this message in context:
 http://old.nabble.com/please-help-me-in-finding-the-default-MAC-protocol-in-tinyos-for-cc2420-and-rf230-transceivers.-tp34451980p34451980.html
 Sent from the TinyOS - Help mailing list archive at Nabble.com.

 ___
 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


 --
 View this message in context: 
 http://old.nabble.com/please-help-me-in-finding-the-default-MAC-protocol-in-tinyos-for-cc2420-and-rf230-transceivers.-tp34451980p34455844.html
 Sent from the TinyOS - Help mailing list archive at Nabble.com.

 ___
 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

Re: [Tinyos-help] How to reduce power consumption in the ATM1281

[Miklos Maroti]

Hi Sergio,

The timer periodically wakes the mote up (to run tasks and to maintain
time), this can add up to some thing, since it wakes up 128 times per
second (if I remember correctly), maybe only 4 times, depending on the
prescaler. I would try to augment McuSleepC to see how deeppower state
it goes into.

Miklos

On Wed, Aug 29, 2012 at 5:59 PM, Sergio Gonzalez serg...@ece.ubc.ca wrote:
 Hi Janos,

 Yes, I already did that according comments of another (older) thread.
 The consumption is above 10 mA when the radio is on, but when I turn off
 the radio and the UART, then the consumption drops to 0.4 mA.
 ActiveMessageC is included, but not wired. I've got my radio code wired
 to RF230ActiveMessageC instead.

 I wonder whether there's a similar situation with the ADC and whether I
 need to include SomeADCComponentC to achieve the same result. Also, I
 know that at least one of the UART ports is off for sure, but I can't
 tell whether the USART port that I use to program the device via ISP is
 off as well.

 Thanks,

 Sergio


 On 12-08-29 08:30 AM, Janos Sallai wrote:
 Sergio:

 Just a wild guess: when the RF230 is turned on, it's not in its lowest
 power state. You have to explicitly include ActiveMessageC in your
 application to allow for the RF230 init code to run, which will put
 the radio chip into its lowest power state.

 Janos

 On Wed, Aug 29, 2012 at 12:17 AM, Sergio Gonzalez serg...@ece.ubc.ca wrote:
 Hello,

 I've been able to somewhat reduce the power consumed by an ATM1281-based
 Zigbit device by switching off the radio and the UART port (via
 SerialActiveMessageC) during periods of inactivity, but I've been unable
 to get below 0.4 mA. I tried to explicitly disable the I2C bus as well
 as, but there was no change. The corresponding fuses for the watchdog
 timer, the brownout detector and the on-chip debugger are already
 (un)programmed. I also tried lowering the MCU's clock frequency, but
 anything other than 8 Mhz won't compile. Stopping the ADC converter does
 not seem to make any difference either. Has anybody had better luck with
 an Iris, Meshbean, or any other device with the ATM1281/RF230 combo?

 Thanks,

 Sergio

 ___
 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
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] How to reduce power consumption in the ATM1281

[Miklos Maroti]

Hi Sergio,

I think what you wrote shows that the consumption might come from the
light sensor. Of course it is not enough to turn off the ADC, you also
have to power down the light sensor with some power pins and possibly
you have to pull up or down the ADC pins to prevent leakage.

Miklos

On Thu, Aug 30, 2012 at 3:56 AM, Sergio Gonzalez serg...@ece.ubc.ca wrote:
 Hi Miklos,

 I physically removed the light sensor that I was monitoring through an ADC
 line, and the consumption dropped to 37 uA (I've also got an accelerometer
 draining ~ 25 uA). So, for some reason the MCU won't go into low power mode
 even if I stop the ADC. I'll dig deeper to try and see why this is
 happening.

 Thanks,

 Sergio



 On 29/08/2012 10:12 AM, Miklos Maroti wrote:

 Hi Sergio,

 The timer periodically wakes the mote up (to run tasks and to maintain
 time), this can add up to some thing, since it wakes up 128 times per
 second (if I remember correctly), maybe only 4 times, depending on the
 prescaler. I would try to augment McuSleepC to see how deeppower state
 it goes into.

 Miklos

 On Wed, Aug 29, 2012 at 5:59 PM, Sergio Gonzalez serg...@ece.ubc.ca
 wrote:

 Hi Janos,

 Yes, I already did that according comments of another (older) thread.
 The consumption is above 10 mA when the radio is on, but when I turn off
 the radio and the UART, then the consumption drops to 0.4 mA.
 ActiveMessageC is included, but not wired. I've got my radio code wired
 to RF230ActiveMessageC instead.

 I wonder whether there's a similar situation with the ADC and whether I
 need to include SomeADCComponentC to achieve the same result. Also, I
 know that at least one of the UART ports is off for sure, but I can't
 tell whether the USART port that I use to program the device via ISP is
 off as well.

 Thanks,

 Sergio


 On 12-08-29 08:30 AM, Janos Sallai wrote:

 Sergio:

 Just a wild guess: when the RF230 is turned on, it's not in its lowest
 power state. You have to explicitly include ActiveMessageC in your
 application to allow for the RF230 init code to run, which will put
 the radio chip into its lowest power state.

 Janos

 On Wed, Aug 29, 2012 at 12:17 AM, Sergio Gonzalez serg...@ece.ubc.ca
 wrote:

 Hello,

 I've been able to somewhat reduce the power consumed by an
 ATM1281-based
 Zigbit device by switching off the radio and the UART port (via
 SerialActiveMessageC) during periods of inactivity, but I've been
 unable
 to get below 0.4 mA. I tried to explicitly disable the I2C bus as well
 as, but there was no change. The corresponding fuses for the watchdog
 timer, the brownout detector and the on-chip debugger are already
 (un)programmed. I also tried lowering the MCU's clock frequency, but
 anything other than 8 Mhz won't compile. Stopping the ADC converter
 does
 not seem to make any difference either. Has anybody had better luck
 with
 an Iris, Meshbean, or any other device with the ATM1281/RF230 combo?

 Thanks,

 Sergio

 ___
 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


___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] ACK problem between TelosB and Iris in Low Power Listening

[Miklos Maroti]

Hi! What if you enable HW ACKS both on the CC2420 and the RF230 (see
the readme in chips/rf230 or lib/rfxlink)? Miklos

On Wed, Aug 15, 2012 at 5:48 AM, Haas.1, H. de
h.d.haa...@student.tue.nl wrote:
 Hello,

 Does anybody knows how fix to ACK problem between TelosB and Iris in Low 
 Power listening. I have implemented the standard IPBasestation and UDPEchoC 
 applications with LPL enabled. The solutions mentioned in 
 http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2009-April/039603.html
  do not solve the problem.
 Things I have tried:
 -   Enabling CC2420_HW_ACKNOWLEDGEMENTS in BaseStation mode
 -   Changing SOFTWAREACK_TIMEOUT to 1000, 1600, 2400, or 3000 on Iris 
 mode.
 All combinations result in a 50-80% packet loss with ping6. While TelosB to 
 TelosB communication has a packet loss of 0-5% with the same application.
 Is there a way to fix this problem?

 Regards,
 Hugo

 ___
 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

Re: [Tinyos-help] is this a bug of FTSP? Re: extremely large skew of 56% in FTSP

[Miklos Maroti]

Hi Xiaohui,

Very nice detective work. I think I understand the problem and I
understand your solution. FTSP tries to maintain the continuity of
time when switching between roots, that is why the root keeps the
previous offset and skew values (and does not update them). You
however essentially reset the offset to 0 and skew to 1, so there can
be an abrupt change. This becomes problematic if two nodes switch
being the root from time to time (e.g. one of them has bad
connectivity).

I think the original algorithm has its problems, but so does your
proposed solution. I think the large skew values are the result of
very unstable clocks at startup, no? What if you delay the start of
the FTSP by a few seconds? An alternative solution would be to slowly
decrease the skew of the root when it recalculates its base point.
That would slowly eliminate the large skews.

Miklos

On Fri, Jul 13, 2012 at 2:32 PM, Xiaohui Liu whu...@gmail.com wrote:
 Hi,

 Finally, I found out why this can happen.

 Suppose A is the node with smallest id in the network and is going to be the
 sync root eventually. At the beginning, it boots up later than some nodes,
 which become roots prior to A. A few reference points from these roots make
 into A's regression table. Because ftsp is still in the process of
 convergence, the skew based on these few entries can be abnormal. What's
 worse, root broadcasts this skew even if the number of entries are less than
 ENTRY_SEND_LIMIT as  shown below.
 if( numEntries  ENTRY_SEND_LIMIT  outgoingMsg-rootID !=
 TOS_NODE_ID ){
 ++heartBeats;
 state = ~STATE_SENDING;
 }
 else if( call Send.send(AM_BROADCAST_ADDR, outgoingMsgBuffer,
 TIMESYNCMSG_LEN, localTime ) != SUCCESS ){
 state = ~STATE_SENDING;
 signal TimeSyncNotify.msg_sent();
 }
 Gradually, every node synchronizes with root and gets the same abnormal
 skew. This is because local clock rates of all nodes are very close with
 some small skew (tens out of a million in my tests) and after sync, the
 global clocks keep pace with the root's local clock.

 I fixed this by making sure root's global time is always equal to its local
 time as follows, regardless of the skew computed from regression table:
 async command error_t GlobalTime.local2Global(uint32_t *time)
 {
  if (outgoingMsg-rootID != TOS_NODE_ID)
 *time += offsetAverage + (int32_t)(skew * (int32_t)(*time -
 localAverage));
 return is_synced();
 }
 I repeated my tests 6 times and ftsp runs like a charm now. The abnormal
 skew never shows up, even root's skew based on regression table can still be
 large.

 On Thu, Jul 12, 2012 at 10:01 PM, Xiaohui Liu whu...@gmail.com wrote:

 Hi,

 I test ftsp alone and find some abnormal skews. One instance is skew of
 23% and the corresponding regression table is:
 localtime  offset
 5327769  1120379
 59822981271252
 5888794 1249698
 5795290 1228145
 5722274 1211314
 5608281 1185039
 5514777 1163486
 5421273 1141932
 The regression figure is here. Almost every of the 130 nodes is returning
 skew of 23% !

 Another is 183%, regression table:
 1474355  450851
 1376050  277030
 1327295  -9142
 1229783  43734

 Any hint on where the issue may arise from, packet-level synchronization
 or packet timestamping? Thanks for your attention.


 On Tue, Jul 10, 2012 at 4:29 PM, Eric Decker cire...@gmail.com wrote:

 It is very difficult to tell what is going on from the outside.

 what I've done with complicated situations like this is add
 instrumentation (logging) of various state in nodes.

 that is what I would recommend.   I don't see anyway around it.


 On Tue, Jul 10, 2012 at 1:16 PM, Xiaohui Liu whu...@gmail.com wrote:

 Hi everyone,

 I'm using FTSP of T32khz accuracy (i.e., TimeSync32kC) to synchronize a
 network consisting of 130 telosB motes. Multiple runs are tested and skews
 after synchronization are recorded. In some runs, the skew is incredibly
 large, up to 56%. In others, it is below 0.0045%, which can be regarded as
 normal. Does anyone know what might be causing this issue? One observation
 is that regardless of the skew in a run, all nodes report almost identical
 skews.

 Your reply will be greatly appreciated.

 --
 -Xiaohui Liu

 ___
 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





 --
 -Xiaohui Liu




 --
 -Xiaohui Liu
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] TinyOS Iris Blip UDPEcho

[Miklos Maroti]

Hi Anand,

On Wed, Jun 6, 2012 at 6:43 AM, S.V.R. Anand an...@ece.iisc.ernet.in wrote:
 Hi Miklos Maroti,

 I am using mmaroti-tinyos-b0567be distribution. After doing 'make iris
 blip' for UDPEcho application, and writing the image using avrdude, I
 see that the application is not even launching. This I confirmed by
 using Leds in the booted function. The avr-gcc compiler version is
 4.5.1.

 The output of the console messages is appended below. From the messages
 I noticed that the memory usage shown is as below.

 compiled UDPEchoC to build/iris/main.exe
           48650 bytes in ROM
           10953 bytes in RAM

 Since Iris has 8MB RAM, could it be causing the problem ? Can you
 suggest how I can go about debugging ? I will be very happy to provide
 you with more information in this process.

Yes, indeed the 8KB RAM is definitely a problem. I never used BLIP
myself, so I do not know if it works, just made sure that it compiles
and the RF230 layer is compatible with BLIP. I have seen on
tinyos-help some discussion on how to reduce the memory requirement of
BLIP, maybe others can help with that.

Best,
Miklos


 Thanks

 Regards
 Anand





 ---
 mkdir -p build/iris

 compiling UDPEchoC to a iris binary
 ncc -o build/iris/main.exe  -Os -DRPL_ROUTING -DRPL_STORING_MODE
 -I/opt/tinyos-2.x/tos/lib/net/rpl -DBLIP_DERIVE_SHORTADDRS
 -DIN6_PREFIX=\fec0::\ -DNEW_PRINTF_SEMANTICS -DPRINTFUART_ENABLED
 -DCC2420_HW_ACKNOWLEDGEMENTS  -DCC2420_HW_ADDRESS_RECOGNITION
 -DPACKET_LINK
 -DTOSH_DATA_LENGTH=112 -I/opt/tinyos-2.x/tos/lib/net/
 -I/opt/tinyos-2.x/tos/lib/printf/ -I/opt/tinyos-2.x/support/sdk/c/blip/
 -I/opt/tinyos-2.x/tos/lib/net/blip/
 -I/opt/tinyos-2.x/tos/lib/net/blip/interfaces/
 -I/opt/tinyos-2.x/tos/lib/net/blip/nwprog/
 -I/opt/tinyos-2.x/tos/lib/net/blip/shell/
 -I/opt/tinyos-2.x/tos/lib/net/blip/serial/
 -I/opt/tinyos-2.x/tos/lib/net/blip/platform/
 -I/opt/tinyos-2.x/tos/lib/net/blip/icmp/
 -I/opt/tinyos-2.x/tos/lib/net/blip/dhcp/
 /opt/tinyos-2.x/support/sdk/c/blip/lib6lowpan/iovec.c
 /opt/tinyos-2.x/support/sdk/c/blip/lib6lowpan/in_cksum.c
 /opt/tinyos-2.x/support/sdk/c/blip/lib6lowpan/ip_malloc.c
 /opt/tinyos-2.x/support/sdk/c/blip/lib6lowpan/utility.c
 /opt/tinyos-2.x/tos/lib/net/blip/table.c -fnesc-separator=__ -Wall
 -Wshadow
 -Wnesc-all -target=iris -fnesc-cfile=build/iris/app.c -board=micasb
 -DDEFINED_TOS_AM_GROUP=0x22 --param max-inline-insns-single=10
 -Ibuild/iris
 -DRF230_DEF_CHANNEL=11 -DIDENT_APPNAME=\UDPEchoC\ -DIDENT_USERNAME=
 \root\
 -DIDENT_HOSTNAME=\netarch-server.\ -DIDENT_USERHASH=0x26eeb1d9L
 -DIDENT_TIMESTAMP=0x4fcedccbL -DIDENT_UIDHASH=0x53e89c47L
 -fnesc-dump=wiring
 -fnesc-dump='interfaces(!abstract())'
 -fnesc-dump='referenced(interfacedefs,
 components)' -fnesc-dumpfile=build/iris/wiring-check.xml UDPEchoC.nc -lm


 /opt/tinyos-2.x/tos/lib/net/blip/shell/UDPShellP.nc:260: warning: call
 via function pointer

 /opt/tinyos-2.x/tos/lib/net/blip/Ieee154AddressP.nc:40: warning:
 `Ieee154Address.changed' called asynchronously from
 `ActiveMessageAddress.changed'

    compiled UDPEchoC to build/iris/main.exe
           48650 bytes in ROM
           10953 bytes in RAM
 avr-objcopy --output-target=srec build/iris/main.exe
 build/iris/main.srec
 avr-objcopy --output-target=ihex build/iris/main.exe
 build/iris/main.ihex



 --
 This message has been scanned for viruses and
 dangerous content by MailScanner, and is
 believed to be clean.


___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Unable to run IPBasestation on iris platform.

[Miklos Maroti]

Hi!

I have an experimental branch that supports BLIP for ISIS here:

https://github.com/mmaroti/tinyos/tree/blip

Please download the WHOLE tree from there (not just specific files)
and give it a try.

Best,
Miklos

On Fri, Jun 1, 2012 at 12:19 AM, ankit jain ankit.jai...@gmail.com wrote:
 Hi everyone,I'm working with tinyos-2.1.1, i have now two version, one taken
 from svn (unstable), one taken from cvs.I'm trying to establish an IP
 communications between IRIS motes.
 The radio on my IRIS in rf230.

 I see that BLIP is not properly working (the compiling i\has not done..) for
 those platforms because the wirings to the radio is not correct (problems in
 BaseStationC.nc and in SerialPacketInfo802_15_4P.nc ).
 Here it is the output of 'make iris blip' in $TOSROOT/apps/IPBaseStation:

 mkdir -p build/iris
 compiling BaseStationC to a iris binary
 ncc -o build/iris/main.exe  -Os -DPACKET_LINK -DDEF_MEMCPY -DENABLE_SPI0_DMA
 -DBLIP_MULTICAST -DCC2420_HW_ACKNOWLEDGEMENTS -DTOSH_DATA_LENGTH=102
 -I/opt/tinyos-2.1.1/tos/lib/net/
 -I/opt/tinyos-2.1.1/support/sdk/c/blip/lib6lowpan/
 -I/opt/tinyos-2.1.1/support/sdk/c/blip/libtcp/
 -I/opt/tinyos-2.1.1/tos/lib/net/blip/
 -I/opt/tinyos-2.1.1/tos/lib/net/blip/interfaces/
 -I/opt/tinyos-2.1.1/tos/lib/net/blip/nwprog/
 -I/opt/tinyos-2.1.1/tos/lib/net/blip/shell/
 -I/opt/tinyos-2.1.1/tos/lib/net/blip/serial/
 -I/opt/tinyos-2.1.1/tos/lib/net/blip/platform/
 /opt/tinyos-2.1.1/support/sdk/c/blip/lib6lowpan/lib6lowpan.c
 /opt/tinyos-2.1.1/support/sdk/c/blip/lib6lowpan/lib6lowpanIP.c
 /opt/tinyos-2.1.1/support/sdk/c/blip/lib6lowpan/lib6lowpanFrag.c
 /opt/tinyos-2.1.1/support/sdk/c/blip/lib6lowpan/in_cksum.c
 /opt/tinyos-2.1.1/support/sdk/c/blip/lib6lowpan/ip_malloc.c
 /opt/tinyos-2.1.1/tos/lib/net/blip/table.c -fnesc-separator=__ -Wall
 -Wshadow -Wnesc-all -target=iris -fnesc-cfile=build/iris/app.c -board=micasb
 -DDEFINED_TOS_AM_GROUP=0x22 --param max-inline-insns-single=10
 -DNO_IP_MALLOC  -DIEEE154FRAMES_ENABLED -DIDENT_APPNAME=\BaseStationC\
 -DIDENT_USERNAME=\root\ -DIDENT_HOSTNAME=\wsn-testbed\
 -DIDENT_USERHASH=0x7a1917aeL -DIDENT_TIMESTAMP=0x4e523e14L
 -DIDENT_UIDHASH=0x12e31c9eL -fnesc-dump=wiring
 -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs,
 components)' -fnesc-dumpfile=build/iris/wiring-check.xml BaseStationC.nc -lm
 BaseStationP.nc:68:20: error: CC2420.h: No such file or directory
 In file included from BaseStationC.nc:100:
 In component `BaseStationP':
 BaseStationP.nc:98: interface CC2420Config not found
 In file included from BaseStationC.nc:100:
 BaseStationP.nc: In function `ConfigureReceive.receive':
 BaseStationP.nc:413: interface has no command or event named `setChannel'
 BaseStationP.nc:416: interface has no command or event named `sync'
 BaseStationP.nc: At top level:
 BaseStationP.nc:434: `syncDone' is not in interface `CC2420Config'
 In file included from
 /opt/tinyos-2.1.1/tos/lib/serial/Serial802_15_4C.nc:43,
  from BaseStationC.nc:102:
 In component `SerialPacketInfo802_15_4P':
 /opt/tinyos-2.1.1/tos/lib/serial/SerialPacketInfo802_15_4P.nc: In function
 `Info.offset':
 /opt/tinyos-2.1.1/tos/lib/serial/SerialPacketInfo802_15_4P.nc:38:
 `cc2420_header_t' undeclared (first use in this function)
 /opt/tinyos-2.1.1/tos/lib/serial/SerialPacketInfo802_15_4P.nc:38: (Each
 undeclared identifier is reported only once
 /opt/tinyos-2.1.1/tos/lib/serial/SerialPacketInfo802_15_4P.nc:38: for each
 function it appears in.)
 /opt/tinyos-2.1.1/tos/lib/serial/SerialPacketInfo802_15_4P.nc: In function
 `Info.dataLinkLength':
 /opt/tinyos-2.1.1/tos/lib/serial/SerialPacketInfo802_15_4P.nc:41:
 `cc2420_header_t' undeclared (first use in this function)
 /opt/tinyos-2.1.1/tos/lib/serial/SerialPacketInfo802_15_4P.nc:41:
 `cc2420_footer_t' undeclared (first use in this function)
 /opt/tinyos-2.1.1/tos/lib/serial/SerialPacketInfo802_15_4P.nc: In function
 `Info.upperLength':
 /opt/tinyos-2.1.1/tos/lib/serial/SerialPacketInfo802_15_4P.nc:44:
 `cc2420_header_t' undeclared (first use in this function)
 /opt/tinyos-2.1.1/tos/lib/serial/SerialPacketInfo802_15_4P.nc:44:
 `cc2420_footer_t' undeclared (first use in this function)
 Reset.h:56:2: error: #error Reset.h not defined/supported for your
 platform, aborting...
 In component `BaseStationC':
 BaseStationC.nc: At top level:
 BaseStationC.nc:136: component CC2420ControlC not found
 BaseStationC.nc:137: no match
 make: *** [exe0] Error 1


 ___
 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

Re: [Tinyos-help] RF230ActiveMessageC RadioChannel.setChannel(), how to commit the change of radio?

[Miklos Maroti]

Hi!

You do not need to commit anything, it will change the channel
immediately (but wait to complete for a currently incoming message).

Miklos

On Fri, Apr 27, 2012 at 7:41 PM, Long Cheng calf9...@gmail.com wrote:
 Hi All,

 I want to set channel of iris mote online,
 so I call RadioChannel.setChannel(channel);
 I wonder how can I commit the changes of the radio? or I do not need to
 commit the change any more ?

 For CC2420 Radio, call CC2420Config.setChannel(channel);
 call CC2420Config.sync();  //calling sync() will commit the changes to the
 CC2420

 thanks for your help!


 ___
 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

Re: [Tinyos-help] TinyOS + STM32 + Silabs Si4432

[Miklos Maroti]

Hi Oleg,

Any help is welcome! :) But yes, we have the ucdual platform with an
rfa1 and si4432 dual radio, and I plan to use it in the near future:

http://ucmote.unicomp.hu/en/content/menu_134/products#drd

Best,
Miklos

On Thu, Mar 29, 2012 at 8:16 AM, Bíró, András andras.b...@unicomp.hu wrote:
 Hi Oleg,

 The silabs driver from szte-wsn is not ready to use, we had some
 hardware bug, and we couldn't really test it. We want to finish it,
 but right now we have more important projects.

 Andris

 On Wed, Mar 28, 2012 at 1:44 PM, Oleg Trenkin legotro...@gmail.com wrote:
 Hi All,

 I want to use TinyOS on my own device. (STM32F2xx + Si4432)
 But, unfortunantly TinyOS main-tree doesn't support my both devices (MCU 
 Radio).

 But I found this:
 STM32 -- http://sourceforge.net/projects/tinyosonstm32/
 Silabs Si443x --
 http://szte-wsn.svn.sourceforge.net/viewvc/szte-wsn/tinyos-2.x/trunk/tos/chips/si443x/

 What do you think about using TinyOS with my hardware?

 ___
 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

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

[Miklos Maroti]

Hi Lewis,

On Tue, Mar 27, 2012 at 8:48 AM, Oldrine Lewis ole...@sutron.com wrote:
 Hi Miklos,

 Removing the CSMA/Tx retries seems to have fixed the issue. I have not seen 
 any corrupted packets since.
 I am kind of surprised that the AT86RF230 has bugs even in the core 
 functionality

Great to hear that. Software is reliable, hardware is not :). By the
way, a lot of hardware bugs are documented in the errata, and they
specifically recommend implementing the retry logic and CSMA in
software. The ATMEGA128RFA1 chip does not seem to be affected by those
bugs however.

Best,
Miklos


 Thanks,
 Lewis



 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Monday, March 26, 2012 12:47 AM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

 Hi Lewis,

 On Mon, Mar 26, 2012 at 5:42 AM, Oldrine Lewis ole...@sutron.com wrote:


 Hi Miklos,

 I have not tested with lower data rates. I will get rerun my tests with a 
 lower data rate and also get the status of the registers.
 However, in the meantime, I captured another corrupted packet where the 
 radio actually resend the correct packet, but it was probably discarded by 
 SubReceive.receive() in UniqueLayerP.nc cos it appeared to be a duplicate 
 packet.

 First Packet ( corrupted data)
 61 88 40 22 00 FF FF 02 00 3F 08 0B 12 10 01 04 00 9A 02 07 00 27 00 00 C2 
 00 00 67 03 05 00
 Second Packet (resend by the radio)
 61 88 40 22 00 FF FF 02 00 3F 08 0B 12 10 01 04 00 AA 02 01 00 2B 00 01 02 
 00 00 01 00 05 00

 This is completely overwritten (it has many errors from the AA on).

 Is there any situation where the sending radio  might retransmit  messages 
 that are broadcast?

 Strange, it should not have resent the packet unless 1) you use
 PacketLink, or 2) you use LowPowerListening. Maybe you can add
 debugging on the sender side as well...

 Best,
 Miklos


 Thanks,
 Lewis


 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Sunday, March 25, 2012 11:14 PM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

 Hi Lewis,

 Very interesting. The RF230 should not have done that: in section 8.2.4 it 
 says:

 In RX_AACK states, if FCS of the received frame is not valid, the
 radio transceiver
 rejects the frame and the TRX_END interrupt will not be generated.

 Do you see this behavior with very low data rates? Can you also print out the

 TRX_STATUS, TRX_STATE, PHY_RSSI and VERSION_NUM registers just after
 you have downloaded the message at line 695 just after the call
 SELN.set();. Would be nice if any change in these registers could
 detect the bad CRC check. Also, does enabling the RADIO_DEBUG produces
 any output with java net.tinyos.tools.DiagMsg?

 Best,
 Miklos

 On Mon, Mar 26, 2012 at 2:05 AM, Oldrine Lewis ole...@sutron.com wrote:
 Hi Miklos,

 I began seeing quite a few of the corrupted packets, so I added some debug
 statements(RF230DriverHwAckP.nc)  to output the raw received data just
 before signaling  RadioReceive.receive(rxMsg);



 Sender :   Node addr 2

 Receiver : Node addr 3

 Tx Type:   Broadcast



 Byte#15 should have been 0x01 instead of 0x51.



 Received data

 61 88 49 22 00 FF FF 02 00 3F 08 0B 12 10 51 04 00 AA 02 01 00 34 00 01 02
 00 00 01 00 05 00



 Expected data

 61 88 49 22 00 FF FF 02 00 3F 08 0B 12 10 01 04 00 AA 02 01 00 34 00 01 02
 00 00 01 00 05 00



 Thanks,

 Lewis







 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos
 Maroti
 Sent: Wednesday, March 21, 2012 2:01 AM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check



 Hi Lewis,



 On Tue, Mar 20, 2012 at 6:26 AM, Oldrine Lewis ole...@sutron.com wrote:

 Hi Miklos,

 If multiple packets arrive in quick succession, and we reject the first
 packet because  radioIrq was set, will  radioIrq go ahead and interrupt the
 micro again? If it does, is it possible that we might end up downloading a
 subsequent packet which might have been corrupted?



 The RF230 has a TRX_UR interrupt (underrun/overrun) which will be

 triggered if the pointer used to fill up the FIFO from the demodulator

 passes the pointer that is used to read the content via SPI. To my

 understanding this will indicate all data corruption errors coming

 from overwriting packets.



 Best,

 Miklos



 Thanks,

 Lewis















 -Original Message-

 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos
 Maroti

 Sent: Tuesday, March 20, 2012 12:04 AM

 To: Oldrine Lewis

 Cc: tinyos-help@millennium.berkeley.edu

 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check



 Hi Lewis,



 On Tue, Mar 20, 2012 at 2:42 AM, Oldrine Lewis

Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

[Miklos Maroti]

Hi Oldrine,

On Mon, Mar 26, 2012 at 8:51 AM, Oldrine Lewis ole...@sutron.com wrote:

 Hi Miklos,

 I am using low power listening and after looking at app.c it seems that 
 Packetlink is also somehow bieng used. Will it re-transmit all packets, 
 regardless of whether they are are broadcast or unicast? All the packets i 
 have right now are broadcast.

They will retransmit broadcast packets for the duration of lisen
length (so to make sure that the other end has received at least one
packet)

 I also modified the register RF230_XAH_CTRL to increase the number of CSMA 
 and transmit retries.

 RF230DriverHwAckP__writeRegister(RF230_XAH_CTRL, (7  4) + (7  1));//from 
 app.c

Please do NOT do it. The hardware retransmission logic of the RF230
has many bugs. It is intentional, that we do not use either the
hardware CSMA nor the hardware retransmissions, and do all of that in
software. You should run all of your tests with XAH disabled.

Best,
Miklos



 Thanks,
 Lewis


 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Monday, March 26, 2012 12:47 AM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

 Hi Lewis,

 On Mon, Mar 26, 2012 at 5:42 AM, Oldrine Lewis ole...@sutron.com wrote:


 Hi Miklos,

 I have not tested with lower data rates. I will get rerun my tests with a 
 lower data rate and also get the status of the registers.
 However, in the meantime, I captured another corrupted packet where the 
 radio actually resend the correct packet, but it was probably discarded by 
 SubReceive.receive() in UniqueLayerP.nc cos it appeared to be a duplicate 
 packet.

 First Packet ( corrupted data)
 61 88 40 22 00 FF FF 02 00 3F 08 0B 12 10 01 04 00 9A 02 07 00 27 00 00 C2 
 00 00 67 03 05 00
 Second Packet (resend by the radio)
 61 88 40 22 00 FF FF 02 00 3F 08 0B 12 10 01 04 00 AA 02 01 00 2B 00 01 02 
 00 00 01 00 05 00

 This is completely overwritten (it has many errors from the AA on).

 Is there any situation where the sending radio  might retransmit  messages 
 that are broadcast?

 Strange, it should not have resent the packet unless 1) you use
 PacketLink, or 2) you use LowPowerListening. Maybe you can add
 debugging on the sender side as well...

 Best,
 Miklos


 Thanks,
 Lewis


 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Sunday, March 25, 2012 11:14 PM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

 Hi Lewis,

 Very interesting. The RF230 should not have done that: in section 8.2.4 it 
 says:

 In RX_AACK states, if FCS of the received frame is not valid, the
 radio transceiver
 rejects the frame and the TRX_END interrupt will not be generated.

 Do you see this behavior with very low data rates? Can you also print out the

 TRX_STATUS, TRX_STATE, PHY_RSSI and VERSION_NUM registers just after
 you have downloaded the message at line 695 just after the call
 SELN.set();. Would be nice if any change in these registers could
 detect the bad CRC check. Also, does enabling the RADIO_DEBUG produces
 any output with java net.tinyos.tools.DiagMsg?

 Best,
 Miklos

 On Mon, Mar 26, 2012 at 2:05 AM, Oldrine Lewis ole...@sutron.com wrote:
 Hi Miklos,

 I began seeing quite a few of the corrupted packets, so I added some debug
 statements(RF230DriverHwAckP.nc)  to output the raw received data just
 before signaling  RadioReceive.receive(rxMsg);



 Sender :   Node addr 2

 Receiver : Node addr 3

 Tx Type:   Broadcast



 Byte#15 should have been 0x01 instead of 0x51.



 Received data

 61 88 49 22 00 FF FF 02 00 3F 08 0B 12 10 51 04 00 AA 02 01 00 34 00 01 02
 00 00 01 00 05 00



 Expected data

 61 88 49 22 00 FF FF 02 00 3F 08 0B 12 10 01 04 00 AA 02 01 00 34 00 01 02
 00 00 01 00 05 00



 Thanks,

 Lewis







 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos
 Maroti
 Sent: Wednesday, March 21, 2012 2:01 AM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check



 Hi Lewis,



 On Tue, Mar 20, 2012 at 6:26 AM, Oldrine Lewis ole...@sutron.com wrote:

 Hi Miklos,

 If multiple packets arrive in quick succession, and we reject the first
 packet because  radioIrq was set, will  radioIrq go ahead and interrupt the
 micro again? If it does, is it possible that we might end up downloading a
 subsequent packet which might have been corrupted?



 The RF230 has a TRX_UR interrupt (underrun/overrun) which will be

 triggered if the pointer used to fill up the FIFO from the demodulator

 passes the pointer that is used to read the content via SPI. To my

 understanding this will indicate all data corruption errors coming

 from overwriting packets.



 Best,

 Miklos



 Thanks

Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

[Miklos Maroti]

Hi Christian,

On Mon, Mar 26, 2012 at 12:37 PM, Christian Haas h...@tm.uka.de wrote:
 On 03/26/2012 04:37 PM, Miklos Maroti wrote:
 Please do NOT do it. The hardware retransmission logic of the RF230
 has many bugs. It is intentional, that we do not use either the
 hardware CSMA nor the hardware retransmissions, and do all of that in
 software. You should run all of your tests with XAH disabled.

 Hi,

 that said, the SW implementation isnt usable as well, at least not if
 your are using LPL and/or packets bigger then 30 Byte. Kinda sucks =/

Yes, then some parameters need to be adjusted. There were some thread
on this. You need increase the SOFTWAREACK_TIMEOUT in RadioConfig.h.
This could/should be adjusted automatically in RF230RadioP based on
the TOSH_DATA_LENGTH. You also need to tweak the LPL parameters.

Miklos

 --
 Dipl. Inform. Christian Haas
 Karlsruher Institut für Technologie
 TM Prof. Dr. Zitterbart
 Raum 102, Geb. 20.50
 Engesserstraße 2 Rechts
 76128 Karlsruhe
 Germany

 Tel.: +49 721 608-48673
 Email:h...@tm.uka.de
 Jabber-ID: h...@tm.uka.de



___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

[Miklos Maroti]

Hi Lewis,

Very interesting. The RF230 should not have done that: in section 8.2.4 it says:

In RX_AACK states, if FCS of the received frame is not valid, the
radio transceiver
rejects the frame and the TRX_END interrupt will not be generated.

Do you see this behavior with very low data rates? Can you also print out the

TRX_STATUS, TRX_STATE, PHY_RSSI and VERSION_NUM registers just after
you have downloaded the message at line 695 just after the call
SELN.set();. Would be nice if any change in these registers could
detect the bad CRC check. Also, does enabling the RADIO_DEBUG produces
any output with java net.tinyos.tools.DiagMsg?

Best,
Miklos

On Mon, Mar 26, 2012 at 2:05 AM, Oldrine Lewis ole...@sutron.com wrote:
 Hi Miklos,

 I began seeing quite a few of the corrupted packets, so I added some debug
 statements(RF230DriverHwAckP.nc)  to output the raw received data just
 before signaling  RadioReceive.receive(rxMsg);



 Sender :   Node addr 2

 Receiver : Node addr 3

 Tx Type:   Broadcast



 Byte#15 should have been 0x01 instead of 0x51.



 Received data

 61 88 49 22 00 FF FF 02 00 3F 08 0B 12 10 51 04 00 AA 02 01 00 34 00 01 02
 00 00 01 00 05 00



 Expected data

 61 88 49 22 00 FF FF 02 00 3F 08 0B 12 10 01 04 00 AA 02 01 00 34 00 01 02
 00 00 01 00 05 00



 Thanks,

 Lewis







 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos
 Maroti
 Sent: Wednesday, March 21, 2012 2:01 AM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check



 Hi Lewis,



 On Tue, Mar 20, 2012 at 6:26 AM, Oldrine Lewis ole...@sutron.com wrote:

 Hi Miklos,

 If multiple packets arrive in quick succession, and we reject the first
 packet because  radioIrq was set, will  radioIrq go ahead and interrupt the
 micro again? If it does, is it possible that we might end up downloading a
 subsequent packet which might have been corrupted?



 The RF230 has a TRX_UR interrupt (underrun/overrun) which will be

 triggered if the pointer used to fill up the FIFO from the demodulator

 passes the pointer that is used to read the content via SPI. To my

 understanding this will indicate all data corruption errors coming

 from overwriting packets.



 Best,

 Miklos



 Thanks,

 Lewis















 -Original Message-

 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos
 Maroti

 Sent: Tuesday, March 20, 2012 12:04 AM

 To: Oldrine Lewis

 Cc: tinyos-help@millennium.berkeley.edu

 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check



 Hi Lewis,



 On Tue, Mar 20, 2012 at 2:42 AM, Oldrine Lewis ole...@sutron.com wrote:

 Hi,



 I am a little confused too cos the FCS check should be automatically done
 in

 the extended mode.



 The corrupted packet I noticed had an incorrect length (argument in

 Receive() event signalled in the app)  and also some of the data bytes
 were

 corrupted. I have not yet been able to capture another corrupted packet

 since.



 With very low probability a corrupted packet can still pass the CRC

 check, maybe you have seen one. Would be nice to know if it would have

 passed a manual CRC check.



 Today, I noticed that I was losing a few packets, which I think was due
 to

 another Interrupt arrving from the RF230 (crcValid = ! radioIrq;). This

 however did not result in a corrupted packet.



 Is it possible that multiple packets arrivng in quick succession might
 cause

 data to get corrupted under some circumstances?



 I think yes, a new packet can overwrite an old one, that is why I have

 the IRQ check there.



 Best,

 Miklos









 Thanks,



 Lewis















 -Original Message-

 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos

 Maroti

 Sent: Sunday, March 18, 2012 8:45 PM

 To: Oldrine Lewis

 Cc: tinyos-help@millennium.berkeley.edu

 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check







 Hi Lewis,







 In the extended mode (which the RF230DriverHwAckP uses) all packets



 with an invalid CRC are discarded. The software ack driver



 (RF230DriverLayerP) does not use the RX_CRC_VALID flag because it was



 not present in the rev A of the chip. (Looking at the docs know I



 cannot find a record of this fact, maybe it was there but



 undocumented?) I am curious how you have seen corrupted messages. Can



 you have specific examples? Do you see them with the softwareack



 driver as well?







 Miklos







 On Sun, Mar 18, 2012 at 8:28 PM, Oldrine Lewis ole...@sutron.com wrote:



 Hi,







 I have a simple test where one node broadcasts packets and it is
 received

 by



 multiple nodes. I noticed that I was occassionally receiving some

 corrupted



 packets. The packets were transmitted correctly because one of the other



 nodes received the packet correctly.







 On doing a little investigation, I noticed

Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

[Miklos Maroti]

Hi Lewis,

On Mon, Mar 26, 2012 at 5:42 AM, Oldrine Lewis ole...@sutron.com wrote:


 Hi Miklos,

 I have not tested with lower data rates. I will get rerun my tests with a 
 lower data rate and also get the status of the registers.
 However, in the meantime, I captured another corrupted packet where the radio 
 actually resend the correct packet, but it was probably discarded by 
 SubReceive.receive() in UniqueLayerP.nc cos it appeared to be a duplicate 
 packet.

 First Packet ( corrupted data)
 61 88 40 22 00 FF FF 02 00 3F 08 0B 12 10 01 04 00 9A 02 07 00 27 00 00 C2 00 
 00 67 03 05 00
 Second Packet (resend by the radio)
 61 88 40 22 00 FF FF 02 00 3F 08 0B 12 10 01 04 00 AA 02 01 00 2B 00 01 02 00 
 00 01 00 05 00

This is completely overwritten (it has many errors from the AA on).

 Is there any situation where the sending radio  might retransmit  messages 
 that are broadcast?

Strange, it should not have resent the packet unless 1) you use
PacketLink, or 2) you use LowPowerListening. Maybe you can add
debugging on the sender side as well...

Best,
Miklos


 Thanks,
 Lewis


 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Sunday, March 25, 2012 11:14 PM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

 Hi Lewis,

 Very interesting. The RF230 should not have done that: in section 8.2.4 it 
 says:

 In RX_AACK states, if FCS of the received frame is not valid, the
 radio transceiver
 rejects the frame and the TRX_END interrupt will not be generated.

 Do you see this behavior with very low data rates? Can you also print out the

 TRX_STATUS, TRX_STATE, PHY_RSSI and VERSION_NUM registers just after
 you have downloaded the message at line 695 just after the call
 SELN.set();. Would be nice if any change in these registers could
 detect the bad CRC check. Also, does enabling the RADIO_DEBUG produces
 any output with java net.tinyos.tools.DiagMsg?

 Best,
 Miklos

 On Mon, Mar 26, 2012 at 2:05 AM, Oldrine Lewis ole...@sutron.com wrote:
 Hi Miklos,

 I began seeing quite a few of the corrupted packets, so I added some debug
 statements(RF230DriverHwAckP.nc)  to output the raw received data just
 before signaling  RadioReceive.receive(rxMsg);



 Sender :   Node addr 2

 Receiver : Node addr 3

 Tx Type:   Broadcast



 Byte#15 should have been 0x01 instead of 0x51.



 Received data

 61 88 49 22 00 FF FF 02 00 3F 08 0B 12 10 51 04 00 AA 02 01 00 34 00 01 02
 00 00 01 00 05 00



 Expected data

 61 88 49 22 00 FF FF 02 00 3F 08 0B 12 10 01 04 00 AA 02 01 00 34 00 01 02
 00 00 01 00 05 00



 Thanks,

 Lewis







 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos
 Maroti
 Sent: Wednesday, March 21, 2012 2:01 AM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check



 Hi Lewis,



 On Tue, Mar 20, 2012 at 6:26 AM, Oldrine Lewis ole...@sutron.com wrote:

 Hi Miklos,

 If multiple packets arrive in quick succession, and we reject the first
 packet because  radioIrq was set, will  radioIrq go ahead and interrupt the
 micro again? If it does, is it possible that we might end up downloading a
 subsequent packet which might have been corrupted?



 The RF230 has a TRX_UR interrupt (underrun/overrun) which will be

 triggered if the pointer used to fill up the FIFO from the demodulator

 passes the pointer that is used to read the content via SPI. To my

 understanding this will indicate all data corruption errors coming

 from overwriting packets.



 Best,

 Miklos



 Thanks,

 Lewis















 -Original Message-

 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos
 Maroti

 Sent: Tuesday, March 20, 2012 12:04 AM

 To: Oldrine Lewis

 Cc: tinyos-help@millennium.berkeley.edu

 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check



 Hi Lewis,



 On Tue, Mar 20, 2012 at 2:42 AM, Oldrine Lewis ole...@sutron.com wrote:

 Hi,



 I am a little confused too cos the FCS check should be automatically done
 in

 the extended mode.



 The corrupted packet I noticed had an incorrect length (argument in

 Receive() event signalled in the app)  and also some of the data bytes
 were

 corrupted. I have not yet been able to capture another corrupted packet

 since.



 With very low probability a corrupted packet can still pass the CRC

 check, maybe you have seen one. Would be nice to know if it would have

 passed a manual CRC check.



 Today, I noticed that I was losing a few packets, which I think was due
 to

 another Interrupt arrving from the RF230 (crcValid = ! radioIrq;). This

 however did not result in a corrupted packet.



 Is it possible that multiple packets arrivng in quick succession might
 cause

 data to get corrupted under some circumstances?



 I think yes, a new

Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

[Miklos Maroti]

Hi Lewis,

On Tue, Mar 20, 2012 at 6:26 AM, Oldrine Lewis ole...@sutron.com wrote:
 Hi Miklos,
 If multiple packets arrive in quick succession, and we reject the first 
 packet because  radioIrq was set, will  radioIrq go ahead and interrupt the 
 micro again? If it does, is it possible that we might end up downloading a 
 subsequent packet which might have been corrupted?

The RF230 has a TRX_UR interrupt (underrun/overrun) which will be
triggered if the pointer used to fill up the FIFO from the demodulator
passes the pointer that is used to read the content via SPI. To my
understanding this will indicate all data corruption errors coming
from overwriting packets.

Best,
Miklos

 Thanks,
 Lewis







 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Tuesday, March 20, 2012 12:04 AM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

 Hi Lewis,

 On Tue, Mar 20, 2012 at 2:42 AM, Oldrine Lewis ole...@sutron.com wrote:
 Hi,

 I am a little confused too cos the FCS check should be automatically done in
 the extended mode.

 The corrupted packet I noticed had an incorrect length (argument in
 Receive() event signalled in the app)  and also some of the data bytes were
 corrupted. I have not yet been able to capture another corrupted packet
 since.

 With very low probability a corrupted packet can still pass the CRC
 check, maybe you have seen one. Would be nice to know if it would have
 passed a manual CRC check.

 Today, I noticed that I was losing a few packets, which I think was due to
 another Interrupt arrving from the RF230 (crcValid = ! radioIrq;). This
 however did not result in a corrupted packet.

 Is it possible that multiple packets arrivng in quick succession might cause
 data to get corrupted under some circumstances?

 I think yes, a new packet can overwrite an old one, that is why I have
 the IRQ check there.

 Best,
 Miklos




 Thanks,

 Lewis







 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos
 Maroti
 Sent: Sunday, March 18, 2012 8:45 PM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check



 Hi Lewis,



 In the extended mode (which the RF230DriverHwAckP uses) all packets

 with an invalid CRC are discarded. The software ack driver

 (RF230DriverLayerP) does not use the RX_CRC_VALID flag because it was

 not present in the rev A of the chip. (Looking at the docs know I

 cannot find a record of this fact, maybe it was there but

 undocumented?) I am curious how you have seen corrupted messages. Can

 you have specific examples? Do you see them with the softwareack

 driver as well?



 Miklos



 On Sun, Mar 18, 2012 at 8:28 PM, Oldrine Lewis ole...@sutron.com wrote:

 Hi,



 I have a simple test where one node broadcasts packets and it is received
 by

 multiple nodes. I noticed that I was occassionally receiving some
 corrupted

 packets. The packets were transmitted correctly because one of the other

 nodes received the packet correctly.



 On doing a little investigation, I noticed that the lower layer driver

 (RF230DriverHwAckP.nc)  does not check the RX_CRC_VALID flag in the
 register

 PHY_RSSI (0x06) which is updated with the result of the FCS check on the

 received packet.







 Would adding another check improve the Receiver reliability?







 Thanks,



 Lewis

























 ___

 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

Re: [Tinyos-help] RF230 HW ACK: Driver uses undefined state transition RX_AACK_ON - TX_ARET_ON?

[Miklos Maroti]

Hi Markus,

On page 89 of the datasheet there is a workaround that shows that you
can switch between TRX_CMD=TX_START the to TRX_CMD=RX_ON and then to
TRX_CMD=TX_ARET_ON. So even in the manual they use this (at lease in
one of the published workarounds of an errata). I do not know how
slower the proper way would be. Yes, this might be undocumented,
from all info I saw RX_AACK_ON is pretty much the same as RX_ON and
TX_ARET_ON is pretty much the same as PLL_ON, and between RX_ON and
PLL_ON you can switch, so this was a natural port of that behavior and
it worked. If it makes you more confortable, I can happy to add a
comment there :)

Miklos

On Wed, Mar 21, 2012 at 5:11 PM, Markus Jung
markus.j...@stud.uni-karlsruhe.de wrote:
 Hello,

 hardware-acknowledgements have been reported to work on real devices
 (AFAIK), but while trying to simulate a TOS application using HWACK with
 LPL, i stumbled upon following behaviour:
 Phase A: The driver puts the radio into RX_AACK_ON mode. All is fine
 until
 Phase B: A transmission gets started. The driver issues a direct state
 transition from RX_AACK_ON to TX_ARET_ON, which is not defined either by
 the datasheet or the software programming manual. It is quite
 interesting to observe real device accepting this (undocumented) state
 transition.

 This behaviour has been observed in simulation protocols and can be
 confirmed by the code in RF230DriverHwAckP (RadioSend.send).

 However: AFAIK, there is no official source which mentions a transition
 RX_AACK_ON-TX_ARET_ON. The only documented way is to use PLL_ON (or,
 not recommended according to Atmels software programming manual,
 TRX_OFF) as a intermediate-state.
 For stability and compatibility reasons, the driver should not use
 undocumented state transitions.

 Regards,
 Markus
 ___
 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

Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

[Miklos Maroti]

Hi Lewis,

On Tue, Mar 20, 2012 at 2:42 AM, Oldrine Lewis ole...@sutron.com wrote:
 Hi,

 I am a little confused too cos the FCS check should be automatically done in
 the extended mode.

 The corrupted packet I noticed had an incorrect length (argument in
 Receive() event signalled in the app)  and also some of the data bytes were
 corrupted. I have not yet been able to capture another corrupted packet
 since.

With very low probability a corrupted packet can still pass the CRC
check, maybe you have seen one. Would be nice to know if it would have
passed a manual CRC check.

 Today, I noticed that I was losing a few packets, which I think was due to
 another Interrupt arrving from the RF230 (crcValid = ! radioIrq;). This
 however did not result in a corrupted packet.

 Is it possible that multiple packets arrivng in quick succession might cause
 data to get corrupted under some circumstances?

I think yes, a new packet can overwrite an old one, that is why I have
the IRQ check there.

Best,
Miklos




 Thanks,

 Lewis







 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos
 Maroti
 Sent: Sunday, March 18, 2012 8:45 PM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check



 Hi Lewis,



 In the extended mode (which the RF230DriverHwAckP uses) all packets

 with an invalid CRC are discarded. The software ack driver

 (RF230DriverLayerP) does not use the RX_CRC_VALID flag because it was

 not present in the rev A of the chip. (Looking at the docs know I

 cannot find a record of this fact, maybe it was there but

 undocumented?) I am curious how you have seen corrupted messages. Can

 you have specific examples? Do you see them with the softwareack

 driver as well?



 Miklos



 On Sun, Mar 18, 2012 at 8:28 PM, Oldrine Lewis ole...@sutron.com wrote:

 Hi,



 I have a simple test where one node broadcasts packets and it is received
 by

 multiple nodes. I noticed that I was occassionally receiving some
 corrupted

 packets. The packets were transmitted correctly because one of the other

 nodes received the packet correctly.



 On doing a little investigation, I noticed that the lower layer driver

 (RF230DriverHwAckP.nc)  does not check the RX_CRC_VALID flag in the
 register

 PHY_RSSI (0x06) which is updated with the result of the FCS check on the

 received packet.







 Would adding another check improve the Receiver reliability?







 Thanks,



 Lewis

























 ___

 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

Re: [Tinyos-help] why BLIP cannot be supported by iris platform?

[Miklos Maroti]

Hi Guys,

I have put together a patch to support the latest BLIP for IRIS. It is
completely untested, it might eat your dog, but it can compile the
PppRouter. If someone wants to give it a try, please go ahead. The
code is here:

https://github.com/mmaroti/tinyos/tree/blip

If things work for IRIS, then all rfxlink platforms will follow and
this will land in tinyos-main.

Miklos

On Fri, Mar 16, 2012 at 10:36 AM, Antonio Liñán C. ali...@zolertia.com wrote:


 http://code.google.com/p/tinyos-main/issues/detail?id=30

 --Antonio

 On Fri, 2012-03-16 at 17:06 +0800, Alvin wrote:
 My question seems a little stupid ,but this has puzzled me a lot. I
 know that the blip can be be supprted well by the telosb or micaz
 platform,but it seems  it isn't compatible with the iris platform.So
 my question is for what reason exactly  it cannot be supported by the
 iris platform?If I want to do the blip test on practical platforms
 ,does that mean my only choice is telosb or micaz? Is there any chance
 the iris platfom can be used to test blip 0r blip2.0 in the coming
 future?
 ___
 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

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] IRIS motes corrupted data received - CRC check

[Miklos Maroti]

Hi Lewis,

In the extended mode (which the RF230DriverHwAckP uses) all packets
with an invalid CRC are discarded. The software ack driver
(RF230DriverLayerP) does not use the RX_CRC_VALID flag because it was
not present in the rev A of the chip. (Looking at the docs know I
cannot find a record of this fact, maybe it was there but
undocumented?) I am curious how you have seen corrupted messages. Can
you have specific examples? Do you see them with the softwareack
driver as well?

Miklos

On Sun, Mar 18, 2012 at 8:28 PM, Oldrine Lewis ole...@sutron.com wrote:
 Hi,

 I have a simple test where one node broadcasts packets and it is received by
 multiple nodes. I noticed that I was occassionally receiving some corrupted
 packets. The packets were transmitted correctly because one of the other
 nodes received the packet correctly.

 On doing a little investigation, I noticed that the lower layer driver
 (RF230DriverHwAckP.nc)  does not check the RX_CRC_VALID flag in the register
 PHY_RSSI (0x06) which is updated with the result of the FCS check on the
 received packet.



 Would adding another check improve the Receiver reliability?



 Thanks,

 Lewis












 ___
 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

Re: [Tinyos-help] IRIS/RF230: Optimistic Timings?

[Miklos Maroti]

Hi Markus,

On Tue, Mar 13, 2012 at 1:29 PM, Markus Jung
markus.j...@stud.uni-karlsruhe.de wrote:
 Hello altogether,

 i am currently developing support for IRIS nodes for the Avrora
 simulation framework, with a special focus on TinyOS applications.
 Simulation protocols and further investigations into the RF230 driver
 source have raised some questions.

Cool! :)

 According to the AT86RF230 datasheet, a transition from P_ON to TRX_OFF
 has a typical duration of 880µs. The driver uses a vale of 510 µs (which
 can be found in Atmels AT86RF230 software programming model)

Actually, the init code waits twice for 510 us, first to get clock,
then we wake it up, wait more.

 This leads directly to the main issue i would like to discuss: The whole
 driver behaves very optimistic and uses the typical values found in the
 datasheet as worst-case values. I have not seen any countermeasures for
 cases in which the radio device uses more time than this typical value,
 in those cases the whole radio communication might (and in fact, does if
 provoked in simulation cases) lock up.
 I have not found any line of code where the device state gets read
 before a state change command is issued, and no hard timeouts for cases
 where the radio is in a different state than expected.

I would be very interested in learning where such measures could be
provided. The problem with all this is the following: what happens if
the hardware never does what you want. How long are you going to wait?
In general I did not want to set timers, because that consumes
resources (and all higher level code shares a single alarm with the
driver).

 The reset timings appear to differ from the datasheet, too (and here
 again, the software programming model tells something different).
 According to the datasheet, the device requires a typical value of 120µs
 after a reset condition until it is operational again.
 During the reset procedure the SPI interface shall be inactive ( SEL = H;
 SCLK = L).
 (AT86RF230 Datasheet)

And I think we wait longer, no?

 To sum it up: The driver uses typical timing values as worst-case
 timings and does not follow any conservative approach (as stated in the
 datasheet on page 21).
 The radio transceiver state is controlled by two signal pins (SLP_TR, RST ) 
 and the
 register 0x02 (TRX_STATE). A successful state change shall be confirmed by 
 reading
 the radio transceiver status from register 0x01 (TRX_STATUS).
 (AT86RF230 Datasheet)

That is true.

 Despite of all this issues, the driver appears to work on real devices.
 I assume the datasheet contains values with rather large safety margins,
 but in my opinion, violating those specifications is not good.
 Especially because the datasheet provides the only mandatory device
 characteristics for building a simulation.

I agree, that it is not good practice to violate those limits. There
are other reasons that a radio driver can lock up, and that what has
caused a lot of trouble for me. In certain situations the whole chip
can lock up, especially when you command it to do something, but at
the very same moment (in around 1 us window !!!) an incoming message
is received, then the internal state machine of the chip can lock up,
and will never receive the message, nor complete the transmit. Only a
reset helps. This seems to be fixed in recent IRIS motes with a new
hardware revision of the chip (I have reported this to Atmel but did
not get a reply). Similar issues prop up with the RF212 and RFA1
drivers.

So based on all this, it seems that a watchdog component should be
installed above all radio drivers (especially in production mode),
which would trigger the reset of the radio is some timing constraints
are not met. I did not do this yet. So my plan is to make sure that
the radio can be reset/restarted at any moment reliably, and then do
this watchdog component. What do you think?

Best,
Miklos


 Regards,
 Markus Jung

 Oh, and by the way: The sequence
 call RSTN.makeOutput();
 call RSTN.set();
 in PlatformInit.init() might issue undefined behaviour (by default, an
 AVR pin is configured as input/low, by configuring it as output before
 setting the desired value, there is an state between with output/low).
 This short glitch violates the minimum reset pulse width of 625ns.
 ___
 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

Re: [Tinyos-help] make iris blip error

[Miklos Maroti]

Hi!

Unfortunately BLIP does not work on IRIS currently. It will take some
effort to port it.

Miklos

On Mon, Mar 12, 2012 at 5:53 AM, Eric Decker cire...@gmail.com wrote:


 On Mon, Mar 12, 2012 at 12:23 AM, Alvin lifengguo1...@gmail.com wrote:


 According to the information,I looked through the codes,I found the code
 in the reset.h
 doesn't even support the iris platform,you can have a look at the
 code:
 void resetMote()
 {
 #if defined(PLATFORM_MICA) ||
 defined(PLATFORM_MICA2) || defined(PLATFORM_MICA2DOT) ||
 defined(PLATFORM_MICAZ)
         cli();
       wdt_enable(0);
       while (1) {
           __asm__ __volatile__(nop \n\t ::);
       }
 #elif defined(PLATFORM_TELOS) || defined(PLATFORM_TELOSB) ||
 defined(PLATFORM_EPIC)
     WDTCTL = 0;
 #else
 #error Reset.h not defined/supported for your platform, aborting...
 #endif
 }


 Now,my question is where can I get the latest IPbaseStation code which can
 fully support the iris platform.thank you very much for your  patience !


 I believe that IRIS predates IPbaseStation.

 I suspect you would have to figure out how to do it and create the code
 yourself.




 ___
 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



 ___
 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

Re: [Tinyos-help] LowPowerListening + RF230 + Large Packets = Broken ?! (2)

[Miklos Maroti]

Hi Christian,

This is very nice finding! I am not that surprised about issue 1, but
I do not understand issue 2. By the way, did you use TASKLET_IS_TASK
or not?

Miklos

On Wed, Mar 7, 2012 at 9:03 AM, Christian Haas h...@tm.uka.de wrote:
 (Next Issue)

 Hi,

 while testing an application originally tested on MicaZ nodes, i
 encountered several problems regarding LPL on Iris nodes:

 1. ...

 2. When you use a higher value for SW ACK Timeout, you will get some
 weird timing issues in the SoftwareAckLayerC: RadioTimer is probably
 interfering with the receiving of a msg, in this case the ACK you will
 receive after sending a packet. You will not be able to receive the ACK
 correctly.

 Regards,
  Christian

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] LowPowerListening + RF230 + Large Packets = Broken ?! (2)

[Miklos Maroti]

Hi Christian,

On Wed, Mar 7, 2012 at 9:20 AM, Christian Haas h...@tm.uka.de wrote:
 Thanks ;)

 I didnt use TASKLET_IS_TASK. Up to now i am still not able to run my
 appliaction properly (with Software Acks).

Please try with TASKLET_IS_TASK. It should not matter, but I would like to know.

 For issue 2:

 Lets say we have Nodes A and B, A is sending a packet of ~90 B to Node B
 with LPL. Normally you would like to see that a is repeating the packet
 several times due to LPL until B wakes up and sends the Ack. B is
 actually waking up and sending the Ack correctly, but A will not receive
 the ACK correctly. To me its seems that the

 tasklet_async event void RadioAlarm.fired()

 fires and interrupts the correct handling of the ACK packet, A will
 simply keep on sending until the end of the LPL time. This is no issue
 for smaller packets (answering time for ACK  SW Ack timeout) but now
 its just like gambling if you receive the packet or not.

Ok, I will take a look, I can start on this trail. Did hardware ACK work?

Miklos


 Regards,
  Christian



 Hi Christian,

 This is very nice finding! I am not that surprised about issue 1, but
 I do not understand issue 2. By the way, did you use TASKLET_IS_TASK
 or not?

 Miklos


___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Iris stops receiving messages after a while

[Miklos Maroti]

Hi Lewis,

This might solve your problem: try adding this to your Makefile:

CFLAGS += -DTASKLET_IS_TASK

The uart module has some problem on iris and cannot work reliably with
the radio unless the radio stack is running in task context.

Best,
Miklos

On Mon, Feb 20, 2012 at 9:00 AM, Oldrine Lewis ole...@sutron.com wrote:


 Hi,

 I am a novice with TinyOS. I am trying to build a small multihop network. I
 am currently testing a component of my routing engine where one of the nodes
 just broadcasts requests and intermediate nodes rebroadcast it. The problem
 is that after a while( sometimes a few minutes, sometime a few hours) one of
 intermediate nodes just stops receiving messages.

 I have Uart debug messages scattered all over and it seems that the last
 activity I see is the event AMSend.SendDone() called in my module.

 The following is some more info on my setup

 H/W Module: Iris

 Low power listening enabled



 Thank you very much for your time and patience.





 Lewis




 ___
 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

Re: [Tinyos-help] Iris stops receiving messages after a while

[Miklos Maroti]

Hi! Just to clarify, your code works fine without LPL? Are you sure
that the bug is not in your code? Does it work with the serial code
completely removed? Miklos

On Mon, Feb 20, 2012 at 10:34 AM, Oldrine Lewis ole...@sutron.com wrote:
 I agree, there are too many bugs in the current DYMO protocol implementation. 
 I tried fixing the code but found it much easier to start from scratch.  I am 
 currently try to build  a very simplified version of the DYMO protocol.


 -Original Message-
 From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti
 Sent: Monday, February 20, 2012 10:04 AM
 To: Oldrine Lewis
 Cc: tinyos-help@millennium.berkeley.edu
 Subject: Re: [Tinyos-help] Iris stops receiving messages after a while

 Hi Lewis,

 This might solve your problem: try adding this to your Makefile:

 CFLAGS += -DTASKLET_IS_TASK

 The uart module has some problem on iris and cannot work reliably with
 the radio unless the radio stack is running in task context.

 Best,
 Miklos

 On Mon, Feb 20, 2012 at 9:00 AM, Oldrine Lewis ole...@sutron.com wrote:


 Hi,

 I am a novice with TinyOS. I am trying to build a small multihop network. I
 am currently testing a component of my routing engine where one of the nodes
 just broadcasts requests and intermediate nodes rebroadcast it. The problem
 is that after a while( sometimes a few minutes, sometime a few hours) one of
 intermediate nodes just stops receiving messages.

 I have Uart debug messages scattered all over and it seems that the last
 activity I see is the event AMSend.SendDone() called in my module.

 The following is some more info on my setup

 H/W Module: Iris

 Low power listening enabled



 Thank you very much for your time and patience.





 Lewis




 ___
 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

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Help for Tinyos

[Miklos Maroti]

Hi Selahattin,

On Mon, Feb 6, 2012 at 12:36 PM, Selahattin Kosunalp
sk...@ohm.york.ac.uk wrote:
 Hi Miklos,

 Sorry again about bothering you, I found all fields below in
 Ieee154PacketLayer interface that makes sense, but except preamble and
 sync. How can I get more info for preamble and sync like default value,
 where they are defined, or are they directly produced in rf230 before a
 message ready to be sent, I mean hardware-based they are?

Read the AT86RF230 datasheet, you can find it on the atmel website or
use google. That has the preamble and sync byte values, but they are
not that important as you cannot change the value of those and it is
done completely in hardware.

 I am sorry that I may ask some stupid questions as I am new user of
 tinyos, is the message frame similar to IEEE 15.4? if so how similar is
 it?

It is standard 802.15.4 message frame.

 Finally, As you said, I used DiagMsag tool and I got some lines on the
 screen, one of the lines is shown below, I can identify some bytes ( group
 id Am type etc) but not all of them, are the pramble and sync bytes a part
 of DiagMsg?

Preamble and sync bytes are not part of the message, and you cannot
observe it, but we know it is transmitted and received and used to get
the bit synchronization right.

 Best wishes,
 -
 11:21:40 'r' 77393350 62691 41 [ 0x41 0x88 0xe5 0x1e 0x00 0x00 0x00 0x01
 0x00 0x3f 0x06 0x80 0x01 0x02 0xd4 ]42
 -

Look at the RF230DriverLayerP.nc file where this line is output. Here it is:

11:21:40 is the PC time when the line was displayed
'r' indicates that this message is a received one.
77393350  is the 32-bit PacketTimeStamp of the message (reception time
of the SFD field)
62691 is the 16-bit current time (both times are in TRadio units)
41 is the message length
[ 0x41 0x88 ... ] is the first 16 bytes of the message
41 is RSSI or link quality (actually two bytes should be here, one if
RSSI the other is LQI)

The payload section starts with the FCF field. You can read the format
in the RF230 datasheet.

Best,
Miklos


 Look at the apps/tests/rfxlink/RadioSniffer application. In
 particular, if you define the RADIO_DEBUG_MESSAGES define in your
 makefile, then it will print out messages with the DiagMsg framework.
 You can display these using the java net.tinyos.tools.DiagMsg
 application. Miklos

 On Thu, Feb 2, 2012 at 1:05 PM, Selahattin Kosunalp
 sk...@ohm.york.ac.uk wrote:
 Hi Miklos,

 That is fairly clear, thanks a lot for your lovely knowledge. The only
 thing, Can we display all the fields on a PC when a packet is received?
 because I am using java serial application to display the messages
 received, I only see destination, Source, Length, Group id, Message
 type.
 Hi Selahattin,

 Ok, here are the fields:

 4 bytes preamble
 1 byte sync
 1 byte length
 2 bytes FCF (frame type)
 1 byte DSN (sequence number)
 1 byte dest PAN (group id)
 2 bytes dest addr
 2 bytes source addr
 1 byte network type for 6lowpan
 1 byte AM message type
 28 bytes payload
 2 bytes crc

 this is 46 bytes. The speed of the radio is 250 kbps, which is 31250
 bytes per sec. So you should be able to transmit 679 messages per
 second.  Everything else is overhead (downloaded/uploaded messages via
 the SPI, processing, tasks, etc). You can calculate the overhead in
 bytes from the observed 500 messages per second: 31250 / 500 = 62.5
 bytes, so the MCU processing time overhead is around 16.5 bytes which
 is around 0.528 millisecond per message.

 Best,
 Miklos


 On Thu, Feb 2, 2012 at 12:32 PM, Selahattin Kosunalp
 sk...@ohm.york.ac.uk wrote:
 I employed 28-bytes data payload, I think the header is 8-bytes
 long(destination, Source, Length, Group id, Message type), As far as I
 know, the header is automatically added by tinyos, I did not do
 anything
 for header. When a packet arrives, I display it on a PC using serial
 java
 app. Then I can see the header fields. Again, I did not include CRC,
 preamle and sync bytes, I just defined a meessage_t variable and send
 it,
 Can we work out the processing time?
 I define a task to send messages using Amsend interface, at first my
 code
 transmits a message when sendDone is signaled, I call post the the
 task
 and send next message, kind of continues transmission. I observe that
 how
 many times sendDone is signaled in a second, then I got around 500
 times.
 Hi Selahattin!

 How did you get the 36 byte value? Did you include all headers and
 the
 CRC? Did you include the 4-byte preamble and the sync byte? Also,
 there is a significant amount of processing involved. How did you
 send
 this many messages? Did you use ActiveMessageC? If so, then packets
 travel through the whole stack and that also takes some time to
 process.

 Best,
 Miklos

 On Thu, Feb 2, 2012 at 12:03 PM, Selahattin Kosunalp
 sk...@ohm.york.ac.uk wrote:
 Hi Miklos,

 Thanks for your 

Re: [Tinyos-help] Help for Tinyos

[Miklos Maroti]

Hi Selahattin!

How did you get the 36 byte value? Did you include all headers and the
CRC? Did you include the 4-byte preamble and the sync byte? Also,
there is a significant amount of processing involved. How did you send
this many messages? Did you use ActiveMessageC? If so, then packets
travel through the whole stack and that also takes some time to
process.

Best,
Miklos

On Thu, Feb 2, 2012 at 12:03 PM, Selahattin Kosunalp
sk...@ohm.york.ac.uk wrote:
 Hi Miklos,

 Thanks for your answer, I am trying to determine the limitations that how
 many packets can be transmitted in a second with iris nodes. Basically,
 the packet size is 36-bytes and transmission rate is 250 kbit. The time
 taken to transmit a packet is (36*8) / 250 =1.15 ms. So, I expect to
 transmit and receive 1000 / 1.15 = 870 packets/second. I turned Backoff,
 CCA and Software-ACK off, nonetheless around 500 packets are transmitted
 and received in a second, so the question is why?. Is it due to the
 processing time or is the transmission rate really equal to 250 kbit?. Am
 I missing something different at this point?

 Best Wishes,
 Hi!

 I do not really understand your problem. The radio can either transmit
 or receive a message, not both at the same time (half duplex). If you
 want to transmit a message while the radio is currently receiving one,
 then the SOFWTARE (the driver running on the microcontroller) will
 wait till the reception completes, and only then uploads the outgoing
 message to the radio chip and transmits it. Hope this helps.

 Best,
 Miklos

 On Thu, Jan 19, 2012 at 5:42 PM, Selahattin Kosunalp
 sk...@ohm.york.ac.uk wrote:
 Hi Miklós,

 I am currently working in tinyos and struggling a problem, I have seen
 some of your comments about the problem. The problem is that packet
 reception simultaneously. As I read your comment, during a transmission
 if
 another packet arrives, radio stack buffers up coming signals and result
 in the first Receive interface. This is known Overlapping problem in
 literature and most mac protocols assume that if overlapping happens,
 collided packets are discarded. From this perspective, I would like
 receiver to not buffer up new packet after a reception is done.

 Would you recommend any interesting idea to do so?,

 Best wishes,


 Selahattin Kosunalp
 PhD Research Student
 Communications Research Group,
 Department of Electronics,
 University of York,
 Heslington, York, YO10 5DD
 Email: sk...@ohm.york.ac.uk




 Selahattin Kosunalp
 PhD Research Student
 Communications Research Group,
 Department of Electronics,
 University of York,
 Heslington, York, YO10 5DD
 Email: sk...@ohm.york.ac.uk


___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Help for Tinyos

[Miklos Maroti]

Hi Selahattin,

Ok, here are the fields:

4 bytes preamble
1 byte sync
1 byte length
2 bytes FCF (frame type)
1 byte DSN (sequence number)
1 byte dest PAN (group id)
2 bytes dest addr
2 bytes source addr
1 byte network type for 6lowpan
1 byte AM message type
28 bytes payload
2 bytes crc

this is 46 bytes. The speed of the radio is 250 kbps, which is 31250
bytes per sec. So you should be able to transmit 679 messages per
second.  Everything else is overhead (downloaded/uploaded messages via
the SPI, processing, tasks, etc). You can calculate the overhead in
bytes from the observed 500 messages per second: 31250 / 500 = 62.5
bytes, so the MCU processing time overhead is around 16.5 bytes which
is around 0.528 millisecond per message.

Best,
Miklos


On Thu, Feb 2, 2012 at 12:32 PM, Selahattin Kosunalp
sk...@ohm.york.ac.uk wrote:
 I employed 28-bytes data payload, I think the header is 8-bytes
 long(destination, Source, Length, Group id, Message type), As far as I
 know, the header is automatically added by tinyos, I did not do anything
 for header. When a packet arrives, I display it on a PC using serial java
 app. Then I can see the header fields. Again, I did not include CRC,
 preamle and sync bytes, I just defined a meessage_t variable and send it,
 Can we work out the processing time?
 I define a task to send messages using Amsend interface, at first my code
 transmits a message when sendDone is signaled, I call post the the task
 and send next message, kind of continues transmission. I observe that how
 many times sendDone is signaled in a second, then I got around 500 times.
 Hi Selahattin!

 How did you get the 36 byte value? Did you include all headers and the
 CRC? Did you include the 4-byte preamble and the sync byte? Also,
 there is a significant amount of processing involved. How did you send
 this many messages? Did you use ActiveMessageC? If so, then packets
 travel through the whole stack and that also takes some time to
 process.

 Best,
 Miklos

 On Thu, Feb 2, 2012 at 12:03 PM, Selahattin Kosunalp
 sk...@ohm.york.ac.uk wrote:
 Hi Miklos,

 Thanks for your answer, I am trying to determine the limitations that
 how
 many packets can be transmitted in a second with iris nodes. Basically,
 the packet size is 36-bytes and transmission rate is 250 kbit. The time
 taken to transmit a packet is (36*8) / 250 =1.15 ms. So, I expect to
 transmit and receive 1000 / 1.15 = 870 packets/second. I turned Backoff,
 CCA and Software-ACK off, nonetheless around 500 packets are transmitted
 and received in a second, so the question is why?. Is it due to the
 processing time or is the transmission rate really equal to 250 kbit?.
 Am
 I missing something different at this point?

 Best Wishes,
 Hi!

 I do not really understand your problem. The radio can either transmit
 or receive a message, not both at the same time (half duplex). If you
 want to transmit a message while the radio is currently receiving one,
 then the SOFWTARE (the driver running on the microcontroller) will
 wait till the reception completes, and only then uploads the outgoing
 message to the radio chip and transmits it. Hope this helps.

 Best,
 Miklos

 On Thu, Jan 19, 2012 at 5:42 PM, Selahattin Kosunalp
 sk...@ohm.york.ac.uk wrote:
 Hi Miklà ³s,

 I am currently working in tinyos and struggling a problem, I have seen
 some of your comments about the problem. The problem is that packet
 reception simultaneously. As I read your comment, during a
 transmission
 if
 another packet arrives, radio stack buffers up coming signals and
 result
 in the first Receive interface. This is known Overlapping problem in
 literature and most mac protocols assume that if overlapping happens,
 collided packets are discarded. From this perspective, I would like
 receiver to not buffer up new packet after a reception is done.

 Would you recommend any interesting idea to do so?,

 Best wishes,


 Selahattin Kosunalp
 PhD Research Student
 Communications Research Group,
 Department of Electronics,
 University of York,
 Heslington, York, YO10 5DD
 Email: sk...@ohm.york.ac.uk




 Selahattin Kosunalp
 PhD Research Student
 Communications Research Group,
 Department of Electronics,
 University of York,
 Heslington, York, YO10 5DD
 Email: sk...@ohm.york.ac.uk




 Selahattin Kosunalp
 PhD Research Student
 Communications Research Group,
 Department of Electronics,
 University of York,
 Heslington, York, YO10 5DD
 Email: sk...@ohm.york.ac.uk


___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Help for Tinyos

[Miklos Maroti]

Look at the apps/tests/rfxlink/RadioSniffer application. In
particular, if you define the RADIO_DEBUG_MESSAGES define in your
makefile, then it will print out messages with the DiagMsg framework.
You can display these using the java net.tinyos.tools.DiagMsg
application. Miklos

On Thu, Feb 2, 2012 at 1:05 PM, Selahattin Kosunalp
sk...@ohm.york.ac.uk wrote:
 Hi Miklos,

 That is fairly clear, thanks a lot for your lovely knowledge. The only
 thing, Can we display all the fields on a PC when a packet is received?
 because I am using java serial application to display the messages
 received, I only see destination, Source, Length, Group id, Message
 type.
 Hi Selahattin,

 Ok, here are the fields:

 4 bytes preamble
 1 byte sync
 1 byte length
 2 bytes FCF (frame type)
 1 byte DSN (sequence number)
 1 byte dest PAN (group id)
 2 bytes dest addr
 2 bytes source addr
 1 byte network type for 6lowpan
 1 byte AM message type
 28 bytes payload
 2 bytes crc

 this is 46 bytes. The speed of the radio is 250 kbps, which is 31250
 bytes per sec. So you should be able to transmit 679 messages per
 second.  Everything else is overhead (downloaded/uploaded messages via
 the SPI, processing, tasks, etc). You can calculate the overhead in
 bytes from the observed 500 messages per second: 31250 / 500 = 62.5
 bytes, so the MCU processing time overhead is around 16.5 bytes which
 is around 0.528 millisecond per message.

 Best,
 Miklos


 On Thu, Feb 2, 2012 at 12:32 PM, Selahattin Kosunalp
 sk...@ohm.york.ac.uk wrote:
 I employed 28-bytes data payload, I think the header is 8-bytes
 long(destination, Source, Length, Group id, Message type), As far as I
 know, the header is automatically added by tinyos, I did not do anything
 for header. When a packet arrives, I display it on a PC using serial
 java
 app. Then I can see the header fields. Again, I did not include CRC,
 preamle and sync bytes, I just defined a meessage_t variable and send
 it,
 Can we work out the processing time?
 I define a task to send messages using Amsend interface, at first my
 code
 transmits a message when sendDone is signaled, I call post the the task
 and send next message, kind of continues transmission. I observe that
 how
 many times sendDone is signaled in a second, then I got around 500
 times.
 Hi Selahattin!

 How did you get the 36 byte value? Did you include all headers and the
 CRC? Did you include the 4-byte preamble and the sync byte? Also,
 there is a significant amount of processing involved. How did you send
 this many messages? Did you use ActiveMessageC? If so, then packets
 travel through the whole stack and that also takes some time to
 process.

 Best,
 Miklos

 On Thu, Feb 2, 2012 at 12:03 PM, Selahattin Kosunalp
 sk...@ohm.york.ac.uk wrote:
 Hi Miklos,

 Thanks for your answer, I am trying to determine the limitations that
 how
 many packets can be transmitted in a second with iris nodes.
 Basically,
 the packet size is 36-bytes and transmission rate is 250 kbit. The
 time
 taken to transmit a packet is (36*8) / 250 =1.15 ms. So, I expect to
 transmit and receive 1000 / 1.15 = 870 packets/second. I turned
 Backoff,
 CCA and Software-ACK off, nonetheless around 500 packets are
 transmitted
 and received in a second, so the question is why?. Is it due to the
 processing time or is the transmission rate really equal to 250 kbit?.
 Am
 I missing something different at this point?

 Best Wishes,
 Hi!

 I do not really understand your problem. The radio can either
 transmit
 or receive a message, not both at the same time (half duplex). If you
 want to transmit a message while the radio is currently receiving
 one,
 then the SOFWTARE (the driver running on the microcontroller) will
 wait till the reception completes, and only then uploads the outgoing
 message to the radio chip and transmits it. Hope this helps.

 Best,
 Miklos

 On Thu, Jan 19, 2012 at 5:42 PM, Selahattin Kosunalp
 sk...@ohm.york.ac.uk wrote:
 Hi Miklà  Ã ³s,

 I am currently working in tinyos and struggling a problem, I have
 seen
 some of your comments about the problem. The problem is that packet
 reception simultaneously. As I read your comment, during a
 transmission
 if
 another packet arrives, radio stack buffers up coming signals and
 result
 in the first Receive interface. This is known Overlapping problem in
 literature and most mac protocols assume that if overlapping
 happens,
 collided packets are discarded. From this perspective, I would like
 receiver to not buffer up new packet after a reception is done.

 Would you recommend any interesting idea to do so?,

 Best wishes,


 Selahattin Kosunalp
 PhD Research Student
 Communications Research Group,
 Department of Electronics,
 University of York,
 Heslington, York, YO10 5DD
 Email: sk...@ohm.york.ac.uk




 Selahattin Kosunalp
 PhD Research Student
 Communications Research Group,
 Department of Electronics,
 University of York,
 Heslington, York, YO10 5DD
 Email: sk...@ohm.york.ac.uk




 Selahattin 

Re: [Tinyos-help] Running TinyOS over Zigbit (not Meshbean)

[Miklos Maroti]

Hi Sergio,

Can you send us your RadioConfig.h file? Is it the same as that for
the IRIS? The two platforms should essentially be completely
compatible, so I would like to see what causes the problems. I assume
that you are running the latest SVN version.

Best,
Miklos

2012/2/2 András Bíró bband...@gmail.com:
 Hi Sergio,

 Sorry, I thought you're using the 868/900 MHz version. My changes are
 only for the rf212 (or other slower than 250kbps radios). The rf230
 should work, it's well tested on the iris motes.

 Andris

 2012/2/1 Sergio Gonzalez serg...@ece.ubc.ca:
 Hi Andris,

 Thanks for the prompt response. I am working with the 2.4 GHz version of the
 Zigbit, so I updated my /tos/lib/rfxlink and /tos/chips/rf230 accordingly,
 but things remain the same. I see that you made several changes to some
 files in the RF212 directory. I'll see whether they are directly applicable
 to the RF230.

 I haven't checked to see whether all registers and operation procedures are
 the same for both chips. However, your changes apply to the SW ACK option,
 so my take is that even if I don't port the new RF212 changes into the RF230
 branch, shouldn't I be able to at least get the HW ACKs working? I wonder
 whether the problem arises due to (mis-)wiring in the corresponding
 configuration files. I'll keep digging.

 Thanks,

 Sergio



 On 02/01/2012 01:13 AM, András Bíró wrote:

 Hi Eric,

 It uses the svn version of rfxlink, but there wasn't any big change in
 that recently, I think it should work with older versions too.
 Anyway, if you wan't to be sure, update the /tos/lib/rfxlink and
 /tos/chips/rf230 directories too.

 Andris

 2012/2/1 Eric Deckercire...@gmail.com:


 2012/2/1 András Bíróbband...@gmail.com

 Hi Sergio,

 I corrected a bunch of timing error on the rf212 radio with the help
 of Miklos, try updating the /tos/chips/rf212 directory from the main
 svn (http://tinyos-main.googlecode.com/svn/trunk/).


 How independent is the rf212 stack?

 Is it reasonable to update just that part of the tree or are there
 dependencies to the main SVN trunk?


 Andris

 On Wed, Feb 1, 2012 at 5:55 AM, Sergio Gonzalezserg...@ece.ubc.ca
 wrote:

 Hi Miklos,

 I am using the files that you sent a few months back and they work
 well,
 except that the Zigbits do not issue neither software nor hardware ACKs
 when prompted (just noticed today). I made sure to include the usual
 Packet.clear(msg) and PacketAcknowledgements.requestAck(msg) before
 sending packets, so I have no idea why this is. I have read and
 followed
 advice from older posts (e.g., increasing SOFTWAREACK_TIMEOUT to 1000
 or
 even 2000, defining PACKET_LINK, etc.) with no luck.

 Any ideas?

 Thanks!

 Sergio


 On 11/05/2011 11:39 PM, Miklos Maroti wrote:

 Hi Sergio,

 On Sun, Oct 30, 2011 at 9:51 PM, Sergio Gonzalezserg...@ece.ubc.ca
  wrote:

 Hi Miklos,

 Thanks for your help! I was already employing the files available
 from
 the
 tinyos-contrib link that you mention. However, the IO configuration
 setup
 defined in those files corresponds to the physical wirings in the
 IRIS
 mote,

 I have attached the files from THAT repository, so you must not have
 the latest version of tinyos-contrib, or using something different.

 not Zigbit. So, I replaced those with the ones you forwarded and I've
 got
 the radio working now. Except for one line, the modifications I had
 mentioned in my previous email were spot on though. So, just for the
 record,
 the correct ones are:

     ...
     HplRF230P.PortIRQ -    IO.PortE5;
     ...
     SLP_TR = IO.PortB4;
     RSTN = IO.PortA7;
     SELN = IO.PortB0;
     ...

 The line HplRF230P.PortCLKM -    IO.PortD6; is not needed anymore
 in
 HplRF230C.nc

 Glad that it worked out for you.

 Best,
 Miklos

 Thanks again!

 Sergio


 Hi Sergio,

 Look at the meshbean platform in


 tinyos-2.x-contrib/ethz/meshbean900/tos/platforms/meshbean/chips/rf230

 I have the attached files there, and I am sure these will be good
 for
 your platform as well.

 Best,
 Miklos

 On Sat, Oct 29, 2011 at 4:27 AM, Sergio Gonzalezserg...@ece.ubc.ca
   wrote:

 Hi Miklos,

 Thank you so much for your previous help. I ended up designing new
 boards
 for my custom zigbit implementation and finally got TinyOS running
 on
 them.
 So far I've got LEDs blinking and serial comms (TestSerial
  Printf)
 working. However, I have been unable to get the radio working.

 The only thing I've noticed so far is what appears to be an
 incorrect pin
 configuration in /tos/platforms/zigbit/chips/rf320/HplRF230C.nc
 that
 does
 not correspond to the presupposed internal pins connections in the
 zigbit
 module. The original file specifies the following configuration:

 ? ?...
 ? ?HplRF230P.PortCLKM -      IO.PortD6;
 ? ?HplRF230P.PortIRQ -      IO.PortD4;
 ? ?...
 ? ?SLP_TR = IO.PortB7;
 ? ?RSTN = IO.PortA6;
 ? ?SELN = IO.PortB0;
 ? ?...

 Obviously, this configuration is intended for the IRIS mote, so I
 changed
 it
 for zigbit as follows

Re: [Tinyos-help] Snoop packets RF230

[Miklos Maroti]

Hi David!

You should look at lib/rfxlink/layers/Ieee154MessageLayerC.nc. There
is the isForMe command on line 142. However, snoop is not yet
implemented in the Ieee154MessageC component, but it would be trivial
to do so, but it requires quite a bit of wiring.

Best,
Miklos

On Mon, Jan 30, 2012 at 5:43 PM, Wacka wacka wackam...@gmail.com wrote:
 Hi again Miklos,

 Thanks for your quick reply. Excuse me, wether I insist,but,is there no way
 to snoop the packets with my own sniffer?I mean.. I'm trying to find
 ieeepacketlayer.isForMe(message) in rf230 folder or something like that..,
 but I can't manage to work it out. In the CC2420 is easy to find.. though
 with IRIS.. I'm becoming crazy.

 Is not possible by software or..?

 Thanks again for your time. You're really helpfull.

 David


 On Mon, Jan 30, 2012 at 5:05 PM, Miklos Maroti mmar...@math.u-szeged.hu
 wrote:

 Hi! Soory, no readme :( Just compile it with make iris, upload it to
 your mote, then run

 java net.tinyos.tools.DiagMsg -comm xxx

 where xxx is your usual serial port settigs, e.g. serial@/ttyUSB0:iris
 or something similar. It will print out messages that it sees to the
 console. Hope it helps.

 Best,
 Miklos

 On Mon, Jan 30, 2012 at 4:32 PM, Wacka wacka wackam...@gmail.com wrote:
  Hi Miklos,
 
  Apologize me, but there is not README file in
  apps/tests/rfxlink/PacketSniffer nor apps/tests/rfxlink/RadioSniffer,
  even
  in the sourceforge/googlecode repository. Nevertheless, I've build my
  own
  specifc sniffer, (I only want to snoop some kind of packets), so I only
  need
  how to let any packet to go up .
 
  Thanks for your time
 
 
  On Mon, Jan 30, 2012 at 2:08 PM, Miklos Maroti
  mmar...@math.u-szeged.hu
  wrote:
 
  Hi!
 
  Use apps/tests/rfxlink/PacketSniffer, read the README there.
 
  Miklos
 
  On Mon, Jan 30, 2012 at 2:04 PM, Correo de Wacka yo_wa...@hotmail.com
  wrote:
  
   Hi all,
  
   I'm trying to snoop packets using RF230 iris mote. As I've read, If
   hard
   acks are enabled, you can't snoop packets, but,how am I able to snoop
   packets if I'm not using hardware acks??? Any makefile command??
  
   Thanks for your time
  
   Best regards
  
   -Er wacka -
 
 



___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Running TinyOS over Zigbit (not Meshbean)

[Miklos Maroti]

Hi!

It looks ok. Are you sure that your TOne clock runs at the right
frequency of 1 MHz? Try setting your RADIO_ALARM_MICROSEC to 1
manually and RADIO_ALARM_MILLI_EXP to 10 manually as in the
RadioConfig.h.

Also, before you do anything, compile RadioCountToLeds or your
application with RADIO_DEBUG defined in your makefile (you should
observe that the application gets bigger). Then run this and connect
it to your PC with a serial and on that run

java net.tinyos.tools.DiagMsg

This might print out useful information on what is failing in your setup.

Best,
Miklos

On Fri, Feb 3, 2012 at 2:10 AM, Sergio Gonzalez serg...@ece.ubc.ca wrote:
 Hi Miklos,

 A copy of my RadioConfig.h file is attached. I am not running the latest SVN
 version, but I recently updated the files in both lib/rfxlink and in
 tos/chips/rf2xx/rf230. I wonder whether the problem occurs if my zigbits'
 clocks are uncalibrated.


 Thanks for your help!

 Sergio


 On 02/02/2012 03:05 PM, Miklos Maroti wrote:

 Hi Sergio,

 Can you send us your RadioConfig.h file? Is it the same as that for
 the IRIS? The two platforms should essentially be completely
 compatible, so I would like to see what causes the problems. I assume
 that you are running the latest SVN version.

 Best,
 Miklos

 2012/2/2 András Bíróbband...@gmail.com:

 Hi Sergio,

 Sorry, I thought you're using the 868/900 MHz version. My changes are
 only for the rf212 (or other slower than 250kbps radios). The rf230
 should work, it's well tested on the iris motes.

 Andris

 2012/2/1 Sergio Gonzalezserg...@ece.ubc.ca:

 Hi Andris,

 Thanks for the prompt response. I am working with the 2.4 GHz version of
 the
 Zigbit, so I updated my /tos/lib/rfxlink and /tos/chips/rf230
 accordingly,
 but things remain the same. I see that you made several changes to some
 files in the RF212 directory. I'll see whether they are directly
 applicable
 to the RF230.

 I haven't checked to see whether all registers and operation procedures
 are
 the same for both chips. However, your changes apply to the SW ACK
 option,
 so my take is that even if I don't port the new RF212 changes into the
 RF230
 branch, shouldn't I be able to at least get the HW ACKs working? I
 wonder
 whether the problem arises due to (mis-)wiring in the corresponding
 configuration files. I'll keep digging.

 Thanks,

 Sergio



 On 02/01/2012 01:13 AM, András Bíró wrote:

 Hi Eric,

 It uses the svn version of rfxlink, but there wasn't any big change in
 that recently, I think it should work with older versions too.
 Anyway, if you wan't to be sure, update the /tos/lib/rfxlink and
 /tos/chips/rf230 directories too.

 Andris

 2012/2/1 Eric Deckercire...@gmail.com:


 2012/2/1 András Bíróbband...@gmail.com

 Hi Sergio,

 I corrected a bunch of timing error on the rf212 radio with the help
 of Miklos, try updating the /tos/chips/rf212 directory from the main
 svn (http://tinyos-main.googlecode.com/svn/trunk/).


 How independent is the rf212 stack?

 Is it reasonable to update just that part of the tree or are there
 dependencies to the main SVN trunk?

 Andris

 On Wed, Feb 1, 2012 at 5:55 AM, Sergio Gonzalezserg...@ece.ubc.ca
 wrote:

 Hi Miklos,

 I am using the files that you sent a few months back and they work
 well,
 except that the Zigbits do not issue neither software nor hardware
 ACKs
 when prompted (just noticed today). I made sure to include the usual
 Packet.clear(msg) and PacketAcknowledgements.requestAck(msg)
 before
 sending packets, so I have no idea why this is. I have read and
 followed
 advice from older posts (e.g., increasing SOFTWAREACK_TIMEOUT to
 1000
 or
 even 2000, defining PACKET_LINK, etc.) with no luck.

 Any ideas?

 Thanks!

 Sergio


 On 11/05/2011 11:39 PM, Miklos Maroti wrote:

 Hi Sergio,

 On Sun, Oct 30, 2011 at 9:51 PM, Sergio
 Gonzalezserg...@ece.ubc.ca
  wrote:

 Hi Miklos,

 Thanks for your help! I was already employing the files available
 from
 the
 tinyos-contrib link that you mention. However, the IO
 configuration
 setup
 defined in those files corresponds to the physical wirings in the
 IRIS
 mote,

 I have attached the files from THAT repository, so you must not
 have
 the latest version of tinyos-contrib, or using something different.

 not Zigbit. So, I replaced those with the ones you forwarded and
 I've
 got
 the radio working now. Except for one line, the modifications I
 had
 mentioned in my previous email were spot on though. So, just for
 the
 record,
 the correct ones are:

     ...
     HplRF230P.PortIRQ -      IO.PortE5;
     ...
     SLP_TR = IO.PortB4;
     RSTN = IO.PortA7;
     SELN = IO.PortB0;
     ...

 The line HplRF230P.PortCLKM -      IO.PortD6; is not needed
 anymore
 in
 HplRF230C.nc

 Glad that it worked out for you.

 Best,
 Miklos

 Thanks again!

 Sergio


 Hi Sergio,

 Look at the meshbean platform in



 tinyos-2.x-contrib/ethz/meshbean900/tos/platforms/meshbean/chips/rf230

 I have the attached files there, and I am sure these will be good
 for
 your

Re: [Tinyos-help] Running TinyOS over Zigbit (not Meshbean)

[Miklos Maroti]

Well, the clock has a binary prescaller, so whatever close you can get
to 1 MHz it is fine. Then you can define RADIO_ALARM_MICROSEC  to
anything you like to get the correct number of timer ticks per 1
microsecond (decimal). But it really does not matter, this value is
used only for timing purposed (ack timeout, backoff) and a little
error is not a big problem there. Miklos

On Fri, Feb 3, 2012 at 2:26 AM, Eric Decker cire...@gmail.com wrote:


 On Thu, Feb 2, 2012 at 5:19 PM, Miklos Maroti mmar...@math.u-szeged.hu
 wrote:

 Hi!

 It looks ok. Are you sure that your TOne clock runs at the right
 frequency of 1 MHz?


 Is this 1MHz or 1MiHz?   This may make a difference.


 Try setting your RADIO_ALARM_MICROSEC to 1
 manually and RADIO_ALARM_MILLI_EXP to 10 manually as in the
 RadioConfig.h.

 Also, before you do anything, compile RadioCountToLeds or your
 application with RADIO_DEBUG defined in your makefile (you should
 observe that the application gets bigger). Then run this and connect
 it to your PC with a serial and on that run

 java net.tinyos.tools.DiagMsg

 This might print out useful information on what is failing in your setup.

 Best,
 Miklos

 On Fri, Feb 3, 2012 at 2:10 AM, Sergio Gonzalez serg...@ece.ubc.ca
 wrote:
  Hi Miklos,
 
  A copy of my RadioConfig.h file is attached. I am not running the latest
  SVN
  version, but I recently updated the files in both lib/rfxlink and in
  tos/chips/rf2xx/rf230. I wonder whether the problem occurs if my
  zigbits'
  clocks are uncalibrated.
 
 
  Thanks for your help!
 
  Sergio
 
 
  On 02/02/2012 03:05 PM, Miklos Maroti wrote:
 
  Hi Sergio,
 
  Can you send us your RadioConfig.h file? Is it the same as that for
  the IRIS? The two platforms should essentially be completely
  compatible, so I would like to see what causes the problems. I assume
  that you are running the latest SVN version.
 
  Best,
  Miklos
 
  2012/2/2 András Bíróbband...@gmail.com:
 
  Hi Sergio,
 
  Sorry, I thought you're using the 868/900 MHz version. My changes are
  only for the rf212 (or other slower than 250kbps radios). The rf230
  should work, it's well tested on the iris motes.
 
  Andris
 
  2012/2/1 Sergio Gonzalezserg...@ece.ubc.ca:
 
  Hi Andris,
 
  Thanks for the prompt response. I am working with the 2.4 GHz version
  of
  the
  Zigbit, so I updated my /tos/lib/rfxlink and /tos/chips/rf230
  accordingly,
  but things remain the same. I see that you made several changes to
  some
  files in the RF212 directory. I'll see whether they are directly
  applicable
  to the RF230.
 
  I haven't checked to see whether all registers and operation
  procedures
  are
  the same for both chips. However, your changes apply to the SW ACK
  option,
  so my take is that even if I don't port the new RF212 changes into
  the
  RF230
  branch, shouldn't I be able to at least get the HW ACKs working? I
  wonder
  whether the problem arises due to (mis-)wiring in the corresponding
  configuration files. I'll keep digging.
 
  Thanks,
 
  Sergio
 
 
 
  On 02/01/2012 01:13 AM, András Bíró wrote:
 
  Hi Eric,
 
  It uses the svn version of rfxlink, but there wasn't any big change
  in
  that recently, I think it should work with older versions too.
  Anyway, if you wan't to be sure, update the /tos/lib/rfxlink and
  /tos/chips/rf230 directories too.
 
  Andris
 
  2012/2/1 Eric Deckercire...@gmail.com:
 
 
  2012/2/1 András Bíróbband...@gmail.com
 
  Hi Sergio,
 
  I corrected a bunch of timing error on the rf212 radio with the
  help
  of Miklos, try updating the /tos/chips/rf212 directory from the
  main
  svn (http://tinyos-main.googlecode.com/svn/trunk/).
 
 
  How independent is the rf212 stack?
 
  Is it reasonable to update just that part of the tree or are there
  dependencies to the main SVN trunk?
 
  Andris
 
  On Wed, Feb 1, 2012 at 5:55 AM, Sergio
  Gonzalezserg...@ece.ubc.ca
  wrote:
 
  Hi Miklos,
 
  I am using the files that you sent a few months back and they
  work
  well,
  except that the Zigbits do not issue neither software nor
  hardware
  ACKs
  when prompted (just noticed today). I made sure to include the
  usual
  Packet.clear(msg) and PacketAcknowledgements.requestAck(msg)
  before
  sending packets, so I have no idea why this is. I have read and
  followed
  advice from older posts (e.g., increasing SOFTWAREACK_TIMEOUT to
  1000
  or
  even 2000, defining PACKET_LINK, etc.) with no luck.
 
  Any ideas?
 
  Thanks!
 
  Sergio
 
 
  On 11/05/2011 11:39 PM, Miklos Maroti wrote:
 
  Hi Sergio,
 
  On Sun, Oct 30, 2011 at 9:51 PM, Sergio
  Gonzalezserg...@ece.ubc.ca
   wrote:
 
  Hi Miklos,
 
  Thanks for your help! I was already employing the files
  available
  from
  the
  tinyos-contrib link that you mention. However, the IO
  configuration
  setup
  defined in those files corresponds to the physical wirings in
  the
  IRIS
  mote,
 
  I have attached the files from THAT repository, so you must not
  have
  the latest version of tinyos-contrib, or using

Re: [Tinyos-help] Running TinyOS over Zigbit (not Meshbean)

[Miklos Maroti]

Hi Sergio,

Can you use your usual application that does not produce ACKS and on a
second node run the apps/tests/rfxlink/RadioSniffer attached to a PC
and run java net.tinyos.tools.DiagMsg on that. That way we will see
what messages are transmitted and we will see the timing as well.

Miklos

On Fri, Feb 3, 2012 at 3:28 AM, Sergio Gonzalez serg...@ece.ubc.ca wrote:
 Hi Miklos,

 I compiled and installed RadioCountToLeds to my motes. There was no output
 on the screen after running java net.tinyos.util.DiagMsg -comm
 serial@/dev/ttyUSB0:57600. I know for a fact that the serial interface is
 working well because I can see the output of regular printf messages. I
 tried doing the same with my test application, but got the same result. I
 checked that the size of both binaries increased after defining
 -DRADIO_DEBUG in my makefiles.

 As you suggested, I also returned RADIO_ALARM_MICROSEC to 1 and
 RADIO_ALARM_MILLI_EXP to 10 manually. These were the original values, but I
 had changed them to reflect the most recent update as per the corresponding
 file in the SVN. Still no luck.

 Thanks for your help,

 Sergio



 On 02/02/2012 05:19 PM, Miklos Maroti wrote:

 Hi!

 It looks ok. Are you sure that your TOne clock runs at the right
 frequency of 1 MHz? Try setting your RADIO_ALARM_MICROSEC to 1
 manually and RADIO_ALARM_MILLI_EXP to 10 manually as in the
 RadioConfig.h.

 Also, before you do anything, compile RadioCountToLeds or your
 application with RADIO_DEBUG defined in your makefile (you should
 observe that the application gets bigger). Then run this and connect
 it to your PC with a serial and on that run

 java net.tinyos.tools.DiagMsg

 This might print out useful information on what is failing in your setup.

 Best,
 Miklos

 On Fri, Feb 3, 2012 at 2:10 AM, Sergio Gonzalezserg...@ece.ubc.ca
  wrote:

 Hi Miklos,

 A copy of my RadioConfig.h file is attached. I am not running the latest
 SVN
 version, but I recently updated the files in both lib/rfxlink and in
 tos/chips/rf2xx/rf230. I wonder whether the problem occurs if my zigbits'
 clocks are uncalibrated.


 Thanks for your help!

 Sergio


 On 02/02/2012 03:05 PM, Miklos Maroti wrote:

 Hi Sergio,

 Can you send us your RadioConfig.h file? Is it the same as that for
 the IRIS? The two platforms should essentially be completely
 compatible, so I would like to see what causes the problems. I assume
 that you are running the latest SVN version.

 Best,
 Miklos


 Quoted text from email thread omitted

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Snoop packets RF230

[Miklos Maroti]

Hi!

Use apps/tests/rfxlink/PacketSniffer, read the README there.

Miklos

On Mon, Jan 30, 2012 at 2:04 PM, Correo de Wacka yo_wa...@hotmail.com wrote:

 Hi all,

 I'm trying to snoop packets using RF230 iris mote. As I've read, If hard
 acks are enabled, you can't snoop packets, but,how am I able to snoop
 packets if I'm not using hardware acks??? Any makefile command??

 Thanks for your time

 Best regards

 -Er wacka -

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Snoop packets RF230

[Miklos Maroti]

Hi! Soory, no readme :( Just compile it with make iris, upload it to
your mote, then run

java net.tinyos.tools.DiagMsg -comm xxx

where xxx is your usual serial port settigs, e.g. serial@/ttyUSB0:iris
or something similar. It will print out messages that it sees to the
console. Hope it helps.

Best,
Miklos

On Mon, Jan 30, 2012 at 4:32 PM, Wacka wacka wackam...@gmail.com wrote:
 Hi Miklos,

 Apologize me, but there is not README file in
 apps/tests/rfxlink/PacketSniffer nor apps/tests/rfxlink/RadioSniffer, even
 in the sourceforge/googlecode repository. Nevertheless, I've build my own
 specifc sniffer, (I only want to snoop some kind of packets), so I only need
 how to let any packet to go up .

 Thanks for your time


 On Mon, Jan 30, 2012 at 2:08 PM, Miklos Maroti mmar...@math.u-szeged.hu
 wrote:

 Hi!

 Use apps/tests/rfxlink/PacketSniffer, read the README there.

 Miklos

 On Mon, Jan 30, 2012 at 2:04 PM, Correo de Wacka yo_wa...@hotmail.com
 wrote:
 
  Hi all,
 
  I'm trying to snoop packets using RF230 iris mote. As I've read, If hard
  acks are enabled, you can't snoop packets, but,how am I able to snoop
  packets if I'm not using hardware acks??? Any makefile command??
 
  Thanks for your time
 
  Best regards
 
  -Er wacka -



___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] errors in 'make telosb sim'

[Miklos Maroti]

tossim works only for the micaz platform.

On Wed, Dec 21, 2011 at 7:46 AM, Tao Zheng tzheng...@gmail.com wrote:
 Hey, all



 In apps of Blink, I can compile tossim on platform micaz using commands
 ‘#make micaz sim’.

 But when I change platform in telosb, there are some errors as following,

 root@debian:/opt/tinyos-2.1.1/apps/Blink# make telosb sim

 mkdir -p simbuild/telosb

   placing object files in simbuild/telosb

   writing XML schema to app.xml

   compiling BlinkAppC to object file sim.o

 ncc -c -shared -fPIC -o simbuild/telosb/sim.o -g -O0 -O -tossim
 -fnesc-nido-tosnodes=1000 -fnesc-simulate
 -fnesc-nido-motenumber=sim_node\(\) -fnesc-gcc=gcc -mdisable-hwmul -Wall
 -Wshadow -Wnesc-all -target=telosb -fnesc-cfile=simbuild/telosb/app.c
 -board= -DDEFINED_TOS_AM_GROUP=0x22 -DIDENT_APPNAME=\BlinkAppC\
 -DIDENT_USERNAME=\root\ -DIDENT_HOSTNAME=\debian\
 -DIDENT_USERHASH=0x0dbc5c03L -DIDENT_TIMESTAMP=0x4ef1806fL
 -DIDENT_UIDHASH=0x8786a72dL -I/usr/include/python2.6/ -Wno-nesc-data-race
 BlinkAppC.nc   -fnesc-dump=components -fnesc-dump=variables
 -fnesc-dump=constants -fnesc-dump=typedefs -fnesc-dump=interfacedefs
 -fnesc-dump=tags -fnesc-dumpfile=app.xml

 Unknown target telosb

 Known targets for TinyOS directory /opt/tinyos-2.1.1/tos

 and the specified include directories are:

   micaz telosb mica2dot telosa intelmote2 null epic shimmer2 iris shimmer
 mica2 tinynode eyesIFXv2 eyesIFXv1 mulle

 make: *** [sim-exe] Error 2



 I don't know why?



 Any suggestion is accepted and helpful.



 Thanks very much.


 ___
 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

Re: [Tinyos-help] IRIS support on current Blip Version

[Miklos Maroti]

Hi Johny,

I have looked briefly at your patch. There are a lot of changes, and
it will take time to sort out all these to my satisfaction. What we
could do is the following, if you are willing to go along:

I will create a new branch on my git repository, this is going to be
based on the current tinyos.main SVN repo. I will incorporate some of
your changes and prepare the commits. Each change will not break any
other code. I would like to go as slowly as possibly. After each
change I would like to look at the remaining issues in a separate
diff. Alternatively, it would be nice if you have a public git repo I
can look at (and some instructions on what to use and what to ignore).

The RF212 code base is fine, once that is done, it will be trivial to
support other rfxlink stacks.  Maybe I will do the RF230 synchronously
so I can compile the changes myself.

I cannot compile the current tinyos-main for telosb, it gives some
compiler errors. Do you see this too? Can you compile your version for
telosb? (Of course I assume it compiles with cc2420x.

Best,
Miklos

On Wed, Nov 30, 2011 at 2:50 AM, Johny Mattsson jmatts...@dius.com.au wrote:
 On Wed, Nov 30, 2011 at 8:17 AM, Miklos Maroti mmar...@math.u-szeged.hu
 wrote:

 I will update the IRIS code to work with BLIP after the current
 release. I do not want to mess with the code before that to keep as
 stable as possible for the release.


 Cool. Let me pull together a fresh patch for you then - we've been doing a
 fair bit of internal BLIP-related work here that I'd love to see adopted
 upstream. We're using RF212 chips here, but I just got a bit of time
 allocated to make our changes work with the CC2420X driver as well, so I'm
 hoping that means it'll give you a good starting point if nothing else.

 Improvements we've got running here include:
 - BLIP on RF212
 - BLIP using extended IEEE 15.4 addresses (we can't assign static node IDs
 due to scale, so need DHCPv6 to work)
 - Support for both short and extended IEEE 15.4 addresses in rfxlink (I
 submitted most of this over in issue 30 already)
 - Support for on-chip frame filtering for short and extended addresses
 (needed to avoid packet storms when meshing, we discovered)
 - Support for larger IPv6 packet sizes (up to 1280)


 As I mentioned when I posted my first patch to the list, there are a few
 things that I'm definitely not happy about with it:
 - It doesn't resolve the confusion around the Send, BareSend and Ieee154Send
 interfaces - in many locations each of them gets renamed to another!
 - Both the BLIP and the Ieee154 packet layers hook into the
 TinyosNetworkLayerC's Ieee154Receive.receive, which is a very bad idea if
 the latter was ever used (it works for our cases, which is why I haven't
 been able to find time to fix it)
 - There should be a more elegant way of structuring this to support the AM,
 Ieee154 and BLIP stacks neatly next to each other. Again, I haven't had the
 time to even look at it, much less get a discussion happening on -dev.


 ** goes diffing in the internal repo **


 Okay, I've attached a patch here (it will get stripped for the list, I know
 - if anyone else wants a copy, just contact me off-list). This patch
 contains all the BLIP/RF212 related changes we have running here, and also
 dry-coded changes to make PppRouter and CoapBlip apps build for telosb using
 the cc2420x driver with our mods. The cc2420x changes should make it
 functionally equivalent to the RF212, but I have no hardware to verify it,
 sorry.


 To avoid any potential confusion: We're not using IRIS motes here at DiUS.
 We have custom hardware based around the LSR siflex02 chip (ATxmega256a3 +
 rf212), and also use LSR's modflex dev kit board. We're not yet ready to
 submit the x256a3/siflex02 platform support upstream however - there are
 some embarrassing issues there we still need to resolve :)


 Best regards,
 /Johny

 --
 Johny Mattsson
 Senior Software Engineer

 DiUS Computing Pty. Ltd.
 where ideas are engineered

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] IRIS support on current Blip Version

[Miklos Maroti]

Hi Guys,

I will update the IRIS code to work with BLIP after the current
release. I do not want to mess with the code before that to keep as
stable as possible for the release.

If you give instructions how to best reproduce the problem with the
current tinyos-main svn trunk line, then I might get this done before
on a separate git repository.

Best,
Miklos

On Tue, Nov 29, 2011 at 4:59 PM, Gabriel Neumüller
horsthuc...@googlemail.com wrote:
 Hi Johny,

 I’ve seen that patch already before. Sorry that I didn’t mention that. But
 for me I can’t compile the patched repository I tried the PppRouter-App if
 this matters.

 I applied the patch to different revisions (HEAD,
 9349b40df52930dc0cdb90a4c1d2da55a10c662a (Because it was the HEAD when the
 patch was posted) ).

 The first Error Message I get is:

 PlatformLed.h: No such file or directory

 In file included from /opt/tinyos-2.x.svn/tos/lib/ppp/PppC.nc:78,

  from /opt/tinyos-2.x.svn/tos/lib/ppp/PppDaemonC.nc:56,

  from PppRouterC.nc:16:

 In component `LedC':

 /opt/tinyos-2.x.svn/tos/system/LedC.nc:88: component PlatformLedC not found

 /opt/tinyos-2.x.svn/tos/system/LedC.nc:89: no match

 In file included from
 /opt/tinyos-2.x.svn/tos/lib/timer/MuxAlarmMilli32C.nc:47,

  from /opt/tinyos-2.x.svn/tos/lib/ppp/LcpAutomatonC.nc:72,

  from
 /opt/tinyos-2.x.svn/tos/lib/ppp/LinkControlProtocolC.nc:89,

      from /opt/tinyos-2.x.svn/tos/lib/ppp/PppDaemonC.nc:65,

  from PppRouterC.nc:16:



 Regards, Gabriel





 Von: Johny Mattsson [mailto:jmatts...@dius.com.au]
 Gesendet: Montag, 28. November 2011 23:29
 An: Gabriel Neumüller
 Cc: tinyos-help@millennium.berkeley.edu
 Betreff: Re: [Tinyos-help] IRIS support on current Blip Version



 Hi Gabriel,

 A while back I posted a patch for getting BLIP to work with RF230/RF212
 chips to the tinyos-help list. It's not the proper way of integrating BLIP
 with these chips, but it does work (we rely on it internally here), so that
 might be enough for you too. Search for the archives for the thread BLIP
 2.0 with RF230/RF212 and you'll find it.

 Regards,
 /Johny

 On Tue, Nov 29, 2011 at 12:52 AM, Gabriel Neumüller
 horsthuc...@googlemail.com wrote:

 Hi all,

 I tried to use the current Blip version with an IRIS Mote, but it seems,
 that it only works with Motes which use cc2420 Chips. So I checked out the
 git revision 48ca7e33cad3c69243800a213208ba1bf032c014  or in svn I think
 it’s rev 5611 . With this version Blip also works with the IRIS Mote. But it
 seems there was a big change between this two versions, so I don’t think it
 makes sense to use the older one.

 Does it make sense, trying to adapt the current blip version to IRIS or is
 there a major change planned? Or is somebody already working on this task?

 Can I use the older version for my project or should I work with the newer
 one?



 Thanks

 Gabriel Neumüller


 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help




 --
 Johny Mattsson
 Senior Software Engineer

 DiUS Computing Pty. Ltd.
 where ideas are engineered


 ___
 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

Re: [Tinyos-help] IRIS support on current Blip Version

[Miklos Maroti]

Hi Johny,

I have done the platform led stuff for IRIS, that is not the problem,
i am committing it now...

Next step: do the AlarmMilli32C, since the IRIS does not have one. It
uses the async Timer 2, which comes with its own limitations.
Currently it uses a single compare register, so it supports a single
alarm, which is already used by the timer subsystem. I need to think
about this.

Best,
Miklos

On Wed, Nov 30, 2011 at 1:47 AM, Johny Mattsson jmatts...@dius.com.au wrote:
 Hi Gabriel,

 Ah, the PlatformLed stuff. I just commented that out in the PppRouter app,
 it's not exactly crucial stuff. :)

 Cheers,
 /Johny


 On Wed, Nov 30, 2011 at 2:59 AM, Gabriel Neumüller
 horsthuc...@googlemail.com wrote:

 Hi Johny,

 I’ve seen that patch already before. Sorry that I didn’t mention that. But
 for me I can’t compile the patched repository I tried the PppRouter-App if
 this matters.

 I applied the patch to different revisions (HEAD,
 9349b40df52930dc0cdb90a4c1d2da55a10c662a (Because it was the HEAD when the
 patch was posted) ).

 The first Error Message I get is:

 PlatformLed.h: No such file or directory

 In file included from /opt/tinyos-2.x.svn/tos/lib/ppp/PppC.nc:78,

  from /opt/tinyos-2.x.svn/tos/lib/ppp/PppDaemonC.nc:56,

  from PppRouterC.nc:16:

 In component `LedC':

 /opt/tinyos-2.x.svn/tos/system/LedC.nc:88: component PlatformLedC not
 found

 /opt/tinyos-2.x.svn/tos/system/LedC.nc:89: no match

 In file included from
 /opt/tinyos-2.x.svn/tos/lib/timer/MuxAlarmMilli32C.nc:47,

  from /opt/tinyos-2.x.svn/tos/lib/ppp/LcpAutomatonC.nc:72,

  from
 /opt/tinyos-2.x.svn/tos/lib/ppp/LinkControlProtocolC.nc:89,

      from /opt/tinyos-2.x.svn/tos/lib/ppp/PppDaemonC.nc:65,

  from PppRouterC.nc:16:



 Regards, Gabriel



 --
 Johny Mattsson
 Senior Software Engineer

 DiUS Computing Pty. Ltd.
 where ideas are engineered


 ___
 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

Re: [Tinyos-help] Question regarding scheduler modification

[Miklos Maroti]

Hi Sobit,

You cannot use any tasks in the implementtion of the scheduler and
there might be some other restrictions. I was bitten similarly with
weird wiring constraints. For sure, there are limitations on what can
be sued and what can be wired to in the implementation of the
scheduler.

Miklos

On Mon, Nov 21, 2011 at 8:59 PM, Sobit Thapa thapaso...@gmail.com wrote:
 Dear all,
 I am trying to modify tinyos scheduler. If I use Active message components
 in TinyScheduler, it is not compiled. I have made new component and tried to
 use it which provides Radio functionality to scheduler. Still, It also
 doesn't work and gives same error message when I call from TinyScheduler.
 So, is there any way to add Active Message Components and Radio components
 in TinyScheduler so that I can distribute task.
 Thanks in advance. Following is my error message:
 esc-dumpfile=build/micaz/wiring-check.xml BlinkAppC.nc -lm
 /opt/tinyos-2.x/tos/chips/cc2420/lpl/DummyLplC.nc:39:2: warning: #warning
 *** LOW POWER COMMUNICATIONS DISABLED ***
 In component `HilTimerMilliC.AlarmToTimerC':
 /opt/tinyos-2.x/tos/lib/timer/AlarmToTimerC.nc: In function `Alarm.fired':
 /opt/tinyos-2.x/tos/lib/timer/AlarmToTimerC.nc(HilTimerMilliC.AlarmToTimerC):71:
 fired.postTask not connected
 In component `Atm128SpiC.Arbiter.Arbiter':
 /opt/tinyos-2.x/tos/system/SimpleArbiterP.nc: In function
 `Resource.request':
 /opt/tinyos-2.x/tos/system/SimpleArbiterP.nc(Atm128SpiC.Arbiter.Arbiter):77:
 grantedTask.postTask not connected
 /opt/tinyos-2.x/tos/system/SimpleArbiterP.nc: In function
 `Resource.release':
 /opt/tinyos-2.x/tos/system/SimpleArbiterP.nc(Atm128SpiC.Arbiter.Arbiter):104:
 grantedTask.postTask not connected
 In component `CC2420CsmaP':
 /opt/tinyos-2.x/tos/chips/cc2420/csma/CC2420CsmaP.nc: In function
 `CC2420Transmit.sendDone':
 /opt/tinyos-2.x/tos/chips/cc2420/csma/CC2420CsmaP.nc:201:
 sendDone_task.postTask not connected
 In component `CC2420ReceiveP':
 /opt/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc: In function
 `RXFIFO.readDone':
 /opt/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc:300:
 receiveDone_task.postTask not connected
 In component `CC2420SpiP':
 /opt/tinyos-2.x/tos/chips/cc2420/spi/CC2420SpiP.nc: In function
 `Resource.request':
 /opt/tinyos-2.x/tos/chips/cc2420/spi/CC2420SpiP.nc:113: grant.postTask not
 connected
 /opt/tinyos-2.x/tos/chips/cc2420/spi/CC2420SpiP.nc: In function
 `Resource.release':
 /opt/tinyos-2.x/tos/chips/cc2420/spi/CC2420SpiP.nc:168: grant.postTask not
 connected
 In component `Atm128SpiP':
 /opt/tinyos-2.x/tos/chips/atm128/spi/Atm128SpiP.nc: In function
 `SpiPacket.send':
 /opt/tinyos-2.x/tos/chips/atm128/spi/Atm128SpiP.nc:256: zeroTask.postTask
 not connected

 Thanks.
 Regards,
 Sobit Thapa
 Graduate Research Assistant
 Texas State University
 ___
 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

Re: [Tinyos-help] Error while running Antitheft - Please define your sensorboard revision

[Miklos Maroti]

Dear Jenis,

The AntiTheft application uses the MTS300 sensor board, it will not
work with the MPR400.

Miklos

On Fri, Nov 18, 2011 at 8:23 PM, Modi, Jenis Ashokkumar
jenis.m...@email.wsu.edu wrote:
 Hi All,

 I am receiving error while running Antitheft application.

 P.S: I am using MPR400CB as a sensor board and MIB600CA, Ethernet Interface 
 board.

 1. As shown in instructions of AntiTheft, I am going to directory Nodes and 
 then trying to install application using this command.

 make mica2 install.0 eprb,192.168.10.500

 I got this error after executing the above line :

 mkdir -p build/mica2
    compiling AntiTheftAppC to a mica2 binary
 ncc -o build/mica2/main.exe  -Os -I%T/lib/net/ctp -I%T/lib/net 
 -I%T/lib/net/4bitle -I%T/lib/net/drip -fnesc-separator=__ -Wall -Wshadow 
 -Wnesc-all -target=mica2 -fnesc-cfile=build/mica2/app.c -board=mts300 
 -DDEFINED_TOS_AM_GROUP=0x22 --param max-inline-insns-single=10 
 -DIDENT_APPNAME=\AntiTheftAppC\ -DIDENT_USERNAME=\jenismodi\ 
 -DIDENT_HOSTNAME=\ubuntu\ -DIDENT_USERHASH=0x2c09a865L 
 -DIDENT_TIMESTAMP=0x4ec6aee3L -DIDENT_UIDHASH=0xd1f71a05L -fnesc-dump=wiring 
 -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs, 
 components)' -fnesc-dumpfile=build/mica2/wiring-check.xml AntiTheftAppC.nc -lm
 /home/jenismodi/Tinyos/release-2-1-2-pre/tos/sensorboards/mts300/PhotoTempDeviceC.nc:44:2:
  error: #error Please define your sensorboard revision: MTS300CA, MTS300CB, 
 MTS310CA, MTS310CB
 make: *** [exe0] Error 1

 2. So I tried to define my sensorboard variable before this script.

 SENSORBOARD=mpr400cb make mica2 install.0 eprb,192.168.10.500

 AFter executing this also, I am getting the same error as shown above.

 Could you tell me if there is anything wrong with above? and if yes, please 
 give the solution.

 Thanks  Regards,
 Jenis




 ___
 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