Re: [riot-devel] More convenient access to the IoT-LAB from a RIOT application

2015-03-20 Thread Oleg Hahm

 How can I select some nodes?

The current version of this Makefile only allows you to specify the number,
the type, and the testbed site of the nodes. I don't know how sensible it
would be to add a more concrete node selection process to this feature. You
can pretty easily specify the concrete nodes by directly using
`experiment-cli` from IoT-LAB cli-tools. (The web frontend can help you with a
graphical representation of the physical topology.)

printk(KERN_WARNING MYNAM : (bad VooDoo)\n);

Description: PGP signature
devel mailing list

Re: [riot-devel] More convenient access to the IoT-LAB from a RIOT application

2015-03-20 Thread Kaspar Schleiser


On 03/18/15 19:23, Oleg Hahm wrote:

in an application's Makefile allows to create IoT-LAB experiments, flash,
reset and access the nodes right from the command line with Make in one go,

Let me know what you think about this idea and what could be improved.

Pretty awesome!

How can I select some nodes?

devel mailing list

[riot-devel] BLE project N2

2015-03-20 Thread Kausthub Naarayan
hi all ,

the BLE stack needs to be developed first on nrf52822 ? and is it possible
to develop all these within 2 months ? And how do we go about giving
deliverables for this project proposal ?
Sorry if this is a trivial question  , i am new to gsoc procedure
thanks in advance

Kausthub Naarayan B
devel mailing list

Re: [riot-devel] CSMA MAC-layer, Open Issues

2015-03-20 Thread Martine Lenders
Hi Jonas,

2015-03-20 18:02 GMT+01:00 Jonas Remmert



 2. The drivers send function builds the IEEE 802.15.4 MAC header on its
 own. The alternative would be to let the MAC layer do this job. This would
 avoid code duplication and make it easier to implement new radio drivers.
 Is there any reason to do this in the driver implementation?

Yes, the MAC layers should be as independent from the drivers as possible
(with protocols like TSCH for IEEE 802.15.4e this is obviously not
possible, but your CSMA implementation might also be used with a cc1100 or
other radios). As for avoiding code duplication with IEEE 802.15.4 header
building, there is the `ieee802154` [1] module for that. There is  also an
older PR by Hauke [2], that hopefully will be updated to the new network
stack scheme soon ;-).


 4. Generally, a successfull TX of a packet is not signalized to upper
 layers. But how do we handle a packet that could not be sent to the channel
 (e.g. channel busy)? Should upper layer be informed about the failure?

No, it just will be dropped (or the MAC must queue it).


a nice Weekend,

Have a nice weekend too,

devel mailing list

Re: [riot-devel] Iotivity, AllJoyn, Thread, Ipso Alliance

2015-03-20 Thread Maciej Wasilak
Hello Baptiste!

2015-03-20 9:02 GMT+01:00 Baptiste Clenet

 I agree with you about IETF protocols, everybody should use them and it
 will make communication easier.

In my opinion IETF protocols have the most potential to become de facto
standards. However IETF doesn't develop high level standards (above
application level). They released CoAP, but they won't define structure of
resources, and contents of messages. You may check OMA LWM2M [1] - it's
heavilly based on IETF standards and compatible with IPSO. It's more suited
for GSM devices though.

Best Regards
Maciej Wasilak

devel mailing list