[riot-devel] GSOC - BLE PROJECT N2

[Kausthub Naarayan]

hi ,

 do we have to develop a single mode BLE or dual mode BLE device ?

if single mode then is this basic architecture fine :

This is the basic architecture layer which I have found out :

Host side we have :
GAP and GATT protocol interact with the
Security manager (SM) and the attribute protocol (ATT)
Which interacts with the L2CAP protocol to send the data to the controller .

Controller side we have the following :
HCI protocol which forms the interface with the link layerand the host
layers

Is this architecture fine to proceed ?
Also what is the next step I need to do to refine this ?

please help

thank you

-- 
Regards
Kausthub Naarayan B
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] [GSOC] Introduction

[Francesco Ermini]

The aim of the project is to avoid the use of hardcoded keys inside the
firmware and add more flexibility in keys management.
So we need an API that performs the following tasks:
1. Wait for an input that just says "hey, install a new key"
i.e  the NFC gateway detects an NFC device in his range or an UART device
has been plug.
2. Check the security parameters.
i.e a device identifier, a timeout for reading the payload,the protocol to
use...other parameters and finally the key
3. Create a database of all the informations received and guarantee that
nobody steels them!
In case of 802.15.4, since the encryption is done by the hardware of the
Xbee, the best solution consists of get rid   of the key right
after the key is set into the Xbee.
In case of RPL and CoAP the idea is to store the key in a secure storage or
a volatile area so that a device   tampering could lead
to key deletion
4. Implement the functions that will set the security keys into the desired
protocol/device

 Finally at the end of the project we'll test the encrypted communications
of the nodes

I hope I was clear, best regards Francesco


2015-03-19 10:57 GMT+01:00 Hauke Petersen :

>  HI Francesco,
>
> On 18.03.2015 19:07, Francesco Ermini wrote:
>
>  Thanks for the Xbee driver,I'll wait the PR for testing!
>
>  The security aspect is about including in RIOT the possibility to
> dynamically insert a set of encryption keys at run time through an external
> channel (I have a collegue working on NFC driver on  RIOT). Basically,the
> keys I want to exchange are those concering the 802.15.4 protocol,but we
> can use the same technique for RPL or CoAP.
>
> Sounds very interesting! There is quite some demand for this inside (and
> outside) of our community. Regarding GSOC - do you have already a rough
> idea about an architecture and a high-level project plan on how you would
> like to structure this as a GSOC project? I encourage you to share this
> with us, so we can help you to improve it!
>
> Cheers,
> Hauke
>
>
>
>
>
> 2015-03-16 19:21 GMT+01:00 Hauke Petersen :
>
>>  Hi Francesco,
>>
>> welcome to RIOT first of all.
>>
>> Cool that you are working with the UDOO boards! BLE development with
>> these boards would indeed be a little difficult, as I don't know any
>> shields without fully integrated network stack, that would allow for access
>> to the BLE link layer.
>>
>> Porting the Xbee device to RIOT is unfortunately already almost finished
>> [1] - I am just sitting on the last fixes and will release a PR in the next
>> couple of days...
>>
>> The security aspect however is not yet included. Taking this to a more
>> general approach (valid for not only the xbee device) is however a very hot
>> topic. Here I would indeed see a project for GSOC. Do you have already any
>> further ideas what you would like to do in this direction? It would be
>> nice, if you could roughly sketch our your ideas, so we can discuss them
>> further.
>>
>> Cheers,
>> Hauke
>>
>> [1] https://github.com/haukepetersen/RIOT/tree/add_driver_xbee
>>
>>
>>
>>
>> On 12.03.2015 15:46, Francesco Ermini wrote:
>>
>>
>>  Hi,
>>
>>  my name is Francesco Ermini, and I'm student in electronics  and
>> telecommunication engineering at the University of Florence,Italy.
>>
>>  My current Ms.C. thesis is about IoT secure communications. Our testbed
>> is made by some UDOO Quad boards, with Linux + RiOT as operating systems
>> (the UDOO can host two OSes at once).
>> I checked the GSOC ideas page, and I found the Bluetooth Low Energy
>> driver one. Although interesting, using BTLE wouldn't rally match my
>> current work.
>> However, we also found that the XBee shield is not yet supported in RiOT
>> (open bug / feature request). This would match a bit more my thesis work,
>> and my (evil) tutor would be happier.
>>
>>  My question is: what about implementing the XBee driver (including the
>> dynamic security keys setup) ?
>>
>>  Best regards,
>>
>>  Francesco
>>
>>
>>  ___
>> devel mailing 
>> listdevel@riot-os.orghttp://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>>
>
>
>  --
> Francesco Ermini
> Via Abebe Bikila, 8 50012 (FI)
> cell. 3338710609
> tell. 055642820
>
>
>


