[Tinyos-help] Problem in Block Write

[kaustav das]

Hi,

I am facing problem in writing packet to flash of telosb mote. I am writing
10 packets  of 56 bytes each using blockwrite.write(). Though this function
returns SUCCESS blockwrite.writedone() is not getting called . As far as I
know this event is called after the writing. So this means write is not
finished after start. What may be the reason behind this? Am I doing any
mistake?

-- 
Kaustav Das,
M.Tech Student,
Department of CSE,
IIT Bombay
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] what motes are you using?

[Li, Haixia-OSU Stillwater]

Hello Eric,

Thanks.
 I also find the memsic. I asked the question in order to know what notes are 
popular now because I feel some people seem lose their interesting for WSN. 
And, one day, a professor asked me how can  I see the TinyOS. It seems most 
people don't like to use TinyOS. I want to know the prospects of the TinyOS and 
these nodes. Sorry for the ambiguous questions.

Thanks,
Haixia



From: Eric Decker [cire...@gmail.com]
Sent: Tuesday, April 17, 2012 9:56 PM
To: Li, Haixia-OSU Stillwater
Cc: tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] what motes are you using?


look at 
http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg35159.html

It will give you a link to memsic.

I found this by going to mail-archive.   Finding the tinyos-help mailing list: 
http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/

And then I searched that mailing list for "buying".   Found it in the first 2 
or 3 results.



On Tue, Apr 17, 2012 at 7:02 PM, Li, Haixia-OSU Stillwater 
mailto:hai...@ostatemail.okstate.edu>> wrote:
Hello all,

I am using IRIS motes. I would like to know what motes you are using because I 
find the Crossbow has been sold. If I want to buy new motes, can anyone give me 
any suggestions? What products do occupy the main WSN market?


Thanks.
Haixia Li


___
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

Re: [Tinyos-help] what motes are you using?

[Eric Decker]

look at
http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg35159.html

It will give you a link to memsic.

I found this by going to mail-archive.   Finding the tinyos-help mailing
list: http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/

And then I searched that mailing list for "buying".   Found it in the first
2 or 3 results.



On Tue, Apr 17, 2012 at 7:02 PM, Li, Haixia-OSU Stillwater <
hai...@ostatemail.okstate.edu> wrote:

>  Hello all,
>
> I am using IRIS motes. I would like to know what motes you are using
> because I find the Crossbow has been sold. If I want to buy new motes, can
> anyone give me any suggestions? What products do occupy the main WSN
> market?
>
>
> Thanks.
> Haixia Li
>
>
> ___
> 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] [Researchers] 15th ACM* International Conference onModelingAnalysis and Simulation of Wireless and Mobile Systems

[Profa Dra Mirela Sechi Moretti Annoni Notare]

--
Our apology if you received multiple copies of this CFP
--

Call for Papers - ACM* MSWiM 2012

The 15th ACM* International Conference on Modeling Analysis
and Simulation of Wireless and Mobile Systems

October 21-25, 2012, Paphos, Cyprus

http://mswimconf.com/

Submission deadline: May 5, 2012

[* ACM Sponsorship pending upon Approval]



MSWiM is an international forum dedicated to high level discussion of
Wireless and Mobile systems, networks, algorithms and applications,
with an emphasis on rigorous performance evaluation. MSWiM is a
highly selective conference with a long track record of publishing
innovative ideas and breakthroughs.

Authors are encouraged to submit full papers presenting new research
related to the theory or practice of all aspects of modeling,
analysis and simulation of mobile and wireless systems. Submitted
papers must not have been published elsewhere nor currently be under
review by another conference or journal.


Topics of Interest

Papers related to wireless and mobile network Modeling, Analysis, Design,
and Simulation are solicited on, but not limited to, the following topics
in mobile and wireless systems:

* Performance evaluation and modeling
* Analytical Models
* Simulation languages and tools for wireless systems
* Wireless measurements tools and experiences
* Formal methods for analysis of wireless systems
* Correctness, survivability and reliability evaluation
* Mobility modeling and management
* Models and protocols for cognitive radio networks
* Models and protocols for autonomic, or self-* networks
* Capacity, coverage and connectivity modeling and analysis
* Wireless network algorithms and protocols
* Wireless PANs, LANs
* Ad hoc networks
* Sensor and actuator networks
* Delay Tolerant Networks
* Vehicular ad hoc networks
* Integration of wired and wireless systems
* Pervasive computing and emerging models
* Wireless multimedia systems
* QoS provisioning in wireless and mobile networks
* Security and privacy of mobile/wireless systems
* Algorithms and protocols for energy-efficiency and power control
* Mobile applications, system software and algorithms
* RF channel modeling and analysis
* Design methodologies, tools, prototype and testbeds
* Parallel and distributed simulation of wireless systems


Organizing Commitee:

General Chair:
Albert Zomaya (University of Sydney, Australia)

General Vice Chair:
Vasos Vassilio (University of Cyprus, Cyprus)

TPC Co-Chairs:
Bjorn Landfeldt (Lund University, Sweden)
Ravi Prakash (University of Texas at Dallas, USA)


Paper Submission, Publication and Important Dates:

High-quality original papers are solicited. Papers must be unpublished
and must not be submitted for publication elsewhere. All papers will be
reviewed by Technical Program Committee members and other experts
active in the field to ensure high quality and relevance to the conference.
Short papers will be included in the technical program to complement
mature results and foster discussion and exchange of novel ideas at an
early stage. Accepted papers will appear in the conference proceedings
to be published by ACM Press.

Submission Deadline: 
Paper registration (abstract and all authors): May 1, 2012

Full paper upload: May 5, 2012

Notification of Acceptance: July 1, 2012

Camera Ready version due: July 25, 2012

Conference Dates: October 21-25, 2012


For more information about the conference, organizing committee,
submission instructions, and venue please see the conference website:
http://mswimconf.com


-
Profa Dra Mirela Sechi Moretti Annoni Notare
http://lattes.cnpq.br/8224632340074096 mir...@ieee.org 


IEEE Latin America Transactions, Editor-in-chief 
http://www.ewh.ieee.org/reg/9/etrans 



___
Researchers mailing list
research...@mailman.ufsc.br
http://mailman.ufsc.br/mailman/listinfo/researchers
__

[Tinyos-help] Compilation problem in Ubuntu 11.10

