Re: [Tinyos-help] Re : CoapBlip - CoapPpp ignores requests from coap-client
Hello everybody, Sorry for the late response and thanks to everybody who helped. I enclose below some steps to make this tutorial work http://tinyos.stanford.edu/tinyos-wiki/index.php/CoAP_-13 All these steps worked before mid-March, so I cannot say if there is a better way to do it right now. 1/ get tinyos-release, referred to as TR 2/ get tinyos-main, referred to as TM 3/ Replace in TR support/sdk/c/coap app/CoapBlip tos/lib/net/coap from same folder in TM 4/ add support/make/coap.extra from TM in TR 5/ Replace in TR tos/interfaces/CoAPClient.nc tos/interfaces/CoAPServer.nc tos/interfaces/libCoAP.nc from same folder in TM 6/ Add tos/interfaces/CoapResource.nc from TM in TR 7/ Remove tos/interfaces/ReadResource.nc and tos/interfaces/WriteResource.nc in TR 8/ Use TR as the tinyos distrib 9/ build TR with normal tinyos procedure 10/ build support/sdk/c/coap as usual 11/ Be sure to use same radio channel for PppRouter and CoapBlip (see makefile) 12/ Proceed with the Coap-13 tutorial As I said, the problem with TM is in the RPL exchange. In this way, we are using the BLIP and BLIP-RPL of TR and the Coap stuff from TM. Finally, we have a working TR with Coap-13 lib and client. The authory of this guide belongs to Congduc Pham, Professor at the University of Pau, France. On 14 March 2014 10:33, Markus Becker m...@comnets.uni-bremen.de wrote: Hi, there have been recent commits, which broke CoAP in TinyOS, see issue https://github.com/tinyos/tinyos-main/issues/253 and https://github.com/tinyos/tinyos-main/issues/254. #254 contains a fix, if you pull that in, at least CoapBlip should work again. Alternatively the working update to -13/-18 was https://github.com/tinyos/tinyos-main/commit/3b3483a56a4b1228a214d0e5715f22a6fa80bc85 BR, Markus On Tuesday 11 March 2014 18:40:10 David Guillen wrote: Hi Mohammad Jamal. Hi everybody, My name is David Guillen and I am doing some CoAP testings for an IoT project. Is there any plan to publish a CoAP version compliant with the tutorial CoAP-13? I am using the tinyos-release as you said and it works fine. But the version in tinyos-main is not even sending packets. I could check that sniffing the radio channel. By the way I offer myself to carry on tests of new versions, if it is needed. Best regards, On 24 February 2014 04:43, Mohammad Jamal Mohiuddin mjmohiud...@cdac.inwrote: Hi Valerio Cervo, Coap is not working with the tinyos-main... Please use the tinyos-release instead of tinyos-main .. https://github.com/tinyos/tinyos-release Regards, Md.Jamal C-DAC Hyderabad -- - This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. -- - ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help | Dipl.-Ing. Markus Becker | Communication Networks | TZI - Center for Computing Technologies | University Bremen | Germany | web: http://www-user.uni-bremen.de/~beckerm/ | mailto: m...@comnets.uni-bremen.de | telephone: +49 421 218 62379 | building: NW1 room: N2260 -- *David Guillén Jiménez* ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Re : CoapBlip - CoapPpp ignores requests from coap-client
Hi Mohammad Jamal. Hi everybody, My name is David Guillen and I am doing some CoAP testings for an IoT project. Is there any plan to publish a CoAP version compliant with the tutorial CoAP-13? I am using the tinyos-release as you said and it works fine. But the version in tinyos-main is not even sending packets. I could check that sniffing the radio channel. By the way I offer myself to carry on tests of new versions, if it is needed. Best regards, On 24 February 2014 04:43, Mohammad Jamal Mohiuddin mjmohiud...@cdac.inwrote: Hi Valerio Cervo, Coap is not working with the tinyos-main... Please use the tinyos-release instead of tinyos-main .. https://github.com/tinyos/tinyos-release Regards, Md.Jamal C-DAC Hyderabad --- This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. --- ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- *David Guillén Jiménez* ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] SPIN MODEL CHECKER
Spin model checker is a validation and verification open source toolset to verify algorithms for trace errors etc. spinroot.com Would you like to know more? David From: Eric Decker cire...@gmail.com To: David Blubaugh davidblubaugh2...@yahoo.com Cc: tinyos-help@millennium.berkeley.edu tinyos-help@millennium.berkeley.edu Sent: Wednesday, August 28, 2013 8:37 PM Subject: Re: [Tinyos-help] SPIN MODEL CHECKER what is a spin model checker? reference? On Wed, Aug 28, 2013 at 12:11 PM, David Blubaugh davidblubaugh2...@yahoo.com wrote: Has anyone ever used the spin model checker for verifying and validating designs within TinyOS??? Also, can the designs with tinyos be of any large complexity or is there a limit to the complexity of design??? how do you define complexity? how do you measure it? tinyos programs are typically limited by RAM and code size. David Blubaugh From: tinyos-help-requ...@millennium.berkeley.edu tinyos-help-requ...@millennium.berkeley.edu To: tinyos-help@millennium.berkeley.edu Sent: Wednesday, August 28, 2013 3:00 PM Subject: Tinyos-help Digest, Vol 124, Issue 26 Send Tinyos-help mailing list submissions to tinyos-help@millennium.berkeley.edu To subscribe or unsubscribe via the World Wide Web, visit https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help or, via email, send a message with subject or body 'help' to tinyos-help-requ...@millennium.berkeley.edu You can reach the person managing the list at tinyos-help-ow...@millennium.berkeley.edu When replying, please edit your Subject line so it is more specific than Re: Contents of Tinyos-help digest... Today's Topics: 1. LEAP+ Protocol (Syed Abdul basir) 2. Help:Telosb BaseStation (Nilavra Pathak) -- Message: 1 Date: Wed, 28 Aug 2013 04:19:20 -0700 (PDT) From: Syed Abdul basir basir...@yahoo.com Subject: [Tinyos-help] LEAP+ Protocol To: tinyos-help@millennium.berkeley.edu tinyos-help@millennium.berkeley.edu Message-ID: 1377688760.98794.yahoomail...@web162405.mail.bf1.yahoo.com Content-Type: text/plain; charset=iso-8859-1 I am trying to compile leap+ code. getting the following error. can any one help me thanks.? the red highlightederrors. thanks. In file included from myLeapAppC.nc:17: In component `myLeapP': myLeapP.nc:31: interface MYA not found In file included from myLeapAppC.nc:17: myLeapP.nc:55: syntax error before `uint32_t' myLeapP: `ReceiveHello.receive' not implemented myLeapP: `TimerLed1Toggle.fired' not implemented myLeapP: `AMControl.startDone' not implemented myLeapP: `AMControl.stopDone' not implemented myLeapP: `TimerTimeStamp.fired' not implemented myLeapP: `Boot.booted' not implemented myLeapP: `AMSendTimeStamp.sendDone' not implemented myLeapP: `TimerHello.fired' not implemented myLeapP: `ReceiveStart.receive' not implemented myLeapP: `TimerMsgs.fired' not implemented myLeapP: `AMSendAck.sendDone' not implemented myLeapP: `TimerMain.fired' not implemented myLeapP: `TimerACK.fired' not implemented myLeapP: `AMSendTimeKeys.sendDone' not implemented myLeapP: `TimerHelloCount.fired' not implemented myLeapP: `TimerLed2Toggle.fired' not implemented myLeapP: `AMSendHello.sendDone' not implemented myLeapP: `TimeTimeKeys.fired' not implemented myLeapP: `ReceiveAck.receive' not implemented myLeapP: `TimerLed0Toggle.fired' not implemented In file included from /opt/tinyos-2.1.0/tos/chips/cc2420/packet/sim/CC2420PacketC.nc:25, from /opt/tinyos-2.1.0/tos/chips/cc2420/csma/sim/CC2420CsmaC.nc:16, from /opt/tinyos-2.1.0/tos/chips/cc2420/sim/CC2420RadioC.nc:63, from /opt/tinyos-2.1.0/tos/chips/cc2420/sim/CC2420ActiveMessageC.nc:75, from /opt/tinyos-2.1.0/tos/platforms/micaz/sim/ActiveMessageC.nc:61, from myLeapAppC.nc:18: In component `CC2420PacketP': /opt/tinyos-2.1.0/tos/chips/cc2420/packet/sim/CC2420PacketP.nc: In function `getNetwork': /opt/tinyos-2.1.0/tos/chips/cc2420/packet/sim/CC2420PacketP.nc:66: warning: initialization from incompatible pointer type /opt/tinyos-2.1.0/tos/chips/cc2420/lpl/DummyLplC.nc:39:2: warning: #warning *** LOW POWER COMMUNICATIONS DISABLED *** make: *** [sim-exe] Error 1 -- next part -- An HTML attachment was scrubbed... URL: https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20130828/fdb9aaad/attachment-0001.htm -- Message: 2 Date: Wed, 28 Aug 2013 09:04:38 -0400 From: Nilavra Pathak nilav...@umbc.edu Subject: [Tinyos-help] Help:Telosb BaseStation To: tinyos-help@millennium.berkeley.edu, tinyos-help-requ...@millenniym.berkeley.edu Message-ID: CADfuJwKQtSSK==h2a_dFkRwHbpTAmaPpH7=5pwujihyvo30...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hey Guys, I have tried to make the BaseStation program
[Tinyos-help] SPIN MODEL CHECKER
Has anyone ever used the spin model checker for verifying and validating designs within TinyOS??? Also, can the designs with tinyos be of any large complexity or is there a limit to the complexity of design??? David Blubaugh From: tinyos-help-requ...@millennium.berkeley.edu tinyos-help-requ...@millennium.berkeley.edu To: tinyos-help@millennium.berkeley.edu Sent: Wednesday, August 28, 2013 3:00 PM Subject: Tinyos-help Digest, Vol 124, Issue 26 Send Tinyos-help mailing list submissions to tinyos-help@millennium.berkeley.edu To subscribe or unsubscribe via the World Wide Web, visit https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help or, via email, send a message with subject or body 'help' to tinyos-help-requ...@millennium.berkeley.edu You can reach the person managing the list at tinyos-help-ow...@millennium.berkeley.edu When replying, please edit your Subject line so it is more specific than Re: Contents of Tinyos-help digest... Today's Topics: 1. LEAP+ Protocol (Syed Abdul basir) 2. Help:Telosb BaseStation (Nilavra Pathak) -- Message: 1 Date: Wed, 28 Aug 2013 04:19:20 -0700 (PDT) From: Syed Abdul basir basir...@yahoo.com Subject: [Tinyos-help] LEAP+ Protocol To: tinyos-help@millennium.berkeley.edu tinyos-help@millennium.berkeley.edu Message-ID: 1377688760.98794.yahoomail...@web162405.mail.bf1.yahoo.com Content-Type: text/plain; charset=iso-8859-1 I am trying to compile leap+ code. getting the following error. can any one help me thanks.? the red highlightederrors. thanks. In file included from myLeapAppC.nc:17: In component `myLeapP': myLeapP.nc:31: interface MYA not found In file included from myLeapAppC.nc:17: myLeapP.nc:55: syntax error before `uint32_t' myLeapP: `ReceiveHello.receive' not implemented myLeapP: `TimerLed1Toggle.fired' not implemented myLeapP: `AMControl.startDone' not implemented myLeapP: `AMControl.stopDone' not implemented myLeapP: `TimerTimeStamp.fired' not implemented myLeapP: `Boot.booted' not implemented myLeapP: `AMSendTimeStamp.sendDone' not implemented myLeapP: `TimerHello.fired' not implemented myLeapP: `ReceiveStart.receive' not implemented myLeapP: `TimerMsgs.fired' not implemented myLeapP: `AMSendAck.sendDone' not implemented myLeapP: `TimerMain.fired' not implemented myLeapP: `TimerACK.fired' not implemented myLeapP: `AMSendTimeKeys.sendDone' not implemented myLeapP: `TimerHelloCount.fired' not implemented myLeapP: `TimerLed2Toggle.fired' not implemented myLeapP: `AMSendHello.sendDone' not implemented myLeapP: `TimeTimeKeys.fired' not implemented myLeapP: `ReceiveAck.receive' not implemented myLeapP: `TimerLed0Toggle.fired' not implemented In file included from /opt/tinyos-2.1.0/tos/chips/cc2420/packet/sim/CC2420PacketC.nc:25, from /opt/tinyos-2.1.0/tos/chips/cc2420/csma/sim/CC2420CsmaC.nc:16, from /opt/tinyos-2.1.0/tos/chips/cc2420/sim/CC2420RadioC.nc:63, from /opt/tinyos-2.1.0/tos/chips/cc2420/sim/CC2420ActiveMessageC.nc:75, from /opt/tinyos-2.1.0/tos/platforms/micaz/sim/ActiveMessageC.nc:61, from myLeapAppC.nc:18: In component `CC2420PacketP': /opt/tinyos-2.1.0/tos/chips/cc2420/packet/sim/CC2420PacketP.nc: In function `getNetwork': /opt/tinyos-2.1.0/tos/chips/cc2420/packet/sim/CC2420PacketP.nc:66: warning: initialization from incompatible pointer type /opt/tinyos-2.1.0/tos/chips/cc2420/lpl/DummyLplC.nc:39:2: warning: #warning *** LOW POWER COMMUNICATIONS DISABLED *** make: *** [sim-exe] Error 1 -- next part -- An HTML attachment was scrubbed... URL: https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20130828/fdb9aaad/attachment-0001.htm -- Message: 2 Date: Wed, 28 Aug 2013 09:04:38 -0400 From: Nilavra Pathak nilav...@umbc.edu Subject: [Tinyos-help] Help:Telosb BaseStation To: tinyos-help@millennium.berkeley.edu, tinyos-help-requ...@millenniym.berkeley.edu Message-ID: CADfuJwKQtSSK==h2a_dFkRwHbpTAmaPpH7=5pwujihyvo30...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hey Guys, I have tried to make the BaseStation program run in the Telosb mote. I am using Ubuntu 13.04 for this . But every-time I try running the program nothing happens. To test whether the mote is working or not I have run the Blink program and it worked perfectly well . So help please. -Nilavra. -- next part -- An HTML attachment was scrubbed... URL: https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20130828/c3c09c20/attachment-0001.htm -- ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help End of Tinyos-help Digest, Vol
Re: [Tinyos-help] How to change the channel frequency of TelosB mote dynamically?
Hi Han TelosB uses the CC2420 radio transceiver, whose libraries are located at /tos/chips/CC2420 (https://github.com/tinyos/tinyos-main/tree/master/tos/chips/cc2420). The component CC2420ControlC may help you (https://github.com/tinyos/tinyos-main/tree/master/tos/chips/cc2420/control). If you are working with the TKN 154 implementation, then, you are using the IEEE 802.15.4 MAC and PHY layers instead the TinyOS native ones. In this case, make use of the primitive PLME_SET_request. Regards David Date: Tue, 11 Jun 2013 01:42:39 -0700 From: pvvinh...@yahoo.com To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] How to change the channel frequency of TelosB mote dynamically? Dear everyone, I'm currently working on TelosB motes using TinyOS 2.1. Could you please show me how to change the channel frequency of Telosb mote dynamically (without using the MAKEFILE). For example, during the operating time, we can use a command/function to change the frequency of motes, depending on the environment conditions, etc. Any help or suggestion will be appreciated. Thank you very much! Han Bin. -- View this message in context: http://tinyos-help.10906.n7.nabble.com/How-to-change-the-channel-frequency-of-TelosB-mote-dynamically-tp23263.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
[Tinyos-help] Synchronization in TinyOS
Hi all, This question is more a request for advice and/or opinion. Some research articles which deal with synchronization (i.e., aimed at designing some kind of TDMA scheme) in wireless sensor networks, state that nodes can maintain synchronization by exchanging clock skew/drift information with neighboring nodes in coverage area. In other words, maintain any sort of local synchronization. In this sense, in the specialized literature and/or datasheets, it can be found information about the clock skew associated to many devices. For example, in [1], authors indicate that, on average, TelosB introduce 30 us per second of drift; also MicaZ have 40 us per second on average of clock drift [2]. Taking into account the aforementioned, had no global synchronization (a unique node, e.g., the coordinator of the network, conducts a periodic synchronization proccess with all nodes of the network), would be any simple way to make this local synchronization in TinyOS? I mean, is it wise to consider in your synchronization protocol either these values found in the literature (e.g., 30 us in case you worked with TelosB); or exchange timestamps between two nodes and calculate the difference of time; etc.? Thanks in advance, David [1] W. Pak, K.-T. Cho, J. Lee, and S. Bahk, “W-MAC: Supporting Ultra Low Duty Cycle in Wireless Sensor Networks,” in Proceedings of the 2008 IEEE Global Telecommunications Conference (IEEE GLOBECOM 2008), 2008, pp. 1–5.[2] Y. Wu, J.A. Stankovic, T. He, S. Lin, Realistic and Efficient Multi-Channel Communications in Wireless Sensor Networks, in: 27th IEEE International Conference on Computer Communications, IEEE, Phoenix, Arizona, 2008, pp. 1193–1201. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Including QueueC and PoolC components
Hi all
Maybe my following question either is a bit tricky or has no solution. Suppose
the following multi-hop scenario where we have an end-device (no routing
capabilities, it only transmits data to a unique destination), one or several
routing devices (their aim is to forward the data transmitted by the end-device
to one or several destinations), and one destination (sink):
End-Device -- Routing Device 1 -- ... -- Routing Device n -- Destination
I am implementing some libraries which ought to be the same regardless of the
type of device, namely end-device, routing device and/or destination. As I
briefly pointed out, the end-device has no routing capabilities, which implies
that its routing table only constains the node it used for joining the network
-parent node- and, additionally, it should not implement any message queue to
store data. On the contrary, this same features do have to be implemented by
the intermediate devices (routing ones), that is, routing tables of higher size
for storing more neighboring devices, and message_t queues.
I've solved the former using dynamic memory (I know this is supposed to not
be used, by I've tried to control the usage of memory). However, the issue
comes with the latter requirement of implementing the message_t queues. This is
explained below.
In my library, I employ a unique configuration file (I'll refer it hereafter as
main_conf.nc ) that wires everything and it is the same for end-devices and
routing-devices. It is worthy to remark that the final application running on
each device has a different configuration file that wires to this library.
Thus, in this file main_conf.nc, the QueueC and PoolC components ought to be
included. A priori, it should be done as follows:
In some .h file:
#define RX_QUEUE_SIZE 12
or
enum{ RX_QUEUE_SIZE = 12};
and in the confuguration file:
implements{...components new QueueC(message_t*, RX_QUEUE_SIZE),
new PoolC(message_t, RX_QUEUE_SIZE);...}
The easy way would be to change the RX_QUEUE_SIZE value to 1 (or eliminate the
QueueC and PoolC components of the code) every time I compile the code for an
end-device, being this slow and/or inefficient. So, is it possible to do this
in any way? Had both components been defined in the configuration file without
indicating the size of the queue, I may use again dynamic memory. But in this
case...
I hope all written above were easily understood!
Regards,
David
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] TKN154: Energy detection scan
Hi all
I have an issue with TKN154 implementation of the IEEE 802.15.4 standard. I am
trying to perform an energy detection scan with a PAN coordinator device over
four pre-defined channels (e.g., 16, 19, 21, and 26) for later, select the one
which best fits some application requirements. The problem arises when the
command MLME_SCAN.request is called. It seems to me that the proccess regarding
this kind of scan falls in a blocked state because the event MLME_SCAN.confirm
is never issued. Here there is part of the code I am using:
---implementation { void function_1() {
ieee154_PANDescriptor_t m_PANDescriptor[4];int8_t EDList [4];
ieee154_phyChannelsSupported_t ScanChannels = 0;
ScanChannels += ((uint32_t) 1) 16; // CH 1ScanChannels +=
((uint32_t) 1) 19; // CH 2ScanChannels += ((uint32_t) 1) 21; //
CH 3ScanChannels += ((uint32_t) 1) 26; // CH 4
call MLME_SCAN.request (ENERGY_DETECTION_SCAN, // ScanType
ScanChannels, // ScanChannels
5, // ScanDuration
0x00, // ChannelPage
4, //
EnergyDetectListNumEntriesEDList,
// EnergyDetectList
4, // PANDescriptorListNumEntries
m_PANDescriptor,// PANDescriptorList
0 // security
);}event void
MLME_SCAN.confirm ( ieee154_status_t status,
uint8_t ScanType, uint8_t ChannelPage,
uint32_t UnscannedChannels,
uint8_t EnergyDetectListNumEntries, int8_t*
EnergyDetectList, uint8_t PANDescriptorListNumEntries,
ieee154_PANDescriptor_t* PANDescriptorList) {
// It is never issued call Leds.Led0On();
}}---
I appreciate all the help possible.
Regards,
David ___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] TKN154: Energy detection scan
Hi Jan
I solved the problem. This was due to the fact of including
PANDescriptorListNumEntries and PANDescriptorList variables when the MLME_SCAN
is requested. I've not dedicated time in examining this problem more in detail,
which a priori, I thing this should not occur. But you are the developer so I
ber there is a reason.
Thanks
David
Date: Thu, 21 Feb 2013 12:25:35 +0100
Subject: Re: [Tinyos-help] TKN154: Energy detection scan
From: ha...@tkn.tu-berlin.de
To: drod...@outlook.com
CC: tinyos-help@millennium.berkeley.edu
Hi David,
MLME_SCAN.request() returns a parameter ieee154_status_t, can you take
a look at its value to check whether it is IEEE154_SUCCESS (only in
this case the confirm event will be signalled).
Jan
On Thu, Feb 21, 2013 at 11:31 AM, David Rodenas drod...@outlook.com wrote:
Hi all
I have an issue with TKN154 implementation of the IEEE 802.15.4 standard. I
am trying to perform an energy detection scan with a PAN coordinator device
over four pre-defined channels (e.g., 16, 19, 21, and 26) for later, select
the one which best fits some application requirements. The problem arises
when the command MLME_SCAN.request is called. It seems to me that the
proccess regarding this kind of scan falls in a blocked state because the
event MLME_SCAN.confirm is never issued. Here there is part of the code I am
using:
---
implementation {
void function_1()
{
ieee154_PANDescriptor_t m_PANDescriptor[4];
int8_t EDList [4];
ieee154_phyChannelsSupported_t ScanChannels = 0;
ScanChannels += ((uint32_t) 1) 16; // CH 1
ScanChannels += ((uint32_t) 1) 19; // CH 2
ScanChannels += ((uint32_t) 1) 21; // CH 3
ScanChannels += ((uint32_t) 1) 26; // CH 4
call MLME_SCAN.request (ENERGY_DETECTION_SCAN, // ScanType
ScanChannels, // ScanChannels
5, // ScanDuration
0x00, // ChannelPage
4, // EnergyDetectListNumEntries
EDList,// EnergyDetectList
4, // PANDescriptorListNumEntries
m_PANDescriptor,// PANDescriptorList
0 // security
);
}
event void MLME_SCAN.confirm (
ieee154_status_t status,
uint8_t ScanType,
uint8_t ChannelPage,
uint32_t UnscannedChannels,
uint8_t EnergyDetectListNumEntries,
int8_t* EnergyDetectList,
uint8_t PANDescriptorListNumEntries,
ieee154_PANDescriptor_t* PANDescriptorList)
{
// It is never issued
call Leds.Led0On();
}
}
---
I appreciate all the help possible.
Regards,
David
___
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] typedef + nx_intN_t = impossible?!
I'll look into it in a week or so...
David
On Feb 12, 2013 7:14 PM, Eric Decker cire...@gmail.com wrote:
Sigh. Would of been nice if we could have found a work around.
File it as a bug against https://github.com/tinyos/nesc
Maybe we can get David's attention.David?
On Tue, Feb 12, 2013 at 3:48 AM, Johny Mattsson jmatts...@dius.com.auwrote:
On 12 February 2013 13:31, Eric Decker cire...@gmail.com wrote:
First, the #define works because it is simple text substitution. So if
you look at the resultant app.c you will see
error_t foo(nx_uint16_t val)
when using the define.
So of course it works.
I'd like to think so, but given that a plain typedef doesn't work in this
situation, I wouldn't say of course - there could've been something wrong
with using nx types as pass-by-value parameters, for example. :)
If you compile Blink say for the telosb and then take a look at app.c you
can see where the nx types are defined. Search for nx_uint16.
I'll do you one better, I'll show you what's in the app.c from the
minimal test case in my previous email:
First there's the nx_uint16_t which is an innocuous enough packed struct:
typedef struct { unsigned char nxdata[2]; } __attribute__((packed))
nx_uint16_t;
Then there's an unused typedef of a __nesc_nxbase_nx_uint16_t whose use
I'm not entirely clear on without delving into compiler internals:
typedef uint16_t __nesc_nxbase_nx_uint16_t ;
There is of course my typedef, looking as expected (module__type name):
typedef nx_uint16_t TestNxTypedefP__my_type16_t;
And then there's the weirdness of the function taking my typedef'd type
as an argument:
static inline error_t
TestNxTypedefP__foo(TestNxTypedefPnesc_nxbase_my_type16_t val);
What I had expected to see here was:
static inline error_t TestNxTypedefP__foo(TestNxTypedefP__my_type16_t
val);
It seems the compiler has an internal translation rule for nx types that
translates them from the struct version to the base version. When
compiling with the #define rather than the typedef, the function prototype
looks like this:
static inline error_t TestNxTypedefP__foo(__nesc_nxbase_nx_uint16_t
val);
To me this seems like a nesc issue (or at the very least a nesc
documentation issue).
Who/where do I bounce this to? Running nescc --help only points at the
gcc bug reporting, which is clearly not applicable here.
Maybe adding a nx_ prefix to your type would help.
Tried that, it didn't help.
Thanks,
/Johny
*
*
--
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] Hidden and Exposed node problem
Hi If there was any accepted/standarized solution for the hidden and exposed terminal phenomena, the current work of the great part of the sciencific community coping with this problem would be unnecessary. There is a plethora of approaches dealing with these problems by making use of multichannel selection, directional antennas, TDMA... In the Tinyos case, you should take a time revising the operation of BoXMAC, and study how nodes access tothe medium taking into account if BoXMAC solves or not the hidden and exposed terminal phenomena. But first, you need more background about what you are trying to study and simulate, e.g., see the following paper: C. Cano, B. Bellalta, A. Cisneros, and M. Oliver, “Quantitative analysis of the hidden terminal problem in preamble sampling WSNs,” Ad Hoc Networks, vol. 10, no. 1, pp. 19–36, 2012. Regards David From: rwmas...@gmail.com Date: Mon, 21 Jan 2013 10:26:34 +0100 To: das.suresh...@gmail.com CC: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] Hidden and Exposed node problem Theoretically, the scenario is adequate enough to cause such a problem, but in my experience, first of all it is not that frequent and secondly, the network has to be more dense which in case of just 3 nodes is not enough. So I would suggest to look into the reason more thorough, it could be just because of the collisions between 2 and 3. On Mon, Jan 21, 2013 at 7:37 AM, Suresh Kumar Das das.suresh...@gmail.com wrote: I am using Tinyos 2.1. Does TOSSIM have any sort of mechanism to deal with hidden and exposed node problem. I am searching it from last 2weeks but can find any sollution. I have 3 nodes 1, 2 and 3. Nod 2 and 3 are sending packets to node 1 in . Some packets are get discarded. How can I solve this problem. Any reply or clue is appreciated. Thanks ___ 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
[Tinyos-help] Error 2: Multiple Targets Specified [Looking for root cause/explanations]
Hi all, I am currently working on a project which requires me to work with Micaz MPR2400 motes attached with the MTS310 sensor boards. At the moment, i am trying to test out the codes from my seniors to see what they do (Apparently it is a base station test code) and i got the following error when i typed Make micaz install,COM4.. I have searched around for the multiple targets specified error but have not come across any definitive solutions or explanations as to what causes it. Can someone please enlighten me as to the possible causes and what is wrong? If the actual codes are required, please let me know again! Error: multiple targets specified make: *** [exe0] Error 2 David Goh Electrical Electronics Engineering Nanyang Technological University ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Multiple Targets Specified
Hi all, I am currently working on a project which requires me to work with Micaz MPR2400 motes attached with the MTS310 sensor boards. At the moment, i am trying to test out the codes from my seniors to see what they do (Apparently it is a base station test code) and i got the following error when i typed 'Make micaz install,MIB520,COM4'. I have searched around for the multiple targets specified error but have not come across any definitive solutions or explanations as to what causes it. Can someone please enlighten me as to the possible causes and what is wrong? If the actual codes are required, please let me know again! Error: multiple targets specified make: *** [exe0] Error 2 David Goh Electrical Electronics Engineering Nanyang Technological University ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Applications for Windows CE (EMBEDDED SQL)
To All, I was wondering if there is a way I can use tinyOS to develop an application within windows CE (based on the tinyOS as a foundation for this application within windows CE) . I was wondering if anyone has ever interfaced tinyOS with embedded SQL to communicate with an external database ?? Thanks, David Blubaugh ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] FW: when does CC2420 radio drop a frame?
Hi Collision due to two transmitters sending a frame to the same receiver simultaneously (if these transmitters don't listen to each other - they are not in coverage area -, then this is called the hidden terminal problem). Regards David Date: Tue, 4 Dec 2012 01:07:26 -0500 From: xiao...@wayne.edu To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] when does CC2420 radio drop a frame? Hi everyone, If address recognition is enabled, the CC2420 radio hardware will drop any incoming frame failing the address recognition. Is there any other case that CC2420 discards a frame, at the hardware level? Thanks in advance. -- -Xiaohui LiuTelosBTinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ 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] Drop packets in TinyOS
Hi Eric Up to now, it doesn't work. In fact, when it is supposed the piece of code executes, the mote resets, and I cannot understand it! I'm also debugging the code but I'm missing something because I don't see anything strange. Lets see if I understood your doubts. In relation to who keeps track of what buffers are available or not, I thing that functionality is part of the QueueC component and yours. Yours because you are who mark when a packet has to be dequeued aimed at being transmitted or discarded, and of the QueueC because it points to a free space of memory where you can enqueue a new packet as well as the head of this queue. On the other hand, when you need to enqueue a new packet, you have to return a empty message_t to the MAC by making a call to Pool.get(). Then, you enqueue the packet by calling Queue.enqueue(new_message_t) . Both components, PoolC and QueueC, point to different spaces of memory but they keep track of if you have space to store more packets, the piece of memory where you enqueue/return a message_t... . And when you dequeue a packet, after the event sendDone(msg) is signaled, you make a call to Pool.put(msg) (I'm sure you're aware of this). This make sense for me, but as I said, for now, it doesn't work! Regards David Date: Tue, 27 Nov 2012 16:31:15 -0800 Subject: Re: [Tinyos-help] Drop packets in TinyOS From: cire...@gmail.com To: drod...@outlook.com CC: tinyos-help@millennium.berkeley.edu On Tue, Nov 27, 2012 at 12:16 AM, David Rodenas drod...@outlook.com wrote: Hi Eric In any case, I have a possible answer which is simpler than I thought. I was addressing the problem wrong, thinking that a message that was enqueued, it was really a peace of dynamic/external memory that came (was transmitted) to the receiver node, so it increased the already occupied memory (there is a reason of why a thought this: I also work with Network Simulator 2 - NS2 - and there you use dynamic memory for messages). This is totally wrong with TinyOS, when you receive a data message and enqueue it, you are only copying the whole content to the corresponding memory location (you defined Queue as static memory) and increasing a counter of enqueued messages. Then you can use PoolC to return an empty message_t to the system. Thus, when you make a call to Queue.dequeue(), what this function returns is a pointer to a static portion of memory (of size message_t) as well as decreases the counter of messages enqueued. Therefore, when another message_t is enqueued, this occupies the same portion of memory so the node never run outs of memory because of what I what asking. Am I right? The gist is certainly correct. The devil as always is in the details. I do hand debugging of code like this to make sure that a) the general case works, b) is argueably correct, and then c) examine the corner cases (where can it screw up, and are there assumptions made about how the code works that can be violated). But I didn't write or test this code. so your mileage may vary (YMMV). But I do think you have the gist of how it behaves. The question is who keeps track of what buffers are available and what denotes the buffer being busy. If you dequeue the packet from the queue, does it something else need to be told that this packet is available? Should it get put back into the Pool? eric Thanks again, regards David Date: Mon, 26 Nov 2012 19:51:48 -0800 Subject: Re: [Tinyos-help] Drop packets in TinyOS From: cire...@gmail.com To: drod...@outlook.com CC: tinyos-help@millennium.berkeley.edu Looking at this problem from the queueing mechanism is coming at the problem from the inside out. So it is pretty difficult trying to answer the question you are asking. To do so really requires looking at the data flow (message_t) and buffer flow at various points in packet transmission and reception. The answer to your question depends on what the original caller of the enqueue wants done.And then there is the whole wiring issue and how to pull the whole thing together. Simply dequeuing the message certainly isn't enough because that most likely leads to lost messages. But the whole scheme needs to be worked out in a systemic fashion. And it would be nice if it were documented. It certianly is a hole. Eventually I'll get to it. I certainly understand what you are trying to accomplish. Been there done that.Sorry I don't have a better answer for you. eric On Mon, Nov 26, 2012 at 7:48 AM, David Rodenas drod...@outlook.com wrote: Hi all I would like to know how to discard a message which is stored in a queue (component QueueC of message_t). To better explain this, lets suppose we have a maximum number of retries during we are trying to forward a data message. This is stored in a queue waiting for being transmitted. A failed transmission can occur due to collisions, interferences, etc. So when this maximum number is reached, the data message
Re: [Tinyos-help] Drop packets in TinyOS
Hi Eric
thanks for your answer. In fact, I thought the same. Although there is
something you pointed out that it just what I need: The answer to your
question depends on what the original caller of the enqueue wants done. [...]
Simply dequeuing the message certainly isn't enough because that most likely
leads to lost messages. Certeanly, what I need is that, if a message has to be
dropped, then it counts as a lost message. So what I don't want to is being
dequeuing messages and at the end, run out of memory because I did not manage
it correctly handling these dequeued messages.
In any case, I have a possible answer which is simpler than I thought. I was
addressing the problem wrong, thinking that a message that was enqueued, it was
really a peace of dynamic/external memory that came (was transmitted) to the
receiver node, so it increased the already occupied memory (there is a reason
of why a thought this: I also work with Network Simulator 2 - NS2 - and there
you use dynamic memory for messages). This is totally wrong with TinyOS, when
you receive a data message and enqueue it, you are only copying the whole
content to the corresponding memory location (you defined Queue as static
memory) and increasing a counter of enqueued messages. Then you can use PoolC
to return an empty message_t to the system. Thus, when you make a call to
Queue.dequeue(), what this function returns is a pointer to a static portion of
memory (of size message_t) as well as decreases the counter of messages
enqueued. Therefore, when another message_t is enqueued, this occupies the same
portion of memory so the node never run outs of memory because of what I what
asking.
Am I right?
Thanks again, regards
David
Date: Mon, 26 Nov 2012 19:51:48 -0800
Subject: Re: [Tinyos-help] Drop packets in TinyOS
From: cire...@gmail.com
To: drod...@outlook.com
CC: tinyos-help@millennium.berkeley.edu
Looking at this problem from the queueing mechanism is coming at the problem
from the inside out.
So it is pretty difficult trying to answer the question you are asking.
To do so really requires looking at the data flow (message_t) and buffer flow
at various points in packet transmission and reception.
The answer to your question depends on what the original caller of the enqueue
wants done.And then there is the whole wiring issue and how to pull the
whole thing together.
Simply dequeuing the message certainly isn't enough because that most likely
leads to lost messages. But the whole scheme needs to be worked out in a
systemic fashion. And it would be nice if it were documented. It certianly
is a hole. Eventually I'll get to it.
I certainly understand what you are trying to accomplish. Been there done
that.Sorry I don't have a better answer for you.
eric
On Mon, Nov 26, 2012 at 7:48 AM, David Rodenas drod...@outlook.com wrote:
Hi all
I would like to know how to discard a message which is stored in a queue
(component QueueC of message_t). To better explain this, lets suppose we have a
maximum number of retries during we are trying to forward a data message. This
is stored in a queue waiting for being transmitted. A failed transmission can
occur due to collisions, interferences, etc. So when this maximum number is
reached, the data message should be discarded, making this same procedure with
the following message (head of the queue). Here there is a simple code of what
I'm asking:
maximum_retries = 3;num_retries = 0;
if (num_retries maximum_retries){message_t * drop_msg = call
Queue.dequeue();drop(drop_msg);
}
The point is that I'm not sure if just dequeuing the message_t is enough. This
message occupies a piece of memory space and this has to be freed. Am I right?
Should I use the function free as in any C-based language when dynamic memory
allocation is used?
Thanks
David
___
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] Possible bug (small one) in TKN154
Hi Jan
I found a possible bug in the DataP.nc and/or TKN154NonBeaconEnabledP.nc.
When you use the non-beacon enabled mode as well as the MCPS_PURGE
functionality, the compiler suggests that PurgeGtsDevice and PurgeGtsCoord are
not connected. In fact these don't need to be connected, but something should
be changed at DataP.nc:
command ieee154_status_t MCPS_PURGE.request ( uint8_t
msduHandle) {if (call PurgeDirect.purge(msduHandle) == IEEE154_SUCCESS ||
call PurgeIndirect.purge(msduHandle) == IEEE154_SUCCESS ||call
PurgeGtsDevice.purge(msduHandle) == IEEE154_SUCCESS ||call
PurgeGtsCoord.purge(msduHandle) == IEEE154_SUCCESS) return
IEEE154_SUCCESS;else return IEEE154_INVALID_HANDLE; }
Maybe change it for (I've not tested it):
command ieee154_status_t MCPS_PURGE.request ( uint8_t
msduHandle) {if (MLME_GET.macBeaconOrder() != 15
MLME_GET.macSuperframeOrder() != 15) // beacon mode{if (call
PurgeDirect.purge(msduHandle) == IEEE154_SUCCESS ||call
PurgeIndirect.purge(msduHandle) == IEEE154_SUCCESS ||call
PurgeGtsDevice.purge(msduHandle) == IEEE154_SUCCESS ||call
PurgeGtsCoord.purge(msduHandle) == IEEE154_SUCCESS) return
IEEE154_SUCCESS;else return IEEE154_INVALID_HANDLE;}else//
non-beacon mode{if (call PurgeDirect.purge(msduHandle) ==
IEEE154_SUCCESS ||call PurgeIndirect.purge(msduHandle) ==
IEEE154_SUCCESS) return IEEE154_SUCCESS;else return
IEEE154_INVALID_HANDLE;} }
Am I right?
Regards
David
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Drop packets in TinyOS
Hi all
I would like to know how to discard a message which is stored in a queue
(component QueueC of message_t). To better explain this, lets suppose we have a
maximum number of retries during we are trying to forward a data message. This
is stored in a queue waiting for being transmitted. A failed transmission can
occur due to collisions, interferences, etc. So when this maximum number is
reached, the data message should be discarded, making this same procedure with
the following message (head of the queue). Here there is a simple code of what
I'm asking:
maximum_retries = 3;num_retries = 0;
if (num_retries maximum_retries){message_t * drop_msg = call
Queue.dequeue();drop(drop_msg);}
The point is that I'm not sure if just dequeuing the message_t is enough. This
message occupies a piece of memory space and this has to be freed. Am I right?
Should I use the function free as in any C-based language when dynamic memory
allocation is used?
Thanks
David ___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Sleeping in TKN154
Hi Jan
I have a simple question. If wanted to switch off the radio instantly, that is
e.g., you are signaled a MCPS_DATA.confirm() event and then you desire to go to
sleep, I suppose you would have to call MLME_RX_ENABLE with RxOnDuration equal
to 0. However, as switching among power modes (e.g., RX -- TX; SLEEP --
RX...) takes some time (and energy), this parameter cannot be 0. In fact, if
you enabled the tkn154 debug, the following would be executed:
dbg_serial(RxEnableP, never actually managed to switch to Rx mode\n);.
So, is there any other form to switch off the radio instantly than calling
MLME_RX_ENABLE? or should RxOnDuration take a very small value (although the
radio would be ON during a very short interval for later go to sleep)? Or I
should add this functionality modifying RxEnable.nc as you pointed out in your
first response?
Thanks
David
From: drod...@outlook.com
To: tinyos-help@millennium.berkeley.edu
Date: Thu, 22 Nov 2012 16:00:00 +
Subject: Re: [Tinyos-help] Sleeping in TKN154
Hi
You were right. The problem was that I had macRxOnWhenIdle set to TRUE since
the beginning of the app. The main reason is that I needed all nodes ON during
a short time interval to conduct a network formation procedure. After that
interval and once the network is formed, macRxOnWhenIdle should be set to FALSE
because MLME_RX_ENABLE enables the receiver during the predefined ON period so
you wouldn't have problems receiving information from other devices.
Thanks Jan for your help
David
Date: Thu, 22 Nov 2012 15:04:59 +
Subject: Re: [Tinyos-help] Sleeping in TKN154
From: ha...@tkn.tu-berlin.de
To: drod...@outlook.com
CC: tinyos-help@millennium.berkeley.edu
Hi David,
I just did a small test and for me it worked, maybe you are
accidentally setting the macRxOnWhenIdle attribute to TRUE? You find
my test code below, e.g. copy into
apps/tests/tkn154/nonbeacon-enabled/TestActiveScan/coordinator/TestActiveScanCoordC
(and to verify set an LED in void offSpiReserved() and reset the same
LED in ReliableWait.waitRxDone(), in
tos/chips/cc2420_tkn154/CC2420TKN154P.nc).
Jan
event void Boot.booted() {
call MLME_RESET.request(TRUE);
}
event void MLME_RESET.confirm(ieee154_status_t status) {
if (status != IEEE154_SUCCESS)
return;
call MLME_SET.macShortAddress(COORDINATOR_ADDRESS);
call MLME_SET.macAssociationPermit(FALSE);
//call MLME_SET.macRxOnWhenIdle(TRUE);
call MLME_START.request(
PAN_ID, // PANId
RADIO_CHANNEL,// LogicalChannel
0,// ChannelPage,
0,// StartTime,
15, // BeaconOrder
15, // SuperframeOrder
TRUE, // PANCoordinator
FALSE,// BatteryLifeExtension
FALSE,// CoordRealignment
NULL, // no realignment security
NULL // no beacon security
);
}
event void MLME_START.confirm(ieee154_status_t status)
{
call Led1Timer.startPeriodic(62500U); // fire timer every 1 sec
}
event void MLME_RX_ENABLE.confirm( ieee154_status_t status)
{
if (status == IEEE154_SUCCESS)
call Leds.led0Toggle();
}
event void Led1Timer.fired() {
call MLME_RX_ENABLE.request(FALSE, 0, 31250); // enable RX for 0.5 sec
}
On Wed, Nov 21, 2012 at 12:16 PM, David Rodenas drod...@outlook.com wrote:
Hi Jan
I asked about switching off periodically the radio transceiver in order to
plan a duty cycle. Then, you told me I should use the MLME_RX_ENABLE
interface provided by the Ieee802154NonBeaconEnabledC component. Well, I've
done that, I mean, I've set a timer which represents a wakeup interval that
when it expires, it should activate the radio transceiver during a time
interval equal to RxOnDuration. My problem is that I'm not really sure if
this really works. The reason is that a mote acting as a receiver node
receives data when it should be sleeping! Here a brief explanation of my
test with pseudocode:
start() // the app starts
{
initialize Rx_enable component (call Init.init(););
start periodic wakeup interval wiTimer;
call MLM_RX_ENABLE(RxOnDuration);
}
MLME_RX_Enable.confirm() {} // It confirms that the radio is enabled
wiTimer.fired () // the witimer expires
{
/*
* Here I should call again MHME_RX_ENABLE with RxOnDuration.
* call MLME_RX_ENABLE(RxOnDuration);
* However, to this test, I do not make the call. As a result, the
* radio should be disabled and the node cannot receive anything
*/
return;
}
recv() // receive data (MCPS_DATA.indication
Re: [Tinyos-help] Sleeping in TKN154
I answer to myself. I was completely wrong! the node switch OFF instantly with
RxOnDuration equal to 0. Sorry!!
From: drod...@outlook.com
To: tinyos-help@millennium.berkeley.edu
Date: Fri, 23 Nov 2012 10:52:59 +
Subject: Re: [Tinyos-help] Sleeping in TKN154
Hi Jan
I have a simple question. If wanted to switch off the radio instantly, that is
e.g., you are signaled a MCPS_DATA.confirm() event and then you desire to go to
sleep, I suppose you would have to call MLME_RX_ENABLE with RxOnDuration equal
to 0. However, as switching among power modes (e.g., RX -- TX; SLEEP --
RX...) takes some time (and energy), this parameter cannot be 0. In fact, if
you enabled the tkn154 debug, the following would be executed:
dbg_serial(RxEnableP, never actually managed to switch to Rx mode\n);.
So, is there any other form to switch off the radio instantly than calling
MLME_RX_ENABLE? or should RxOnDuration take a very small value (although the
radio would be ON during a very short interval for later go to sleep)? Or I
should add this functionality modifying RxEnable.nc as you pointed out in your
first response?
Thanks
David
From: drod...@outlook.com
To: tinyos-help@millennium.berkeley.edu
Date: Thu, 22 Nov 2012 16:00:00 +
Subject: Re: [Tinyos-help] Sleeping in TKN154
Hi
You were right. The problem was that I had macRxOnWhenIdle set to TRUE since
the beginning of the app. The main reason is that I needed all nodes ON during
a short time interval to conduct a network formation procedure. After that
interval and once the network is formed, macRxOnWhenIdle should be set to FALSE
because MLME_RX_ENABLE enables the receiver during the predefined ON period so
you wouldn't have problems receiving information from other devices.
Thanks Jan for your help
David
Date: Thu, 22 Nov 2012 15:04:59 +
Subject: Re: [Tinyos-help] Sleeping in TKN154
From: ha...@tkn.tu-berlin.de
To: drod...@outlook.com
CC: tinyos-help@millennium.berkeley.edu
Hi David,
I just did a small test and for me it worked, maybe you are
accidentally setting the macRxOnWhenIdle attribute to TRUE? You find
my test code below, e.g. copy into
apps/tests/tkn154/nonbeacon-enabled/TestActiveScan/coordinator/TestActiveScanCoordC
(and to verify set an LED in void offSpiReserved() and reset the same
LED in ReliableWait.waitRxDone(), in
tos/chips/cc2420_tkn154/CC2420TKN154P.nc).
Jan
event void Boot.booted() {
call MLME_RESET.request(TRUE);
}
event void MLME_RESET.confirm(ieee154_status_t status) {
if (status != IEEE154_SUCCESS)
return;
call MLME_SET.macShortAddress(COORDINATOR_ADDRESS);
call MLME_SET.macAssociationPermit(FALSE);
//call MLME_SET.macRxOnWhenIdle(TRUE);
call MLME_START.request(
PAN_ID, // PANId
RADIO_CHANNEL,// LogicalChannel
0,// ChannelPage,
0,// StartTime,
15, // BeaconOrder
15, // SuperframeOrder
TRUE, // PANCoordinator
FALSE,// BatteryLifeExtension
FALSE,// CoordRealignment
NULL, // no realignment security
NULL // no beacon security
);
}
event void MLME_START.confirm(ieee154_status_t status)
{
call Led1Timer.startPeriodic(62500U); // fire timer every 1 sec
}
event void MLME_RX_ENABLE.confirm( ieee154_status_t status)
{
if (status == IEEE154_SUCCESS)
call Leds.led0Toggle();
}
event void Led1Timer.fired() {
call MLME_RX_ENABLE.request(FALSE, 0, 31250); // enable RX for 0.5 sec
}
On Wed, Nov 21, 2012 at 12:16 PM, David Rodenas drod...@outlook.com wrote:
Hi Jan
I asked about switching off periodically the radio transceiver in order to
plan a duty cycle. Then, you told me I should use the MLME_RX_ENABLE
interface provided by the Ieee802154NonBeaconEnabledC component. Well, I've
done that, I mean, I've set a timer which represents a wakeup interval that
when it expires, it should activate the radio transceiver during a time
interval equal to RxOnDuration. My problem is that I'm not really sure if
this really works. The reason is that a mote acting as a receiver node
receives data when it should be sleeping! Here a brief explanation of my
test with pseudocode:
start() // the app starts
{
initialize Rx_enable component (call Init.init(););
start periodic wakeup interval wiTimer;
call MLM_RX_ENABLE(RxOnDuration);
}
MLME_RX_Enable.confirm() {} // It confirms that the radio is enabled
wiTimer.fired () // the witimer expires
{
/*
* Here I should call again MHME_RX_ENABLE with RxOnDuration
Re: [Tinyos-help] Sleeping in TKN154
Hi
You were right. The problem was that I had macRxOnWhenIdle set to TRUE since
the beginning of the app. The main reason is that I needed all nodes ON during
a short time interval to conduct a network formation procedure. After that
interval and once the network is formed, macRxOnWhenIdle should be set to FALSE
because MLME_RX_ENABLE enables the receiver during the predefined ON period so
you wouldn't have problems receiving information from other devices.
Thanks Jan for your help
David
Date: Thu, 22 Nov 2012 15:04:59 +
Subject: Re: [Tinyos-help] Sleeping in TKN154
From: ha...@tkn.tu-berlin.de
To: drod...@outlook.com
CC: tinyos-help@millennium.berkeley.edu
Hi David,
I just did a small test and for me it worked, maybe you are
accidentally setting the macRxOnWhenIdle attribute to TRUE? You find
my test code below, e.g. copy into
apps/tests/tkn154/nonbeacon-enabled/TestActiveScan/coordinator/TestActiveScanCoordC
(and to verify set an LED in void offSpiReserved() and reset the same
LED in ReliableWait.waitRxDone(), in
tos/chips/cc2420_tkn154/CC2420TKN154P.nc).
Jan
event void Boot.booted() {
call MLME_RESET.request(TRUE);
}
event void MLME_RESET.confirm(ieee154_status_t status) {
if (status != IEEE154_SUCCESS)
return;
call MLME_SET.macShortAddress(COORDINATOR_ADDRESS);
call MLME_SET.macAssociationPermit(FALSE);
//call MLME_SET.macRxOnWhenIdle(TRUE);
call MLME_START.request(
PAN_ID, // PANId
RADIO_CHANNEL,// LogicalChannel
0,// ChannelPage,
0,// StartTime,
15, // BeaconOrder
15, // SuperframeOrder
TRUE, // PANCoordinator
FALSE,// BatteryLifeExtension
FALSE,// CoordRealignment
NULL, // no realignment security
NULL // no beacon security
);
}
event void MLME_START.confirm(ieee154_status_t status)
{
call Led1Timer.startPeriodic(62500U); // fire timer every 1 sec
}
event void MLME_RX_ENABLE.confirm( ieee154_status_t status)
{
if (status == IEEE154_SUCCESS)
call Leds.led0Toggle();
}
event void Led1Timer.fired() {
call MLME_RX_ENABLE.request(FALSE, 0, 31250); // enable RX for 0.5 sec
}
On Wed, Nov 21, 2012 at 12:16 PM, David Rodenas drod...@outlook.com wrote:
Hi Jan
I asked about switching off periodically the radio transceiver in order to
plan a duty cycle. Then, you told me I should use the MLME_RX_ENABLE
interface provided by the Ieee802154NonBeaconEnabledC component. Well, I've
done that, I mean, I've set a timer which represents a wakeup interval that
when it expires, it should activate the radio transceiver during a time
interval equal to RxOnDuration. My problem is that I'm not really sure if
this really works. The reason is that a mote acting as a receiver node
receives data when it should be sleeping! Here a brief explanation of my
test with pseudocode:
start() // the app starts
{
initialize Rx_enable component (call Init.init(););
start periodic wakeup interval wiTimer;
call MLM_RX_ENABLE(RxOnDuration);
}
MLME_RX_Enable.confirm() {} // It confirms that the radio is enabled
wiTimer.fired () // the witimer expires
{
/*
* Here I should call again MHME_RX_ENABLE with RxOnDuration.
* call MLME_RX_ENABLE(RxOnDuration);
* However, to this test, I do not make the call. As a result, the
* radio should be disabled and the node cannot receive anything
*/
return;
}
recv() // receive data (MCPS_DATA.indication())
{
// Here I have another node that periodically broadcasts a message.
// When this message is received, it activates one of the receiver
node'leds.
}
What am I considering that it's wrong? Does MHME_RX_ENABLE really work and
after RxOnDuration, the radio goes to sleep mode?
Thanks,
David
Date: Wed, 14 Nov 2012 12:45:25 +0100
Subject: Re: [Tinyos-help] Sleeping in TKN154
From: ha...@tkn.tu-berlin.de
To: drod...@outlook.com
CC: tinyos-help@millennium.berkeley.edu
Hi David,
there are two places where you can implement such duty-cycling: (a) on
top of the MAC: your component would wire to MLME_RX_ENABLE interface
provided by Ieee802154NonBeaconEnabledC and you would have a periodic
timer that fires at the desired ON-Time. In the event-handler you
would call MLME_RX_ENABLE with a RxOnDuration parameter matching
your ON-time interval. If timers are not accurate enough for you
(because they fire in task context), you (b) could use Alarms instead.
Then you
Re: [Tinyos-help] Sleeping in TKN154
Hi Jan
I asked about switching off periodically the radio transceiver in order to plan
a duty cycle. Then, you told me I should use the MLME_RX_ENABLE interface
provided by the Ieee802154NonBeaconEnabledC component. Well, I've done that, I
mean, I've set a timer which represents a wakeup interval that when it expires,
it should activate the radio transceiver during a time interval equal to
RxOnDuration. My problem is that I'm not really sure if this really works. The
reason is that a mote acting as a receiver node receives data when it should be
sleeping! Here a brief explanation of my test with pseudocode:
start() // the app starts{ initialize Rx_enable component (call
Init.init();); start periodic wakeup interval wiTimer; call
MLM_RX_ENABLE(RxOnDuration);}
MLME_RX_Enable.confirm() {} // It confirms that the radio is enabled
wiTimer.fired () // the witimer expires{ /** Here I should call again
MHME_RX_ENABLE with RxOnDuration.* call MLME_RX_ENABLE(RxOnDuration);*
However, to this test, I do not make the call. As a result, the * radio
should be disabled and the node cannot receive anything*/return;}
recv() // receive data (MCPS_DATA.indication()){ // Here I have another node
that periodically broadcasts a message.// When this message is received, it
activates one of the receiver node'leds.}
What am I considering that it's wrong? Does MHME_RX_ENABLE really work and
after RxOnDuration, the radio goes to sleep mode?
Thanks,
David
Date: Wed, 14 Nov 2012 12:45:25 +0100
Subject: Re: [Tinyos-help] Sleeping in TKN154
From: ha...@tkn.tu-berlin.de
To: drod...@outlook.com
CC: tinyos-help@millennium.berkeley.edu
Hi David,
there are two places where you can implement such duty-cycling: (a) on
top of the MAC: your component would wire to MLME_RX_ENABLE interface
provided by Ieee802154NonBeaconEnabledC and you would have a periodic
timer that fires at the desired ON-Time. In the event-handler you
would call MLME_RX_ENABLE with a RxOnDuration parameter matching
your ON-time interval. If timers are not accurate enough for you
(because they fire in task context), you (b) could use Alarms instead.
Then you would have to modify the MAC. You could extend RxEnableP with
your own async duty-cycle configuration interface and also modify its
interface towards DispatchUnslottedCsmaP (which you would also have to
extend / make async). Unless you need such accurate timing, you'd
probably go for option (a) - you can make some tests to find out
when the radio actually changed state (to see if it satisfies your
timing requirements): just set the tkn154debug flag and you will get
statistics via printf (see apps/tests/tkn154/README.txt for details).
Jan
On Wed, Nov 14, 2012 at 11:32 AM, David Rodenas drod...@outlook.com wrote:
Hi all
I am interseted in programming a duty-cycling scheme by making use of the
TKN154 libraries. In particular, I want to induce the motes to periods of
activity (ON) and inactivity (OFF) over the IEEE 802.15.4 non-beacon mode.
As example:
||++-++-++---
||+ ON | OFF | ON | OFF
| ON | OFF...
||++-++-++---
||+IEEE 802.15.4 NON-BEACON MODE
...
||+-
My problem is not how to sinchronize nodes for transmission and reception;
it's knowing which components or libraries can I use to control de CC2420,
and switch the radio ON/OFF periodocally. I've been trying to figure out how
to do it through the LowPowerListening component (but I cannot use it
because my protocol does not requires the transmission of preambles), or
taking shots in the dark with the TKN files at /tos/lib/mac/tkn154, but I am
completely lost.
Please, any help possible would be appreciated.
Thanks
David
___
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] Sleeping in TKN154
Hi all I am interseted in programming a duty-cycling scheme by making use of the TKN154 libraries. In particular, I want to induce the motes to periods of activity (ON) and inactivity (OFF) over the IEEE 802.15.4 non-beacon mode. As example: ||++-++-++---||+ ON | OFF | ON | OFF | ON | OFF ...||++-++-++---||+ IEEE 802.15.4 NON-BEACON MODE ...||+- My problem is not how to sinchronize nodes for transmission and reception; it's knowing which components or libraries can I use to control de CC2420, and switch the radio ON/OFF periodocally. I've been trying to figure out how to do it through the LowPowerListening component (but I cannot use it because my protocol does not requires the transmission of preambles), or taking shots in the dark with the TKN files at /tos/lib/mac/tkn154, but I am completely lost. Please, any help possible would be appreciated. Thanks David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Sleeping in TKN154
Hi Jan your reply is highly appreciated. For know, I don't need accurate timing, only handle the duty cycle scheme, so I choose option (a). Thanks again, David Date: Wed, 14 Nov 2012 12:45:25 +0100 Subject: Re: [Tinyos-help] Sleeping in TKN154 From: ha...@tkn.tu-berlin.de To: drod...@outlook.com CC: tinyos-help@millennium.berkeley.edu Hi David, there are two places where you can implement such duty-cycling: (a) on top of the MAC: your component would wire to MLME_RX_ENABLE interface provided by Ieee802154NonBeaconEnabledC and you would have a periodic timer that fires at the desired ON-Time. In the event-handler you would call MLME_RX_ENABLE with a RxOnDuration parameter matching your ON-time interval. If timers are not accurate enough for you (because they fire in task context), you (b) could use Alarms instead. Then you would have to modify the MAC. You could extend RxEnableP with your own async duty-cycle configuration interface and also modify its interface towards DispatchUnslottedCsmaP (which you would also have to extend / make async). Unless you need such accurate timing, you'd probably go for option (a) - you can make some tests to find out when the radio actually changed state (to see if it satisfies your timing requirements): just set the tkn154debug flag and you will get statistics via printf (see apps/tests/tkn154/README.txt for details). Jan On Wed, Nov 14, 2012 at 11:32 AM, David Rodenas drod...@outlook.com wrote: Hi all I am interseted in programming a duty-cycling scheme by making use of the TKN154 libraries. In particular, I want to induce the motes to periods of activity (ON) and inactivity (OFF) over the IEEE 802.15.4 non-beacon mode. As example: ||++-++-++--- ||+ ON | OFF | ON | OFF | ON | OFF... ||++-++-++--- ||+IEEE 802.15.4 NON-BEACON MODE ... ||+- My problem is not how to sinchronize nodes for transmission and reception; it's knowing which components or libraries can I use to control de CC2420, and switch the radio ON/OFF periodocally. I've been trying to figure out how to do it through the LowPowerListening component (but I cannot use it because my protocol does not requires the transmission of preambles), or taking shots in the dark with the TKN files at /tos/lib/mac/tkn154, but I am completely lost. Please, any help possible would be appreciated. Thanks David ___ 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] make: uisp: command not found (MicaZ and TinyOS 2.1.2)
Hi all I am getting the following error on TinyOS-2.1.2 (installed on Ubuntu 12.04) when I try to install any app on MicaZ. For example, with Blink: ---$ make micaz install mib520,/dev/ttyUSB0mkdir -p build/micazcompiling BlinkAppC to a micaz binaryncc -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=\user\ -DIDENT_HOSTNAME=\user-vbox\ -DIDENT_USERHASH=0x41040a3eL -DIDENT_TIMESTAMP=0x508e415dL -DIDENT_UIDHASH=0xfb0b11caL -fnesc-dump=wiring -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs, components)' -fnesc-dumpfile=build/micaz/wiring-check.xml BlinkAppC.nc -lm compiled BlinkAppC to build/micaz/main.exe2044 bytes in ROM 51 bytes in RAMavr-objcopy --output-target=srec build/micaz/main.exe build/micaz/main.srecavr-objcopy --output-target=ihex build/micaz/main.exe build/micaz/main.ihexwriting TOS imagecp build/micaz/main.srec build/micaz/main.srec.outinstalling micaz binary using mib510uisp -dprog=mib510 -dserial=/dev/ttyUSB0 --wr_fuse_h=0xd9 -dpart=ATmega128 --wr_fuse_e=ff --erase --upload if=build/micaz/main.srec.out --verifymake: uisp: Command not foundmake: *** [program] Error 127--- Any idea? All the help possible is appreciated. Regards, David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] make: uisp: command not found (MicaZ and TinyOS 2.1.2)
Thanks Eric, I thought that problem didn't have nothing to do with ubuntu packages. In any case, after installing the uisp package, I got the following error: Direct Parallel Access not defined. Thereby, I looked for any solution and I found out the following web page: http://recolog.blogspot.com.es/2011/07/running-tikiridb-with-micaz-motes.html. Here, the owner of the page explains how to solve this same issue. Hence, anyone that has this problem, check that page. Now it works. Again, thanks. David Date: Mon, 29 Oct 2012 02:01:06 -0700 Subject: Re: [Tinyos-help] make: uisp: command not found (MicaZ and TinyOS 2.1.2) From: cire...@gmail.com To: drod...@outlook.com CC: tinyos-help@millennium.berkeley.edu you are missing the program uisp: Universal In-System Programmer. try: sudo apt-get install uisp in the future if you are looking for something, try http://packages.ubuntu.com On Mon, Oct 29, 2012 at 1:48 AM, David Rodenas drod...@outlook.com wrote: Hi all I am getting the following error on TinyOS-2.1.2 (installed on Ubuntu 12.04) when I try to install any app on MicaZ. For example, with Blink: --- $ make micaz install mib520,/dev/ttyUSB0mkdir -p build/micazcompiling BlinkAppC to a micaz binaryncc -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=\user\ -DIDENT_HOSTNAME=\user-vbox\ -DIDENT_USERHASH=0x41040a3eL -DIDENT_TIMESTAMP=0x508e415dL -DIDENT_UIDHASH=0xfb0b11caL -fnesc-dump=wiring -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs, components)' -fnesc-dumpfile=build/micaz/wiring-check.xml BlinkAppC.nc -lm compiled BlinkAppC to build/micaz/main.exe2044 bytes in ROM 51 bytes in RAMavr-objcopy --output-target=srec build/micaz/main.exe build/micaz/main.srec avr-objcopy --output-target=ihex build/micaz/main.exe build/micaz/main.ihex writing TOS imagecp build/micaz/main.srec build/micaz/main.srec.out installing micaz binary using mib510 uisp -dprog=mib510 -dserial=/dev/ttyUSB0 --wr_fuse_h=0xd9 -dpart=ATmega128 --wr_fuse_e=ff --erase --upload if=build/micaz/main.srec.out --verifymake: uisp: Command not found make: *** [program] Error 127--- Any idea? All the help possible is appreciated. Regards, David ___ 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] make: uisp: command not found (MicaZ and TinyOS 2.1.2)
Hi Andras As I said, I got the uisp package from the http://recolog.blogspot.com.es/2011/07/running-tikiridb-with-micaz-motes.html. In particular, it seems to me that the owner of the page has updloaded this package to a personal host: http://azadeha.at.ifi.uio.no/uisp.tar.gz. I downloaded it, installed and it works perfect. Regarding the version of my tinyos-tools, it is the latest one, which corresponds to the TinyOS-2.1.2 version (I do not remember if the repository is the tiny-prod, managed by Eric Decker I think...). What I can say is that this TinyOS version lacks of this package and also it should be part of the tinyos-tools. Regards David Date: Mon, 29 Oct 2012 15:01:43 +0100 Subject: Re: [Tinyos-help] make: uisp: command not found (MicaZ and TinyOS 2.1.2) From: andras.b...@unicomp.hu To: drod...@outlook.com CC: tinyos-help@millennium.berkeley.edu Hi David, You were right. Uisp should be part of tinyos-tools, did you installled it? If you did, what repository did you used? What's the version of your tinyos-tools? Andris On Mon, Oct 29, 2012 at 10:26 AM, David Rodenas drod...@outlook.com wrote: Thanks Eric, I thought that problem didn't have nothing to do with ubuntu packages. In any case, after installing the uisp package, I got the following error: Direct Parallel Access not defined. Thereby, I looked for any solution and I found out the following web page: http://recolog.blogspot.com.es/2011/07/running-tikiridb-with-micaz-motes.html. Here, the owner of the page explains how to solve this same issue. Hence, anyone that has this problem, check that page. Now it works. Again, thanks. David Date: Mon, 29 Oct 2012 02:01:06 -0700 Subject: Re: [Tinyos-help] make: uisp: command not found (MicaZ and TinyOS 2.1.2) From: cire...@gmail.com To: drod...@outlook.com CC: tinyos-help@millennium.berkeley.edu you are missing the program uisp: Universal In-System Programmer. try: sudo apt-get install uisp in the future if you are looking for something, try http://packages.ubuntu.com On Mon, Oct 29, 2012 at 1:48 AM, David Rodenas drod...@outlook.com wrote: Hi all I am getting the following error on TinyOS-2.1.2 (installed on Ubuntu 12.04) when I try to install any app on MicaZ. For example, with Blink: --- $ make micaz install mib520,/dev/ttyUSB0 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=\user\ -DIDENT_HOSTNAME=\user-vbox\ -DIDENT_USERHASH=0x41040a3eL -DIDENT_TIMESTAMP=0x508e415dL -DIDENT_UIDHASH=0xfb0b11caL -fnesc-dump=wiring -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs, components)' -fnesc-dumpfile=build/micaz/wiring-check.xml BlinkAppC.nc -lm compiled BlinkAppC to build/micaz/main.exe 2044 bytes in ROM 51 bytes in RAM avr-objcopy --output-target=srec build/micaz/main.exe build/micaz/main.srec avr-objcopy --output-target=ihex build/micaz/main.exe build/micaz/main.ihex writing TOS image cp build/micaz/main.srec build/micaz/main.srec.out installing micaz binary using mib510 uisp -dprog=mib510 -dserial=/dev/ttyUSB0 --wr_fuse_h=0xd9 -dpart=ATmega128 --wr_fuse_e=ff --erase --upload if=build/micaz/main.srec.out --verify make: uisp: Command not found make: *** [program] Error 127 --- Any idea? All the help possible is appreciated. Regards, David ___ 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] Sending/Receiving Video with TelosB
Hi Sean you should do any previous research to be aware of the current advances and limitations with regard to the video transmission with wireless sensor networks. Search papers with the following topic: wireless multimedia sensor networks. Then, you might find out valuable answers for your concerns. In particular, transmitting multimedia information requires high energy and computational resources. If you want to transmit video, you might need any special hardware or software to conduct the compression of the images (according with any standard, e.g., H264, JPEG2000, etc.) captured by the video sensor. In this sense, you shoud take care of the image format (CIF, QCIF...), the memory storage of telosb in order to store the images, etc... Again, you need a serial background. Good luck, David Date: Thu, 18 Oct 2012 14:02:21 +0200 From: sean.dek...@gmx.com To: tinyos-help@millennium.berkeley.edu; tinyos-help-requ...@millennium.berkeley.edu Subject: [Tinyos-help] Sending/Receiving Video with TelosB Hi everyone, Do you think it is possible to send/receive video with any quality between TelosB motes? Here is the scenario: There is a TelosB connected to PC using USB (serial port obviously) and there is another TelosB that has a digital cammra attached to it (using the 10 pin header). Do you think this scenario is practical, considering the data rate and other criterias? Regards, Sean. ___ 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] char signedness in NesC and compiler warnings
On Fri, Oct 5, 2012 at 12:05 AM, Eric Decker cire...@gmail.com wrote: I've cc'd the nesc god too. On Thu, Oct 4, 2012 at 5:27 AM, Flemming Nyboe flemm...@rocketscience.eu wrote: Hello, After upgrading to msp430-gcc 4.6.3 (from cygwinports), I get warnings like RootC.nc:141:7: warning: pointer targets in passing argument 1 of ‘sprintf’ differ in signedness [-Wpointer-sign] /usr/lib/gcc/msp430/4.6.3/../../../../msp430/include/stdio.h:51:41: note: expected ‘char *’ but argument is of type ‘uint8_t *’ The argument to sprintf() in this case is in fact char*, and looking in app.c, I noticed that the reason is NesC 1.3.4 sometimes, but not always, represents char as uint8_t. That's interesting. And seems weird. David? I one application, when I declare 'char txt[2][128];', it becomes 'char SNC__txt[2][128];' in app.c In another, when I declare 'char txt[2][128];', it becomes 'uint8_t SNC__txt[2][128];' in app.c that is strange. I think it should be consistent. I'd say the proper conversion would be char to char. This all seems rather strange... I can't help much w/o an example file and ncc/nescc command line, though - could you provide those? David Gay This raises two questions 1) What's up with the occasional char/uint8_t conversion in NesC David? 2) Since I did not get these warnings on my previous dated msp430-gcc 3.2.3, were they just disabled? yes. 3.2.3 had lots of stuff disabled. It worked and was good for its time. The newer toolchain is complaining correctly. Regards Flemming Nyboe ___ 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] FW: Lotus
Hi Fabio I asked the same question at http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg41257.html. To the best of my knowledge, there is still no current drivers for lotus devices though it would be fine. I am not at that level to develop its drivers so the only thing you can do is wait for it, or start doing it yourself. Bye David Date: Wed, 19 Sep 2012 09:41:16 +0200 From: fabio.d.giuse...@gmail.com To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Lotus Hi guys, I would like to use TinyOS on the Memsic Lotus platform to use CoAP and DTLS for a small distributed application. Is it fairly supported? Also, has anybody used Lotusview? In the manual Memsic claims that the application is based on TinyOS, while I have found on this forum that it's not well supported and drivers were still missing in May. Thanks a lot -- Fabio Di Giuseppe ___ 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] TelosB stuck in reset cycle
I have a Sentilla T-Mote Sky TelosB mote running code that immediately crashes when powered up. Consequently, tos-bsl times out when I try to erase and install a fixed version. Is there a way to do a hard erase of the flash memory without an active USB connection? Magic sequence of buttons on the device, perhaps? Thanks, David Harrison University College Dublin ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] questions about usage of keyword atomic
I was going to put a fancy explanation in here about what's going on
with TOSH_INTERRUPT/SIGNAL, how atomicity checking works, etc.
But then I found out that (AFAICT) the msp430 platform was never
updated for the not-so-very-new-anymore atomicity annotations for
interrupt handlers (@hwevent, @atomic_hwevent). So in practical terms,
there's no atomicity checking on msp430 (or any platform except atm128
and possibly some pxa27x code).
To summarize:
- reentrant interrupt handlers must be annotated with @hwevent()
- non-reentrant interrupt handlers must be annotated with @atomic_hwevent()
- if a non-reentrant interrupt handler wants to enable interrupts
half-way through, it must do it using a call to
__nesc_enable_interrupt() (which should be defined anyway)
For reference, here's the atm128 macros that replaced (some time
ago...) TOSH_INTERRUPT/TOSH_SIGNAL:
/* We need slightly different defs than SIGNAL, INTERRUPT */
#define AVR_ATOMIC_HANDLER(signame) \
void signame() __attribute__ ((signal)) @atomic_hwevent() @C()
#define AVR_NONATOMIC_HANDLER(signame) \
void signame() __attribute__ ((interrupt)) @hwevent() @C()
David Gay
On Wed, Aug 29, 2012 at 10:22 PM, Eric Decker cire...@gmail.com wrote:
I've added David Gay (the nesc author and maintainer) to see what he has to
add.
On Wed, Aug 29, 2012 at 7:52 PM, Xiaohui Liu whu...@gmail.com wrote:
Thanks again for your promptly reply. I still have a few follow-up
questions, please CIL.
On Wed, Aug 29, 2012 at 8:38 PM, Eric Decker cire...@gmail.com wrote:
On Wed, Aug 29, 2012 at 4:40 PM, Xiaohui Liu whu...@gmail.com wrote:
Thank you both for sharing your insights. I still have a few comments,
CIL.
On Tue, Aug 28, 2012 at 3:52 AM, Eric Decker cire...@gmail.com wrote:
On Mon, Aug 27, 2012 at 6:59 PM, Xiaohui Liu whu...@gmail.com wrote:
Hello all,
1) I have the following code snippet:
uint8_t a;
async event void Alarm1.fired() {
a = 0;
}
This compiles successfully without any warning.
Isn't there a racing condition here, between Alarm1 and itself?
I don't know what you mean by the above. How can Alarm1 have a race
condition with itself?
I was thinking the interrupt that generates Alarm1 can be nested, but
turns out it is TOSH_SIGNAL and cannot be. What I actually want to express
is that if Alarm1.fired() is replaced by another event generated by a
nested
interrupt TOSH_INTERRUPT, should a be protected?
If you do indeed cause the interrupts to be nested then yes it should be
protected.
Nested interrupts on the msp430s have lots of problems and you probably
don't want to do this.
Looks to me like in the above program there is only one place where a
is accessed, so how can there be a race condition.
2) If the following is added.
async event void Alarm2.fired() {
a = 1;
}
Still, this compiles successfully without any warning. Isn't there an
additional racing condition here, between Alarm1 and Alarm2 (and Alarm2
and
itself)?
async is considered to be one level of execution. So there still
isn't a race condition. When Alarm1 fires, a gets set to 0. Alarm2 can
not get in and thus there is not a race condition.
this is a nesc assumption. That async is one level of execution (one
context).
By assumption, you mean Alarm cannot be preempted?
Interrupted is the correct term. Preemption is a little bit different.
1) What is the difference?
First, all preemptions are interruptions but not all interruptions are
preemptions.
Preemption is a technique that interrupts a task temporarily with out its
cooperation with the intention of resuming the task later. ie. time
slicing.Its a context switch that typically is fairly expensive. ie.
tosthreads for example does support preemption. Preemption is typically
built on top of a timer interrupt and implements time-slicing. Full
processor and process (task) state are typically saved to a purpose tasked
block of storage (task/process block) to allow a restart later.
Interrupts are typically a h/w thing and interrupt the immediate cpu
context. Minimal h/w state is saved on the stack.
In other words, interrupts are a more primative h/w based construct that can
be used to implement preemption.
The assumption that nesc makes is that there are two levels of context
and that the async context doesn't get interrupted.
2) If async context does not get interrupted, then there should never be
atomic in async context, at least when no interrupt is TOSH_INTERRUPT. But
this is clearly not the case. For instance, the following can be found in
CC2420ReceiveP.nc
Don't know what to tell you. People do various things and it isn't
necessarily justified. The code isn't really code reviewed and is developed
in an academic context. Typically that means that the development envelope
isn't as rigorously fleshed out as in other contexts.
async event void InterruptFIFOP.fired
[Tinyos-help] TOSThreads, TinyLD and Callbacks to loaded modules
I have a TOSThreads, TinyLD system, heavily based on the SerialLoaderFlash
example.
I compile new functionality on the laptop as a dynamic threads module, transfer
it to the mote where it gets stored in flash. When the module is loaded, it
registers itself with the monolithic app on the mote by calling a function I
exposed by adding it to: tos/lib/tosthreads/lib/tinyld/tosthread_slcs_types.h.
So far so good.
This registration function takes a function pointer as an argument which is,
if you like, the constructor of the module that just registered itself.
Unfortunately, when the monolithic code calls this function nothing much
happens. Far as I can tell, the function pointer being passed in by the loaded
module becomes invalid as it enters the monolithic app.
The loaded module looks like this (simplified for clarity):
tosthread_t button_sensor_source;
tosthread_t button_sensor_source_registration;
Source alloc_button_sensor_source() {
// whatever
}
void button_sensor_source_registration_thread(void* arg) {
register_source(alloc_button_sensor_source);
}
void tosthread_main(void* arg) {
tosthread_create(button_sensor_source_registration,
button_sensor_source_registration_thread, NULL, 200);
}
When TinyLD does it's thing, tosthread_main gets invoked which creates a new
thread that uses the button_sensor_source_registration_thread function as
it's entry point and in there registers itself with the main app.
A simplistic version of the Registration function (the one in the monolithic
app) looks like this:
void register_source(Source (*constructor)()) {
Source source = constructor();
// whatever
}
When I test this, the line that calls the function is executed, but the
function constructor points to is not invoked.
Anyone know what's going wrong here?
Is there anyway to make the constructor pointer valid in the main app?
Does the loaded module become invalid when it's tosthread_main function exits?
FYI - This is a port of code that works flawlessly on Contiki, but I may simply
be using the wrong paradigm for TinyOS/TOSThreads. If I am, please point me in
the right direction!
Many thanks,
David Harrison
University College Dublin
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Does TinyOS dist from http://tinyos.stanford.edu/tinyos/dists/ubuntu support TelosB motes?
Hi all
I have the latest version of tinyos (from tinyos trunk) with telosb working
together. I found the solution after several instalations and looking into the
following threads:
http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg41701.html
http://www.mail-archive.com/shimmer-users@eecs.harvard.edu/msg00411.html
What I've done is the following (using a Ubuntu 10.04 LTS) - Please read them
carefully before doing anything -:
$ sudo dpkg -P `dpkg -l nesc '*tinyos*' | grep ^ii | awk '{ print $2 }' |
xargs`$ sudo apt-get clean$ sudo gedit /etc/apt/sources.listadddeb
http://tinyprod.net/repos/debian squeeze maindeb
http://tinyprod.net/repos/debian msp430-46 main/add$ sudo apt-get update$ gpg
--keyserver keyserver.ubuntu.com --recv-keys 34EC655A$ gpg -a --export 34EC655A
| sudo apt-key add -$ apt-get install tinyos-2.1.1 nesc tinyos-tools
msp430-tinyos-legacy avr-tinyos$ sudo gedit $HOME/.bashrcaddsource
/opt/tinyos-2.1.1/tinyos.sh/add
$ sudo chown -R id /opt/tinyos-2.1.1
Now, if you go to $TOSROOT/apps/Blink, and do make telosb, it should work.
However, I recommend you have the latest instalation of tinyos, so (first steps
retrieved from
http://docs.tinyos.net/tinywiki/index.php/Installing_from_SVN/GIT):
$ cd $HOME$ mkdir -p local/src$ cd local/src$ svn checkout
http://tinyos-main.googlecode.com/svn/trunk/ tinyos-2.x
(now, I made a backup of everything within the tinyos-2.1.1 directory, and
after that, I deleted everything except the tinyos.sh file)
$ cd local/src/tinyos-2.x$ cp -r * /opt/tinyos-2.1.1/$ cd
/opt/tinyos-2.1.1/tools$ ./Bootstrap$ ./configure --prefix=$HOME/local$ make
all$ make install
At this point, you have the latest version of tinyos, but now, make telosb
does not work. The reason is that you need the msp430-46 toolchain:
$ sudo apt-get install msp430-46$ cd /usr (where the directory msp430 is, maybe
/usr/local)$ mv msp430 msp430-gcc-3.2.3$ ln -s /opt/msp430-46 msp430$ cd
/usr/bin$ rm msp430-*$ ln -s ../msp430/bin/* .
And that's all. This finally worked for me. I wish you luck.
David
Date: Thu, 26 Jul 2012 23:00:15 -0700
From: cire...@gmail.com
To: gary.lee1...@gmail.com
CC: tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] Does TinyOS dist from
http://tinyos.stanford.edu/tinyos/dists/ubuntu support TelosB motes?
On Thu, Jul 26, 2012 at 8:56 PM, Gary Lee gary.lee1...@gmail.com wrote:
Thanks for your reply.
Could you let me know how to install *-legacy packages, where the 3.2.3
compiler lives now from stanford.
Read the rest of the email. I already told you. Follow the links. Go read
the README at tinyprod.net/repos/debian
On Thu, Jul 26, 2012 at 12:17 AM, Eric Decker cire...@gmail.com wrote:
On Wed, Jul 25, 2012 at 8:49 PM, Gary Lee gary.lee1...@gmail.com wrote:
make telosb works before.
when I run ncc --version -target=telosb, I got
ncc: 1.2.4
nescc: 1.3.4
msp430-gcc: msp430-gcc (GCC) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Prior to updating the tools from dists/ubuntu, I strongly suspect you had the
3.2.3 compiler. Because it worked.
When you updated the tools again you got the 4.5.3 compiler which is
incompatible with the T2.1.1 release code you have in /opt/tinyos-2.1.1.
Try installing the *-legacy packages, it is where the 3.2.3 compiler lives
now. I beleive they are in the dists/ubuntu repository at stanford. They
also exist in the tinyprod repository at http://tinyprod.net/repos/debian/
On Wed, Jul 25, 2012 at 10:41 PM, Eric Decker cire...@gmail.com wrote:
On Wed, Jul 25, 2012 at 8:26 PM, Gary Lee gary.lee1...@gmail.com wrote:
Hi,
I have installed TinyOS 2.1.1 from
http://tinyos.stanford.edu/tinyos/dists/ubuntu many times.
Did make telosb work before?
recently, when I installed from http://tinyos.stanford.edu/tinyos/dists/ubuntu
again, when I run make micaz, it works fine.
However, when I run make telosb, lots of errors.
what does the output of
ncc --version -target=telosb
say?
Any help?
Thanks a lot,
Gary
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
Eric B. Decker
Senior (over 50 :-) Researcher
--
Eric B. Decker
Senior (over 50 :-) Researcher
--
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] Does TinyOS dist from http://tinyos.stanford.edu/tinyos/dists/ubuntu support TelosB motes?
Hi Erik
thanks, your email was really useful. As you say, what I did was rocket
science, but I could not be able to find another solution because of my poor
knowledge of linux.
Bye
David
Date: Fri, 27 Jul 2012 02:25:36 -0700
Subject: Re: [Tinyos-help] Does TinyOS dist from
http://tinyos.stanford.edu/tinyos/dists/ubuntu support TelosB motes?
From: cire...@gmail.com
To: drod...@hotmail.com
CC: tinyos-help@millennium.berkeley.edu
On Fri, Jul 27, 2012 at 12:55 AM, David Rodenas drod...@hotmail.com wrote:
Hi all
I have the latest version of tinyos (from tinyos trunk) with telosb working
together. I found the solution after several instalations and looking into the
following threads:
Cool.
Be aware that David is doing an installation of the Released T2.1.1 (which is
getting pretty dated at this point) and ALSO the development trunk which is
about to be released as T2.1.2.
Installing both isn't usual, I'd actually recommend installing from the
TinyProd (master Branch) on github which is a snapshot from the TinyOS
development trunk. The master branch will always follow the current (latest)
full release of TinyOS. In this case the upcoming T2.1.2 release.
MSP430 toolchains come in various flavors because it has gotten extensively
reworked by Peter Bigot (this is a good thing).
The Release T2.1.1 code builds with the older msp430 toolchain (3.2.3, now
called legacy). The legacy toolchain installs into the /usr heirarchy.
The Development Trunk builds with the newer msp430 4.6.3 toolchain (now called
-46). The -46 toolchain installs into /opt/msp430-46.
What I've done is the following (using a Ubuntu 10.04 LTS) - Please read them
carefully before doing anything -:
11.10 is recommended at this point. I've also used 10.04, 10.10 and am
currently using 11.10. All my current testing and operational use has been on
11.10. If you are setting up a new system, use 11.10 (Oneric) or give 12.04 a
try. It should work, but hasn't been tested.
Be warned, the following will remove your existing packages named nesc, and
anything with tinyos in its package name. This includes any installation of
tinyos-2.1.1 you might have.
If you don't want that to happen remove the packages one by one by hand.
$ sudo dpkg -P `dpkg -l nesc '*tinyos*' | grep ^ii | awk '{ print $2 }' |
xargs`$ sudo apt-get clean
It is better to add the deb lines into /etc/apt/sources.d/tinyprod-debian.list
as described in the README. Just to keep things seperate. apt-get update will
automatically find the additions.
$ sudo gedit /etc/apt/sources.list
adddeb http://tinyprod.net/repos/debian squeeze maindeb
http://tinyprod.net/repos/debian msp430-46 main
/add$ sudo apt-get update
be aware that the packages on tinyprod.net are signed with my key, which you
are installing below. The packages on stanford have not been signed (the last
I looked). This can potentially be a security problem if you are using
unsigned packages from stanford.
$ gpg --keyserver keyserver.ubuntu.com --recv-keys 34EC655A
$ gpg -a --export 34EC655A | sudo apt-key add -$ apt-get install tinyos-2.1.1
nesc tinyos-tools msp430-tinyos-legacy avr-tinyos$ sudo gedit $HOME/.bashrcadd
source /opt/tinyos-2.1.1/tinyos.sh/add
$ sudo chown -R id /opt/tinyos-2.1.1
This completes the installation of the old T2.1.1 release and the legacy tools.
Your PATH variable typically includes /usr/bin and since this is where the
legacy tools get installed, the toolchain that gets used comes from /usr/bin
when you build T2 apps.
Now, if you go to $TOSROOT/apps/Blink, and do make telosb, it should work.
The remainder is installing the development trunk code and required tools.
However, I recommend you have the latest instalation of tinyos, so (first steps
retrieved from
http://docs.tinyos.net/tinywiki/index.php/Installing_from_SVN/GIT):
$ cd $HOME$ mkdir -p local/src$ cd local/src$ svn checkout
http://tinyos-main.googlecode.com/svn/trunk/ tinyos-2.x
You can also use git (which I recommend, it's a better fit for how T2
development seems to be working):
cd local/srcgit clone git://github.com/tinyprod/prod.git tinyos-2.x
The s/w will be in local/src/tinyos-2.x and you will be on the master branch
from the tinyprod/prod repository. You will have to modify the environment
variables to set TOSDIR and TOSROOT correctly.
See the script tinyos.sh in /opt/tinyos-2.1.1 for details about what gets set.
(now, I made a backup of everything within the tinyos-2.1.1 directory, and
after that, I deleted everything except the tinyos.sh file)
You don't need to do any of this. Change the environment variables for
TOSROOT and TOSDIR as needed to point to your local copy of the source code.
You really don't want to mess with /opt/tinyos-2.1.1 because for one thing it
was installed as a package. It won't hurt anything but is weird and is a
whole bunch of extra steps. You really don't need to do this. Just change
the environment
[Tinyos-help] TKN154: What I am receiving?
Hi all
Sorry for the length, but I thing that it was necessary to explain my concern.
I've programmed a telosb acting as a transmitter that sends periodically a
broadcast message to another telosb acting as a network coordinator (and also
as a reciver). I am using the TKN154 libraries. The main network parameters
are:
RADIO CHANNEL is 26,PAN ID is 0x4927,COORDINATOR ADDRESS is 0x6287,DEVICE
ADDRESS is 0x6245,TRANSMISSION is broadcast (daddr is 0x).
The payload contains two fields: 1) the device address (0x6287) and 2) four
uint16_t values as network data (0x2301 0x2302 0x2303 0x2304)
The coordinator app is based on the packetsniffer app (apps/tests/tkn154) with
some modifications. What I want is to send every data frame received by the
coordinator through the serial port to my laptop. Thereby, here is the part of
the code that conducts this issue:
event message_t* MCPS_DATA.indication ( message_t* frame_ ){ call
Leds.led1Toggle(); if (call Queue.enqueue(frame_) != SUCCESS) {call
Leds.led0On(); // overflowreturn frame_; } else {post
serialSendTask();return call Pool.get(); }} task void serialSendTask() {
message_t* frame; uint8_t headerLen; uint8_t payloadLen; uint8_t
serialLen; uint8_t *header; uint8_t *payload; uint8_t i; if (call
Queue.empty() || m_serialSendBusy)return;frame = call Queue.head();
headerLen = call Frame.getHeaderLength(frame); payloadLen = call
Frame.getPayloadLength(frame); header = call Frame.getHeader(frame); payload
= call Frame.getPayload(frame); /* // Test 1: printf printf(MHRLen:
%d\n, headerLen); printf(MHR: ); for (i=0; iheaderLen; i++){
printf(0x%02X , header[i]); } printf(\n);printf(PayloadLen:
%d\n, payloadLen); printf(Payload: ); for (i=0; ipayloadLen; i++){
printf(0x%02X , payload[i]); } printf(\n\n); */// Test 2: java
Listen serialLen = headerLen + payloadLen; m_serialSendBusy = TRUE; if (call
SerialSend.send(frame, serialLen) != SUCCESS)report_received(); //call
Leds.led2Toggle();}
As you can see, I carry out two tests: 1) by using the printf libraries, I
represent the content of the header and the payload fields; and 2) I use the
Listen java app to see what I receive from the serial port. The results are the
following:
Test 1: PRINTF (only one data frame is depicted since the transmission
conditions and network data are always the same)
$ java net.tinyos.tools.PrintfClient -comm serial@/dev/ttyUSB0:telosb
MHRLen: 9MHR: 0x41 0x88 0x90 0x27 0x49 0xFF 0xFF 0x45 0x62 PayloadLen:
10Payload: 0x45 0x62 0x01 0x23 0x02 0x23 0x03 0x23 0x04 0x23
I've not checked the header fields but, a priori, the result is what I
expected.
Test 2: LISTEN JAVA (5 data frames are depicted)
$ java net.tinyos.tools.Listen -comm serial@/dev/ttyUSB0:telosb
02 00 00 00 00 00 00 00 00 00 00 00 00 45 62 01 23 02 23 03 23 04 23 06 EA 00
00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 45 62 00 00 02 23 03
23 04 23 08 EB 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 45
62 00 00 02 23 03 23 04 23 0C E9 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00
00 00 00 00 00 45 62 00 00 02 23 03 23 04 23 09 EA 00 00 00 00 00 00 00 02 00
00 00 00 00 00 00 00 00 00 00 00 45 62 00 00 02 23 03 23 04 23 0C EB 00 00 00
00 00 00 00
I am aware of that the first byte is the AM type (0x02). In addition, the
payload is successfully received (45 62 01 23 02 23 03 23 04 23). However,
where is the header? And the latest zeros? and what do 06 EA, 08 EB, 0C
E9, 09 EA, 0C EB mean?
I'd like to know what I am doing wrong. In this sense, all the help possible
would be appreciated.
Regards
David ___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Collision detection at transmitter.
Hi all I recommend you do some research about Aloha in ISO 18000-7. I have no idea of this recommended practice of yours, but this is the usual procedure of a CSMA-CA mechanism. At the best of my knowledge, a node acting as a transmitter cannot detect a collision, so what this node does is the following: 1) This node is willing to transmit so it listens to the channel a number of CCA time intevals (e.g., in IEEE 802.15.4 non-beacon mode, is one while in the beacon mode, this number is two).2) If the channel is free, it transmits. Otherwise (it detects a transmission within its coverage range), it delays its own transmission a backoff time (random time), after which a new attempt of retransmission is conducted.3) If the channel was free (your case), but your transmission has collided (e.g., due to hidden nodes), it depends on which type of transmission are you carrying out. For instante, if you are using an unicast transmission with acknowledgment, the fact that you don't receive the ack from the receiver (after a particular time interval) tells the transmitter that it was any kind of fail, and it considers its transmission as a collision. In this case, the transmitter sets another backoff time (provided that a maximum number of retransmissions have not been already done). An! other example is a broadcast transmission. In this type, the ack frames are not required, so if the transmission collided, it depends on your protocol: 1) you broadcast something and waits for any action to be done, so you detect a possible problem (maybe a collision); 2) you broadcast something to share some kind of information but you don't expect anything, so the collision is not detected. Regads, David Date: Tue, 24 Jul 2012 23:08:23 -0700 From: cire...@gmail.com To: pnk...@naver.com CC: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] Collision detection at transmitter. On Tue, Jul 24, 2012 at 10:35 PM, 최익성 pnk...@naver.com wrote: Dear Eric Decker. Thank you very much for your kind explanation. I know that the collision detection is not required in CSMA/CA. Is there any way to detect the collision at transmitter? Not that I am aware of. The issue is whether the h/w can can hear itself when transmitting. I don't think the cc2420 has the capabililtiy and with out hearself then doing collision detection becomes problematic. In case of slotted aloha in ISO 18000-7, do we need detect the collision only at receiver? No idea. I'm not familar with slotted aloha. A collision seen at a receiver can show up in various ways. I don't know if that means that the receiver can reliably determine that a collision has taken place. Regardless, I don't see how the receiver detecting a collision can in any reasonable fashion impact the operation of the transmitter. The transmitter needs to detect the collision. If you must do a protocol that requires reliable collision detection, you must select your radio h/w such that CD is supported. Thank you very much. Sincerely Yours, Ick-Sung Choi. -Original Message- From: Eric Deckercire...@gmail.com To: 최익성pnk...@naver.com; Cc: tinyos-help@millennium.berkeley.edu; Sent: 2012-07-25 (수) 13:25:52 Subject: Re: [Tinyos-help] Collision detection at transmitter. On Tue, Jul 24, 2012 at 6:56 PM, 최익성 pnk...@naver.com wrote: Dear tinyos developers. I have a basic question about collision detection at transmitter. Its CSMA/CA not CSMA/CD so it is collision avoidance. In CSMA/CA, transmitter transmits the frame. If there is a collision, the transmitter tries to transmit the frame after random backoff time. How can the transmitter detects the collision? Typically this kind of thing is implemented in h/w. You don't specify what h/w you are using... (Yes, it would have been helpful if you told us the specifics of what h/w you are using). So I'm assuming the telosb with the cc2420 radio. the cc2420 hardware does Clear Channel Assessment and provides status bits that tell the driver what is happening. I believe if the channel is busy it is up to the driver to handle the back off. I would suggest you take a look at the cc2420 manual (pg 50) and look at the cc2420 driver where it deals with CCA and possibly the STXONCCA command strobe. Thank you very much. Sincerely Yours, Ick-Sung Choi. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Eric B. Decker Senior (over 50 :-) Researcher -- Eric B. Decker Senior (over 50 :-) Researcher ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] TKN15.4 issue: problem receiving ack
Hi all
I am working with the TKN15.4 libraries, the TinyOS implementation of the IEEE
802.15.4 standard. In particular, I am doing some tests with the non-beacon
mode of this implementation. I've modified the TestIndirectData app
(tinyos-2.x/apps/tests/tkn154/nonbeacon-enabled/TestIndirectData) aimed at
performing a direct transmission instead of an indirect transmission. In this
sense, I've done the following (a few) changes in the code:
1) The device acts as receiver node. It does not perform any polling process,
only switches to receiver state (promiscuous mode) listening to incomming
transmissions.
TestIndirectDataDeviceAppC.ncconfiguration
TestIndirectDataDeviceAppC{} implementation { [...]App.PromiscuousMode
- MAC; //add}
TestIndirectDataDeviceC.ncmodule
TestIndirectDataDeviceC{ uses {[...]interface SplitControl as
PromiscuousMode; //add }} implementation { [...]void startApp() {
[...] // call PollTimer.startPeriodic(62500U);call
PromiscuousMode.start(); // add }[...] //add event void
PromiscuousMode.startDone(error_t error) { } event void
PromiscuousMode.stopDone(error_t error) { } ///add
}
2) The coordinator is who transmits data. Only modifications of txOptions in
the MCPS_DATA.request has been done:
TestIndirectDataCoordC.ncmodule
TestIndirectDataDeviceC{} implementation { [...]void sendIndirectData(){
[...]call MCPS_DATA.request( frame,
// frame, strlen(payload),
// payloadLength, 0,
// msduHandle, // TX_OPTIONS_INDIRECT |
TX_OPTIONS_ACK // TxOptions, TX_OPTIONS_ACK //
TxOptions,);[...] }[...]
event void MCPS_DATA.confirm( message_t *msg,
uint8_t msduHandle, ieee154_status_t
status, uint32_t Timestamp) {
[...]//addelse if(status == IEEE154_NO_ACK){
call Leds.led2On(); }///add
}[...]
}
Taking in account the aforementioned, the message is actually received by the
device, but coordinator's led2On indicates to me that any ack has been
transmitted or received.
What am I doing wrong?
All the help possible would be appreciated.
Thanks!
David ___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] LOTUS devices manufactured by MEMSIC VS TinyOS
Hi all I am interested in lotus devices manufactured by MEMSIC Inc. However, I've seen that there is not support for TinyOS. Am I wrong? Is anyone working with these devices? Would it be a bad investment? They are fully compatible with Imote2, but I suppose Imote2's drivers would't work on Lotus. All the help/opinions/suggestions are appreciated. Thanks! David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] LOTUS devices manufactured by MEMSIC VS TinyOS
Hi Thanks a lot for your answers. They're really helpful. Bye! From: thomas.sch...@utah.edu Date: Thu, 10 May 2012 09:21:11 -0600 Subject: Re: [Tinyos-help] LOTUS devices manufactured by MEMSIC VS TinyOS To: sal...@isis.vanderbilt.edu CC: drod...@hotmail.com; tinyos-help@millennium.berkeley.edu Note that the LOTUS uses a LPC1758. You would have to write all the peripheral drivers for it in TinyOS, as that hasn't been done yet. So I think Janos' estimate of one man-month is low, unless you really know what you do. - Thomas -- Assistant Professor Electrical and Computer Engineering University of Utah, Salt Lake City On Thu, May 10, 2012 at 8:28 AM, Janos Sallai sal...@isis.vanderbilt.edu wrote: As far as I can tell, it's a completely new platform. I would guess that the code exists in the main tree for most of the hardware components, though setting up platform support for the LOTUS in tinyos is still a nontrivial task -- at least one man-month of work. Maybe a bit more if the board schematics are not publicly available. Janos On Thu, May 10, 2012 at 5:46 AM, David Rodenas drod...@hotmail.com wrote: Hi all I am interested in lotus devices manufactured by MEMSIC Inc. However, I've seen that there is not support for TinyOS. Am I wrong? Is anyone working with these devices? Would it be a bad investment? They are fully compatible with Imote2, but I suppose Imote2's drivers would't work on Lotus. All the help/opinions/suggestions are appreciated. Thanks! David ___ 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
[Tinyos-help] Destroying Threads Created by DynamicLoader
I've modified the SerialLoaderFlash example application to include a new
message type requesting the previously loaded DynamicThread be stopped, i.e.
destroyed. Doesn't work.
Anyone in a position to give me the heads up on why not?
My code is included below.
Thanks, David
--8---
Having read some old posts that suggested having multiple threads in the
deployed app was problematic, the deployed app/thread has a single thread that
simply blinks the blue led every second:
void tosthread_main(void* arg) {
for(;;) {
led2Toggle();
tosthread_sleep(1000);
}
}
Here's the modified code from FlashVolumeManagerP.nc, additions are in bold.
Obviously I had to modify certain other files to include DynamicThread, but I
guess we can take that as read.
FYI - putting call DynamicThread.destroy(thread); in the
DynamicLoader.loadFromFlashDone method does destroy the thread so my guess is
it's something to do with the state the thread is in at the point I try to stop
it.
implementation
{
tosthread_t thread;
[ snip ]
case SERIALMSG_STOP :
error = call DynamicThread.destroy(thread);
if (error != SUCCESS)
sendReply(error, sizeof(SerialReplyPacket));
break;
case SERIALMSG_RUN :
error = call DynamicLoader.loadFromFlash(VOLUME_MICROEXEIMAGE);
if (error != SUCCESS)
sendReply(error, sizeof(SerialReplyPacket));
break;
}
return msg;
}
event void DynamicLoader.loadFromFlashDone(uint8_t volumeId, tosthread_t id,
error_t error) {
thread = id;
sendReply(error, sizeof(SerialReplyPacket));
}
[ snip ]
}___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Compute instant energy consumption
Hi all I wonder if there is any TinyOS component or any method to measure the instant energy consumption (or get the average energy consumption periodically) on the nodes in a real fashion (not by means of simulation tools). I am working with Micaz devices and the only idea that comes to my mind is using theoretical values from MicaZ's datasheet. However, this would be just an estimation, and it would take too much time to compute this information. All the help possible would be appreciated. Thanks in advance, David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Destroying Threads Created by DynamicLoader
I've modified the SerialLoaderFlash example application to include a new
message type requesting the previously loaded DynamicThread be stopped, i.e.
destroyed. Doesn't work.
Anyone in a position to give me the heads up on why not?
My code is included below.
Thanks, David
--8---
Having read some old posts that suggested having multiple threads in the
deployed app was problematic, the deployed app/thread has a single thread that
simply blinks the blue led every second:
void tosthread_main(void* arg) {
for(;;) {
led2Toggle();
tosthread_sleep(1000);
}
}
Here's the modified code from FlashVolumeManagerP.nc, additions are in bold.
Obviously I had to modify certain other files to include DynamicThread, but I
guess we can take that as read.
FYI - putting call DynamicThread.destroy(thread); in the
DynamicLoader.loadFromFlashDone method does destroy the thread so my guess is
it's something to do with the state the thread is in at the point I try to stop
it.
implementation
{
tosthread_t thread;
[ snip ]
case SERIALMSG_STOP :
error = call DynamicThread.destroy(thread);
if (error != SUCCESS)
sendReply(error, sizeof(SerialReplyPacket));
break;
case SERIALMSG_RUN :
error = call DynamicLoader.loadFromFlash(VOLUME_MICROEXEIMAGE);
if (error != SUCCESS)
sendReply(error, sizeof(SerialReplyPacket));
break;
}
return msg;
}
event void DynamicLoader.loadFromFlashDone(uint8_t volumeId, tosthread_t id,
error_t error) {
thread = id;
sendReply(error, sizeof(SerialReplyPacket));
}
[ snip ]
}___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Send serial packet between two motes
Hai, The TestSerial app works fine for me between mote and PC but when I wire two motes together it doesn't work. These are telosb type notes but without the FTDI chip. There seem differences in the packet format of that sent by the TestSerial java app on the PC and the packets sent by the mote. Packets sent by the mote seem to start with 0x7e 0x45 whereas those coming from the PC will start with 0x7e 0x44/0x43. Sending the same packet thats received from the mote back to it doesn't do anything either. Any idea on how to send a packet from a mote that another will be able to receive or get a mote to receive the 0x7e 0x45 packets sent by another mote? ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Send serial packet between two motes
Hai, The TestSerial app works fine for me between mote and PC but when I wire two motes together it doesn't work. These are telosb type notes but without the FTDI chip. There seem differences in the packet format of that sent by the TestSerial java app on the PC and the packets sent by the mote. Packets sent by the mote seem to start with 0x7e 0x45 whereas those coming from the PC will start with 0x7e 0x44/0x43. Sending the same packet thats received from the mote back to it doesn't do anything either. Any idea on how to send a packet from a mote that another will be able to receive or get a mote to receive the 0x7e 0x45 packets sent by another mote? ___ 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
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 drod...@hotmail.com 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
[Tinyos-help] CameraMultihop Compile Error
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
[Tinyos-help] TinyOS Get stuck in 'Device Detected'
Hello. I'm new to tinyos and I just finished the installation. I'm using TinyOS-2.x in cygwin on windows 7. I got two problems: 1.When I tried this to download Blink program into imote2, with USBLoaderHost -p build/intelmote2/main.bin.out, win7 can't find the USB driver,it got stuck and kept showing Device Detected. Do you have met this problem? 2. When I tried to install the blink program using command make intelmote2 intall bootloader, the log showed that installing intelmote2 binary using jflashmm, which I think shoud be using USBLoaderHost, right? And it got the error Couldn't access giveio device at last. Do you know how to solve this? I'll be very appreciate if you can help me out. Looking forward to your answers. -- 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] Few questions
Hi Juan You should take a look at the IEEE 802.15.4 standard in order to get more information and resolve your doubts: http://www.ieee802.org/15/pub/TG4.html Bye! David Date: Sat, 17 Mar 2012 19:42:57 +0100 From: juan.jose.martinez.ro...@gmail.com To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Few questions Hello everyone. I’m using the TinyOS V2.1.1 with TELOS B and I’ve got some questions. On the standard 802.15.4 the CSMA-CA algorithm, in slotted this version of TinyOS give the option of “Battery life extension”. What it meant? Another thing is. When “ BE=min(2,macMinBE) ” wich is this possible value for BE. Thanks Juan ___ 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] Problem installing app in MicaZ
Hi all I have a strange problem on a Windows 7 machine. I am working with TinyOS 2.x and MicaZ, and when I type make micaz install mib520,/dev/ttyS7, I get the following: $ make micaz install mib520,/dev/ttyS7 mkdir -p build/micaz compiling BlinkToRadioAppC 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=\BlinkToRadioApp\ -DIDENT_USERNAME=\Helio\ -DIDENT_HOSTNAME=\HP-PC\ -DIDENT_USERHASH=0xfa1592 40L -DIDENT_TIMESTAMP=0x4f589a8fL -DIDENT_UIDHASH=0xc4904224L -fnesc-dump=wiring -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs, co mponents)' -fnesc-dumpfile=build/micaz/wiring-check.xml BlinkToRadioAppC.nc -lm /opt/tinyos-2.x/tos/chips/cc2420/lpl/DummyLplC.nc:39:2: warning: #warning *** L OW POWER COMMUNICATIONS DISABLED *** compiled BlinkToRadioAppC to build/micaz/main.exe 11654 bytes in ROM 311 bytes in RAM avr-objcopy --output-target=srec build/micaz/main.exe build/micaz/main.srec avr-objcopy --output-target=ihex build/micaz/main.exe build/micaz/main.ihex writing TOS image cp build/micaz/main.srec build/micaz/main.srec.out installing micaz binary using mib510 uisp -dprog=mib510 -dserial=/dev/ttyS7 --wr_fuse_h=0xd9 -dpart=ATmega128 --wr_f use_e=ff --erase --upload if=build/micaz/main.srec.out --verify Programmer is not responding. /opt/tinyos-2.x/support/make/avr/mib510.extra:31: recipe for target `program' failed make: *** [program] Error 2 The MIB520 interface uses COM7 and COM8 and I've tried all /dev/ttySx possible!!! I have installed it correctly in several computers but It doesn't work in this one. What could be the problem? All the help possible would be appreciated. Thanks, David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Problem with BaseStation15.4
Hi all I'm having problems when compiling the BaseStation15.4 application for Micaz devices: --$ make micazmkdir -p build/micazgcc -o seriallisten15-4 seriallisten15-4.o /opt/tinyos-2.x/tos/../support/sdk/c/sf/libmote.agcc: /opt/tinyos-2.x/tos/../support/sdk/c/sf/libmote.a: No such file or directoryMakefile:9: recipe for target `seriallisten15-4' failedmake: *** [seriallisten15-4] Error 1-- Does anyone else have this problem? I appreciate all the help possible Thanks, David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Problem with BaseStation15.4
/Serial.h:81:/opt/tinyos-2.x/tos/types/AM.h:6: syntax error before `nx_am_id_t'[...] /opt/tinyos-2.x/tos/types/AM.h:12: syntax error before `am_addr_t'/opt/tinyos-2.x/tos/lib/serial/Serial.h:83: syntax error before `uart_id_t'[...] /opt/tinyos-2.x/tos/lib/serial/Serial.h:138: warning: data definition has no type or storage classfailed to parse message file /opt/tinyos-2.x/tos/lib/serial/Serial.hMakefile:697: recipe for target `serialpacket.h' failedmake: *** [serialpacket.h] Error 1- I've been looking for a solution, but I cannot find it. All the help possible would be appreciated. Thanks in advance David From: drod...@hotmail.com To: tinyos-help@millennium.berkeley.edu Date: Tue, 21 Feb 2012 09:10:13 + Subject: [Tinyos-help] Problem with BaseStation15.4 Hi all I'm having problems when compiling the BaseStation15.4 application for Micaz devices: --$ make micazmkdir -p build/micazgcc -o seriallisten15-4 seriallisten15-4.o /opt/tinyos-2.x/tos/../support/sdk/c/sf/libmote.agcc: /opt/tinyos-2.x/tos/../support/sdk/c/sf/libmote.a: No such file or directoryMakefile:9: recipe for target `seriallisten15-4' failedmake: *** [seriallisten15-4] Error 1-- Does anyone else have this problem? I appreciate all the help possible Thanks, David ___ 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] (no subject)
Hi all I'm trying to install TinyOS on a Windows 7 machine, but I am getting the following error: $ rpm -Uvh --force --nodeps avrdude-tinyos-5.6cvs-1.cygwin.i386.rpmPreparing... ### [100%] 1:avrdude-tinyos ### [100%]/usr/bin /Copying the driver to the windows directorytarget file: C:\Windows\giveio.sysDenied Access.0 files(s) copied(s).Remove a running service if needed...Installing Windows NT/2k/XP driver: giveioinstall failed, file not found: C:\Windows\giveio.sysstarting giveio... start failed (status 6): I appreciate all the help possible. Thanks David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] (no subject)
Hi Andris You are right. I have just find the same answer. I am using the MicaZ devices and the MIB520CB Interface Board and I suppose that to install an app, I have to use make micaz install mib520,port. In this sense, as the MIB520CB Interface Board is connected to an usb port from my laptop, what port name should I use? comx? usbx? where x is 0, 1 ... I am using a cygwin environment and TinyOS 2.x Thanks for the help David Date: Mon, 13 Feb 2012 19:53:08 +0100 Subject: Re: [Tinyos-help] (no subject) From: bband...@gmail.com To: drod...@hotmail.com CC: tinyos-help@millennium.berkeley.edu Hi David, Giveio.sys doesn't work on Vista and newer, but if you don't plan to use parrellel port programmer, you don't need it. Andris On Mon, Feb 13, 2012 at 7:03 PM, David Rodenas Herráiz drod...@hotmail.com wrote: Hi all I'm trying to install TinyOS on a Windows 7 machine, but I am getting the following error: $ rpm -Uvh --force --nodeps avrdude-tinyos-5.6cvs-1.cygwin.i386.rpm Preparing...### [100%] 1:avrdude-tinyos ### [100%] /usr/bin / Copying the driver to the windows directory target file: C:\Windows\giveio.sys Denied Access. 0 files(s) copied(s). Remove a running service if needed... Installing Windows NT/2k/XP driver: giveio install failed, file not found: C:\Windows\giveio.sys starting giveio... start failed (status 6): I appreciate all the help possible. Thanks David ___ 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] (no subject)
Hi again I am sorry about the spam. I found the solution at http://docs.tinyos.net/tinywiki/index.php/Cygwin_User_Notes Thanks! From: drod...@hotmail.com To: tinyos-help@millennium.berkeley.edu Date: Mon, 13 Feb 2012 19:13:29 + Subject: Re: [Tinyos-help] (no subject) Hi Andris You are right. I have just find the same answer. I am using the MicaZ devices and the MIB520CB Interface Board and I suppose that to install an app, I have to use make micaz install mib520,port. In this sense, as the MIB520CB Interface Board is connected to an usb port from my laptop, what port name should I use? comx? usbx? where x is 0, 1 ... I am using a cygwin environment and TinyOS 2.x Thanks for the help David Date: Mon, 13 Feb 2012 19:53:08 +0100 Subject: Re: [Tinyos-help] (no subject) From: bband...@gmail.com To: drod...@hotmail.com CC: tinyos-help@millennium.berkeley.edu Hi David, Giveio.sys doesn't work on Vista and newer, but if you don't plan to use parrellel port programmer, you don't need it. Andris On Mon, Feb 13, 2012 at 7:03 PM, David Rodenas Herráiz drod...@hotmail.com wrote: Hi all I'm trying to install TinyOS on a Windows 7 machine, but I am getting the following error: $ rpm -Uvh --force --nodeps avrdude-tinyos-5.6cvs-1.cygwin.i386.rpm Preparing...### [100%] 1:avrdude-tinyos ### [100%] /usr/bin / Copying the driver to the windows directory target file: C:\Windows\giveio.sys Denied Access. 0 files(s) copied(s). Remove a running service if needed... Installing Windows NT/2k/XP driver: giveio install failed, file not found: C:\Windows\giveio.sys starting giveio... start failed (status 6): I appreciate all the help possible. Thanks David ___ 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] Stop spam!!!!!!!!
I all I have the same problem. I counted more than 200 messages from Abhishek MajumdarAdd!!! Date: Thu, 2 Feb 2012 13:04:12 +0200 From: engleza...@ceid.upatras.gr To: Tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Stop spam This user Abhishek MajumdarAdd is spamming my inbox folder threw Tinyos-help mailing list Does anybody have the same problem? ___ 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] Question about tmote sky flash storage
Hi there. If I have a tmote sky mote (telosb), then: 1. How much storage space is there in flash? 2. If the board is upgraded with a new chip (with ability to access more storage space), then how well will TinyOS support this? I have an upcoming project where we may need to store a large amount of log records to flash (record log records data for a month, and then pull the data later), but I'd first like to check a few details. Kind regards, David. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Different compilers within the same TinyOS-2.1
Hi Eric thanks for your answer. Would you mind giving me some brief instructions to do those switches? David Date: Tue, 25 Oct 2011 16:14:58 -0700 Subject: Re: [Tinyos-help] Different compilers within the same TinyOS-2.1 From: cire...@gmail.com To: drod...@hotmail.com CC: tinyos-help@millennium.berkeley.edu On Tue, Oct 25, 2011 at 11:25 AM, David Rodenas Herráiz drod...@hotmail.com wrote: Hi everyone I am working with Imote2 and MicaZ motes and I want to ask if PXA27x (compiler for Imote2) Atmel AVR tools (compiler or MicaZ) might work within the same TinyOS-2.1 installation. Sure. The toolchain invoked is determined by switches in the .platform file for the platform being compiled. So it should work fine. Thanks in advance David ___ 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] Different compilers within the same TinyOS-2.1
Thanks Eric. I had some problems installing the xscale compiler (for Imote2): rpm -ivh --ignoreos xscale-elf-gcc-3.4.3-1.cygwin.i386.rpm Preparing...### [100%] file /usr/man/man7/fsf-funding.7 from install of xscale-elf-gcc-3.4.3-1 conflicts with file from package avr-gcc-4.1.2-1 file /usr/man/man7/gfdl.7 from install of xscale-elf-gcc-3.4.3-1 conflicts with file from package avr-gcc-4.1.2-1 and more... I suppose that I'll have to install it manually. Therefore, I don't know when but I'll tell you if it finally works. David Rodenas Herráiz Date: Wed, 26 Oct 2011 03:10:34 -0700 Subject: Re: [Tinyos-help] Different compilers within the same TinyOS-2.1 From: cire...@gmail.com To: drod...@hotmail.com CC: tinyos-help@millennium.berkeley.edu take a look a different .platform files A pattern will become apparent. You'll see things like... -gcc=msp430-gcc-mmcu=msp430x1611 -fnesc-target=msp430 and like -gcc=avr-gcc-mmcu=atmega128-fnesc-target=avr I don't know of any documentation for these things. I mostly fly by the seat of my pants when it comes to what these switches do. On Wed, Oct 26, 2011 at 12:44 AM, David Rodenas Herráiz drod...@hotmail.com wrote: Hi Eric thanks for your answer. Would you mind giving me some brief instructions to do those switches? David Date: Tue, 25 Oct 2011 16:14:58 -0700 Subject: Re: [Tinyos-help] Different compilers within the same TinyOS-2.1 From: cire...@gmail.com To: drod...@hotmail.com CC: tinyos-help@millennium.berkeley.edu On Tue, Oct 25, 2011 at 11:25 AM, David Rodenas Herráiz drod...@hotmail.com wrote: Hi everyone I am working with Imote2 and MicaZ motes and I want to ask if PXA27x (compiler for Imote2) Atmel AVR tools (compiler or MicaZ) might work within the same TinyOS-2.1 installation. Sure. The toolchain invoked is determined by switches in the .platform file for the platform being compiled. So it should work fine. Thanks in advance David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Eric B. Decker Senior (over 50 :-) Researcher -- Eric B. Decker Senior (over 50 :-) Researcher ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Different compilers within the same TinyOS-2.1
Hi everyone I am working with Imote2 and MicaZ motes and I want to ask if PXA27x (compiler for Imote2) Atmel AVR tools (compiler or MicaZ) might work within the same TinyOS-2.1 installation. Thanks in advance David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] CHANGE PACKET SIZE TO TINYOS 2.X
Hi, I would like to know how to change the size of packets sent by a telosb with TinyOS 2.x. 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] CHANGE PACKET SIZE TO TINYOS 2.X
Hi, I would like to know how to change the size of packets sent by a telosb with TinyOS 2.x, through the radio. Thanks in advance. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] TosThreads compilation error
I believe I may have tracked down the cause of the problem. Revision 5455 (16 Feb 2011, committed by pabigot) made changes to tinyos-2.x/tos/chips/msp430/pins/HplMsp430GeneralIOC.nc.(among other files). These changes add support for MSP430 pin resistors, as well as mspgcc4. Specifically, line 344 includes component PlatformC, with the comment dummy to end unknown sequence. This is done because previous components are conditionally included based on pre-processor directives. Components are separated with a comma (,), however the last component needs to be terminated with a semicolon (;). As it is difficult to determine which will be the last included component, the dummy component PlatformC is included at the end, so the list of included components is always terminated with a semicolon. For some reason, including PlatformC in HplMsp430GeneralIOC causes the compilation error in the previous email (below). I do not know exactly why - my knowledge of TinyOS or TosThreads does not go that far. I have attached a patch that, instead of attempting to list all components at once and guessing the end of the list, contains the components keyword and terminates the components list within EACH pre-processor condition. This avoids having to have a dummy component to complete the components list, and now compiles fine when using TosThreads. If this patch is OK, can somebody please commit. Also, if anybody has any ideas as to why including PlatformC breaks TosThreads, I am interested - particularly if this is an indication of an uncovered bug. David From: David Rodda Sent: Monday, 27 June 2011 2:00 PM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] TosThreads compilation error I am getting an error when compiling any TinyOS application that uses TosThreads. When compiling the blink application in the TosThreads apps directory I get the following error: = make telosb threads /tinyos-2.x/tos/lib/tosthreads/system/TinyThreadSchedulerP.nc:191: warning: call via function pointer /tinyos-2.x/tos/lib/tosthreads/system/SystemCallP.nc:49: warning: call via function pointer In component `HilTimerMilliC.AlarmToTimerC': /tinyos-2.x/tos/lib/timer/AlarmToTimerC.nc: In function `Alarm.fired': /tinyos-2.x/tos/lib/timer/AlarmToTimerC.nc(HilTimerMilliC.AlarmToTimerC):82: fired.postTask not connected In component `SystemCallP': /tinyos-2.x/tos/lib/tosthreads/system/SystemCallP.nc: In function `SystemCall.start': /tinyos-2.x/tos/lib/tosthreads/system/SystemCallP.nc:74: threadTask.postTask not connected In component `ThreadTimersC.VirtualizeTimerC': /tinyos-2.x/tos/lib/timer/VirtualizeTimerC.nc: In function `startTimer': /tinyos-2.x/tos/lib/timer/VirtualizeTimerC.nc(ThreadTimersC.VirtualizeTimerC):151: updateFromTimer.postTask not connected In component `HilTimerMilliC.VirtualizeTimerC': /tinyos-2.x/tos/lib/timer/VirtualizeTimerC.nc: In function `startTimer': /tinyos-2.x/tos/lib/timer/VirtualizeTimerC.nc(HilTimerMilliC.VirtualizeTimerC):151: updateFromTimer.postTask not connected make: *** [exe0] Error 1 = This happens regardless of the application I compile or the platform I target. This setup was working when I last tried to compile, earlier on this year, but I have since updated the TinyOS. Using TinyOS 2.x from SVN, on windows under Cygwyn. It appears I am not the only one having this issue - this post on nabble in early June raises the same issue. http://old.nabble.com/Problem-compiling-tosthreads-demo-code-tt31744254.html#a31744254 Has anybody else experienced this issue? Any help appreciated. David The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments. HplMsp430InterruptC.nc.patch Description: HplMsp430InterruptC.nc.patch ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] TosThreads compilation error
I am getting an error when compiling any TinyOS application that uses TosThreads. When compiling the blink application in the TosThreads apps directory I get the following error: = make telosb threads /tinyos-2.x/tos/lib/tosthreads/system/TinyThreadSchedulerP.nc:191: warning: call via function pointer /tinyos-2.x/tos/lib/tosthreads/system/SystemCallP.nc:49: warning: call via function pointer In component `HilTimerMilliC.AlarmToTimerC': /tinyos-2.x/tos/lib/timer/AlarmToTimerC.nc: In function `Alarm.fired': /tinyos-2.x/tos/lib/timer/AlarmToTimerC.nc(HilTimerMilliC.AlarmToTimerC):82: fired.postTask not connected In component `SystemCallP': /tinyos-2.x/tos/lib/tosthreads/system/SystemCallP.nc: In function `SystemCall.start': /tinyos-2.x/tos/lib/tosthreads/system/SystemCallP.nc:74: threadTask.postTask not connected In component `ThreadTimersC.VirtualizeTimerC': /tinyos-2.x/tos/lib/timer/VirtualizeTimerC.nc: In function `startTimer': /tinyos-2.x/tos/lib/timer/VirtualizeTimerC.nc(ThreadTimersC.VirtualizeTimerC):151: updateFromTimer.postTask not connected In component `HilTimerMilliC.VirtualizeTimerC': /tinyos-2.x/tos/lib/timer/VirtualizeTimerC.nc: In function `startTimer': /tinyos-2.x/tos/lib/timer/VirtualizeTimerC.nc(HilTimerMilliC.VirtualizeTimerC):151: updateFromTimer.postTask not connected make: *** [exe0] Error 1 = This happens regardless of the application I compile or the platform I target. This setup was working when I last tried to compile, earlier on this year, but I have since updated the TinyOS. Using TinyOS 2.x from SVN, on windows under Cygwyn. It appears I am not the only one having this issue - this post on nabble in early June raises the same issue. http://old.nabble.com/Problem-compiling-tosthreads-demo-code-tt31744254.html#a31744254 Has anybody else experienced this issue? Any help appreciated. David The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Never get an ACK on Iris motes
Hi Miklos,
you were right. I did not put the messages back into the pool in the case of
failure. I corrected this in my example application and now I am no longer able
to reproduce the error I had before. I wonder though why this is the case since
as I said before I never had a run in which a send() or sendDone() gave me an
error, so all packets from the pool should have been returned to the pool after
sending. Does this mean that I have to write code like this to make sure my
application works properly?:
function {
if(whatever) {
do something with the message_t from pool;
return message_t to pool;
return from function;
}
else {
do something else with the message_t from pool;
return message_t to pool;
return from function;
}
return message_t to pool;
return from function;
}
In my eyes the code after the if-else statement is unnecessary since I will
never get there. But in my example application the code that was never reached
in a test run (even though it was reachable in contrast to the example above)
nevertheless changed my programs behavior. In my real program I do still get
the described error and I do not know where to search for leaking packets or
other errors anymore.
Thanks for your advice
David
Am 20.06.2011 um 15:27 schrieb Miklos Maroti:
Hi David,
On Mon, Jun 20, 2011 at 12:39 PM, David Piotrowski tin...@zeroflag.eu wrote:
Hi Miklos,
I do not get failures, send returns just fine. I am also releasing the
packets back to the pool after sondDone occurs.
No, you do NOT put back the message after a sendDone(FAIL) even or a
send command which fails.
The packets from the pool are only manipulated after I get them from the
pool and before I release them to the pool again, so I think even if they
get corrupted in the pool they should be properly setup again before sending
them. I am not using Packet.clear though. I'll try that and see whether it
has any influence on my results.
You should call Packet.clear(). I suppose, that the MessagePool
maintains a linked list of entries and stores pointers and that
corrupts the internal layout, so you have to call Packet.clear() for
each message.
Best,
Miklos
Thanks for your input.
David
Am 19.06.2011 um 23:45 schrieb Miklos Maroti:
Hi David,
Do you see any failures? (send fails or sendDone fails?) If any of
those occur, then you have to put the message back to the pool.
Another thing you should do: call Packet.clear before you set up the
data in the message. The values in the pool can be corrupted. I think
this is the source of your problems.
Best,
Miklos
On Sun, Jun 19, 2011 at 11:33 PM, David Piotrowski tin...@zeroflag.eu
wrote:
Hello again,
I did some more investigations on the ACK error I described in my previous
mail. It seems like I had quite the same error about a year ago but since
then I used tossim quite a lot and the error did not show up there.
I have written a small example application that shows the error I have.
The application has a fixed message_t variable and a pool from which it
gets another message_t. It then sends the fixed message_t and the
message_t from the pool alternately over and over again. Upon reception
the receiving node lights the received message on its LED. The nodes print
some debugging information out on the screen showing which kind of
message_t they are actually sending and if it is acknowledged.
Depending on the size of the pool used I get different behavior when it
comes to acknowledgements. For me the configuration of the program
appended yields no ack for packets that come from the pool but the packets
not coming from the pool all get acknowledgements. Other pool sizes yield
other results. In several (maybe all?) configurations the first two
packets never get acknowledged independent of whether they come from the
pool or not. Another thing to notice is that although the packets are not
acknowledged, they have been properly received, which is signaled by the
blinking LEDs. In some configurations the behaviour of ACKs changes
between resets of the node.
I am really searching for some advice on this. The actual program I am
working on is using at least two pools, which I suspect are the reason why
I never get an ack there although all the messages sent are received and
everything is working flawless in tossim.
Thanks, David.
___
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] Never get an ACK on Iris motes
Hi Miklos, I do not get failures, send returns just fine. I am also releasing the packets back to the pool after sondDone occurs. The packets from the pool are only manipulated after I get them from the pool and before I release them to the pool again, so I think even if they get corrupted in the pool they should be properly setup again before sending them. I am not using Packet.clear though. I'll try that and see whether it has any influence on my results. Thanks for your input. David Am 19.06.2011 um 23:45 schrieb Miklos Maroti: Hi David, Do you see any failures? (send fails or sendDone fails?) If any of those occur, then you have to put the message back to the pool. Another thing you should do: call Packet.clear before you set up the data in the message. The values in the pool can be corrupted. I think this is the source of your problems. Best, Miklos On Sun, Jun 19, 2011 at 11:33 PM, David Piotrowski tin...@zeroflag.eu wrote: Hello again, I did some more investigations on the ACK error I described in my previous mail. It seems like I had quite the same error about a year ago but since then I used tossim quite a lot and the error did not show up there. I have written a small example application that shows the error I have. The application has a fixed message_t variable and a pool from which it gets another message_t. It then sends the fixed message_t and the message_t from the pool alternately over and over again. Upon reception the receiving node lights the received message on its LED. The nodes print some debugging information out on the screen showing which kind of message_t they are actually sending and if it is acknowledged. Depending on the size of the pool used I get different behavior when it comes to acknowledgements. For me the configuration of the program appended yields no ack for packets that come from the pool but the packets not coming from the pool all get acknowledgements. Other pool sizes yield other results. In several (maybe all?) configurations the first two packets never get acknowledged independent of whether they come from the pool or not. Another thing to notice is that although the packets are not acknowledged, they have been properly received, which is signaled by the blinking LEDs. In some configurations the behaviour of ACKs changes between resets of the node. I am really searching for some advice on this. The actual program I am working on is using at least two pools, which I suspect are the reason why I never get an ack there although all the messages sent are received and everything is working flawless in tossim. Thanks, David. ___ 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] Never get an ACK on Iris motes
I forgot to mention that if you want to try the test application out you just take two nodes and install the application assigning the nodes the addresses 1 and 2. They will figure out where to send the messages on their own then. David Am 19.06.2011 um 23:33 schrieb David Piotrowski: Hello again, I did some more investigations on the ACK error I described in my previous mail. It seems like I had quite the same error about a year ago but since then I used tossim quite a lot and the error did not show up there. I have written a small example application that shows the error I have. The application has a fixed message_t variable and a pool from which it gets another message_t. It then sends the fixed message_t and the message_t from the pool alternately over and over again. Upon reception the receiving node lights the received message on its LED. The nodes print some debugging information out on the screen showing which kind of message_t they are actually sending and if it is acknowledged. Depending on the size of the pool used I get different behavior when it comes to acknowledgements. For me the configuration of the program appended yields no ack for packets that come from the pool but the packets not coming from the pool all get acknowledgements. Other pool sizes yield other results. In several (maybe all?) configurations the first two packets never get acknowledged independent of whether they come from the pool or not. Another thing to notice is that although the packets are not acknowledged, they have been properly received, which is signaled by the blinking LEDs. In some configurations the behaviour of ACKs changes between resets of the node. I am really searching for some advice on this. The actual program I am working on is using at least two pools, which I suspect are the reason why I never get an ack there although all the messages sent are received and everything is working flawless in tossim. Thanks, David. MakefilepoolTestAppC.ncpoolTestC.nc ___ 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] Never get an ACK on Iris motes
Hello again, I did some more investigations on the ACK error I described in my previous mail. It seems like I had quite the same error about a year ago but since then I used tossim quite a lot and the error did not show up there. I have written a small example application that shows the error I have. The application has a fixed message_t variable and a pool from which it gets another message_t. It then sends the fixed message_t and the message_t from the pool alternately over and over again. Upon reception the receiving node lights the received message on its LED. The nodes print some debugging information out on the screen showing which kind of message_t they are actually sending and if it is acknowledged. Depending on the size of the pool used I get different behavior when it comes to acknowledgements. For me the configuration of the program appended yields no ack for packets that come from the pool but the packets not coming from the pool all get acknowledgements. Other pool sizes yield other results. In several (maybe all?) configurations the first two packets never get acknowledged independent of whether they come from the pool or not. Another thing to notice is that although the packets are not acknowledged, they have been properly received, which is signaled by the blinking LEDs. In some configurations the behaviour of ACKs changes between resets of the node. I am really searching for some advice on this. The actual program I am working on is using at least two pools, which I suspect are the reason why I never get an ack there although all the messages sent are received and everything is working flawless in tossim. Thanks, David. Makefile Description: Binary data poolTestAppC.nc Description: Binary data poolTestC.nc Description: Binary data ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Never get an ACK on Iris motes
Hello, I hope someone out there can help me with this issue because I begin to freak out on this. I wrote a program that makes use of Packet Acknowledgments. While in TosSim everything works nicely, I do never get an ACK for the packets I send with my real Iris motes. The packets do arrive at the other node though and everything is fine but the sending node never gets an ACK. I guess my code is ok since everything is good when using tossim. I also programmed another little test application to see if this was just my programs fault but the new test application does not receive any ACKs, too. Are Iris nodes just not capable of sending/receiving ACKs? Any help or suggestions are very welcome. David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] TinyOS install on Mac OS X 1.6
Running into some difficulties with the install. I cannot find reference to it anywhere else. In the java component I get the follow errors from the make. cat: SerialPacket.java: No such file or directory i686-apple-darwin10-gcc-4.2.1: .: linker input file unused because linking not done mig: fatal: no name yet, line -1: no SubSystem declaration warning: option -java-classname=net.tinyos.message.SerialPacket after filename(s) ignored /usr/bin/mig: line 207: /var/folders/lm/lmF5C5ABHeCcERkrccClUU+++TI/-Tmp-//mig.bMdbqS/java.35935.c: No such file or directory i686-apple-darwin10-gcc-4.2.1: /var/folders/lm/lmF5C5ABHeCcERkrccClUU+++TI/-Tmp-//mig.bMdbqS/java.35935.c: No such file or directory mig: fatal: no name yet, line -1: no SubSystem declaration /usr/bin/mig: line 207: /var/folders/lm/lmF5C5ABHeCcERkrccClUU+++TI/-Tmp-//mig.bMdbqS/Serial.h.35935.c: No such file or directory i686-apple-darwin10-gcc-4.2.1: /var/folders/lm/lmF5C5ABHeCcERkrccClUU+++TI/-Tmp-//mig.bMdbqS/Serial.h.35935.c: No such file or directory mig: fatal: no name yet, line -1: no SubSystem declaration /usr/bin/mig: line 207: /var/folders/lm/lmF5C5ABHeCcERkrccClUU+++TI/-Tmp-//mig.bMdbqS/serial_packet.35935.c: No such file or directory i686-apple-darwin10-gcc-4.2.1: /var/folders/lm/lmF5C5ABHeCcERkrccClUU+++TI/-Tmp-//mig.bMdbqS/serial_packet.35935.c: No such file or directory mig: fatal: no name yet, line -1: no SubSystem declaration warning: option -I/Users/Neodymium/Documents/RUBICON/tinyos-2.x/tos/types after filename(s) ignored rmdir: /var/folders/lm/lmF5C5ABHeCcERkrccClUU+++TI/-Tmp-//mig.bMdbqS: No such file or directory javac SerialPacket.java javac: file not found: SerialPacket.java Usage: javac options source files use -help for a list of possible options make: *** [SerialPacket.class] Error 2 If anyone can cut through this fog, I would really appreciate it. Otherwise I will try and get a linux machine. -- - David Swords ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] AMSend.send() returns SUCCESS, but AMSend.sendDone() is never signaled.
Hey everyone -
I'm working on some radio code for the telosB motes. Specifically, my code
calls AMSend.send(), and via the printf library, I've proved that it returns
SUCCESS.
Unfortunately, the event for sendDone never gets called.
I've heard that this can be caused due to ack issues, so for now, I've
tossed a
#define CC2420_NO_ACKNOWLEDGEMENTS
right after my include statements.
Anyone have any other ideas of what can cause this?
--- Code Below ---
#include SensorMsg.h
#include printf.h
#define CC2420_NO_ACKNOWLEDGEMENTS
module Uint8_tSenderC{
provides
{
interface ByteSend;
}
uses{
interface Leds;
interface AMSend;
interface SplitControl as AMControl;
interface Packet;
interface AMPacket;
interface Resource as RadioResource;
}
}
implementation{
bool busy = FALSE;
uint8_t sendVal;
event void AMSend.sendDone(message_t *msg, error_t error){
error_t retVal;
printf(AMSend.sendDone(%p, %u), msg, error);
printfflush();
call Leds.led1On();
if(error == SUCCESS)
{ call Leds.led2Toggle();
retVal = call AMControl.stop();
while(!(retVal == SUCCESS || retVal == EALREADY ))
{
retVal = call AMControl.stop();
}
}
else
{
call AMSend.send(AM_BROADCAST_ADDR, msg, sizeof(SensorMessage_t));
}
}
event void AMControl.startDone(error_t error){
error_t retVal;
message_t msgBuf;
printf(AMControl.startDone started. Parameter: %u. SendVal:%u\n,error,
sendVal);
printfflush();
if(error == SUCCESS)
{
if(!busy)
{
SensorMessage_t * payload;
payload = (SensorMessage_t *) call Packet.getPayload(msgBuf,
sizeof(SensorMessage_t));
payload-nodeId=TOS_NODE_ID;
payload-sensorType=0x01;
payload-msgType=0x03;
payload-msgValue= sendVal;
busy = TRUE;
printf(Payload of %u packed into message buffer at %p\n, sendVal,
msgBuf);
printfflush();
retVal = call AMSend.send(AM_BROADCAST_ADDR, msgBuf,
sizeof(SensorMessage_t));
printf(AMSend.send() returned %u\n, retVal);
printfflush();
while(retVal != SUCCESS)
{
if(retVal == EBUSY)
{
call Leds.led1On();
}
if(retVal == FAIL)
{
call Leds.led1On();
}
printf(AMSend.send() returned %u\n, retVal);
printfflush();
retVal = call AMSend.send(AM_BROADCAST_ADDR, msgBuf,
sizeof(SensorMessage_t));
}
printf(AMSend.send() returned SUCCESS\n);
printfflush();
call Leds.led2On();
}
}
else
{
printf(AMSend.send() restarted!\n);
printfflush();
call AMControl.start();
}
}
event void RadioResource.granted(){
error_t retVal;
retVal = call AMControl.start();
while(!(retVal == SUCCESS || retVal == EALREADY ))
{
retVal = call AMControl.start();
}
}
event void AMControl.stopDone(error_t error){
call RadioResource.release();
signal ByteSend.sendDone();
}
command error_t ByteSend.doSend(uint8_t toSend){
error_t ret;
if(!busy)
{
printf(Attempting to send %u\n, toSend);
printfflush();
sendVal = toSend;
ret = call RadioResource.request(); //immediateRequest();
while(ret != SUCCESS)
{
printf(RadioResource.request() failed with status %u\n, ret);
printfflush();
ret = call RadioResource.request(); //immediateRequest();
}
printf(RadioResource.request() returned SUCCESS\n);
printfflush();
call Leds.led0On();
}
else
{
ret = FALSE;
}
return ret;
}
}
--- Code Above
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] AMSend.send() returns SUCCESS, but AMSend.sendDone() is never signaled.
That's an excellent idea I never thought to look for.
However, I know it's not that specific infinite loop, since the printf()
usually prints the same thing (except for the occasional bad packet?), and
that's:
Thread[Thread-1,5,main]serial@/dev/mote_ultrasound:115200: resynchronising
Attempting to send 101
RadioResource.request() returned SUCCESS
AMControl.startDone started. Parameter: 0. SendVal:101
Payload of 101 packed into message buffer at 0x38b6
AMSend.send() returned 0
AMSend.send() returned SUCCESS
Based on my code, that seems to imply it makes a success on it's first try.
Is there any profiling tool I can use on the msp430 found in the telosB,
rather than trying to tease out the error by hand?
Thanks again for your help and rapid response,
On Thu, May 5, 2011 at 12:39 PM, Michael Schippling sc...@santafe.eduwrote:
One should get a sendDone() with a failed ACK, although
you probably need to look at the message.ack field rather
then the error argument to figure it out.
If you are not getting the sendDone() call ever-at-all,
I would suspect that you have something hogging the processor
-- like that possibly infinite-loop of error checking after
your send() call (I'm too lazy to run it in my head) -- or
that calling send() from the startDone() is too early in
the cycle. If that's the case you could try calling send()
from a Timer.fired(), or posting a Task to do it a little
later on.
MS
David Lee wrote:
Hey everyone -
I'm working on some radio code for the telosB motes. Specifically, my code
calls AMSend.send(), and via the printf library, I've proved that it returns
SUCCESS.
Unfortunately, the event for sendDone never gets called.
I've heard that this can be caused due to ack issues, so for now, I've
tossed a
#define CC2420_NO_ACKNOWLEDGEMENTS
right after my include statements.
Anyone have any other ideas of what can cause this?
--- Code Below ---
#include SensorMsg.h
#include printf.h
#define CC2420_NO_ACKNOWLEDGEMENTS
module Uint8_tSenderC{
provides {
interface ByteSend;
}
uses{
interface Leds;
interface AMSend;
interface SplitControl as AMControl;
interface Packet;
interface AMPacket;
interface Resource as RadioResource;
}
}
implementation{
bool busy = FALSE;
uint8_t sendVal;
event void AMSend.sendDone(message_t *msg, error_t error){
error_t retVal;
printf(AMSend.sendDone(%p, %u), msg, error);
printfflush();
call Leds.led1On();
if(error == SUCCESS)
{ call Leds.led2Toggle();
retVal = call AMControl.stop();
while(!(retVal == SUCCESS || retVal == EALREADY ))
{
retVal = call AMControl.stop();
}
}
else
{
call AMSend.send(AM_BROADCAST_ADDR, msg, sizeof(SensorMessage_t));
}
}
event void AMControl.startDone(error_t error){
error_t retVal;
message_t msgBuf;
printf(AMControl.startDone started. Parameter: %u. SendVal:%u\n,error,
sendVal);
printfflush();
if(error == SUCCESS)
{
if(!busy)
{
SensorMessage_t * payload;
payload = (SensorMessage_t *) call Packet.getPayload(msgBuf,
sizeof(SensorMessage_t));
payload-nodeId=TOS_NODE_ID;
payload-sensorType=0x01;
payload-msgType=0x03;
payload-msgValue= sendVal;
busy = TRUE;
printf(Payload of %u packed into message buffer at %p\n, sendVal,
msgBuf);
printfflush();
retVal = call AMSend.send(AM_BROADCAST_ADDR, msgBuf,
sizeof(SensorMessage_t));
printf(AMSend.send() returned %u\n, retVal);
printfflush();
while(retVal != SUCCESS)
{
if(retVal == EBUSY)
{
call Leds.led1On();
}
if(retVal == FAIL)
{
call Leds.led1On();
}
printf(AMSend.send() returned %u\n, retVal);
printfflush();
retVal = call AMSend.send(AM_BROADCAST_ADDR, msgBuf,
sizeof(SensorMessage_t));
}
printf(AMSend.send() returned SUCCESS\n);
printfflush();
call Leds.led2On();
}
}
else {
printf(AMSend.send() restarted!\n);
printfflush();
call AMControl.start();
}
}
event void RadioResource.granted(){
error_t retVal;
retVal = call AMControl.start();
while(!(retVal == SUCCESS || retVal == EALREADY ))
{
retVal = call AMControl.start();
}
}
event void AMControl.stopDone(error_t error){
call RadioResource.release();
signal ByteSend.sendDone();
}
command error_t ByteSend.doSend(uint8_t toSend){
error_t ret;
if(!busy)
{
printf(Attempting to send %u\n, toSend);
printfflush();
sendVal = toSend;
ret = call RadioResource.request(); //immediateRequest();
while(ret != SUCCESS)
{
printf(RadioResource.request() failed with status %u\n, ret);
printfflush();
ret = call RadioResource.request(); //immediateRequest();
}
printf(RadioResource.request() returned SUCCESS\n);
printfflush();
call Leds.led0On();
}
else
{
ret = FALSE;
}
return ret;
}
}
--- Code Above
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] AMSend.send() returns SUCCESS, but AMSend.sendDone() is never signaled.
So, I've broken a test bit out that just handles the sending of a single
byte.
I've stuck more printfs in there to check for loops (not enough leds to use
those)
I'm not seeing any loops in my code's output. For references, here's the
output:
Thread[Thread-1,5,main]serial@/dev/mote_ultrasound:115200: resynchronising
RadioTestC Booted!
Attempting to send 50
RadioResource.request() - outside loop - returned SUCCESS
doSend returned 0
RadioResource.granted() - before loop - retVal: 0
RadioResource.granted() - after loop - retVal: 0
AMControl.startDone started. Parameter: 0. SendVal:50
Payload of 50 packed into message buffer at 0x38b6
AMSend.send() - before loop - returned 0
AMSend.send() - after loop - returned SUCCESS
AMSend.send() about to return
The code puts the email above the moderation limit, so I've posted it
herehttp://pastebin.com/9sqN6Bv1
On Thu, May 5, 2011 at 1:37 PM, Michael Schippling sc...@santafe.eduwrote:
I don't know of any telos profiling tools. It does have
pads for a JTAG connector which you could use to trace
code, but I've never used it. Toggling LEDs is the best
debugging tool available, since it's easy (if you keep
the on/off patterns logical somehow) and doesn't interfere
with timing -- of course I always debug with printf's
on real computers too --
I think simplifying your program a bit and putting the
send() in it's own task might be the best start.
The issue with processor-hogging, and the reason
programs need to be broken up into small execution
units, is that TOS is not pre-emptive. So if you have
something that gets stuck in a loop and doesn't return
to the scheduler, no other tasks get executed. Since
everything pretty much relies on being able to fire
off a new task, even the Timer code, the system drags
to a halt.
MS
David Lee wrote:
That's an excellent idea I never thought to look for.
However, I know it's not that specific infinite loop, since the printf()
usually prints the same thing (except for the occasional bad packet?), and
that's:
Thread[Thread-1,5,main]serial@/dev/mote_ultrasound:115200:
resynchronising
Attempting to send 101
RadioResource.request() returned SUCCESS
AMControl.startDone started. Parameter: 0. SendVal:101
Payload of 101 packed into message buffer at 0x38b6
AMSend.send() returned 0
AMSend.send() returned SUCCESS
Based on my code, that seems to imply it makes a success on it's first
try.
Is there any profiling tool I can use on the msp430 found in the telosB,
rather than trying to tease out the error by hand?
Thanks again for your help and rapid response,
On Thu, May 5, 2011 at 12:39 PM, Michael Schippling
sc...@santafe.edumailto:
sc...@santafe.edu wrote:
One should get a sendDone() with a failed ACK, although
you probably need to look at the message.ack field rather
then the error argument to figure it out.
If you are not getting the sendDone() call ever-at-all,
I would suspect that you have something hogging the processor
-- like that possibly infinite-loop of error checking after
your send() call (I'm too lazy to run it in my head) -- or
that calling send() from the startDone() is too early in
the cycle. If that's the case you could try calling send()
from a Timer.fired(), or posting a Task to do it a little
later on.
MS
David Lee wrote:
Hey everyone -
I'm working on some radio code for the telosB motes.
Specifically, my code calls AMSend.send(), and via the printf
library, I've proved that it returns SUCCESS.
Unfortunately, the event for sendDone never gets called.
I've heard that this can be caused due to ack issues, so for
now, I've tossed a
#define CC2420_NO_ACKNOWLEDGEMENTS
right after my include statements.
Anyone have any other ideas of what can cause this?
--- Code Below ---
#include SensorMsg.h
#include printf.h
#define CC2420_NO_ACKNOWLEDGEMENTS
module Uint8_tSenderC{
provides {
interface ByteSend;
}
uses{
interface Leds;
interface AMSend;
interface SplitControl as AMControl;
interface Packet;
interface AMPacket;
interface Resource as RadioResource;
}
}
implementation{
bool busy = FALSE;
uint8_t sendVal;
event void AMSend.sendDone(message_t *msg, error_t error){
error_t retVal;
printf(AMSend.sendDone(%p, %u), msg, error);
printfflush();
call Leds.led1On();
if(error == SUCCESS)
{ call Leds.led2Toggle();
retVal = call AMControl.stop();
while(!(retVal == SUCCESS || retVal == EALREADY ))
{
retVal = call AMControl.stop();
}
}
else
{
call AMSend.send(AM_BROADCAST_ADDR, msg, sizeof(SensorMessage_t
Re: [Tinyos-help] AMSend.send() returns SUCCESS, but AMSend.sendDone() is never signaled.
Sorry for the double-email, but I may have found some interesting
information.
I tried using MSPSim, which I know isn't 100% accurate, but it at least has
a Profile command.
It seems I'm spending a LOT of time in McuSleepC__getPowerState.
Does that indicate anything?
On Thu, May 5, 2011 at 3:34 PM, David Lee d...@gray101.com wrote:
So, I've broken a test bit out that just handles the sending of a single
byte.
I've stuck more printfs in there to check for loops (not enough leds to use
those)
I'm not seeing any loops in my code's output. For references, here's the
output:
Thread[Thread-1,5,main]serial@/dev/mote_ultrasound:115200:
resynchronising
RadioTestC Booted!
Attempting to send 50
RadioResource.request() - outside loop - returned SUCCESS
doSend returned 0
RadioResource.granted() - before loop - retVal: 0
RadioResource.granted() - after loop - retVal: 0
AMControl.startDone started. Parameter: 0. SendVal:50
Payload of 50 packed into message buffer at 0x38b6
AMSend.send() - before loop - returned 0
AMSend.send() - after loop - returned SUCCESS
AMSend.send() about to return
The code puts the email above the moderation limit, so I've posted it
herehttp://pastebin.com/9sqN6Bv1
On Thu, May 5, 2011 at 1:37 PM, Michael Schippling sc...@santafe.eduwrote:
I don't know of any telos profiling tools. It does have
pads for a JTAG connector which you could use to trace
code, but I've never used it. Toggling LEDs is the best
debugging tool available, since it's easy (if you keep
the on/off patterns logical somehow) and doesn't interfere
with timing -- of course I always debug with printf's
on real computers too --
I think simplifying your program a bit and putting the
send() in it's own task might be the best start.
The issue with processor-hogging, and the reason
programs need to be broken up into small execution
units, is that TOS is not pre-emptive. So if you have
something that gets stuck in a loop and doesn't return
to the scheduler, no other tasks get executed. Since
everything pretty much relies on being able to fire
off a new task, even the Timer code, the system drags
to a halt.
MS
David Lee wrote:
That's an excellent idea I never thought to look for.
However, I know it's not that specific infinite loop, since the printf()
usually prints the same thing (except for the occasional bad packet?), and
that's:
Thread[Thread-1,5,main]serial@/dev/mote_ultrasound:115200:
resynchronising
Attempting to send 101
RadioResource.request() returned SUCCESS
AMControl.startDone started. Parameter: 0. SendVal:101
Payload of 101 packed into message buffer at 0x38b6
AMSend.send() returned 0
AMSend.send() returned SUCCESS
Based on my code, that seems to imply it makes a success on it's first
try.
Is there any profiling tool I can use on the msp430 found in the telosB,
rather than trying to tease out the error by hand?
Thanks again for your help and rapid response,
On Thu, May 5, 2011 at 12:39 PM, Michael Schippling
sc...@santafe.edumailto:
sc...@santafe.edu wrote:
One should get a sendDone() with a failed ACK, although
you probably need to look at the message.ack field rather
then the error argument to figure it out.
If you are not getting the sendDone() call ever-at-all,
I would suspect that you have something hogging the processor
-- like that possibly infinite-loop of error checking after
your send() call (I'm too lazy to run it in my head) -- or
that calling send() from the startDone() is too early in
the cycle. If that's the case you could try calling send()
from a Timer.fired(), or posting a Task to do it a little
later on.
MS
David Lee wrote:
Hey everyone -
I'm working on some radio code for the telosB motes.
Specifically, my code calls AMSend.send(), and via the printf
library, I've proved that it returns SUCCESS.
Unfortunately, the event for sendDone never gets called.
I've heard that this can be caused due to ack issues, so for
now, I've tossed a
#define CC2420_NO_ACKNOWLEDGEMENTS
right after my include statements.
Anyone have any other ideas of what can cause this?
--- Code Below ---
#include SensorMsg.h
#include printf.h
#define CC2420_NO_ACKNOWLEDGEMENTS
module Uint8_tSenderC{
provides {
interface ByteSend;
}
uses{
interface Leds;
interface AMSend;
interface SplitControl as AMControl;
interface Packet;
interface AMPacket;
interface Resource as RadioResource;
}
}
implementation{
bool busy = FALSE;
uint8_t sendVal;
event void AMSend.sendDone(message_t *msg, error_t error){
error_t retVal;
printf(AMSend.sendDone(%p, %u), msg, error);
printfflush();
call
Re: [Tinyos-help] CTP timeout-related questions
Thanks for those replies: I have a better understanding now of how the CTP+LPL timeouts work. Fyi: I am seeing about 5-6 hour delays in re-establishing the mesh network when there's a problem Here's the use case: - 2 motes, pretty far away from the basestation, but the signal is able to get through. Each mote is transmitting a sensor reading over CTP+LPL once a minute (except when the mote is still busy in a sensor read or send, from a previous cycle). - Occasionally, something happens to interrupt the mesh network (maybe something in the office that adds some interference), and then both the motes drop off the network (basestation stops receiving data over CTP+LPL), and don't want to come up again again. - If I take both motes and put them right next to the basestation, the data still doesn't come through - About 5-6 hours later, the signals start coming through again on both motes at around the same time. I've seen this type of pattern a couple of times so far. I think that this might be because of the CTP send code on both motes, taking a very long time to time out, possibly combined with the mesh network having trouble re-establishing. If it becomes a problem, I'll see if using the send cancel interface to CTP on the motes helps a bit, to get the data coming through from the motes again sooner. Or maybe I need to try something like making all the motes reboot themselves after an hour of CTP inactivity, or explicitely turning the CTP algorithm off and on on all the motes, to help restart the logic? Thanks for your advice so far. PS: With regards to my earlier question, CTP+LPL, with a 1 second duty cycle, seems to be working very well for me so far in terms of low power usage. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Contribution to TinyOS - MSPSim build extra
Hey all, I'm using TinyOS for a university project, and specifically am working with the TelosB motes. I'm also using the YETI plugin for Eclipse, so running any sort of simulation was a bit of a pain. In order to be able to simulate my stuff via the standard build system, I made a custom .extra file for the build system. The changeset consists of the following things: 1. A new file mspsim.extras that lives in the /support/make/msp folder 2. A new folder, /tools/mspsim that contains mspsim.jar and its lib folder 3. A utility script that I wrote called open-terminal, that handles opening a terminal for the simulator (the eclipse one tends not to work reliably) regardless of platform. Once it's properly installed, enabling the mspsim extra automatically builds the project and then starts the simulator. Currently, since I don't believe MSPSim is part of TinyOS, my build extra doesn't download or compile that dependency. I'm unsure of what the next step is, though. Apparently, it isn't the tinyos-devel mailing list, because they rejected this. Should I just attach the files to a followup? Thanks for your input ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Contribution to TinyOS - MSPSim build extra
Hey all, I'm using TinyOS for a university project, and specifically am working with the TelosB motes. I'm also using the YETI plugin for Eclipse, so running any sort of simulation was a bit of a pain. In order to be able to simulate my stuff via the standard build system, I made a custom .extra file for the build system. The changeset consists of the following things: 1. A new file mspsim.extras that lives in the /support/make/msp folder 2. A new folder, /tools/mspsim that contains mspsim.jar and its lib folder 3. A utility script that I wrote called open-terminal, that handles opening a terminal for the simulator (the eclipse one tends not to work reliably) regardless of platform. Once it's properly installed, enabling the mspsim extra automatically builds the project and then starts the simulator. Currently, since I don't believe MSPSim is part of TinyOS, my build extra doesn't download or compile that dependency. I'm unsure of what the next step is, though. Apparently, it isn't the tinyos-devel mailing list, because they rejected this. Should I just attach the files to a followup? Thanks for your input David A. Lee Co-Social Chair - Tau Kappa Epsilon Xi Chapter Projects Manager - IEEE@Wash U ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP timeout-related questions
Also, a quick amendment to the one question: 4. Time for CTP network to re-establish. If the motes are unable to contact the basestation for a long time (eg: hours/days), but then later the basestation becomes available - then how long typically would it take for the network to re-establish, and for data to start coming through from the sensors? Also, does it make a difference whether the basestation is initially available (routes are able to establish before the basestation goes offline), or if the basestation is not available when the sensor motes are started, but then later the basestation comes online. Regards, David. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] CTP timeout-related questions
Hi there, I've started using CTP+LPL in a project (thanks for the earlier suggestion), and have a few questions about the network behavior when the basestation mote is offline/unavailable. (in this mail, I assume a very basic setup, where the motes can normally all reach the basestation directly over CTP). Also, I'm using the official TinyOS 2.1.1 release, installed from the deb files. Basically I have these queries: 1. CTP send timeout length: If you send a packet over CTP, but the basestation is off, the sent event never seems to fire (even with an error/timeout code). Or rather, sometimes it does, but not other times. Will the send eventually timeout, or will the mote eternally be in a trying to send state, without calling any event code in the app? If there is an eventual send timeout, then how long is it, and where can it be configured? 2. Cancelling CTP send: If for instance you're trying to send data over CTP from sensors, but your data is out of date (basestation off for a long time), or your sensor changes it's mind about wanting to send - is there a way to cancel an existing in progress send? I don't see an interface for this. Would stopping and starting the radio, and the collect engines achieve the same thing? (at the moment: I'm assuming that if the mote has been offline for a long time, that the first received packet's sensor data should be ignored, due to likely being very out of date). 3. Updating the packet being sent. Alternately - if the CTP algorithm is taking a long time to send the packet (basestation is off for a long time), is it safe to update the not-yet-sent payload with newer details? (probably not safe, but just checking). 4. Time for CTP network to re-establish. If the motes are unable to contact the basestation for a long time (eg: hours/days), but then later the basestation becomes available - then how long typically would it take for the network to re-establish, and for data to start coming through from the sensors? Thanks for your time, David. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Advice for tinyos network logic (low power sensor mesh network)
Hi there, I need to make an application, with these requirements: 1. Take a sensor reading every 30 minutes 2. Use mesh networking to transfer sensor readings to PC 3. Conserve battery power as much as possible There will be several sensor motes in the field. The motes are tmote sky, with 2 penlight batteries. I've already implemented the above (using CTP network protocol), but I'm concerned about battery life. What type of network logic do you recommend? I have done a bit of research on this, but I'm a beginner with tinyos, so I'm not sure what will work best, and be simple to implement. Below this there are some (tldr) notes I've made, for what I've researched so far (mainly reading mailing list and docs) as a reference. You can skim or ignore it. Thanks, David. ===TLDR stuff below=== From what I've read, continuous collect algorithm usage will exhaust the battery fairly quickly (in about 1-2 weeks), due to radio actively listening. If possible, I'd like to extend the battery life to several months (tinyos faq mentions that 6-month lifetime can be achieved, including multi-hop networking). I have done a bit of research, and found these possiblities: - Low Power Listening - SCP-MAC And I've also considered an alternative network layout (some motes are wall-powered, or have larger batteries, and act as relays for the other motes. Either using CTP or Tymo). My biggest problem is being a beginner with tinyos coding (it will take me a long time if I need to start digging into network code). So I'm looking for some simple-to-implement logic that will maximize battery life with the above application. As a beginner with tinyos, my problems with the above are: 1. LPL: - Is reported to have problems with CTP in the mailing lists - Motes being constantly in transmit mode (waiting for other motes to wake up) might take a lot of battery life - I'm not sure what the optimal settings are to use with this. - Will lowering the transmit strength in the compile settings, help to extend the battery life? 2. SCP-MAC - I think it might be tinyos 1.x-only - Not sure how well it will work alongside the CTP algorithm (radio turning off for a long time, means that CTP will have a lot of extra network traffic when motes radio come on again, wasting battery). (I've also considered a basic re-implementation: All motes sync their time over disseminate, and then turn off/on periodically (off 30 mins, on 2 mins, off again, etc) to share data and re-sync time. But this might be complicated, and waste a lot of battery due to extra CTP/disseminate network traffic to re-discover routes each time). 3. Custom network setup (small number of high-powered motes act as relays, with CTP) (basically, all the sensors just wake up, do a sensor reading, broadcast it to anyone listening, and then go back to sleep for another 30 mins. And then a 2nd type of mote with high power, listens for these values, and relays via collect back to the PC). - I'm concerned this might have a lot of dropped readings sometimes (nodes trying to relay too much data - eg: 10 sensors read by 5 relays in a short period, meaning 50 packets need to be sent over CTP to PC, overloading relay motes a bit). Will probably need to spend time finetuning and error checking (eg: each relay mote has a whitelist of sensor motes it will forward data for). 4. Tymo (point-to-point) Another possibility, is to have each relay mote store all the readings, and then the PC makes the basestation mote use Tymo algorithm to connect to each relay over mult-hop, and then pull all it's data, before going on to the next relay. (The difference to CTP is that we don't have a lot of relay motes using the network simultaneously, causing congestion/overload). - Not sure how well this will work (how well Tymo works with 2.x). Also the PC needs to know about all the relays, to cycle between them. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] TosThreads Thread.pause and Thread.resume not working
Hi
I am using the latest TInyos 2.x from Subersion, on a Shimmer (MSP430) mote.
I am experiencing unexpected behaviour using the Thread.pause() and
Thread,resume() functions when using TosThreads.
My understanding is that when Thread.pause() is called from within a thread it
should sleep, until another thread or event calls Thread.resume(). However, I
am finding that while Thread.pause() returns SUCCESS, the thread continues
executing.
When using condition a variable the thread waiting on the condition variable
sleeps until the condition variable is signalled.
I notice in tinyos-2.x/tos/lib/tosthreads/system/StaticThreadP.nc, which
provides the Thread interface, Thread.pause() calls
ThreadScheduler.stopThread(), whereas I would have expected it to call
ThreadScheduler.suspendCurrentThread() as is the case with the condition
variable implementation. Using the patch below makes Thread.pause() and
Thread.resume() function as expected.
Have I misinterpreted the way pause and resume should function? Does this fix
make sense?
Thanks
David
--
Index: StaticThreadP.nc
===
--- StaticThreadP.nc(revision 5307)
+++ StaticThreadP.nc(working copy)
@@ -73,11 +73,11 @@
}
command error_t Thread.pause[uint8_t id]() {
-return call ThreadScheduler.stopThread(id);
+return call ThreadScheduler.suspendCurrentThread();
}
command error_t Thread.resume[uint8_t id]() {
-return call ThreadScheduler.startThread(id);
+return call ThreadScheduler.wakeupThread(id);
}
command error_t Thread.stop[uint8_t id]() {
End Diff
--
The information in this e-mail may be confidential and subject to legal
professional privilege and/or copyright. National ICT Australia Limited accepts
no liability for any damage caused by this email or its attachments.
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Current mac protocol
Hi Kartik If you make an application for Telosb, or any other mote, under TinyOS, the MAC protocol used is the Berkeley's implementation, which is B-MAC. There is a lot of information on Internet, try at IEEE Xplore webpage for articles. Bye David Rodenas Herriz El 20/10/2010 22:03, Kartik Siddhabathula escribi: Hi Wasif, Seems you didn't get my question. I know where mac is in tinyos. I want to know what type of MAC is used by telosb motes? is it S-Mac, B-Mac or X-Mac? Where is the documentation for that? Thanks, Kartik --- On Wed, 10/20/10, wasif masood rwmas...@gmail.com wrote: From: wasif masood rwmas...@gmail.com Subject: Re: [Tinyos-help] Current mac protocol To: "Kartik Siddhabathula" siddhabathulakar...@yahoo.com Cc: "TinyoS help" tinyos-help@millennium.berkeley.edu Date: Wednesday, October 20, 2010, 2:58 PM its under tos/chips/cc2420 On Wed, Oct 20, 2010 at 8:44 PM, Kartik Siddhabathula siddhabathulakar...@yahoo.com wrote: Hi all, I would like to know what is the current mac protocol used by cc2420 radio chips. I read it our forum archives that it is a combination of B-Mac and X-Mac. I need a proper reference so that I can back up the claim. Does anyone have any idea where I can find the MAC protocol implementation of cc2420. Thanks, Kartik ___ 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] [Tinyos-devel] parametrized interfaces : an array of timers
On Wed, Sep 22, 2010 at 12:14 AM, Roger Larsson roger.lars...@ltu.se wrote:
So the fix is to add:
default command Timers.startPeriodic[int id](int interval) {
... complain/handle/ignore unexpected call ...
}
That this command has to be written feels wrong for three reasons...
1) compiler error does not even talk about the need for a 'default',
BlinkC.nc:51: Timers.startPeriodic not connected
even when being on the right track you easily run inte other compile
errors that won't help you toward the correct solution
Probably a good idea to add an explanation of the possible fixes
(either add a wiring or a default handler) on the first occurrence of
the error message.
2) has to be written
3) not in Timers.ncc (shouldn't all Timers.xx commands be in Timers.ncc?)
No - the Timer code has nothing to do with this, it's your code that
has to decide what to do when trying to invoke a non-existent timer.
More paranoid code than TinyOS typically contains might:
- log an error somewhere
- attempt some recovery action
- ...
All of the above depend on the caller, not the callee.
Note that it would of course be possible to write an analysis that
detected that in this particular program there's no need for a
default startPeriodic command. However that would be a bad idea (in
general at least), as:
- it makes BlinkC less of a standalone component (the missing
startPeriodic command will be needed for some wiring patterns)
But adding this to BlinkC.ncc gives the same problem, shouldn't really be
added to BlinkAppC.ncc
Or can the compiler handle several modules defining this function? (each with
its own unique count series?)
- this unique() / uniqueCount() stuff just don't feel right...
- it makes code's correctness quite dependent on exactly what analysis
is performed in the compiler to detect when default commands/events
are not required (should 'for (i = 0; i 2; i++) call
Timers.startPeriodic[i](...);' work too?)
A lot more likely code would be
for (int i=0; i uniqueCount(Timers); i++)
Timers.startPeriodic[i](...)
This pattern could be statically analysed and code generated. But if not
wouldn't the compiler need to put a dispatch handling somewhere?
Yes, as I said it could be analysed (2 or uniqueCount() would be
equally easily analysed FWIW). But I'm of the strong opinion that
making code correctness depend on fancy-ish analyses is a bad idea
(fancy analyses are great for optimization or bug-finding, but that's
a separate activity).
Why not in an automatically generated default function, calling something
like handle_..._error() in default case?
And let the user define this 'handle_..._error' function instead!
Because hiding potential errors is bad. And the default handler is
this handle...error function you want, on a per-module basis.
And finally: Why doesn't isn't the Blink example code use this feature in the
first place?
Because it doesn't expect to have its timers unwired (and would fail
if they were). Note that some components do have default handlers for
some interfaces, e.g. for optional callbacks (the module signals some
event, but it's ok if no-one cares).
David Gay
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Make quot; [program] Error 57quot; on uisp command
Hi everyone Has anyone been able to resolve the problem Make [program] error 57??? Thanks for your time and responses David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] HELP! How to send raw data to UART
Hello, I have the following network, using CTP: Node 03 Node 00 (Root) - PC Root node receives a message every 10 seconds from Node 03, and sends it to PC. The payload of the message is node ID(2B), seqNumber(2B), Data(8B) However, when using the java listen serial tool I get the following output (30 seconds): 00 FF FF 00 00 09 00 72 21 00 13 00 03 00 01 00 10 00 FF FF 00 00 0C 00 93 00 03 00 13 00 00 00 00 00 00 00 00 00 FF FF 00 00 09 00 72 21 00 14 00 03 00 01 00 11 00 FF FF 00 00 0C 00 93 00 03 00 14 00 00 00 00 00 00 00 00 00 FF FF 00 00 09 00 72 21 00 15 00 03 00 01 00 12 00 FF FF 00 00 0C 00 93 00 03 00 15 00 00 00 00 00 00 00 00 I only understand lines 2,4,6. which contain, in this order: 00 + Dest@ + Src@ + Length + GroupID + AMType + Payload Why 6 rows, shouldn't be 3 rows only? Where are the CTP and Serial Headers ? (Serial header should start with 7E right?) (My main objective is getting hops count from ctp header) Thanks in advance. I am really stuck in this... DG ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] How to send data from PC to mote using SerialForwarder
Hi I want to write a C++ program to send data from PC to a base station mote (app BaseStation) , and this one, send the data received to another mote. I have problems with the format packet I have to send (I connect to SerialForwarder and receive data). I have the following code (to do it, I used: http://www.tinyos.net/tinyos-2.x/doc/html/tep113.html): char lenmsg = 13; unsigned char buff[13]; int i = 0; buff[i++] = 0x7E; // Framing byte buff[i++] = 0x40; // Protocol byte: SerialP buff[i++] = 0x09; // Sequence number? buff[i++] = 0x00; // Packet format dispatch byte buff[i++] = 0xFF; // Message dest address buff[i++] = 0xFF; // Message dest address buff[i++] = 0x01; // Packet size buff[i++] = 0x00; // Group ID buff[i++] = 0x06; // Message Type //buff[i++] = 0x5D; // 0x06 isn't a scape, so I don't need it buff[i++] = 0x56; // Data buff[i++] = 0x00; // CRC ?? I don't know how to calculate CRC buff[i++] = 0x00; // CRC buff[i++] = 0x7E; // Framing byte */ send(fd, lenmsg, 1, 0); send(fd, (char*)buff, lenmsg, 0); I can see in the counter of packets written in the SerialForwarder (java version) that the packet is send, but it doesn't reach the basestation. I don't know if I'm using the right packet format to send data to SerialForwarder, because I thing the code above is for serial communication, not to SerialForwarder communication. I tested the following code (SerialAM message), but I had the same result: char lenmsg = 13; unsigned char buff[13]; int i = 0; buff[i++] = 0xFF; // Message dest address buff[i++] = 0xFF; // Message dest address buff[i++] = 0x01; // Packet size buff[i++] = 0x00; // Group ID buff[i++] = 0x06; // Message Type buff[i++] = 0x56; // Data send(fd, lenmsg, 1, 0); send(fd, (char*)buff, lenmsg, 0); Any suggestion? Thanks David _ Sé el protagonista de GQ con Messenger y Vodafone Blackberry. ¡Y gana premios! http://serviciosmoviles.es.msn.com/messenger/vodafone.aspx___ 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 send data from PC to mote using SerialForwarder
Thanks a lot, I solved it. I put my code here: _ char lenmsg = 9; unsigned char buff[9]; int i = 0; buff[i++] = 0x00; // syncByte buff[i++] = 0xFF; // Destination Address buff[i++] = 0xFF; // Destination Address buff[i++] = 0x00; // Link source address buff[i++] = 0x00; // Link source address buff[i++] = 0x01; // Message length buff[i++] = 0x00; // Group ID buff[i++] = 0x09; // Active Message handler type buff[i++] = 0x56; // Payload send(fd, lenmsg, 1, 0); send(fd, (char*)buff, lenmsg, 0); return 0; _ David Date: Tue, 29 Jun 2010 15:49:55 +0800 From: dodda...@comp.nus.edu.sg To: drod...@hotmail.com CC: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] How to send data from PC to mote using SerialForwarder Following is a detailed example that we used explain to undergrad students here. Sorry for being too detailed. 1) start sf at the desired port number, for ex., ./sf 9001 /dev/ttyUSB0 telosb 9001 - SF port number /dev/ttyUSB0 - device address telosb - you can use name of the mote to specify baudrate 2) Once you start SF at 9001, you can use a) sfsend to send commands to your mote: ./sfsend syncByte destination source length AMType PAYLOAD syncByte (1 byte): 0 destination (two bytes): 0 126 source (2 bytes): 0 0 length (1 byte): length of payload group (1 Byte): 0 AMType (1 byte): AM type of your message PAYLOAD: payload starts here b) You can use sflisten to see what your program dumps from the mote ./sflisten hostAddr sfPort e.x., ./sflisten 127.0.0.1 9001 Regards, Manjunath D Manjunath D *** On Tue, 29 Jun 2010, David Rodenas Herráiz wrote: Hi I want to write a C++ program to send data from PC to a base station mote (app BaseStation) , and this one, send the data received to another mote. I have problems with the format packet I have to send (I connect to SerialForwarder and receive data). I have the following code (to do it, I used: http://www.tinyos.net/tinyos-2.x/doc/html/tep113.html): char lenmsg = 13; unsigned char buff[13]; int i = 0; buff[i++] = 0x7E; // Framing byte buff[i++] = 0x40; // Protocol byte: SerialP buff[i++] = 0x09; // Sequence number? buff[i++] = 0x00; // Packet format dispatch byte buff[i++] = 0xFF; // Message dest address buff[i++] = 0xFF; // Message dest address buff[i++] = 0x01; // Packet size buff[i++] = 0x00; // Group ID buff[i++] = 0x06; // Message Type //buff[i++] = 0x5D; // 0x06 isn't a scape, so I don't need it buff[i++] = 0x56; // Data buff[i++] = 0x00; // CRC ?? I don't know how to calculate CRC buff[i++] = 0x00; // CRC buff[i++] = 0x7E; // Framing byte */ send(fd, lenmsg, 1, 0); send(fd, (char*)buff, lenmsg, 0); I can see in the counter of packets written in the SerialForwarder (java version) that the packet is send, but it doesn't reach the basestation. I don't know if I'm using the right packet format to send data to SerialForwarder, because I thing the code above is for serial communication, not to SerialForwarder communication. I tested the following code (SerialAM message), but I had the same result: char lenmsg = 13; unsigned char buff[13]; int i = 0; buff[i++] = 0xFF; // Message dest address buff[i++] = 0xFF; // Message dest address buff[i++] = 0x01; // Packet size buff[i++] = 0x00; // Group ID buff[i++] = 0x06; // Message Type buff[i++] = 0x56; // Data send(fd, lenmsg, 1, 0); send(fd, (char*)buff, lenmsg, 0); Any suggestion? Thanks David _ Sé el protagonista de GQ con Messenger y Vodafone Blackberry. ¡Y gana premios! http://serviciosmoviles.es.msn.com/messenger/vodafone.aspx
Re: [Tinyos-help] [Tinyos-devel] toolchain vs. nesc issue
I'll improve the error message... David Gay On Sun, Jun 13, 2010 at 11:37 PM, Jordi Soucheiron jsouchei...@dexmatech.com wrote: I found this kind of error several times when I was messing with the compiler options. It took me a while to realize where the error was. I agree that some work should be put into making this kind of errors less obscure. On the other hand I guess that only a few developers are experiencing this kind of problems (I don't really think that many people need to be playing with the compiler flags as we do). Jordi Soucheiron Software Engineer DEXMA Parc Tecnològic la Salle Sant Joan de la Salle, 42 08022 Barcelona t/f: [+34] 93 181 01 95 www.dexmatech.com jsouchei...@dexmatech.com 2010/6/13 Eric Decker cire...@gmail.com I'm working with TinyOS on various msp430 based cpus and various mspgcc toolchains. And have run into an interesting problem with nesc. I'd like to request that the error handling for this particular problem be changed so that the nature of the error is a little less obtuse. Baseline: I'm running the Zolertia tool chain which is a mspgcc 3.2.3 modified to support lots of new TI chips. The 2618 works, the 5438 doesn't. This tool chain supports the -mdata-64k and -mcode-64k toolchain switches to restrict code and data to 64K. The 2618 only has 8K of ram and the code base is currently around 32K so limiting to 64K has many advantages. Also until recently we were using threads and threads doesn't support the new chips (needs chip dependent code to handle bigger registers). The support/make/mm4.target file includes PFLAG += -mdata-64k -mcode-64k This works great. Recently, I've started working with Peter Bigot's mspgcc4 toolchain because it has good working support for the 5438 which we are in the process of transitioning to. Much better power consumption plus even more peripherals. Yum. However, the toolchain doesn't support -mdata-64k or -mcode-64k. And when I fire up a tinyos compile I get the following: make debug mm4 msp430-jtag -e build/mm4/main.exe BUILD: 22 mkdir -p build/mm4 compiling mmC to a mm4 binary ncc -o build/mm4/main.exe -O1 -g -fnesc-no-inline -DFAKE_SURFACE -DXWAIT -DDEFAULT_EAVES=TRUE -DGPS_TEST -DGPS_LEAVE_UP -DGPS_STAY_UP -DGPS_RO -DGPS_COMM_EMIT_29 -D_BUILD=22 -I/home/cire/mm/t2_mm/include -I/home/cire/mm/t2_mm/tos/platforms/mm4 -I/home/cire/mm/t2_mm/tos/platforms/mm -I/home/cire/mm/t2_mm/tos/system -I/home/cire/mm/t2_mm/tos/interfaces -mdisable-hwmul -mdata-64k -mcode-64k -fnesc-separator=__ -Wall -Wshadow -Wnesc-all -target=mm4 -fnesc-cfile=build/mm4/app.c -board= -DDEFINED_TOS_AM_GROUP=0x22 -DIDENT_APPNAME=\mmC\ -DIDENT_USERNAME=\cire\ -DIDENT_HOSTNAME=\zot\ -DIDENT_USERHASH=0x11dce1bdL -DIDENT_TIMESTAMP=0x4c149f53L -DIDENT_UIDHASH=0xcf776613L mmC.nc -lm nesc1: internal error: couldn't define builtin macros - exiting make: *** [exe0] Error 1 Now I know for sure that the above error is being caused by the -mdata-64k and -mcode-64k because when I remove them the compile works fine. And I'm getting much tighter code being generated. My build goes down from 33652 bytes to 26286 bytes. (This is unoptimized sizes). So my request is this Can you make the internal error be a bit more discriptive of what is going wrong? It isn't exactly clear what the connection is between internal macros and -m switches to the compiler are. Luckily I had an intuitive leap as to what was going on so was able to narrow it down. eric -- Eric B. Decker Senior (over 50 :-) Researcher ___ Tinyos-devel mailing list tinyos-de...@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] TinyOS - ZigBee Security?
Hello, I would just to know if the security protocol of Zigbee (encryption with AES-CTR, CBC, etc..) is already implemented in TinyOS? I read a lot of things about security in WSNs but i am seeing that there isn't a lot of things implemented. Thank you , D. -- David M. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] A TestNetwork app question
Hi, In TestNetworkAppC.nc configuration, why the following two lines use CL_TEST not AM_TESTNETWORKMSG as parameter? components new CollectionSendC(CL_TEST); components new SerialAMSenderC(CL_TEST); I thought AM_TESTNETWORKMSG was the real AM message type used in TestNetwork app. Did I miss anything here? -- Regards, - David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] help packet oscilloscope
The first 7 bytes are from TOS_Msg struct since you are including your
oscilloscope msg into the TOS_Msg data field.
uint16_t addr;
uint8_t type;
uint8_t group;
uint8_t length;
int8_t data[TOSH_DATA_LENGTH];
uint16_t crc;
You can see the TOS_Msg struct definition in AM.h file
Regards
David
De: tinyos-help-boun...@millennium.berkeley.edu
[mailto:tinyos-help-boun...@millennium.berkeley.edu] En nombre de Carlo Desogus
Enviado el: jueves, 06 de mayo de 2010 11:14
Para: tinyos help
Asunto: [Tinyos-help] help packet oscilloscope
Hi,
i`m working with oscilloscope application with ubuntu and tinyos 2.1.1.
I followed the 6th lesson of the tutorial but i don`t understand well the
packet format.
When i run Listen i get an packet format like this:
00 FF FF 00 01 1C 00 93 00 00 01 00 00 01 00 14 0F 55 1B 04 0F 55 1B 04 0F 59
1B 04 0F 56 1B 05 0F 55 1B 04
In the Oscilloscope.h the packet structure is:
typedef nx_struct oscilloscope {
nx_uint16_t version; /* Version of the interval. */
nx_uint16_t interval; /* Samping period. */
nx_uint16_t id; /* Mote id of sending mote. */
nx_uint16_t count; /* The readings are samples count * NREADINGS onwards */
nx_uint16_t readings[NREADINGS];
} oscilloscope_t;
So i thought that the packet could be of 2+2+2+2+2*10=28 byte.
But i see a packet with 36 bytes!!! Why??? What is my mistake??? What i`m
missing???
Can you let me see the beginning of the payload???
Thanks in advance.
Carlo
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] help packet oscilloscope
Sorry I meant the first 5 bytes :
2 bytes :Node address à 00 FF
1 byte : AM_TYPE à FF
1 byte: GROUP_IDà 00
1 byte: LENGTH à01
The last 2 bytes after data field should be CRC
De: tinyos-help-boun...@millennium.berkeley.edu
[mailto:tinyos-help-boun...@millennium.berkeley.edu] En nombre de David Conde
Enviado el: jueves, 06 de mayo de 2010 11:47
Para: 'Carlo Desogus'; 'tinyos help'
Asunto: Re: [Tinyos-help] help packet oscilloscope
The first 7 bytes are from TOS_Msg struct since you are including your
oscilloscope msg into the TOS_Msg data field.
uint16_t addr;
uint8_t type;
uint8_t group;
uint8_t length;
int8_t data[TOSH_DATA_LENGTH];
uint16_t crc;
You can see the TOS_Msg struct definition in AM.h file
Regards
David
De: tinyos-help-boun...@millennium.berkeley.edu
[mailto:tinyos-help-boun...@millennium.berkeley.edu] En nombre de Carlo Desogus
Enviado el: jueves, 06 de mayo de 2010 11:14
Para: tinyos help
Asunto: [Tinyos-help] help packet oscilloscope
Hi,
i`m working with oscilloscope application with ubuntu and tinyos 2.1.1.
I followed the 6th lesson of the tutorial but i don`t understand well the
packet format.
When i run Listen i get an packet format like this:
00 FF FF 00 01 1C 00 93 00 00 01 00 00 01 00 14 0F 55 1B 04 0F 55 1B 04 0F 59
1B 04 0F 56 1B 05 0F 55 1B 04
In the Oscilloscope.h the packet structure is:
typedef nx_struct oscilloscope {
nx_uint16_t version; /* Version of the interval. */
nx_uint16_t interval; /* Samping period. */
nx_uint16_t id; /* Mote id of sending mote. */
nx_uint16_t count; /* The readings are samples count * NREADINGS onwards */
nx_uint16_t readings[NREADINGS];
} oscilloscope_t;
So i thought that the packet could be of 2+2+2+2+2*10=28 byte.
But i see a packet with 36 bytes!!! Why??? What is my mistake??? What i`m
missing???
Can you let me see the beginning of the payload???
Thanks in advance.
Carlo
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Has anybody installed any Zigbee stack into Telosb motes?
Hi, I would like to know if it is possible to install Zigbee stack into Telosb motes. I have read that Z-Stack from Texas Instrument has a version for MSP430 and CC2420, has anybody tried it? Thank you in advance David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] TestNetwork app problem communicating with serial port
Hi, I am trying to print out more meaningful messages sent to serial port from a small network formed in TestNetwork app. So I created a java directory under TestNetwork and added a Makefile: Makefile BUILD_EXTRA_DEPS += TestNetwork.class CLEAN_EXTRA = *.class TestNetworkMsg.java TestNetwork.class: $(wildcard *.java) TestNetworkMsg.java javac *.java TestNetworkMsg.java: mig java -target=null -java-classname=TestNetworkMsg ../TestNetwork.h TestNetworkMsg -o $@ - The make cmd ran ok and it generated TestNetworkMsg.java. Following the Mote-PC serial communication tutorial, I launched MsgReader as following: java net.tinyos.tools.MsgReader TestNetworkMsg -comm serial@ /dev/ttyUSB1:iris serial@/dev/ttyUSB1:57600: resynchronising That's it! I didn't see any more messages coming out of this unlike what's expected in the tutorial. But I can see the raw output just by using java net.tinyos.tools.Listen -comm serial@/dev/ttyUSB1:iris. Anything wrong with this? Thanks. -- Regards, - David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] TestNetwork app: How to use dissemination?
Hi, I was able to run CTP using TestNetwork. The README also mentions that dissemination can be used. I 'd like to send small values from the host PC (attached to the root mote) to all other motes in the network. README file doesn't specify how to do this. Can anyone show me an example or a pointer to any docs? -- Regards, - David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP in TestNetwork questions
Hi Om_p: So is there another application that can perform both CTP and Dissemination functions? - David On Sat, May 1, 2010 at 3:31 PM, Omprakash Gnawali gnaw...@cs.stanford.eduwrote: On Sun, Apr 25, 2010 at 12:09 PM, David Li w.david...@gmail.com wrote: Hi Omprakash, Another question: The README seems to indicate that I can issue a cmd from the host to all motes in the network. But I haven't found out how to do that yet. Can you explain a little bit? No, you can't do that anymore. I need to update the README and clean up the directory. - om_p -- Regards, - David ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] *****SPAM***** Re: Getting bad packet from InternalVoltage measures in Telosb
Hi, I agree with you, I saw in TMote datasheet that minimum voltage level for TelosB working right is 2,1 Volts, in fact, everything works right except InternalVoltage measures, why is this? Does the InternalVoltage measures need higher level of battery to performance this operation? Is it because the Internal Voltage is got from the MSP430? What is the real lowest voltage level (got from practical experience) that you have found when you work with Telosb? Thank you in advance -Mensaje original- De: André Rodrigues [mailto:andremiguelrodrig...@gmail.com] Enviado el: martes, 27 de abril de 2010 20:35 Para: Michael Schippling; David Conde CC: tinyos-help@millennium.berkeley.edu Asunto: *SPAM* Re: [Tinyos-help] Getting bad packet from InternalVoltage measures in Telosb Spam detection software, running on the system produccion.citic.es, has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi The MSP datasheet says that but on the other way the TMoteSky datasheet claims 2.1 as the mininum for running at 8MHz. Something is wrong... [...] Content analysis details: (4.2 points, 4.0 required) pts rule name description -- -- 0.0 STOX_REPLY_TYPESTOX_REPLY_TYPE 1.1 DNS_FROM_OPENWHOIS RBL: Envelope sender listed in bl.open-whois.org. -0.0 SPF_PASS SPF: sender matches SPF record 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] 3.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Getting bad packet from InternalVoltage measures in Telosb
Hi, I am getting measures from InternalVoltage in TelosB and when the battery level is lower than 2,6 I got bad packet from a address 4502 or 0125, have anybody had the same problem? Thank you in advance ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] reading sensors
Take a look to Oscilloscope application. Regards De: tinyos-help-boun...@millennium.berkeley.edu [mailto:tinyos-help-boun...@millennium.berkeley.edu] En nombre de Carlo Desogus Enviado el: lunes, 26 de abril de 2010 18:16 Para: tinyos-help@millennium.berkeley.edu Asunto: [Tinyos-help] reading sensors I`m reading your Sampler applications because i should work with several sensors (light, temperature, humidity...). Did you also develop a java application to show the data received?? Thanks CD ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