-- 
Francesco Ermini
Via Abebe Bikila, 8 50012 (FI)
cell. 3338710609
tell. 055642820
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NFC & Atmel AT86RF232B

[Simone Pecora]

Hi all,
I'm a telecommunication engineer student and I'm working on pn532 driver
for my thesis project. It works wired to a sam3x via spi communication.
The library works correctly for the authentication, read, format and write
mifare cards but i want to make a pairing with tho wsn riot nodes via nfc.
It doesn't work completely but it's almost done. In a couple of days i'll
probably finish and I'll release a PR.

Best regards,

Simone
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NFC & Atmel AT86RF232B

[Joel Chotard]

Hi Thomas,

Thanks for your informations.
I'm checking the NXP NFC components and need a feedback from the NXP supplier 
for the best version. It's seems the NTAG I2C has interested functions.
When we will get the complet datasheet we will check the job we have to do.
Joël

-Message d'origine-
De : devel [mailto:devel-boun...@riot-os.org] De la part de Thomas Eichinger
Envoyé : jeudi 19 mars 2015 10:51
À : RIOT OS kernel developers
Objet : Re: [riot-devel] NFC & Atmel AT86RF232B

Hi Joël,

ad NFC:
I got me some NXP pn532 modules some time ago as I heard there is work on 
specifying 6LoWPAN over ISO 14443 (which NFC is part of). Beside this there are 
a lot of interesting applications you could build in combination with 
constraint networks.
Sadly, I didn’t come too far with the driver, as it includes a (more) complex 
communication with the module, at least for the pn532, and it was kind of a 
private side project. My initial work can be found in [1].

ad rf212b:
As Joakim stated, the existing at86rf231 driver supports the rf212b as the main 
functionality is the same for all current Atmel radio devices.
I’m also currently refactoring the driver, providing the ability to extend the 
common functionality by very device specific features without writing it from 
scratch. I have it running for the rf231 already but need some more time to 
debug and entangle it correctly with all the other new network stack work. I 
will open a WIP PR for this today.

Best, Thomas


> On 18 Mar 2015, at 22:04, Joël Chotard  wrote:
> 
> Hi all,
> 
> Does somebody is working on a RIOT NFC device driver ? and the ATMEL sub-G 
> AT86RF212B driver ?
> 
> Joël
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] PR submitted for at86rf212b driver

[Baptiste Clenet]

Thanks a lot!
As soon as I've got this transceiver, I will try it.

2015-03-19 15:09 GMT+01:00 nidhya elango :

> Dear RIOTers,
>
> Further to a few queries, the following PR has been made for the addition
> of a driver for the at86rf212b transceiver from atmel.
> https://github.com/RIOT-OS/RIOT/pull/2647
> Kindly note that netdev_802154_driver_t features in this driver are yet to
> be verified.
> Thanks and Regards,
> Nidhya
>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>


-- 

*Clenet BaptisteFR: +33 6 29 73 05 39*
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] PR submitted for at86rf212b driver

[nidhya elango]

Dear RIOTers,

Further to a few queries, the following PR has been made for the addition
of a driver for the at86rf212b transceiver from atmel.
https://github.com/RIOT-OS/RIOT/pull/2647
Kindly note that netdev_802154_driver_t features in this driver are yet to
be verified.
Thanks and Regards,
Nidhya
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

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

[Gaëtan Harter]

Hi Oleg,

I think it's a good idea, it will allow easier runnig RIOT code on the 
platform.

I will write feedback directly on the PR.

Regards,
Gaëtan

On 03/18/2015 07:23 PM, Oleg Hahm wrote:

Dear rewewing IoTlers,

I just opened a pull request in RIOT that should ease the work with RIOT
applications on the IoT-LAB testbed a little bit:
https://github.com/RIOT-OS/RIOT/pull/2640

Including the proposed Makefile like

  include $(RIOTBASE)/dist/Makefile.iot-lab

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,
e.g. executing

export BOARD=iot-lab_M3
make iotlab-auth
make iotlab-exp IOTLAB_NODES=10 IOTLAB_DURATION=60 IOTLAB_SITE=grenoble
make iotlab-flash
make iotlab-term

will reserve an experiment for 10 nodes and 60 minutes in Grenoble, flash the
current application to all nodes and starts serial_aggregator for these nodes.

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

Cheers,
Oleg


___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] New Event: Hack'n'ACK @ Monthly from 5pm to 10pm on the last Tuesday (RIOT Events)

[Martine Lenders]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20150331T17
DTEND;TZID=Europe/Berlin:20150331T22
RRULE:FREQ=MONTHLY;BYDAY=-1TU
DTSTAMP:20150319T120715Z
UID:lbk4mfucqdomcf7c8o9cg4c...@google.com
CREATED:20150319T120715Z
DESCRIPTION:View your event at https://www.google.com/calendar/event?action
 =VIEW&eid=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2cgazNxbDhzZXR2N2w0OG9mbm9sMHRmd
 XU2dHNAZw.
