Hi guys,
I would like to ask the following: In order to change the IPv6
addresses that my WSN will use with CoAP does it suffice to set the
-DIN6_PREFIX and -DCOAP_CLIENT_DEST in apps/CoapBlip/Makefile and
apps/PppRouter/Makefile or do I have to make any other adjustments?
PS: Naturally, I also
**
CALL FOR INDUSTRIAL DEMO, RESEARCH DEMO AND POSTER CONTRIBUTIONS
European Conference on Wireless Sensor Networks
February 15-17, 2012
Trento, Italy
IMPORTANT DEADLINES:
Industrial Demo/Research Demo/Poster
proposal due: December 5, 2011
Call for Proposals to host the
European Conference on Wireless Sensor Networks (EWSN) 2013
www.ewsn.org
The European Conference on Wireless Sensor Networks (EWSN) is a
leading international conference devoted to exchange of research
results in the field
Hello!
I have a problem with the Atmel128 i2c environment.
I want to read out the k30 co2-sensormodul from senseair.
On this sensor the i2c communication is implemented in software.
Because of that there is an advice in the datasheet
that it might come to problems during the i2c communication
Hi Sebastian,
I'd spend a lot of time with the MasterPacketP, and never had such
problems. However your solution is not quite good. If the I2C is
really busy, your modification will abort the communication on any
request. Moreover, you're signaling readDone() from the read()
command, which can
Hi guys,
I would like to ask the following: In order to change the IPv6
addresses that my WSN will use with CoAP does it suffice to set the
-DIN6_PREFIX and -DCOAP_CLIENT_DEST in apps/CoapBlip/Makefile and
COAP_CLIENT_DEST only needs to be modified, if you are using the CoAP client,
i.e.
If by open you mean edit or view, and you are doing that
by double clicking on the file in a GUI file manager, then
it looks like the .nc file type is associated with some
other kind of document. I don't know how Ubuntu's file
manager works, but there should be some way to change
that association
I'm not sure what you mean by slow, but here's something to check...
The T1 version of I2C for the ATmega used bit banging on the TOS
side rather than the controller's I2C hardware -- go figure
I found that it didn't recognize a wait-state-request from
external devices and would lose a bit
Thank you for your quick reply!
Yes I see my workaround isn't such a good idea.
With other I2C-Sensors (tsl2561 light sensor) I also hadn't any problems
and all worked fine. But with the k30 co2 sensor in particular something
doesn't work.
I also tried to slow down the i2c clock but it
I don't know if what you are working with uses hardware
or software (since I've only used T1) -- if you have started
with Moteworks you probably have T1...
Look at the low level driver and see. If it uses ATmega
hardware I would hope that it supports the so called clock
synchronization mechanism.
10 matches
Mail list logo