[Manoja Rao]

Hi
I had the same problem . Installing nesc 1.3.3 solved it .

Regards,
Manoj

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

[Tinyos-help] [Researchers] 16th IEEE/ACM* International Symposium on DistributedSimulation and Real Time Applications - Dublin, 25-27/10/2012.

[Profa Dra Mirela Sechi Moretti Annoni Notare]

Please accept our apologies if you have received multiple copies.


Call for Papers - DS-RT 2012

16th IEEE/ACM* International Symposium on
Distributed Simulation and Real Time Applications
http://ds-rt.com/2012/
October 25-27, 2012
Dublin, Ireland


* IEEE/ACM pending approval


*** The Symposium ***

In its sixteenth year, the 2012 IEEE/ACM International Symposium on
Distributed Simulation and Real Time Applications (DS-RT 2012) will
take place in Dublin, Ireland.


DS-RT 2012 serves as a forum for simulationists from academia, industry
and research labs, for presenting recent research results in Distributed
Simulation and Real Time Applications. DS-RT 2012 targets the growing
overlap between large distributed simulations and real time
applications, such as collaborative virtual environments, pervasive and
ubiquitous application scenarios, motor-, controller-, sensor- and
actuator systems.

The conference features prominent invited speakers as well as papers by
top researchers in the field. DS-RT 2012 will include contributed
technical papers, invited papers, and panel discussions. The proceedings
will be published by IEEE-CS press.


*** Call for Papers ***

DS-RT provides an international forum for the discussion and
presentation of original ideas, recent results and achievements by
researchers, students, and systems developers on issues and challenges
related to distributed simulation and real time applications. Authors
are encouraged to submit both theoretical and practical results of
significance. Demonstration of new tools/applications is very desirable.

The scope of the symposium includes, but is not limited to:

o Paradigms, Methodology and Software Architectures for Large Scale
Distributed and Real-Time Simulations (e.g. Parallel and Distributed
Simulation, Multi-Agent Based Distributed Simulation, HLA/RTI,
Web, Grid and cloud based Simulation, hardware-software co-design for
extreme scale simulations)

o Paradigms, Modelling, Architecture and Environments for Large Scale
Real-time Systems and Concurrent Systems with hard and soft Real-Time
Contstraints

o Non-functional Properties of Distributed Simulation and Real-Time
Systems (e.g. Dependability, Availability, Reliability,
Maintainability, Safety, Security, Trustworthiness, QoS)

o Theoretical Foundations of Large Scale Real-Time and Simulation Models
(e.g. Event Systems, Causality, Space-Time Models, Notions of Time,
Discrete and Continuous Systems, Simulator Coordination)

o Simulation Studies at Large and Very Large Scale (e.g. Industrial,
Commercial, Ecological and Environmental, Societal, Power and Energy,
Pervasive and Ubiquitous Computing Systems)