LAST-MODIFIED:20150319T120715Z
LOCATION:c-base Berlin\; HAW Hamburg
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Hack'n'ACK
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Regarding Project A2

[Hiesgen, Raphael]

Hi Dinuka,

welcome to RIOT! 

> I would like to know whether for what platform(ARM,Intel Galileo) we have to 
> develop the applications?

You can target any platform you want, as long as it runs RIOT. If you want 
adapt the project idea as is, the biggest constraint for target hardware is 
memory size. We use the stm32f4discovery boards ourselves for testing with 
RIOT, CAF and C++. The board is already supported by RIOT and has 1MB ROM and 
192 KB RAM if I am not mistaken.

Here are some more thoughts on the project, which I have posted on the mailing 
list earlier:

> The idea is to use the C++ Actor Framework for programming. It is an 
> implementation of the actor model [1] and can be found on Github [2]. The 
> project itself features some examples and documentation how to use it. It 
> should be noted that RIOT support is still in development, see the topic/caf 
> branch of my RIOT fork [3] and the topic/riot branch of CAF [4]. For now, you 
> can use actors on the board, but the network communication is not implemented 
> (yet).
> 
> The network stack we want to deploy is based on IEEE 802.15.4, 6LoWPAN, UDP 
> and CoAP. To enable IEEE 802.15.4 and 6LoWPAN on desktop machines we acquired 
> some usb dongles [4]. For testing CAF with RIOT, we use stm32f4discovery 
> boards which have a lot of memory available, but do not have a transceiver. 
> Getting that to work is required at some point.
> 
> In any case, I would suggest to start by developing the application logic on 
> a desktop machine. It allows for easier debugging and should allow you to use 
> basically the same code on RIOT later on. Further, it is helpful to have a 
> small setup for testing your deployment later on. 

Hope this answers your question.

Raphael

[1] http://en.wikipedia.org/wiki/Actor_model
[2] https://github.com/actor-framework/actor-framework
[3] https://github.com/josephnoir/RIOT
[4] http://rosand-tech.com/products/r-idge/prod.html

> On Mar 18, 2015, at 6:09 PM, Dinuka Salwathura  
> wrote:
> 
> Hello RIOT community,
> 
> I am Dinuka Sawlathura from University of Moratuwa, Sri Lanka. 
> I am doing Computer Science & Engineering(Integrated Computer Engineering).
> 
> I like to work on following project,
> 
> Project A2: Intelligently Interacting Light Switches
> I would like to know whether for what platform(ARM,Intel Galileo) we have to 
> develop the applications?
> 
> Thank you,
> best regards,
> Dinuka
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Hello_RIOT

[Otmane El Mouaatamid]

Hi Peter
thank you for your feedback about my issues .

with best regards .


Otmane

2015-03-19 8:19 GMT+00:00 Peter Kietzmann :

>  Hi Otmane,
>
> welcome to the RIOT community! Please go a bit through the wiki pages and
> checkout the open issues list [1]. There you can find some issues labeled
> "Newbie-Task-Candidate". Would be nice if you work on one (or more) issues
> and make a PR for your fixes. This is a good point to start working with
> RIOT and get in contact with the community. Also you'll learn a bit about
> our workflows... Regarding the further progress I guess it would be really
> informative for you to read the notes from the yesterday's virtual GSOC
> meeting [2].
>
> Cheers,
> Peter
>
> [1] https://github.com/RIOT-OS/RIOT/issues
> [2] http://pad.spline.de/Ouide7Nzd8
>
>
> Am 18.03.2015 um 17:28 schrieb Otmane El Mouaatamid:
>
>  Hello RIOT,
> my name is Otmane EL MOUATAMID , i have 26 years i from Morocco , i'm PhD
> student , my research axes :
> - IoT-A,
> - ad-hoc
> - MANet,
> - VANet,
> - WSN,
> - M2M,
> - RFID,
> - NFC.
>
>  i'm interested to work in RIoT, Project N2: Implementation of LwM2M.
> but i'm new n the summer code and RIOT, i'm reading about RIOT now  i
> liked the idea,
> now i need  knowledge how to i can start my work and how i can contribute
> in this project .
>
>
>  best regards!
>
>  Otmane .elmouaatamid
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttp://lists.riot-os.org/mailman/listinfo/devel
>
>
> --
> Peter Kietzmann
>
> Hamburg University of Applied Sciences
> Dept. Informatik, Internet Technologies Group
> Berliner Tor 7, 20099 Hamburg, Germany
> Fon: +49-40-42875-8426
> Web: http://www.haw-hamburg.de/inet
>
>
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Benchmarks

