Nahr,
This is how the radio chip works, and not the TinyOS implementation. This
is how the radio decides if it received a 0 or a 1. TinyOS can only access
the final result, not the actual value used for the soft decision.
- Thomas
On Wed, Sep 9, 2015 at 5:43 AM, Nahr Elk wrote:
> Hello,
>
> B
Hello,
Based on a previous discussion: Dr Levis said that CC2420 uses a soft chip
decision. It calculates the closeness of each chip to 0 and 1 and then
chooses the symbol sequence which is closest to the soft chip decisions.
Please where this is implemented in TinyOS.
Thank you
--
Nahr Elk
___
Dear all
How to implement Frequency hopping on CC2420 radio chip ?
Thank you
Hamza
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
http://www.avast.com
___
Tinyos-help mailing list
Tinyos-h
And encryption worked again?
--Antonio
On Tue, Dec 10, 2013 at 2:32 PM, Łukasz Szubart
<184...@student.pwr.wroc.pl>wrote:
> I'm writing my engineering thesis about cc2420 AES encryption. I found
> that there is a problem in tos 2.1.2. Neither CC2420SecurityTest nor
> tutorial program fromhttp:/
I'm writing my engineering thesis about cc2420 AES encryption. I found
that there is a problem in tos 2.1.2. Neither CC2420SecurityTest nor
tutorial program
fromhttp://tinyos.stanford.edu/tinyos-wiki/index.php/CC2420_Security_Tutorial
works properly.
In CC2420SecurityTest even if i changed encryp
than the sender, the result is also plain
text.
-Mensaje original-
De: tinyos-help-boun...@millennium.berkeley.edu
[mailto:tinyos-help-boun...@millennium.berkeley.edu] En nombre de Bipin
Enviado el: miércoles, 06 de noviembre de 2013 10:56
Para: tinyos-help@millennium.berkeley.edu
Asunto: R
You are done that succesfully. i just done the same TestSecurity
in my motebut i cant even receive the the encrypted data in the
my Basestation... not even single packet. i dont know... y...?
--
View this message in context:
http://tinyos-help.10906.n7.nab
Hello,
I've installed RadioCountToLeds in a z1 mote to test cc2420 security but when I
try to get the message value with baseStation installed in other mote, I only
get the plain text I'm sending, not encrypted.
The code is the same it's on
https://github.com/tinyos/tinyos-main/tree/master/apps
Hello,
I've installed RadioCountToLeds in a z1 mote to test cc2420 security but when I
try to get the message value with baseStation installed in other mote, I only
get the plain text I'm sending, not encrypted.
The code is the same it's on
https://github.com/tinyos/tinyos-main/tree/master/apps
Dear all (Eric, Thomas, Wasif, Srikanth),
thanks for your input (I was on vacation so here comes my late reply).
> you need a sniffer
>
> trying to do this by getting somekind of tell tale from the code is very
> difficult.
>
> you need to instrument the network.
Yes, but that's really what I w
Christian:
We have had good luck with the
ATAVRRZUSBSTICK-ND
USB stick from Digikey, and viewing the 802.15.4 packets with
Wireshark. The instructions at
http://www.newae.com/tiki-index.php?page=RavenUSBProgramming
are helpful in programming the device.
Brad Nickerson
cs.unb.ca/~bgn
On 1
you need a sniffer
trying to do this by getting somekind of tell tale from the code is very
difficult.
you need to instrument the network.
On Thu, Sep 12, 2013 at 2:55 PM, Srikanth Nori wrote:
> Hi Christian,
>
> In my experience at least, tracking down problems with ACKs has been
> phenomen
Hi Christian,
In my experience at least, tracking down problems with ACKs has been
phenomenally difficult. I have no direct advice but a couple of
suggestions:
On Fri, Aug 30, 2013 at 10:10 AM, Christian Renner
wrote:
>
> We have 3 nodes: one receiver R and two senders A and B. Software ACKs
> a
Dear all,
I'm currently working on implementing the Orinoco routing protocol
(which is based on RI-MAC) for the TelosB/Tmote platform. Things work
fine with one exception: packets get lost due to the following, strange
behavior (I won't go into protocol details but just explain what happens):
Are you using your own ack frames or the defaulf 802.15.4 ack frames
because as far as I know there is no dest field in the ack frame of
802.15.4, so there are possibilities of messing up with acks. See the data
sheet of CC2420 for more details and CTP neo paper from Omparkash, this
problem has bee
Christian,
Try to use the cc2420x driver and see if the problem persists.
On Sep 3, 2013 6:03 AM, "Christian Renner" wrote:
>
> Dear all,
>
> I'm currently working on implementing the Orinoco routing protocol
> (which is based on RI-MAC) for the TelosB/Tmote platform. Things work
> fine with one
Dear all,
I'm currently working on implementing the Orinoco routing protocol
(which is based on RI-MAC) for the TelosB/Tmote platform. Things work
fine with one exception: packets get lost due to the following, strange
behavior (I won't go into protocol details but just explain what happens):
Hi Wasif,
The cc2420x stack should be straightforward to set up with the z1.
Just follow how it's set up on the telos.
One thing it needs is a fast SPI bit rate. My suspicion is that the
SPI on the z1 is configured with 256 or 512 kbps bit rate, though I
can't confirm this. You might want to take
Wasif:
Regarding setting the backoff values to 1us in the cc2420x stack: this
clearly doesn't work, because the code would schedule an alarm 1us in the
future, which is simply not possible. By the time the operation of
scheduling the alarm completes, that time instant is going to be in the
past, a
thanks Miklos, that is convenient!
On Thu, Jan 10, 2013 at 10:23 AM, Miklos Maroti wrote:
> Hi Wasif,
>
> On Thu, Jan 10, 2013 at 10:05 AM, wasif masood wrote:
> >
> > Thanks Janos, now these stacks seem to have some relevance, see the
> > histograms below:
> >
> > http://s7.postimage.org/3oh7d6
Hi Wasif,
On Thu, Jan 10, 2013 at 10:05 AM, wasif masood wrote:
>
> Thanks Janos, now these stacks seem to have some relevance, see the
> histograms below:
>
> http://s7.postimage.org/3oh7d6gln/cc2420.png
>
> http://s9.postimage.org/qswev86xr/cc2420x.png
>
>
> Miklos,
>
> Thanks for the reply but
Thanks Janos, now these stacks seem to have some relevance, see the
histograms below:
http://s7.postimage.org/3oh7d6gln/cc2420.png
http://s9.postimage.org/qswev86xr/cc2420x.png
Miklos,
Thanks for the reply but I was referring to timestamping accuracy in
Ucmini, so the question was does ucmini
Hi Wasif!
Ucmini uses the atmega128rfa1 chip (and not the cc2420) and it is
fully supported in tinyos, just type "make ucmini".
Miklos
On Wed, Jan 9, 2013 at 11:55 AM, wasif masood wrote:
>
> Thanks alot Janos! it seems to work now, it was a clumsy mistake on my side.
> Another Questions, make
Thanks alot Janos! it seems to work now, it was a clumsy mistake on my
side. Another Questions, make z1 CC2420x doesn't work. Do u ever have any
experience with that! and also neither for UCMINI.
Regards,
Wasif!
On Wed, Jan 9, 2013 at 4:25 PM, Janos Sallai wrote:
> Wasif:
>
> Regarding setting
Hi all,
I am trying to measure the message delay on Telosb platform and now
comparing the CC2420 stack with CC2420X stack. Below are the two Histograms
showing the delay spread of Cc2420 and CC2420X stacks respectively. The
experiment is perfromed for around 1 hr at the same time using two
differe
You don't specify what hardware you are using. But it is clear from your
context below that you are using the cc2420 so I'm assuming a telosb. But
the pertinent part is the 2420 anyway.
It is my understanding of the cc2420 h/w at least in normal mode, that
there is a maximum packet size of 128
Hi there,
I am working on situation where there are two sensor nodes (sender and
receiver). when a receiver receive a particular msg from sender, it should
transmit it for particular time (say 2 mins) and should not release the
medium before finishing its task. Now problem arises that receiver
suc
Hello everyone,
The cc2420 data sheet states its RSSI accuracy is -6 to +6 dBm. Does the
range represent, e.g. the 95% confidence interval obtained during hardware
test, or the standard deviation? I am really interested in finding out what
it really represents.
Thanks very much and any input woul
Hi
We try to use splitcontrol to control the cc2420 turn on/off.
But we met some problem when turn on.
The process is we set and the node also ack like we set ex Leds.
Except sendMsg, we cannot send any message but can receive.
Is any idea about this?
Ps: we have tried just
On Wed, Apr 18, 2012 at 10:09 AM, Omar Hassan wrote:
> hi there,
>
> I am using tinyos 2.1.0, and Telosb motes, I want to set DACTST and TOPTST
> registers, but I cannot find them in CC2420SpiC.
>
Access to those registers isn't provided as currently defined. The
interface provided as defined r
hi there,
I am using tinyos 2.1.0, and Telosb motes, I want to set DACTST and TOPTST
registers, but I cannot find them in CC2420SpiC.
Can anyone help me?
Regards,
Omar Mohammad
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://ww
Hi All,
Recently I have went through the nesC code of CC2420 driver of TinyOS. Here
is a problem, what is the default value of "maxRetries" in CC2420?
I read TEP 126 (CC2420 Radio Stack) and the source code and know
PacketLinkC is responsible for retransmission. But I don't know where this
"maxR
Hi all,
I am doing some experiments on jamming packets using CC2420 motes (TinyOS
2.1.0),
I am using a coordinator node to sync the sender and the jammer.
I disabled CSMA, and I am able now to receive corrupted packets.
The experiments results are not satisfying, the corrupted packets numbers
a
Hi Sean,
The receiver must know in advance the radio frequency over which radio
transmissions will take place. Otherwise, you can implement a channel
scanning routine at the receiver, or leave the receiver's frequency
fixed, and have the transmitter send 'hello' packets sequentially on
each ch
Hi fellows,
I'm doing some tests using tinyos 2.1.0 on telosb mote which uses CC2420
chip.
We can set the radio frequency (on 16 channels) before a mote transmitting
packets by adding in the Makefile:
CFLAGS += -DCC2420_DEF_CHANNEL=11
So is there any way that we can get the transmitting radio fr
ahh exactly, sorry couldn't get it first. yes in that case you are right.
Personally, in one of my cases, I myself built an exponential backoff
strateggy in which the backoff timer expires after the transmission window
exceeds the backoff period. Regarding the random backoff strategy, I guess
it is
Hi,
> I think the retry attempts are counted if you include the PACKET_LINK
> directive in your make file. have a look at the CC2420ActiveMessageC and
> CC2420PacketP. As far as I remember, in case you dont include this
> directive, MAC does not account for retry attempts.
No. The packet link lay
I think the retry attempts are counted if you include the PACKET_LINK
directive in your make file. have a look at the CC2420ActiveMessageC and
CC2420PacketP. As far as I remember, in case you dont include this
directive, MAC does not account for retry attempts.
On Thu, Sep 8, 2011 at 12:19 PM, Da
Hi,
> So far I have found that any discarding cannot happen (retries are
> endless) from the code I found in $TOSROOT/tos/chips/cc2420; perhaps,
> the only way such thing can happen is in the event that the user
> himself cancels the attempts to send.
After a quick look into the code I would conf
Hello,
I'm trying to find out if CC2420 radio stack implementation for micaZ does
actually discard packets if the channel is found to be busy a certain number of
times like other MAC protocols do. So far I have found that any discarding
cannot happen (retries are endless) from the code I found
the RSSI of a packet is stored in its metadata once it is received. You
can use the CC2420Packet.getRSSI() to get the RSSI value of a packet
(which is an indicator for the signal power at which that packet was
received). The Tx power of the packet has to be sent by you in the payload
of the packet
Hi All,
I wish to embed the tx_power and rssi value in the metadata part of a packet
to be sent. Can I know how I can do that? What components/interface to use?
Please help me.
Many thanks in advance.
Yusnaidi
___
Tinyos-help mailing list
Tinyos-help@
On May 10, 2011, at 1:49 AM, Viktor Zsoldos wrote:
> - I've installed the BaseStation from apps/tests/cc2420/TestSecurity, and
> trying to read the secured traffic with net.tinyos.tools.Listen, but only
> ordinary headers are showing (dst, src, len, gID, hID), I can't see any
> CC2420 or securit
Hi,
I'm trying to use the CC2420 security features
(http://docs.tinyos.net/index.php/CC2420_Security_Tutorial), and have some
questions.
- I've installed the BaseStation from apps/tests/cc2420/TestSecurity, and
trying to read the secured traffic with net.tinyos.tools.Listen, but only
ordinary
I need some lower level testing programs. Like, to test the GPIO pins. To
check if the interrupt pins are working correctly. If the TXFIFO load
succeeded or not? etc.
For example, like this
http://docs.tinyos.net/index.php/Platform_Creation_and_Testing
> The first program I would check is RadioCo
The first program I would check is RadioCountToLeds :)
-John
On Apr 20, 2011, at 1:50 PM, Prasanna Karthik V wrote:
> hi all,
>I need pointers to some testing programs that would help me in test
> the working of a CC2420 radio.
>
> I have soldered some pins of the MCU to a CC2420 module. No
hi all,
I need pointers to some testing programs that would help me in test
the working of a CC2420 radio.
I have soldered some pins of the MCU to a CC2420 module. Now i want to
know if the connections i made are correct or not.
___
Tinyos-help mail
Hi Peter,
I see. If you have access to an ZigBit 900 module, then that uses the
RF212 chip where you can enable the test modes digitally. (By the way,
I thought that the RF230 also has some digital way to enable the test
mode, also wrote to Atmel about it, but I did not get a straight
answer. I ha
Hello Miklos,
Now I am sure that we can not use the TST Pin because it is not
connected to the microcontroller!!!
So what I did,
I looked at the Internet sources you mentioned. In the
mikrocontroller.net link I found an additional link
http://www.mikrocontroller.net/articles/Meshnetics_Zigbee
w
Hi Peter!
Look at these:
http://ratatanek.cz/blog/zigbit-atzb-24-a2-pinout
http://www.mikrocontroller.net/topic/84931
http://www.meshnetics.com/netcat_files/Image/M-251~06-(ZigBit%20900%20OEM%20Module%20Product%20Datasheet).pdf
None of these mentions the TST pin, so probably it is not connected.
Hello Miklos,
thanks for your answer. I checked the following documents for the ZigBit
Amp to find out, if the TST pin from RF230 is connected to the
microcontroller:
http://www.meshnetics.com/netcat_files/Image/P-MBPN-461~01-(WDB-A1281-PN
%20Schematics).pdf
and
http://www.adaptivemodules.com/
Hi Peter,
You definitely need the TEST pin of the RF230 connected to the
microcontroller, otherwise you cannot give out a unmodulated signal
with the RF230. That pin is NOT connected on the IRIS and most
probably it is not connected for the ZigBit module either. With the
RF212 it is possible to se
Hello everyone,
I have seen a lot of question about implementing the unmodulated carrier
on CC2420 in the TinyOS mailing list. Unfortunately, most of the
questions did not receive any answer.
In order to measure the output power of different platforms (using SMA
connector and a spectrum analyzer),
I did some test lately as well. I checked rather influence of layers on
transmission speed and I used 32kHz timer too, but now I am interested in
more precise time testing, ie. CPU cycles. However it's hard for me to go
deep into TinyOs to get the lowest layer - very close to physical.
I gave up an
hi,
I did some measurements recently. I quantified the time taken by the
different components. Here are my results:
before Amsend.send() statement 64420
Send.send() 64426
send() 64427
AcquireSpiresource() 64431
before loadtxfifo() statement 64432
Loadtxfifo() 64433
before TXFIFO.write() stateme
Hi,
I think software processing also need time. In CC2420TransmitP.nc, before
transmission, TX data has to be loaded from ram to CC2420 through SPI bus,
I think it's a time-consuming operation.
What's more, you can turned off radio backoff (through RadioBackoff
interface provided by CC2420Active
Hi
Does it happen in every packet transmission?
If no, maybe some packets are retransmitted by PacketLink Layer?
2011/3/28 蔡沅峰
> Dear all,
>
>
> We have a high-data-rate application and we need to decrease the
> transmission delay (between send.send and send.sendDone).
>
> The payload of our pa
Dear all,
We have a high-data-rate application and we need to decrease the transmission
delay (between send.send and send.sendDone).
The payload of our packet is 80 bytes. ( Total packet size is about 100 bytes
in
Tinyos )
We've adjusted the initial backoff time defined in CC2420csmaP.nc to
Philip Levis :
>
> On Mar 17, 2011, at 3:26 AM, tja...@mail.tu-berlin.de wrote:
>
>> Hello,
>> I think I have found a bug in the cc2420 stack concerning the
>> transmission power of the acknowledgements. Maybe someone can verify
>> it? I don?t know who is responsible for the stack at the moment. I
On Mar 17, 2011, at 3:26 AM, tja...@mail.tu-berlin.de wrote:
> Hello,
> I think I have found a bug in the cc2420 stack concerning the
> transmission power of the acknowledgements. Maybe someone can verify
> it? I don?t know who is responsible for the stack at the moment. Is it
> still David
Hi
just you are putting the value of the transmission power as 1, in CC2420
data sheet (Table 9) there is no value 1, and 3 is for -25 dBm. so, may be
the radio doesn't recognize the value and set it for the default value 31.
I didn't check for value 1. So, check other values if you can
Yasser Z
By Philip Levis :
> On Mar 17, 2011, at 3:26 AM, tja...@mail.tu-berlin.de wrote:
>
>> Hello,
>> I think I have found a bug in the cc2420 stack concerning the
>> transmission power of the acknowledgements. Maybe someone can verify
>> it? I don?t know who is responsible for the stack at the moment.
On Mar 17, 2011, at 3:26 AM, tja...@mail.tu-berlin.de wrote:
> Hello,
> I think I have found a bug in the cc2420 stack concerning the
> transmission power of the acknowledgements. Maybe someone can verify
> it? I don?t know who is responsible for the stack at the moment. Is it
> still David?
Hello,
I think I have found a bug in the cc2420 stack concerning the
transmission power of the acknowledgements. Maybe someone can verify
it? I don?t know who is responsible for the stack at the moment. Is it
still David?
I am using the svn revision 5304 on the cc2420 folder.
In my setup a t
Hi all,
I came across a paper titled "Approaching the Maximun 802.15.4 Multi-hop
Throughput", in which they discuss about the bottlenecks in achieving high
throughput and packet copying being one of the major factors contributing
to this issue.
They have used Tmote sky and Contiki OS in their exp
[nel...@cmc.ca]
Skickat: den 8 november 2010 15:01
Till: Stephen Dawson-Haggerty
Kopia: tinyos-help@millennium.berkeley.edu
Ämne: Re: [Tinyos-help] CC2420: length field in 802.15.4 header is used without
initialisation, fcf field not set in any case
Hi Stephen
Yes, the problems are fixed in revision 5215.
: [Tinyos-help] CC2420: length field in 802.15.4 header is used
without initialisation, fcf field not set in any case
Yes, you are correct. Thanks for suggesting the changes -- can you
check out 5215 and verify that this fixes the problem?
Thanks,
Steve
On Thu, Nov 4, 2010 at 9:34 PM, Silvan Nellen
Yes, you are correct. Thanks for suggesting the changes -- can you
check out 5215 and verify that this fixes the problem?
Thanks,
Steve
On Thu, Nov 4, 2010 at 9:34 PM, Silvan Nellen wrote:
> Hello,
>
>
>
> I have two issues regarding revision 5214 (the newest at the time of
> writing) of the tr
Hello,
I have two issues regarding revision 5214 (the newest at the time of writing)
of the trunk (https://tinyos-main.googlecode.com/svn/trunk):
1.
After updating from revision 5160 to 5214, Zigbee communication stopped working
on Shimmer. Using a Zigbee packet sniffer I found out that all upd
Hello.
The datasheet of cc2420 states the sensitivity threshold is -94dBm. But when
doing noise floor listening (for example the RssiToSerial application under
apps/test/cc2420) the reading is usually around -110. So are these readings
valid?
Many thanks.
Regards,
Peng
_
Hi all,
I wrote an application based on UDPEcho for Micaz (tinyos-2.1.1 blip)
and I'm using the default LPL so far.
cc2420 works fine and has an active period about 8msec when no packet
is on the radio.
I modified the application in order to read ADC0 and ADC1. If I read
more than one ADC c
It seems to be the only difference!
I only have another task that call the UDP send (I removed all the
others debugging).
I slightly modified IPDispatchP in order to provide the InfoLowLayer
interface and signal the event.
Only "task info()" and event "InfoLowLayer.infolowlayer" have access
Hi all,
I'm using the default Low Power Listening from the Blip stack
(tinyos-2.1.1) and I've measured the CC2420 active period while it
senses the channel and no signal is in the air.
According with my osciloscope, the cc2420 reads the CCA pin for
approximately 6 msec if there is no signa
Hi all,
I'm using the default Low Power Listening from the Blip stack
(tinyos-2.1.1) and I've measured the CC2420 active period while it
senses the channel and no signal is in the air.
According with my osciloscope, the cc2420 reads the CCA pin for
approximately 6 msec if there is no signal
Hi all,
I'm using the default Low Power Listening from the Blip stack
(tinyos-2.1.1) and I've measured the CC2420 active period while it
senses the channel and no signal is in the air.
According with my osciloscope, the cc2420 reads the CCA pin for
approximately 6 msec if there is no signal
Hi Janos,
I have also used AlarmHybridMicro32C component to get "pulse" values. As you
said I have saved all alarm fire events at pulse variable and sent it
through
TimeSyncAMSend.send(...) . However, again I always get hude clock drifts and
cannot estimate relative hw clock rate of the reference
Hi Janos,
I haven't compiled your test application yet but I have developed a sample
application and I have only used your msp430 library /tinyos-2.x-
contrib/vu/tos/chips/msp430 for my application.
Let me explain how the application works:
I have used 3 nodes. One of the nodes (reference node)
Sinan,
> I achieved 0x50 microsecond periodicity by such a way:
>
> - I set a milli timer of (of 0x1400 milliseconds)
> - I store the local time at the first fire ıf the timer at a variable called
> "pulse"
> - At each timeout of the timer, I add 0x50 to the "pulse" variable
> - And I give
Hi Janos,
I achieved 0x50 microsecond periodicity by such a way:
- I set a milli timer of (of 0x1400 milliseconds)
- I store the local time at the first fire ıf the timer at a variable called
"pulse"
- At each timeout of the timer, I add 0x50 to the "pulse" variable
- And I give "pulse" a
Hi Sinan,
> I have used 3 nodes. One of the nodes (reference node) broadcast a packet
> using TimeSyncAMSend interface at every 0x50 microseconds and the other
> nodes which are in the broadcast range of the sender receive this message
> and queries the corresponding local time transformation
Hi Sinan,
I have just run the test app
(tinyos-2.x-contrib/vu/apps/TestPacketTimeSync), but didn't see any
extreme inconsistencies apart from some clock drift. Would you mind
running this app and sharing the output with me? Also, can you send me
the compilation output (output of "PFLAGS=-v make te
Hi Janos,
I have downloaded tinyos-2.x from repository as well as tinyos-2.x-contrib.
I have applied the steps you have written previously to use your stack.
I have a transmitter node which transmits a message every 5 seconds. The
nodes which receive this message get timestamps of the received
Sinan:
> I am doing the same steps. I am still searching what did I do wrong... I am
> using system which has been newly checked out from tinyos-2.x development
> repository.
Which setup do you use out of the two I described? Can you please send
me the numbers you get?
Janos
> 06 Ağustos 2010 17
Hi Janos ,
I am doing the same steps. I am still searching what did I do wrong... I am
using system which has been newly checked out from tinyos-2.x development
repository.
Is it possible to use only the codes in the directory *
/tinyos-cvs/tinyos-2.x-contrib/vu/tos/chips/msp430* without changing
Sinan,
The problem is that it's not possible to tell the radio stack to
transmit a message at time t. The time delay between
TimeSyncAMSend.send() being called and the message actually going out
has a significant jitter (clear channel assessment, collision
avoidance mechanism is going on in betwee
Hi Janos,
thanks for your reccomendations. I have tried it but however I think that
there are inconsistencies between the timestamps I receive.
One of the nodes periodically sends a beacon in every 5 seconds using a
AlarmMilli and TimeSyncAMSend. When the other nodes receive and timestamp
these m
Sinan,
I actually have an alternative cc2420 radio stack implementation under
tinyos-2.x-contrib/vu that does what you want. That is, the msp430
timer subsystem is reprogrammed such that timer A is the 32kHz timer
and timer B is the micro timer. The radio stack uses the micro timer
for timestampin
Sinan,
Things are not that easy, unfortunately. For port 4.1, that's where
the interrupt line of the cc2420 is connected, you must use timer B
for capture. This means that you will need to reprogram the whole
timer subsystem such that timer B is driven by the internal DCO, and
timer A is driven by
Hi again,
I wanted to add some comments to my last reply.
When I connect Timer A to SFD, I could get time= 0 from *async event void
CaptureSFD.captured( uint16_t time )* and it means all timestamps are
invalid. Also, I could not get time values LocalTimeMicroC component and it
always returns 0.
Hi Thomas,
I am working on a similar platform to Telos I think... (It is Genetlab
Sensenode platform). I have connected TimerA to the SFD line as you said. I
have modified the file HplCC2420InterruptsC.
configuration HplCC2420InterruptsC {
provides interface GpioCapture as CaptureSFD;
provid
Hi Sinan,
The problem is not in the TinyOS code. The hardware you use (I assume
TelosB or Sky?) does not support these timestamps by default. The
timestamps are taken when the SFD line toggles. This line is connected
to the TimerB, which is sourced from the 32kHz signal. Thus, you can
not get micr
Hello all,
I have a problem on microsecond precision timestamps. I am using CC24 radio
chip and MSP430 microcontroller. As far as I understood, the packets are
timestamped at CC2420ReceiveP and CC2420TransmitP files.
/* CC2420Receive Commands /
/**
* Start f
Hi guys,
is there any minimum packet length checking in CC2420?
for example if packet length smaller than 5 it will just drop it...
if yes where should i disable it??is it in CC2420ReceiveP.nc??
Thanks alot
___
Tinyos-help mailing list
Tinyos-help@mil
Hi,
If CC2420 is using SPI to do data exchange with ATmega128, can CC2420 still
receive data from the channel simultaneously?
If the answer is yes, then if the RXFIFO overflows at this time, do we need to
let ATmega128 flush RXFIFO after spi ends?
Thanks.
Jingyao
It worked! Thank you very much!
Jung Il
On Thu, Jun 10, 2010 at 11:09 AM, Janos Sallai
wrote:
> Jung Il:
>
> First, half of the packet is loaded using SpiPacket interface as usual, and
>> I issue STXON command. And then the rest of the packet is loaded using
>> TXFIFO_RAM interface to specify t
Jung Il:
First, half of the packet is loaded using SpiPacket interface as usual, and
> I issue STXON command. And then the rest of the packet is loaded using
> TXFIFO_RAM interface to specify the offset in the TXFIFO. But during this
> TXFIFO_RAM.write() operation, a TX underflow occurs. CC2420 is
Hi all,
I am trying to minimize the latency while transmitting without loading the
packet in advance.
First, half of the packet is loaded using SpiPacket interface as usual, and
I issue STXON command. And then the rest of the packet is loaded using
TXFIFO_RAM interface to specify the offset in th
Hi, Janos.
Thank you once again for your reply.
I didn't know that stack. I've been using only TOSSIM.
But accomplishing what you said would cause to port the whole stack, right?
I was just interested on LPL.
Got to know more about this stack.
Kind regards,
Pedro Nunes
On Tue, Jun 1, 2010 at 2:
Pedro:
Why don't you port the rf2xx stack (tos/chips/rf2xx) to TOSSIM? The code is
organized such that only the lowermost layer is transceiver-specific. The
transceiver-specific driver layer is responsible for powering on and off the
radio, sending packets, downloading received packets and
timesta
Hello, Janos.
Thank you a lot for your reply - it was very enlightening.
Now, I am trying to figure it out how to port that behavior to TOSSIM (since
it does not simulate Low Power Listening).
I was trying to port the LPL used by CC2420 but it has a lot of dependencies
and therefore porting it wo
1 - 100 of 323 matches
Mail list logo