o Performance and Validation of Large Scale and Distributed Simulations
(e.g., benchmarking and analytical results, empirical studies
DIS, HLA/RTI studies;

o Languages and Tools, Development Environments, Data Interfaces,
Network Protocols and Model Repositiories that address Very Large
Simulations

o Data Management and Distribution Issues, Interest Management, Semantic
Modeling, Multi-resolution Modeling, Dead-Reckoning Mechanisms

o Pervasive and Ubiquitous Computing Architectures and Applications
that involve Simulations and/or adhere to Real-Time Constraints

o Simulation based Virtual Environments and Mixed Reality Systems
(e.g. Interactive Virtual Reality, Human Communication through
Immersive Environments)

o Collaborative Virtual and Augmented Reality, Shared Interaction
Spaces, Telepresence Systems and Shared Workspaces, 3D Video and
Acoustic Reconstruction, Shared Object Manipulation

o Serious Gaming and Massive Multiplayer Online Games (MMOG) applications,
architectures and scalability issues.

o Visual Interactive Simulation Environments (e.g., Generic Animation,
Visual Interactive Modeling, Interactive Computer Based Training and
Learning; Scientific Visualization; High-End Computer Graphics;

o Design Issues, Interaction Designs, Human Comuter Interaction Issues
raised by Large Scale DS-RT Systems

o Media Convergence (e.g. New Technologies, Media Theory, Real-Time
considerations of Multi Modality, etc.)

o Innovative Styles of Interactions with Large Scale DS-RT Systems
(e.g. Implicit, Situative and Attentive Interaction, Tangible
Interaction, Embedded Interaction, etc.)

o Technologies for Living Labs (e.g. Mirror World Simulation,
Interoperability, Large Scale Multi Sensor Networks, Global Wireless
Communication, Multi Stakeholder Understanding and Innovation)

o Environmental and Emerging Simulation Challenges (e.g. Growth of
Human Population, Climate Change, CO2, Health Care, Ecosystems,
Sustainable Development, Water and Energy Supply, Human Mobility,
Air Traffic, World Stock Markets, Food Supply Chains, Megacities, Smart Cities,
Disaster Planning, etc.)


*** Important Dates

Paper Submission Deadline

[Tinyos-help] chaos on iris node

[lujuan ma]

Hello,

I want to implement chaos on iris node.
Can I change the spectrum spreading sequence of the iris node?
Can I change the modulation scheme?
Thank you!

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

[Tinyos-help] CameraMultihop Compile Error

[David Zhao]

Hi, everyone. I really need your help.

I'm working with Tinyos-2.x in CYGWIN-WINDOWSXP. I had a problem while
"make" in the app "cameraMultihop/c/" directory.  Error Information is like
this:

building /opt/tinyos-2.x-contrib/intelmote2/support/sdk/c/camera_cmd
make[1]: Entering directory
`/opt/tinyos-2.x-contrib/intelmote2/support/sdk/c/camera_cmd'
cc -c -DTOSH_DATA_LENGTH=100 -Wall camera_cmd.c img_stat.c cmd_msg.c
status.c bigmsg_frame_part.c /support/sdk/c/compress/jpegUncompress.c
/support/sdk/c/compress/huffmanUncompress.c -I.
-I/apps/cameraMultiHop/camNode -I/support/sdk/c/compress
-I/opt/tinyos-2.x/tos/../support/sdk/c/sf
cc: /support/sdk/c/compress/jpegUncompress.c: No such file or directory
cc: /support/sdk/c/compress/huffmanUncompress.c: No such file or directory
camera_cmd.c:11:21: jpeglib.h: No such file or directory
camera_cmd.c:18:27: tinyos_macros.h: No such file or directory
camera_cmd.c:19:21: jpeghdr.h: No such file or directory
camera_cmd.c:20:21: jpegTOS.h: No such file or directory
camera_cmd.c:21:28: jpegUncompress.h: No such file or directory
camera_cmd.c:22:25: quanttables.h: No such file or directory
camera_cmd.c: In function `save_img_jpg':
camera_cmd.c:457: error: storage size of 'cinfo' isn't known
camera_cmd.c:458: error: storage size of 'jerr' isn't known
camera_cmd.c:459: error: `JSAMPROW' undeclared (first use in this function)
camera_cmd.c:459: error: (Each undeclared identifier is reported only once
camera_cmd.c:459: error: for each function it appears in.)
camera_cmd.c:459: error: parse error before "row_pointer"
camera_cmd.c:473: warning: implicit declaration of function `jpeg_std_error'
camera_cmd.c:474: warning: implicit declaration of function
`jpeg_create_compress'
camera_cmd.c:475: warning: implicit declaration of function
`jpeg_stdio_dest'
camera_cmd.c:480: error: `JCS_RGB' undeclared (first use in this function)
camera_cmd.c:480: error: `JCS_GRAYSCALE' undeclared (first use in this
function)
camera_cmd.c:481: warning: implicit declaration of function
`jpeg_set_defaults'
camera_cmd.c:482: warning: implicit declaration of function
`jpeg_set_quality'
camera_cmd.c:482: error: `TRUE' undeclared (first use in this function)
camera_cmd.c:483: warning: implicit declaration of function
`jpeg_start_compress'
camera_cmd.c:486: error: `row_pointer' undeclared (first use in this
function)
camera_cmd.c:487: warning: implicit declaration of function
`jpeg_write_scanlines'
camera_cmd.c:490: warning: implicit declaration of function
`jpeg_finish_compress'
camera_cmd.c:492: warning: implicit declaration of function
`jpeg_destroy_compress'
camera_cmd.c:457: warning: unused variable `cinfo'
camera_cmd.c:458: warning: unused variable `jerr'
camera_cmd.c: In function `write_img_file':
camera_cmd.c:504: error: `code_header_t' undeclared (first use in this
function)
camera_cmd.c:504: error: parse error before "header"
camera_cmd.c:506: warning: implicit declaration of function
`decodeJpegBytes'
camera_cmd.c:506: error: `header' undeclared (first use in this function)
Makefile:36: recipe for target `camera_cmd.o' failed
make[1]: *** [camera_cmd.o] Error 1
make[1]: Leaving directory
`/opt/tinyos-2.x-contrib/intelmote2/support/sdk/c/camera_cmd'
Makefile:17: recipe for target
`/opt/tinyos-2.x-contrib/intelmote2/support/sdk/c/camera_cmd/libcamera_cmd.a'
failed
make: ***
[/opt/tinyos-2.x-contrib/intelmote2/support/sdk/c/camera_cmd/libcamera_cmd.a]
Error 2

I found this may be caused by lacking the jpeg-6b dev library. However,
it's really difficult to install this in cygwin because of the dependancy.
I also can't install libc-dev library in cygwin. Do you know how to solve
this problem?

What I want to do is to add Jpeg algorithm into image transmission with
imote2. But the app "cameraTestJpegSerial" doesn't work for the Jpeg.
Someone on the internet said the app "cameraMultihop" works well with
tranmitting Jpeg image.That's why I got here.

Any help will be very appreciated.Thanks in advance!

-- 
Best Regards

Sincerely,

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

Re: [Tinyos-help] what motes are you using?

[Li, Haixia-OSU Stillwater]

Hi all,

Sorry for what  I said. In fact, the crossbow seems not to sell motes any more. 
I cannot find the mote information from its web. And, I head the company sold 
this part. Is this true? Thanks.



From: tinyos-help-boun...@millennium.berkeley.edu 
[tinyos-help-boun...@millennium.berkeley.edu] on behalf of Li, Haixia-OSU 
Stillwater [hai...@ostatemail.okstate.edu]
Sent: Tuesday, April 17, 2012 9:02 PM
To: tinyos-help@millennium.berkeley.edu
Subject: [Tinyos-help] what motes are you using?

Hello all,

I am using IRIS motes. I would like to know what motes you are using because I 
find the Crossbow has been sold. If I want to buy new motes, can anyone give me 
any suggestions? What products do occupy the main WSN market?


Thanks.
Haixia Li

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

[Tinyos-help] what motes are you using?

[Li, Haixia-OSU Stillwater]

Hello all,

I am using IRIS motes. I would like to know what motes you are using because I 
find the Crossbow has been sold. If I want to buy new motes, can anyone give me 
any suggestions? What products do occupy the main WSN market?


Thanks.
Haixia Li

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

Re: [Tinyos-help] Installing pppd in Blip 2.0

[Maycon Maia Vitali]

*Maycon Maia Vitali* (aka 0ut0fBound)
Offensive Security Certified Expert (OSCE)
Security Researcher @ Hack'n Roll
http://maycon.hacknroll.com
Hack'n Roll



2012/4/17 

> Dear all.
>
> I am trying to install the driver for Blip 2.0 in a computer with
> constrained resources in order to communicate it with the mote BaseStation
> (telosb). I managed to run Blip 1.0 with sheevaplug (based on ARM) but for
> Blip 2.0 is a bit complicated. So I have a question.
>
> The pppd come by default with tinyos-2.x or my computer must have
> installed it before run Blip 2.0?
>

The pppd is a common tool on linux OS. Each distribution has a simples way
to instasll it.


>
> According to the tutorials, I can't do :
>
> pppd debug passive noauth nodetach 115200 /dev/ttyUSB0 nocrtscts nocdtrcts
> lcp-echo-interval 0 noccp noip ipv6 ::23,::24
>
>
You need to install ppp tool. On ArchLinux I did pacman -S ppp and got
installed.


> Thanks in advance,
>
> Alejandro.
>
>
>
>
>
> > On Mon, Apr 16, 2012 at 5:14 AM, Daniel Bimschas <
> > bimsc...@itm.uni-luebeck.de> wrote:
> >
> >> Hi list,
> >>
> >> I've read http://www.tinyos.net/tinyos-2.1.0/doc/html/tep113.html and I
> >> want to make sure that I understood everything correctly / ask some
> >> questions:
> >>
> >> 1) SerialP CRC field: The guide says "CR = Two-byte CRC over S to end of
> >> Payload: SerialP". Does this mean that the CRC includes the S (sequence
> >> number) field?
> >>
> >
> > That was my understanding but from taking a close look at the source
> code,
> > it looks like it also includes the Proto byte in front of the sequence
> > field.   And the CRC should include the PROTO byte too.
> >
> > Phil is that correct?
> >
> >
> >> 2) The SerialP documentation states that PC-to-mote communication
> >> can/does
> >> use acknowledgements.
> >>
> >
> > I've never understood the SerialP ack implementation.  Not sure exactly
> > what it does or how it works.
> >
> >
> >>  a) Are acknowledgements mandatory or optional?
> >>
> >
> > From what I've seen they are optional.   I've got serial communications
> > (transmit only from the mote) and there is nothing on the other side that
> > is sending asks back.
> >
> >  b) I can't find out how the acknowledgments are represented in the
> packet
> >> format (3.6). How do you request an acknowledgment? Are they always
> >> send?
> >>  c) How does the actual acknowledgment message look like (packet
> >> format)?
> >>
> >
> > Not sure but I suspect that it uses just the Proto field and the sequence
> > number.   If they are actually used, it would be good if it were properly
> > documented.
> >
> >
> > 3) The SerialP description states "SerialP uses SerialFrameComm to send a
> >> delimiter between frames". Does this mean that a fragmented packet on
> >> application layer will result in several packets encapsulated in
> >> HdlcTranslateC, using different sequence number fields in the SerialP
> >> payload of HdlcTranslateC?
> >>
> >
> > SerialP and the AM layer does not do any fragmentation.   There is no
> > fragmentation implemented.   It is one of the reasons I'm interested in
> > the
> > 6lowpan IPv6 implementation.  The problem is IPv6 is rather fat and I'm
> > almost out of space on my mote.
> >
> >
> >> 4) The SerialP description states "SerialP uses SerialFrameComm to send
> >> a
> >> delimiter between frames, a serial-level type field, [...]".
> >>  a) Is the "serial-level type field" the same field as "P = Protocol
> >> byte:
> >> SerialP" in "3.6 Packet Format"? Or is this referring to "D = Packet
> >> format
> >> dispatch byte: SerialDispatcherC"?
> >>
> >
> > I believe the "serial-level type field" being referred  to is the type
> > field that is part of the payload.   If D is 0 then the Payload is an
> > Active Message packet and the payload looks like
> >
> > dst src len grp type data
> >
> > The example packet in the TEP is wrong.   It says that the packet looks
> > like:
> >
> > 7e 40 09 00 be ef 05 7d 5d 06 01 02 03 04 05 7e
> >
> > It is missing the SRC field which is normally is included.   And it is
> > also
> > missing the CRC.   Given a dispatch byte of 00 the following data is an
> AM
> > packet and should have dst, src, len, grp, am_type, data.   The low level
> > serial encapsulation doesn't have any inherent addressing.So as soon
> > as
> > the example starts to talk about a destination address and given that the
> > dispatch byte is a 0, it is talking about the AM encapsulation.
> >
> >
> >>  b) In case the "serial-level type field" is not the same as "P =
> >> Protocol
> >> byte: SerialP": What's the purpose of P? What values can it take?
> >>
> >
> > P is different than the serial-level type field.   It can have...
> >
> > 67 PROTO_ACK
> > 68 PROTO_PACKET_ACK
> > 69 PROTO_PACKET_NOACK
> >
> > The whole protocol is underspecified so I have no idea how it works or
> > what
> > these values do.   The only one that seems to currently be implemented is
> > PROTO_PACKET_ACK.
> >
> > But like I said abo

Re: [Tinyos-help] Repository error

[Eric Decker]

I don't have a ARM host.   Don't know what you can do.


On Tue, Apr 17, 2012 at 12:53 PM,  wrote:

> Dear Erick.
>
> Thanks for you answer.
>
> Yes is for ARM architecture...
>
> But do you know about another solution in this cases?
>
> Thanks in advance.
>
> Alejandro.
>
> > what's armel?   I believe it is ARM based.   So isn't supported by
> > TinyProd.
> >
> > TinyProd only provides cross compiler toolchains for AVR and MSP430.
> The
> > host architecture provided is only i386 and amd64.
> >
> >
> > On Mon, Apr 16, 2012 at 3:00 AM, Alex FP  wrote:
> >
> >> Dear all.
> >>
> >> I've added this in the sourcelist of my sheevaplug (with debian lenny)
> >>
> >>   deb http://tinyprod.net/repos/debian squeeze main
> >>
> >>
> >> But when I do the "aptitude update" this error appears
> >>
> >>
> >> Err http://tinyprod.net squeeze/main armel Packages
> >>   404  Not Found
> >>
> >> Please someone have any idea about how to fix it?
> >>
> >> Thanks in advance,
> >>
> >> Alex.
> >>
> >>
> >>
> >> ___
> >> 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
>
>
>


-- 
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] Coap Addressing

[Constantinos Marios Angelopoulos]

Hi guys,

there is my problem; when I flash a mote with CoapBlipC and assign to
it an ID greater than 10, then the node fails to join the rest of the
network. In particular, when I try to ping6 (eg ping6 fec0::10) it
returns with "exceeded: Hop limit" and the server dies not respond to
any requests.

I tried assigning hexadecimal addresses (eg fec0::a) but it also failed.
Any ideas?

Thank you in advance,
Marios
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Installing pppd in Blip 2.0

[acamap]

Dear all.

I am trying to install the driver for Blip 2.0 in a computer with
constrained resources in order to communicate it with the mote BaseStation
(telosb). I managed to run Blip 1.0 with sheevaplug (based on ARM) but for
Blip 2.0 is a bit complicated. So I have a question.

The pppd come by default with tinyos-2.x or my computer must have
installed it before run Blip 2.0?

According to the tutorials, I can't do :

pppd debug passive noauth nodetach 115200 /dev/ttyUSB0 nocrtscts nocdtrcts
lcp-echo-interval 0 noccp noip ipv6 ::23,::24

Thanks in advance,

Alejandro.





> On Mon, Apr 16, 2012 at 5:14 AM, Daniel Bimschas <
> bimsc...@itm.uni-luebeck.de> wrote:
>
>> Hi list,
>>
>> I've read http://www.tinyos.net/tinyos-2.1.0/doc/html/tep113.html and I
>> want to make sure that I understood everything correctly / ask some
>> questions:
>>
>> 1) SerialP CRC field: The guide says "CR = Two-byte CRC over S to end of
>> Payload: SerialP". Does this mean that the CRC includes the S (sequence
>> number) field?
>>
>
> That was my understanding but from taking a close look at the source code,
> it looks like it also includes the Proto byte in front of the sequence
> field.   And the CRC should include the PROTO byte too.
>
> Phil is that correct?
>
>
>> 2) The SerialP documentation states that PC-to-mote communication
>> can/does
>> use acknowledgements.
>>
>
> I've never understood the SerialP ack implementation.  Not sure exactly
> what it does or how it works.
>
>
>>  a) Are acknowledgements mandatory or optional?
>>
>
> From what I've seen they are optional.   I've got serial communications
> (transmit only from the mote) and there is nothing on the other side that
> is sending asks back.
>
>  b) I can't find out how the acknowledgments are represented in the packet
>> format (3.6). How do you request an acknowledgment? Are they always
>> send?
>>  c) How does the actual acknowledgment message look like (packet
>> format)?
>>
>
> Not sure but I suspect that it uses just the Proto field and the sequence
> number.   If they are actually used, it would be good if it were properly
> documented.
>
>
> 3) The SerialP description states "SerialP uses SerialFrameComm to send a
>> delimiter between frames". Does this mean that a fragmented packet on
>> application layer will result in several packets encapsulated in
>> HdlcTranslateC, using different sequence number fields in the SerialP
>> payload of HdlcTranslateC?
>>
>
> SerialP and the AM layer does not do any fragmentation.   There is no
> fragmentation implemented.   It is one of the reasons I'm interested in
> the
> 6lowpan IPv6 implementation.  The problem is IPv6 is rather fat and I'm
> almost out of space on my mote.
>
>
>> 4) The SerialP description states "SerialP uses SerialFrameComm to send
>> a
>> delimiter between frames, a serial-level type field, [...]".
>>  a) Is the "serial-level type field" the same field as "P = Protocol
>> byte:
>> SerialP" in "3.6 Packet Format"? Or is this referring to "D = Packet
>> format
>> dispatch byte: SerialDispatcherC"?
>>
>
> I believe the "serial-level type field" being referred  to is the type
> field that is part of the payload.   If D is 0 then the Payload is an
> Active Message packet and the payload looks like
>
> dst src len grp type data
>
> The example packet in the TEP is wrong.   It says that the packet looks
> like:
>
> 7e 40 09 00 be ef 05 7d 5d 06 01 02 03 04 05 7e
>
> It is missing the SRC field which is normally is included.   And it is
> also
> missing the CRC.   Given a dispatch byte of 00 the following data is an AM
> packet and should have dst, src, len, grp, am_type, data.   The low level
> serial encapsulation doesn't have any inherent addressing.So as soon
> as
> the example starts to talk about a destination address and given that the
> dispatch byte is a 0, it is talking about the AM encapsulation.
>
>
>>  b) In case the "serial-level type field" is not the same as "P =
>> Protocol
>> byte: SerialP": What's the purpose of P? What values can it take?
>>
>
> P is different than the serial-level type field.   It can have...
>
> 67 PROTO_ACK
> 68 PROTO_PACKET_ACK
> 69 PROTO_PACKET_NOACK
>
> The whole protocol is underspecified so I have no idea how it works or
> what
> these values do.   The only one that seems to currently be implemented is
> PROTO_PACKET_ACK.
>
> But like I said above it is unclear to me how the ack mechanism works.   I
> think it is used as flow control in one direction only (host to mote,
> ie. when the mote receives).
>
>
>
>>
>> ===
>> Some background why I'm asking these questions:
>>
>> I'm currently developing TinyOS support for the WISEBED wireless sensor
>> network testbeds (see. http://wisebed.eu). The specific function is that
>> the testbed backend shall be able to read individual packets from the
>> nodes
>> stream and forward the individual packets to the remote experimenter
>> using
>> the testbed.
>>
>
> Okay.  I don't see why you want to expose your

[Tinyos-help] simulation

[Hanen Rekik]

Hi,
I want to simulate my app energy consumption** using PowerTOSSIMZ with
different topolgy.Please, can anyone send me an example of topology.txt
file with big number of motes (50, 100, 150 or 200 motes).
Thanks for your help..
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Repository error

[acamap]

Dear Erick.

Thanks for you answer.

Yes is for ARM architecture...

But do you know about another solution in this cases?

Thanks in advance.

Alejandro.

> what's armel?   I believe it is ARM based.   So isn't supported by
> TinyProd.
>
> TinyProd only provides cross compiler toolchains for AVR and MSP430.   The
> host architecture provided is only i386 and amd64.
>
>
> On Mon, Apr 16, 2012 at 3:00 AM, Alex FP  wrote:
>
>> Dear all.
>>
>> I've added this in the sourcelist of my sheevaplug (with debian lenny)
>>
>>   deb http://tinyprod.net/repos/debian squeeze main
>>
>>
>> But when I do the "aptitude update" this error appears
>>
>>
>> Err http://tinyprod.net squeeze/main armel Packages
>>   404  Not Found
>>
>> Please someone have any idea about how to fix it?
>>
>> Thanks in advance,
>>
>> Alex.
>>
>>
>>
>> ___
>> 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

[Tinyos-help] Coap Addressing

[Constantinos Marios Angelopoulos]

Hi guys,

there is my problem; when I flash a mote with CoapBlipC and assign to
it an ID greater than 10, then the node fails to join the rest of the
network. In particular, when I try to ping6 (eg ping6 fec0::10) it
returns with "exceeded: Hop limit" and the server dies not respond to
any requests.

I tried assigning hexadecimal addresses (eg fec0::a) but it also failed.
Any ideas?

Thank you in advance,
Marios
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] [Avrora] Running Blip 1.0 (UDPEcho + IPBaseStation) in Avrora

[Maycon Maia Vitali]

That trouble was solved setting the socket to non-blocking mode.

--- sfsource-orig.c 2012-04-17 13:53:28.0 -0300
+++ sfsource.c 2012-04-17 13:48:55.0 -0300
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "sfsource.h"

@@ -84,6 +85,13 @@
   return -1;
 }

+  /**
+   * set socket in non-blocking mode
+   */
+  int flags;
+  if (-1 == (flags = fcntl(fd, F_GETFL, 0))) flags = 0;
+  fcntl(fd, F_SETFL, flags | O_NONBLOCK);
+
   return fd;
 }

Finally it seems to work!


*Maycon Maia Vitali* (aka 0ut0fBound)
Offensive Security Certified Expert (OSCE)
Security Researcher @ Hack'n Roll
http://maycon.hacknroll.com
Hack'n Roll



2012/4/17 Maycon Maia Vitali 

> I notice that ip-driver is locked on read_sf_packet call:
>
> (gdb) bt
> #0  0x77b120f0 in __read_nocancel () from /lib/libc.so.6
> #1  0x0040cf08 in saferead (fd=9, buffer=0x7fffdf3f, count=1)
> at sfsource.c:18
> #2  0x0040d0de in read_sf_packet (fd=9, len=0x7fffe4d8)
> at sfsource.c:131
> #3  0x00403bee in serial_input () at serial_tun.c:1025
> #4  0x00404122 in serial_tunnel (tun_fd=8) at serial_tun.c:1360
> #5  0x004020d1 in main (argc=, argv=0x7fffe718)
> at serial_tun.c:1492
> (gdb)
>
> Anybody has some idea to solve this?
>
> 
> *Maycon Maia Vitali* (aka 0ut0fBound)
> Offensive Security Certified Expert (OSCE)
> Security Researcher @ Hack'n Roll
> http://maycon.hacknroll.com
> Hack'n Roll
>
>
>
> 2012/4/17 Christian Haas 
>
>> On 04/17/2012 02:18 PM, Maycon Maia Vitali wrote:
>> > Hello Christian,
>> > *
>> > *
>> > What version did you simulate? BLIP 2.0 on Micaz? The last version is
>> too
>> > big to compile for Micaz platform. Running in physical node, it works
>> just
>> > on telosb platform.
>> >
>>
>> BLIP 1.x, not sure which SVN Rev. I used. I used a modified avr-gcc to
>> get rid of the RAM/ROM problems on MicaZ, so yes i used MicaZ
>>
>> > Did you used SF_SRC too? How do you communicate with network? Did you
>> use
>> > IPBaseStation or a serial communication with each node? I would like to
>> > connect in BaseStation using nc6 and access any node in same way. Is
>> that
>> > possible?
>>
>> Yes i used SF_SRC, too. We used ip-driver + SerialForwarder +
>> IPBaseStation. I was able to use ping6 as far as i remember.
>> >
>> > Someone already used the socat tool to create a virtual device to use
>> > between avrora and some another application that uses just linux
>> devices?
>>
>> Dunno.
>>
>> Regards,
>>  Christian
>>
>>
>> --
>> 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

[Tinyos-help] High precision timer

[alireza dehghani]

Hi all

For determining location of nodes I need to use high precision timer on
MicaZ motes.
I know that there is some modules and interfaces for doing that but till
now I cannot
perform that for cc2420. If somebody know about that PLEASE help me?

Thanks in advance.

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

Re: [Tinyos-help] [Avrora] Running Blip 1.0 (UDPEcho + IPBaseStation) in Avrora

[Maycon Maia Vitali]

I notice that ip-driver is locked on read_sf_packet call:

(gdb) bt
#0  0x77b120f0 in __read_nocancel () from /lib/libc.so.6
#1  0x0040cf08 in saferead (fd=9, buffer=0x7fffdf3f, count=1)
at sfsource.c:18
#2  0x0040d0de in read_sf_packet (fd=9, len=0x7fffe4d8)
at sfsource.c:131
#3  0x00403bee in serial_input () at serial_tun.c:1025
#4  0x00404122 in serial_tunnel (tun_fd=8) at serial_tun.c:1360
#5  0x004020d1 in main (argc=, argv=0x7fffe718)
at serial_tun.c:1492
(gdb)

Anybody has some idea to solve this?


*Maycon Maia Vitali* (aka 0ut0fBound)
Offensive Security Certified Expert (OSCE)
Security Researcher @ Hack'n Roll
http://maycon.hacknroll.com
Hack'n Roll



2012/4/17 Christian Haas 

> On 04/17/2012 02:18 PM, Maycon Maia Vitali wrote:
> > Hello Christian,
> > *
> > *
> > What version did you simulate? BLIP 2.0 on Micaz? The last version is too
> > big to compile for Micaz platform. Running in physical node, it works
> just
> > on telosb platform.
> >
>
> BLIP 1.x, not sure which SVN Rev. I used. I used a modified avr-gcc to
> get rid of the RAM/ROM problems on MicaZ, so yes i used MicaZ
>
> > Did you used SF_SRC too? How do you communicate with network? Did you use
> > IPBaseStation or a serial communication with each node? I would like to
> > connect in BaseStation using nc6 and access any node in same way. Is that
> > possible?
>
> Yes i used SF_SRC, too. We used ip-driver + SerialForwarder +
> IPBaseStation. I was able to use ping6 as far as i remember.
> >
> > Someone already used the socat tool to create a virtual device to use
> > between avrora and some another application that uses just linux devices?
>
> Dunno.
>
> Regards,
>  Christian
>
>
> --
> 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] IEEE 802.15.4 Implementation and broadcast transmission

[David Rodenas]

Hi Jan
Thanks a lot for your reply. You are right! It has no sense doing an indirect 
broadcast transmission. What I just wanted to do is a broadcast transmission 
employing the unslotted IEEE 8021.5.4 csma-ca. For this reason, what it seems 
to me is that I am not using the correct transmission options in the 
MCPS_DATA.request function. That filed should be zero what means a direct 
broadcast transmission. 
I'll check that and see if it is works. Again, thanks a lot for your help!
David
> Date: Tue, 17 Apr 2012 15:09:10 +0200
> Subject: Re: [Tinyos-help] IEEE 802.15.4 Implementation and broadcast 
> transmission
> From: ha...@tkn.tu-berlin.de
> To: drod...@hotmail.com
> CC: tinyos-help@millennium.berkeley.edu
> 
> Hi David,
> 
> >  what it is fine but to my astonishment, when I checked that function which
> > is implemented at the bottom of the same file, I realized that the return
> > value was due to: [...]
> > Therefore, the broadcast transmission is not implemented by default.
> 
> A default is called when no component is wired. In nonbeacon-enabled
> mode indeed no component is wired, so the default is executed and you
> get an error code. This was likely done, because I'm not quite sure
> what indirect transmission using a broadcast address in
> nonbeacon-enabled mode actually means (maybe you can give your
> interpretation?).
> 
> The standard (IEEE 802.15.4-2006)  says in Sect. 7.1.1.1.3: "If the
> TxOptions parameter specifies that an indirect transmission is
> required and this primitive is received by the MAC sublayer of a
> coordinator, the data frame is sent using indirect transmission, i.e.,
> the data frame is added to the list of pending transactions stored on
> the coordinator and extracted at the discretion of the device
> concerned using the method described in 7.5.6.3. Transactions with a
> broadcast destination address will be transmitted using the mechanism
> described in 7.2.1.1.3.". Unfortunately Sect. 7.2.1.1.3 does not
> describe any mechanism (it just defines the use of the frame pending
> bit) ...
> 
> One interpretation could be: the coordinator stores the packet and any
> device that asks for the data via POLL will get the packet. The
> problem with that approach is: when would you remove the packet from
> the coordinator's queue (after macTransactionPersistenceTime)?
> 
> BTW, make sure you're using the latest code from SVN
> (http://code.google.com/p/tinyos-main/).
> 
> Thanks,
> Jan
> 
> 
> On Tue, Apr 17, 2012 at 10:39 AM, David Rodenas  wrote:
> > Hi all
> >
> > I've doing some research with the IEEE 802.15.4 TinyOS Implementation
> > (TKN154) whose libs are located at "/tos/lib/mac/tkn154" and test
> > applications at "/apps/tests/tkn154" directories. I am aware that the
> > majority of the community research do not work with this, but I appreciate
> > all the help possible.
> >
> >
> > In particular, I'm trying to send a broadcast data frame employing the IEEE
> > 802.15.4 non-beacon enabled mode. To to this, I've been working with the
> > TestIndirectData application
> > (/apps/tests/tkn154/TestIndirectData/coordinator). As the README.txt file
> > indicates, "In this application one node takes the role of a PAN coordinator
> > in a nonbeacon-enabled 802.15.4 PAN, every 3 seconds it sends a packet to a
> > device using indirect transmission (i.e. the packet is buffered until it is
> > polled by the device). A second node acts as the device, it switches to the
> > pre-defined
> > channel and polls the coordinator every 1 second for outstanding
> > indirect transmissions." I've tested the application and it works fine.
> > However, I've changed two things in the code in order to send broadcast
> > frames instead unicast frames as follows (changes in bold):
> >
> > 
> > void sendIndirectData(){
> >
> > ieee154_address_t deviceAddress;
> > // deviceAddress.shortAddress = DEVICE_ADDRESS;
> > deviceAddress.shortAddress = 0x;
> > call Frame.setAddressingFields(
> >   &frame,
> >   ADDR_MODE_SHORT_ADDRESS, // SrcAddrMode,
> >   ADDR_MODE_SHORT_ADDRESS, // DstAddrMode,
> >   PAN_ID,  // DstPANId,
> >   &deviceAddress,  // DstAddr,
> >   NULL // security
> > );
> > /* call MCPS_DATA.request(
> >   &frame,   // frame,
> >   strlen(payload),  //
> > payloadLength,
> >   0,//
> > msduHandle,
> >   TX_OPTIONS_INDIRECT | TX_OPTIONS_ACK  //
> > TxOptions,
> > );  */
> > status_t = call MCPS_DATA.request(
> >   &frame,   // frame,
> >

Re: [Tinyos-help] IEEE 802.15.4 Implementation and broadcast transmission

[Jan Hauer]

Hi David,

>  what it is fine but to my astonishment, when I checked that function which
> is implemented at the bottom of the same file, I realized that the return
> value was due to: [...]
> Therefore, the broadcast transmission is not implemented by default.

A default is called when no component is wired. In nonbeacon-enabled
mode indeed no component is wired, so the default is executed and you
get an error code. This was likely done, because I'm not quite sure
what indirect transmission using a broadcast address in
nonbeacon-enabled mode actually means (maybe you can give your
interpretation?).

The standard (IEEE 802.15.4-2006)  says in Sect. 7.1.1.1.3: "If the
TxOptions parameter specifies that an indirect transmission is
required and this primitive is received by the MAC sublayer of a
coordinator, the data frame is sent using indirect transmission, i.e.,
the data frame is added to the list of pending transactions stored on
the coordinator and extracted at the discretion of the device
concerned using the method described in 7.5.6.3. Transactions with a
broadcast destination address will be transmitted using the mechanism
described in 7.2.1.1.3.". Unfortunately Sect. 7.2.1.1.3 does not
describe any mechanism (it just defines the use of the frame pending
bit) ...

One interpretation could be: the coordinator stores the packet and any
device that asks for the data via POLL will get the packet. The
problem with that approach is: when would you remove the packet from
the coordinator's queue (after macTransactionPersistenceTime)?

BTW, make sure you're using the latest code from SVN
(http://code.google.com/p/tinyos-main/).

Thanks,
Jan


On Tue, Apr 17, 2012 at 10:39 AM, David Rodenas  wrote:
> Hi all
>
> I've doing some research with the IEEE 802.15.4 TinyOS Implementation
> (TKN154) whose libs are located at "/tos/lib/mac/tkn154" and test
> applications at "/apps/tests/tkn154" directories. I am aware that the
> majority of the community research do not work with this, but I appreciate
> all the help possible.
>
>
> In particular, I'm trying to send a broadcast data frame employing the IEEE
> 802.15.4 non-beacon enabled mode. To to this, I've been working with the
> TestIndirectData application
> (/apps/tests/tkn154/TestIndirectData/coordinator). As the README.txt file
> indicates, "In this application one node takes the role of a PAN coordinator
> in a nonbeacon-enabled 802.15.4 PAN, every 3 seconds it sends a packet to a
> device using indirect transmission (i.e. the packet is buffered until it is
> polled by the device). A second node acts as the device, it switches to the
> pre-defined
> channel and polls the coordinator every 1 second for outstanding
> indirect transmissions." I've tested the application and it works fine.
> However, I've changed two things in the code in order to send broadcast
> frames instead unicast frames as follows (changes in bold):
>
> 
> void sendIndirectData(){
>
>     ieee154_address_t deviceAddress;
>     // deviceAddress.shortAddress = DEVICE_ADDRESS;
>     deviceAddress.shortAddress = 0x;
>     call Frame.setAddressingFields(
>                           &frame,
>                           ADDR_MODE_SHORT_ADDRESS,     // SrcAddrMode,
>                           ADDR_MODE_SHORT_ADDRESS,     // DstAddrMode,
>                           PAN_ID,                      // DstPANId,
>                           &deviceAddress,              // DstAddr,
>                           NULL                         // security
>                         );
>     /* call MCPS_DATA.request(
>                           &frame,                               // frame,
>                           strlen(payload),                      //
> payloadLength,
>                           0,                                    //
> msduHandle,
>                           TX_OPTIONS_INDIRECT | TX_OPTIONS_ACK  //
> TxOptions,
>                         );  */
> status_t = call MCPS_DATA.request(
>                           &frame,                               // frame,
>                           strlen(payload),                      //
> payloadLength,
>                           0,                                    //
> msduHandle,
>                           TX_OPTIONS_INDIRECT  // TxOptions,
>                         );
>     call Leds.led1On();
>     call Led1Timer.startOneShot(12500U);
>   }
> 
>
> When I tested the application, it didn't work when it was supposed to. For
> this reason I've been checking the code looking for the problem. Firstly,
> the event MCPS_DATA.confirm was never signaled. So I checked the return
> value of MCPS_DATA.request (status_t) and its value was
> always IEEE154_INVALID_PARAMETER. Following with the tests, I checked the
> DataP.nc file (/tos/lib/mac/tkn154/DataP.nc) where the MCPS_DATA.request is
> implemented. In that file, when the transmission options are equal to
> TX_OPTIONS_INDIRECT, and the device address is e

[Tinyos-help] IEEE 802.15.4 Implementation and broadcast transmission

[David Rodenas]

Hi all
I've doing some research with the IEEE 802.15.4 TinyOS Implementation (TKN154) 
whose libs are located at "/tos/lib/mac/tkn154" and test applications at 
"/apps/tests/tkn154" directories. I am aware that the majority of the community 
research do not work with this, but I appreciate all the help possible.

In particular, I'm trying to send a broadcast data frame employing the IEEE 
802.15.4 non-beacon enabled mode. To to this, I've been working with the 
TestIndirectData application (/apps/tests/tkn154/TestIndirectData/coordinator). 
As the README.txt file indicates, "In this application one node takes the role 
of a PAN coordinator in a nonbeacon-enabled 802.15.4 PAN, every 3 seconds it 
sends a packet to a device using indirect transmission (i.e. the packet is 
buffered until it is polled by the device). A second node acts as the device, 
it switches to the pre-definedchannel and polls the coordinator every 1 second 
for outstanding indirect transmissions." I've tested the application and it 
works fine. However, I've changed two things in the code in order to send 
broadcast frames instead unicast frames as follows (changes in bold):

void sendIndirectData(){
ieee154_address_t deviceAddress;// deviceAddress.shortAddress = 
DEVICE_ADDRESS;deviceAddress.shortAddress = 0x;call 
Frame.setAddressingFields(  &frame, 
 ADDR_MODE_SHORT_ADDRESS, // SrcAddrMode,   
   ADDR_MODE_SHORT_ADDRESS, // DstAddrMode, 
 PAN_ID,  // DstPANId,  
&deviceAddress,  // DstAddr,  NULL  
   // security);/* call 
MCPS_DATA.request(  &frame, 
  // frame,  strlen(payload),  // 
payloadLength,  0,
// msduHandle,  TX_OPTIONS_INDIRECT | TX_OPTIONS_ACK  
// TxOptions,);  */   status_t = call 
MCPS_DATA.request(  &frame, 
  // frame,  strlen(payload),  // 
payloadLength,  0,
// msduHandle,  TX_OPTIONS_INDIRECT  // TxOptions,  
  ); call Leds.led1On();call 
Led1Timer.startOneShot(12500U);  }
When I tested the application, it didn't work when it was supposed to. For this 
reason I've been checking the code looking for the problem. Firstly, the event 
MCPS_DATA.confirm was never signaled. So I checked the return value of 
MCPS_DATA.request (status_t) and its value was always 
IEEE154_INVALID_PARAMETER. Following with the tests, I checked the DataP.nc 
file (/tos/lib/mac/tkn154/DataP.nc) where the MCPS_DATA.request is implemented. 
In that file, when the transmission options are equal to TX_OPTIONS_INDIRECT, 
and the device address is equal to 0x, it does the following call:

txStatus = call BroadcastTx.transmit(txFrame);

 what it is fine but to my astonishment, when I checked that function which is 
implemented at the bottom of the same file, I realized that the return value 
was due to:

default command ieee154_status_t BroadcastTx.transmit(ieee154_txframe_t *data) 
{ return IEEE154_INVALID_PARAMETER;}

Therefore, the broadcast transmission is not implemented by default. 
Taking into account the aforementioned, Does (or did) anybody have this same 
problem? How can I solve it? Any ideas? What portion of code shoud I add?
Thanks a lot
David

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

Re: [Tinyos-help] Block Erase of Telosb motes

[András Bíró]

Hi,

Yes it is. Stm25p can only erase sectors (64kB). Basicly all flash
memories work like this, but some of them can simulate rewrite (like
at45db, or sd cards)

Andris

On Tue, Apr 17, 2012 at 6:23 AM, kaustav das  wrote:
> Hi,
> Is it necessary to call Block Write.erase () every time when I try to write
> bytes on same position of the f;ash of telosb motes? Is there any way to
> erase a specific interval of the flash storage?
>
> --
> Kaustav Das,
> M.Tech Student,
> Department of CSE,
> IIT Bombay
>
>
> ___
> 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