[Oleg Hahm]

Hi Simon!

> Yes I tried to compile the rpl_udp example for the samr21-xpro but it did
> not have enough RAM. Even with RPL in non-storing mode and a very small
> routing table it would not fit.

Well, in non-storing you basically don't need any routing table (except for
the root node), but still it sounds weird to me that it doesn't fit. I guess
some optimization could be doable but...

> Ultimately we would be looking to run UDP/RPL/COAP on top of the
> IPv6/6lowpan/802.15.4 stack.
> 
> For the evaluation just UDP would be fine to give me an idea if a M0+ would
> be fast enough.
> 
> Is the size of RAM/flash for RIOT likely to increase? Currently building the
> rpl_udp example results in 109K text+data, 37K bss. We were thinking of
> going for a M0+ with 128KB flash and 64KB RAM but this does not leave much
> room for expansion.

Hopefully and most likely the contrary will be the case. As the current network
stack could definitely need quite some memory optimizations and wastes a lot
of memory by many memcpy operations, we decided to completely redesign it, in
order come up with a much slimmer solution. (Apart of having identified other
drawbacks of the old solution.)

This new stack should definitely fit on the 32 kB RAM of the SAMr21 including
UDP/RPL/CoAP, but I cannot give any concrete numbers by now. Hauke, Martine,
can you give some rough numbers for the current state of the implementation?

Another advantage of the redesigned network stack will be its configurability.
The current version, for example, always expects the default minimum MTU for
IPv6 of 1280 bytes and thus reserves this once in the outgoing and once for
the incoming buffer.

For more information on the new network stack, see our paper on
http://arxiv.org/abs/1502.01968 and the minutes from the meeting in February:
https://github.com/RIOT-OS/RIOT/wiki/minutes-network-task-force-feb-2015

There is also most of the functionality already out there on Github as Pull
Requests.

> Am I correct in thinking that the IPv6/6lowpan/UDP/TCP/RPL stacks are fairly
> complete but there is quite a bit missing at the 802.15.4 mac layer such as
> beacons and security? I assume this will increase the code size of RIOT?

Yes, this assumption is mostly correct. The biggest limitations for the upper
layer stack are:
 - In the current version, 6LoWPAN and IPv6 are mostly entangled and therefore
   IPv6 cannot be used standalone.
 - Without support for multiple radios on one board, similar to Contiki, the
   border router will work only over stdio over a serial port (and haven't
   been tested for quite a while).
 - Only the basic TCP feature set is implemented. Due to memory constraints,
   the window size is fixed to one.

However, as I said before, we can expect rather a _de_creasing code size for
the new version of the network stack, eliminating these shortcomings.

Cheers,
Oleg
-- 
printk ("Barf\n");
linux-2.6.6/arch/v850/kernel/module.c


pgppxxts9bQVP.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

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

[Oleg Hahm]

Hi Baptiste!

> This question is not particularly about Riot but it makes sense to ask you
> since future Riot device might use one of this high level protocol
> (Iotivity, AllJoyn, Thread, Ipso Alliance).
> What do you think about them?  In your opinion, which one will be mostly
> used?

To be honest, to me most of these alliance and consortia have the disadvantage
of being very blurry and vague about the concrete techniques and protocols.
I haven't heard of Iotivity before and looking at their web page, it seems
that they're mostly targeting bigger devices than we do usually in the RIOT
ecosystem. Same goes for AllJoyn as far as I can see. Real constrained IoT
devices are expected to connect to something more powerful to integrate them
into the Internet. That seems to be exactly this type of silo solution most
RIOT developers don't believe to be helpful on the long run.

For Thread, it's really hard to tell at the moment, since there's no
specification and everything's happening behind closed doors, which are to
expensive to open - except you're a global player with some money. From the
technologies and protocol suites they mention and from the people that I know
who are involved there, it sounds rather reasonable and I hope that they will
come up with something more useful than ZigBee, but I still don't understand
the need for yet another protocol stack.

To me IPSO alliance seems to be the most natural choice, since they are not
proposing their own (silo) solution, but build on existing standards, mostly
from IETF.

> Is there any future developments planned on RIOT?

Well, first of all, I have to say that most of the original RIOT core team are
either network or system guys. Means, real applications and working on high
level protocols, was out of scope in the beginning. Fortunately, over time and
as the RIOT community grew this changed and people started to work on several
upper layer solutions. However, I think it's not yet clear if there will be
the one go-to solution or - what sounds more probable to me - several high
layer protocols tailored for different use cases. Hence, I think (and hope) we
will have several solutions in RIOT over the next years.

Personally, I'm a strong believer in open standards and therefore I prefer
IETF protocols wherever possible.

