There are drivers for the cc1100 chip in the tinyos-2.x contribs under
tinyos-2.x-contrib/blaze/tos/chips/blazeradio
Kevin
On Oct 31, 2007 12:25 AM, jiwen zhang [EMAIL PROTECTED] wrote:
Hello:
I designed a mote and the hardware are Atmega128L and cc1100 .but tinyos
doesn't support a mote
Hello:
I designed a mote and the hardware are Atmega128L and cc1100 .but tinyos
doesn't support a mote with cc1100, so i have to write the bottom codes to
support my platform .Now I really don't know how to do .Can you give me some
advice. Thank you very much.
I find a Key word Blaze radio
Hi there,
recently I started implementing a localization protocol on Tmote Sky
motes using TinyOS 2. The communication during the protocol must be
secured. Namely I need encryption and message signing. I guess TinySec
would do a good job, but TinyOS 2 doesn't seem to support it, is that
Hi,
I'm working on porting TinyOS to jennic since 3 months, It's my Master Thesis.
so if you are doing the same, why we don't join our forces ?
Thanks.
Mejda CHOUAIEB
Network Telecommunication Engineer.
Master Student.
Research Area: Wireless Sensor Networks.
- Message d'origine
De :
Hello.
I'm a telecommunications engineering degree student from Barcelona (Spain).
I'm working with tinyos-2.x under Linux. I have a question executing the
RssiToSerial application. As you would can know, RssiToSerial shows by console
strings like the following:
Hi,
I have libc installed for ba-elf because I have
C:\jennic\cygwin\ba-elf\ba-elf\lib\libc.a
but I want to understand what is this cc1 ?
- Message d'origine
De : Kevin Klues [EMAIL PROTECTED]
À : mejda chouaieb [EMAIL PROTECTED]
Cc : tinyos-help@millennium.berkeley.edu
Envoyé le :
Will/Should the second send initiate a second preamble within LPL or
will/should LPL decide to send the message straight away (can't really use
the ACK'd LPL as a number of the messages are basically broadcast so if I
ACK then I run the risk of only the node that ACK'd receiving properly if
the
Hello,
During the development of a signal generator code on a Tmote Mini, I am
experiencing some problems with the settings for the DAC, DMA and Timer
components. I used the file TestDAC12DMAM.nc as an example to create my own
code to output a selection of different frequencies to the DAC
Hello,
Sorry for the previous incomplete subject name, but here is my question
again. During the development of a signal generator code on a Tmote Mini, I
am experiencing some problems with the settings for the DAC, DMA and Timer
components. I used the file TestDAC12DMAM.nc as an example to
On Oct 30, 2007, at 10:49 PM, Kevin Klues wrote:
Sorry, you're right, atmeaga128 is little endian as well. The reason
the network types (or more appropriate -- platform independent types)
are needed is because the msp430 expects all tw-byte variables to be
word aligned (can only start at even
I'm working in TinyOS2. I have a set of clients and one poller.
The poller mote receives the client replies in the same time window.
I used the queuing tecnique found in the BaseStation Example, but it
isn't enought efficient.
Is there another way to solve this problem?
I appreciate any advice.
Hello
I'm working in TinyOS2. I have a set of clients and one poller.
The poller mote receives the client replies in the same time window.
I used the queuing tecnique found in the BaseStation Example, but it
isn't enought efficient.
Is there another way to solve this problem?
I appreciate any
Hi all.
The issues is the 16-bit timestamp in the received packet somethimes
results incorrect, in that case the time result always less than what
I aspect.
Probably the the timestamp refers to the previous SFD signal.
I tried to compare that timestmap against the time argument of the
In TinyOS 2.0.1 the Ack LPL version should not stop sending its wake-up
transmission to the broadcast address, ensuring all nodes in the vicinity
receive the broadcast packet. The LPL layer, when sending to the broadcast
address, disables acknowledgement requests and shouldn't even check
Hi All,
I'm compliling my modified nc fileIntToLedsM while I'm getting warnings
as Send.sendDone called asynchronously. In fact I got three such kind of
warnings though with different calling functions fSendAborted,
immedPacketSent,and also Receive.receive called asynchronously from
Hi Federico,
I met the same problem. I've written a time synchronization component
for TinyOS 2.x. Currently some (very few) synchronization messages are
discarded because of the error of metadata-time (earlier than
expected).
Hope some one can point out the reason.
Regards,
Min
On 10/31/07,
I suppose you could get around this manually for now by using LPL's
setRxSleepInterval(0) just before transmitting the 2nd packet i.e. control
the preamble/packetised wake-up for successive tranmissions externally to
LPL. For no_ACK LPL:
setRxSleepInterval(500)
send pkt 1
[wait for senddone]
On Oct 31, 2007, at 10:27 AM, Michael Schippling wrote:
So...basically EVERY platform we are dealing with is little-endian,
-- unless you are still running on a 68K (Mac?) of some kind -- but we
force the network types to be big-end just to increase the processing
requirements?
Hey -- I'm
2 edge cases:
1) A packet is received, generating a timestamp. The packet is dropped
internally to CC2420 hardware, while a second packet is received which
generates a second timestamp. The older timestamp is applied to the newer
packet.
2) A corrupted packet is received, forcing the
So...basically EVERY platform we are dealing with is little-endian,
-- unless you are still running on a 68K (Mac?) of some kind -- but we
force the network types to be big-end just to increase the processing
requirements?
And the full extent of the doc on this is in the T2WG message that
Given that you are getting an exec() error, cc1 is probably a pre-processor
pass for the C compiler. There may be some components of your compiler that
are not installed. I'd go look for a manifest of what's supposed to be in
your compiler package. It could also be a 'standard' gcc component that
It was these two members that started me down this garden path
and I wondered about:
uint16_t destpan;
uint16_t addr;
I don't know the significance of destpan, but I presume the addr
(destination mote ID) is solely for the benefit of the software and
can be any-agreed-upon-ended. Good point
CtpInfo.getEtx() was returning 0 because of a bug. It was returning
the ETX from the current parent to the root. Your network was probably
a single hop network so all the nodes had the root as their
parent. Etx from the root would be 0 so it was returning 0.
I have fixed this so that it returns
Try [EMAIL PROTECTED]:tmote for your MOTECOM, I believe it will
select some special parsing for tmote messages. At least it let
me receive Delta msgs with Listen.
You'll have to go look at the Delta message structure to see which
bytes are of interest, I don't know offhand.
As to the 3000
I understand now the ADC count, thank to you. I tried [EMAIL PROTECTED]:tmote
and
I do get cleaner messages of the following structure
08 00 00 00 00 00 7E 00 65 7D 00 00 01 00 00 00 00 00
08 00 00 00 00 00 7E 00 65 7D 00 00 01 00 00 00 00 00
08 00 00 00 00 00 7E 00 65 7D 00 00 01 00 00 00 00 00
I logged this packet that is going to Trawler from Delta and I obtained the
following
1193897839449 Message MultiHopMsg
[sourceaddr=0x1]
[originaddr=0x1]
[seqno=0x6d8]
[originseqno=0x6d8]
[ttl=0x0]
[id=0x21]
[data=0xde 0x5 0x0 0x0 0xa7 0xb 0x7e 0x0 0x3 0x0 0x7e 0x0 0xff 0xff 0xff
Hi,
I am also new bye to TinyOs and I would also like to port TinyOs on my own
platform but couldnt get from where to start.
Can you suggest from where I have to begin for porting it on any new
environment.
I think that make rules file and the different platforms and interfaces in
the
In response to both of your recent messages
There should be no difference between Listen results and display results,
if one changes the other should as well. So I can't explain why you don't
see any new data in the Listen output...
However the Listen output doesn't match the log output you
28 matches
Mail list logo