Cheers,
Oleg
-- 
fs_dprintk (FS_DEBUG_INIT, "Ha! Initialized OK!\n");
linux-2.6.6/drivers/atm/firestream.c


pgpAq7uNiP6Pj.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Project S2: RIOT as an RPython Module

[Kaspar Schleiser]

Hi AAshish,

Thanks for your interest!

On 03/12/15 19:36, Regmi, Aashish wrote:

I was wondering if you could provide more information about the project
so that I can get a clear understanding about the project and about how
to get started with project.
Well, some of us think that it would be nice to be able to write RIOT 
applications in a language different than C.


RPython would be one way, as it allows compiling Python code to plain C, 
which could be linked to RIOT.


Another way would be to port e.g., micropython[1], to RIOT as a package.

Any "print("Hello World!")" written in python but running on a RIOT node 
would probably an awesome outcome of this project.


While this needs some understanding of programming languages in general, 
it is more a project requiring knowledge about how to integrate and 
adapt a python interpreter or runtime into the ressource-constrained 
RIOT environment, with the involved challenges around memory management, 
linking, ...


If you are still interested, the next step for you would be to prepare a 
short application [1][2]. The main part of the application consists of 
your proposed (high-level) project plan. Maybe have also a look at our 
last dev-meeting minutes [3] for some more information.


Furthermore we would like to see some first involvement with RIOT by 
contributing a (simple) pull request to RIOT. The purpose of this is to 
get you an idea of how the community works and what RIOT development is 
about. Have a look at our development procedures [4] and contributing 
guidelines [5]. The easiest way to get involved is by looking at issues 
marked as 'Newbie-Task-Candidate' and to fix one (or more) of them.


Let us know if you have more specific questions!

Cheers,
Kaspar
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NFC & Atmel AT86RF232B

[Thomas Eichinger]

Hi,

> On 19 Mar 2015, at 10:54, Oleg Hahm  wrote:
> 
>> 
>> Sadly, I didn’t come too far with the driver, as it includes a (more) complex
>> communication with the module, at least for the pn532, and it was kind of a
>> private side project. My initial work can be found in [1].
> 
> Link was missing. ;)

Of course, sorry about that.

[1] https://github.com/thomaseichinger/RIOT/tree/pn532

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NFC & Atmel AT86RF232B

[Oleg Hahm]

Hi Thomas!

> I got me some NXP pn532 modules some time ago as I heard there is work
> on specifying 6LoWPAN over ISO 14443 (which NFC is part of). 

Indeed, there is. See https://tools.ietf.org/html/draft-ietf-6lo-nfc-00

> Sadly, I didn’t come too far with the driver, as it includes a (more) complex
> communication with the module, at least for the pn532, and it was kind of a
> private side project. My initial work can be found in [1].

Link was missing. ;)

Cheers,
Oleg
-- 
The worst part about token ring jokes is that if someone starts telling one
while you are telling yours, all joking stops.


pgpwNwstUxK_7.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] [GSOC] Introduction

[Hauke Petersen]

HI Francesco,

On 18.03.2015 19:07, Francesco Ermini wrote:

Thanks for the Xbee driver,I'll wait the PR for testing!

The security aspect is about including in RIOT the possibility to 
dynamically insert a set of encryption keys at run time through an 
external channel (I have a collegue working on NFC driver on  RIOT). 
Basically,the keys I want to exchange are those concering the 802.15.4 
protocol,but we can use the same technique for RPL or CoAP.
Sounds very interesting! There is quite some demand for this inside (and 
outside) of our community. Regarding GSOC - do you have already a rough 
idea about an architecture and a high-level project plan on how you 
would like to structure this as a GSOC project? I encourage you to share 
this with us, so we can help you to improve it!


Cheers,
Hauke





2015-03-16 19:21 GMT+01:00 Hauke Petersen >:


Hi Francesco,

welcome to RIOT first of all.

Cool that you are working with the UDOO boards! BLE development
with these boards would indeed be a little difficult, as I don't
know any shields without fully integrated network stack, that
would allow for access to the BLE link layer.

Porting the Xbee device to RIOT is unfortunately already almost
finished [1] - I am just sitting on the last fixes and will
release a PR in the next couple of days...

The security aspect however is not yet included. Taking this to a
more general approach (valid for not only the xbee device) is
however a very hot topic. Here I would indeed see a project for
GSOC. Do you have already any further ideas what you would like to
do in this direction? It would be nice, if you could roughly
sketch our your ideas, so we can discuss them further.

Cheers,
Hauke

[1] https://github.com/haukepetersen/RIOT/tree/add_driver_xbee




On 12.03.2015 15:46, Francesco Ermini wrote:


Hi,

my name is Francesco Ermini, and I'm student in electronics  and
telecommunication engineering at the University of Florence,Italy.

My current Ms.C. thesis is about IoT secure communications. Our
testbed is made by some UDOO Quad boards, with Linux + RiOT as
operating systems (the UDOO can host two OSes at once).
I checked the GSOC ideas page, and I found the Bluetooth Low
Energy driver one. Although interesting, using BTLE wouldn't
rally match my current work.
However, we also found that the XBee shield is not yet supported
in RiOT (open bug / feature request). This would match a bit more
my thesis work, and my (evil) tutor would be happier.

My question is: what about implementing the XBee driver
(including the dynamic security keys setup) ?

Best regards,

Francesco


___
devel mailing list
devel@riot-os.org  
http://lists.riot-os.org/mailman/listinfo/devel





--
Francesco Ermini
Via Abebe Bikila, 8 50012 (FI)
cell. 3338710609
tell. 055642820


___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Benchmarks

[Simon Vincent]

Yes I tried to compile the rpl_udp example for the samr21-xpro but it 
did not have enough RAM. Even with RPL in non-storing mode and a very 
small routing table it would not fit.


Ultimately we would be looking to run UDP/RPL/COAP on top of the 
IPv6/6lowpan/802.15.4 stack.


For the evaluation just UDP would be fine to give me an idea if a M0+ 
would be fast enough.


Is the size of RAM/flash for RIOT likely to increase? Currently building 
the rpl_udp example results in 109K text+data, 37K bss. We were thinking 
of going for a M0+ with 128KB flash and 64KB RAM but this does not leave 
much room for expansion.


Am I correct in thinking that the IPv6/6lowpan/UDP/TCP/RPL stacks are 
fairly complete but there is quite a bit missing at the 802.15.4 mac 
layer such as beacons and security? I assume this will increase the code 
size of RIOT?


Thanks

Simon

On 18/03/15 06:51, Ludwig Ortmann wrote:

Hi,

I think our only m0+/802.15.4 board is the samr21-xpro and there are problems 
with the current/old network stack because of its memory demands.
That said: which  protocol on top of IP are you interested in?
I assume you want to ignore RPL and any other side-tasks for this evaluation?

Cheers,
Ludwig

Am 17. März 2015 17:46:52 MEZ, schrieb Simon Vincent :

Hi Craig,

We have a 802.15.4 transceiver that is capable of 250kbps. We are
thinking of using this with a Cortex M0+ but wanted to make sure that
the M0+ would have the processing power to handle the
802.15.4/6lowpan/ipv6 stack at a datarate of 250kbps.

I just wondered if anyone had done any datarate measurements on
existing
development boards using the Cortex M0+?

- Simon

On 17/03/15 16:20, Craig Younkins wrote:

Hi Simon,

Throughput will be highly dependent upon the RF environment and what
transceiver you are using. The M0+ most likely has enough power to do
it under ideal conditions, but retransmissions due to collisions will
limit the effective bandwidth.

You can use 900 mhz and 2.4 ghz transceivers with 15.4. ~900 is
significantly less crowded but lower theoretical bandwidth. The Atmel
212B is 900 Mhz and specs 1000 kbps as the max air data rate.

Which transceiver are you using?

Craig Younkins

On Tue, Mar 17, 2015 at 11:42 AM, Simon Vincent
mailto:simon.vinc...@xsilon.com>> wrote:

 Has anyone done any performance tests to see what throughput can
 be achieved using RIOT?

 I would be interested to know if the Cortex M0+ is powerful

enough

 to sustain 250Kb/s TCP over 6lowpan/802.15.4.

 Does RIOT have any mechanism to measure CPU usage?

 - Simon
 ___
 devel mailing list
 devel@riot-os.org 
 http://lists.riot-os.org/mailman/listinfo/devel




___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel





___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NFC & Atmel AT86RF232B

[Thomas Eichinger]

Hi Joël,

ad NFC:
I got me some NXP pn532 modules some time ago as I heard there is work
on specifying 6LoWPAN over ISO 14443 (which NFC is part of). Beside this
there are a lot of interesting applications you could build in combination
with constraint networks.
Sadly, I didn’t come too far with the driver, as it includes a (more) complex
communication with the module, at least for the pn532, and it was kind of a
private side project. My initial work can be found in [1].

ad rf212b:
As Joakim stated, the existing at86rf231 driver supports the rf212b as the 
main functionality is the same for all current Atmel radio devices.
I’m also currently refactoring the driver, providing the ability to extend
the common functionality by very device specific features without writing
it from scratch. I have it running for the rf231 already but need some more
time to debug and entangle it correctly with all the other new network stack
work. I will open a WIP PR for this today.

Best, Thomas


> On 18 Mar 2015, at 22:04, Joël Chotard  wrote:
> 
> Hi all,
> 
> Does somebody is working on a RIOT NFC device driver ? and the ATMEL sub-G 
> AT86RF212B driver ?
> 
> Joël
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

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

[Baptiste Clenet]

Hi Rioters,

This question is not particularly about Riot but it makes sense to ask you
since future Riot device might use one of this high level protocol
(Iotivity, AllJoyn, Thread, Ipso Alliance).
What do you think about them?  In your opinion, which one will be mostly
used?
Is there any future developments planned on RIOT?

Cheers,

-- 

*Clenet BaptisteFR: +33 6 29 73 05 39*
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Hello_RIOT

[Peter Kietzmann]

Hi Otmane,

welcome to the RIOT community! Please go a bit through the wiki pages 
and checkout the open issues list [1]. There you can find some issues 
labeled "Newbie-Task-Candidate". Would be nice if you work on one (or 
more) issues and make a PR for your fixes. This is a good point to start 
working with RIOT and get in contact with the community. Also you'll 
learn a bit about our workflows... Regarding the further progress I 
guess it would be really informative for you to read the notes from the 
yesterday's virtual GSOC meeting [2].


Cheers,
Peter

[1] https://github.com/RIOT-OS/RIOT/issues
[2] http://pad.spline.de/Ouide7Nzd8


Am 18.03.2015 um 17:28 schrieb Otmane El Mouaatamid:

Hello RIOT,
my name is Otmane EL MOUATAMID , i have 26 years i from Morocco , i'm 
PhD student , my research axes :

- IoT-A,
- ad-hoc
- MANet,
- VANet,
- WSN,
- M2M,
- RFID,
- NFC.

i'm interested to work in RIoT, Project N2: Implementation of LwM2M.
but i'm new n the summer code and RIOT, i'm reading about RIOT now  i 
liked the idea,
now i need  knowledge how to i can start my work and how i can 
contribute in this project .



best regards!

Otmane .elmouaatamid


___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


--
Peter Kietzmann

Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] PWM on STM32-L1

[Peter Kietzmann]

Hello Vivien & Co.,

and welcome to RIOT! Let my try to bring some light into the dark :-) . 
You'll find my comments inline. The general idea of the "periph_conf.h" 
is a RIOT specific hardware/pin abstraction. Is it correct assuming you 
have a stm32 nucleo-l1 board?



Am 17.03.2015 um 14:50 schrieb Vivien Michel:

Hello,

We are four students, working on riot-os implementation for STM32-L1. 
But we are facing some problems : we're trying to add PWM features in 
order to use a motor shield. We already have implemented the pwm.h for 
our board. And now we're having a hard time understanding how we 
should proceed with the periph_conf.h file.


The pwm.h is a peripheral interface which you can find in 
"RIOT/drivers/include/periph/pwm.h". You'll need to fulfill this API 
with your driver implementation but NOT adapt it. It is designed to 
match the basic functionalities.


Actually, our main confusion comes from the defines that we have to 
use to configure the pwm pins.


As stated above, the periph_conf.h decouples hardware-specific stuff 
from the RIOT naming-scheme. For example, you can setup the pin PA09 on 
the board and name it GPIO_0 in RIOT.


- Regarding the channels, we don't really get what it refers to ? Do 
the values defined for these channels directly correspond to the 
number written on the board near the pins (numbers 3, 5, 6, 9, 10 and 
11 on the stm32l1) ? Why are there four channels defined for each pwm 
pins in the stm32f3discovery's periph_conf.h ?


Comparing the stm32f3discovery you can have multiple PWM channels on one 
port. Each channel can fulfill a separate PWM and therefore has its own 
pin. On stm32f3discovery there are two ports with four channels each. 
For your first implementation you don't need to implement multiple 
channels per board. One working PWM (pin) should be enough to validate 
the driver.
You can not compare the numbers written on the stm32 nuclea-l1 and the 
stm32f3discovery. I guess you need to understand the I/O pin multiplexer 
in general. Please read [1] p.175 sec. 7.3.2.


- What values should we use for the PWM_X_DEV, PWM_X_CLKEN(), 
PWM_X_CLKDIS() and PWM_X_PORT_CLKEN() ?


Did you have a look at the CMSIS header? You can find it in 
RIOT/cpu/stm32l1/include/stm32l1xx.h. There, all registers and cpu 
specific configurations are named. You should have a look at (i) the use 
of this file comparing for example to the gpio implementation and (ii) 
compare the stm32f3 PWM implementation. You will see that the PWM 
especially depends by timers (TIMx). You'll also need to enable bus 
clocks for the peripherals. You can find all principles in the stm32f3 
implementation as this is really similar to the stm32l1 i think. Also 
you can find everithing in the manual [1].


- For the PWM_X_PORT, should we use GPIOC and GPIOD as it is done for 
the stm32f3 ?


You need to go into the manual and see where you can map these pins to. 
It think it is not possible on every port and every pin for each 
potential function. Select a port and pin where no other peripheral 
function is placed.


- Should we disable the pins in the GPIO config if we want to use them 
as PWM ?


Please try to avoid multiple functions for one pin. Then you don't have 
to disable them.




We would be very grateful for any help.

Are you fine now, any further questions?



Best regards.


Cheers,
Peter



___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


--
Peter Kietzmann

Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NFC & Atmel AT86RF232B

[Akshay Mishra]

My colleague Nidhya should be posting on this. Expect EoD India time.

Akshay

On Thursday, 19 March 2015, Baptiste Clenet  wrote:

> Hello,
>
> I'm also interesting in AT86RF212B driver.
> Ashkay has already done some improvements with this driver.
> Does anybody have a WIP branch to try this driver?
>
> Cheers,
>
> 2015-03-18 22:14 GMT+01:00 Joakim Gebart  >:
>
>> Hello,
>>
>> On Wed, Mar 18, 2015 at 10:08 PM, Craig Younkins > > wrote:
>> > I think the at86rf231 driver works with the 212B or will otherwise
>> require
>> > minimal changes. I have not tested it but anticipate using it. In the
>> linux
>> > kernel they are both supported in the same file.
>>
>> Yes, the AT86RF212B works with the at86rf231 driver. The driver is
>> undergoing some work right now, see
>> https://github.com/RIOT-OS/RIOT/pull/2562 and
>> http://lists.riot-os.org/pipermail/devel/2015-March/002247.html
>>
>> I have seen a memory corruption bug with the driver but not had the
>> time to pinpoint it exactly, it seems to happen randomly, but in the
>> vicinity of the radio RX code. I will open a PR when I find a solution
>> unless someone else beats me to it.
>>
>> Best regards,
>> Joakim
>> www.eistec.se
>>
>> >
>> > Craig Younkins
>> >
>> > On Wed, Mar 18, 2015 at 5:04 PM, Joël Chotard > >
>> > wrote:
>> >>
>> >> Hi all,
>> >>
>> >> Does somebody is working on a RIOT NFC device driver ? and the ATMEL
>> sub-G
>> >> AT86RF212B driver ?
>> >>
>> >> Joël
>> >> ___
>> >> devel mailing list
>> >> devel@riot-os.org 
>> >> http://lists.riot-os.org/mailman/listinfo/devel
>> >
>> >
>> >
>> > ___
>> > devel mailing list
>> > devel@riot-os.org 
>> > http://lists.riot-os.org/mailman/listinfo/devel
>> >
>> ___
>> devel mailing list
>> devel@riot-os.org 
>> http://lists.riot-os.org/mailman/listinfo/devel
>>
>
>
>
> --
>
> *Clenet BaptisteFR: +33 6 29 73 05 39 <%2B33%206%2029%2073%2005%2039>*
>
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NFC & Atmel AT86RF232B

[Baptiste Clenet]

Hello,

I'm also interesting in AT86RF212B driver.
Ashkay has already done some improvements with this driver.
Does anybody have a WIP branch to try this driver?

Cheers,

2015-03-18 22:14 GMT+01:00 Joakim Gebart :

> Hello,
>
> On Wed, Mar 18, 2015 at 10:08 PM, Craig Younkins 
> wrote:
> > I think the at86rf231 driver works with the 212B or will otherwise
> require
> > minimal changes. I have not tested it but anticipate using it. In the
> linux
> > kernel they are both supported in the same file.
>
> Yes, the AT86RF212B works with the at86rf231 driver. The driver is
> undergoing some work right now, see
> https://github.com/RIOT-OS/RIOT/pull/2562 and
> http://lists.riot-os.org/pipermail/devel/2015-March/002247.html
>
> I have seen a memory corruption bug with the driver but not had the
> time to pinpoint it exactly, it seems to happen randomly, but in the
> vicinity of the radio RX code. I will open a PR when I find a solution
> unless someone else beats me to it.
>
> Best regards,
> Joakim
> www.eistec.se
>
> >
> > Craig Younkins
> >
> > On Wed, Mar 18, 2015 at 5:04 PM, Joël Chotard 
> > wrote:
> >>
> >> Hi all,
> >>
> >> Does somebody is working on a RIOT NFC device driver ? and the ATMEL
> sub-G
> >> AT86RF212B driver ?
> >>
> >> Joël
> >> ___
> >> devel mailing list
> >> devel@riot-os.org
> >> http://lists.riot-os.org/mailman/listinfo/devel
> >
> >
> >
> > ___
> > devel mailing list
> > devel@riot-os.org
> > http://lists.riot-os.org/mailman/listinfo/devel
> >
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>



-- 

*Clenet BaptisteFR: +33 6 29 73 05 39 <%2B33%206%2029%2073%2005%2039>*
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel