Re: [riot-devel] Bridge border router and 6LowPan interfaces

[Daniel Krebs]

Hi Baptiste,

I guess what you're trying to achieve is the common use case of the 
border router AFAIK. Did you try to setup an "affe::x"-style address on 
node B? I'm still not too familiar with IPv6 terms, but I think that 
those fe80:: addresses are in a local scope and therefore not forwarded 
by a router, while the "affe::x" addresses are global.


Node B:
# ifconfig 7 add affe::3
# udp server start 

Linux:
$ netcat -6u affe::3

I had this exact same setup (with same addresses) already and it worked 
out of the box that way, so I'm pretty sure that in principle what 
you're trying to do is possible and you're not far away ;)



Cheers,
Daniel

Am 07.03.2016 um 11:00 schrieb Baptiste Clenet:

I want to be able to send a packet from LINUX to board B through board
A (border router)
LINUX -> A -> B

and then receive the answer from B to LINUX through A
LINUX <- A <- B

So I will be able to open an UDP socket on my LINUX on the interface
tun which will receive packets from board B.
Does it make sense?

Baptiste

2016-03-07 10:52 GMT+01:00 Kaspar Schleiser :

Hey,

On 03/07/2016 08:43 AM, Baptiste Clenet wrote:

@Cenk (or anyone), could you give me some help on that please?

Just so I understand correctly: you basically want to sniff traffic that
passes between the two samr21 on linux via the tun interface?
There's currently no support for that.

Do you have a third samr21? We usually set that up as sniffer.

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





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

[riot-devel] OpenOCD-RTOS support for RIOT

[Daniel Krebs]

Dear fellow RIOTing developers,

OpenOCD-RTOS support is coming to RIOT but needs your help. But first 
what am I talking about?


When debugging a RIOT application via GDB you will be able to get an 
overview of all running threads and their states:

(gdb) info threads
[New Thread 2]
[New Thread 3]
  Id   Target Id Frame
  3Thread 3 (at86rfxx :  : Blocked receive) 0x4104 in 
_msg_receive (m=m@entry=0x2f00 <_lwmac_stacks+860>, 
block=block@entry=1) at .../RIOT/core/msg.c:329
  2Thread 2 (main :  : Blocked mutex) mutex_lock 
(mutex=mutex@entry=0x2a6c ) at 
.../RIOT/core/mutex.c:53
* 1Thread 1 (idle :  : Running) lpm_arch_set 
(target=target@entry=LPM_IDLE) at .../RIOT/cpu/samd21/lpm_arch.c:98


You can switch the current thread and investigate the stackframe:

(gdb) thr 2
[Switching to thread 2 (Thread 2)]
#0  mutex_lock (mutex=mutex@entry=0x2a6c ) at 
.../RIOT/core/mutex.c:53

(gdb) bt
#0  mutex_lock (mutex=mutex@entry=0x2a6c ) at 
.../RIOT/core/mutex.c:53
#1  0x2c96 in _xtimer_sleep (offset=396000, 
long_offset=long_offset@entry=0) at .../RIOT/sys/xtimer/xtimer.c:53
#2  0x0fa4 in xtimer_usleep (offset=) at 
.../RIOT/sys/include/xtimer.h:487

#3  main () at .../main.c:79


All you need to get this working is my yet unmerged PR [1] in RIOT and a 
modified version of OpenOCD. But the OpenOCD patches need reviewing at 
their code review tool and I was told to send some RIOT developers to 
actually do that reviewing because nobody @ OpenOCD is using RIOT. So to 
get this upstream please head over to their Gerrit [2] and do the 
reviewing if you want this feature.

You can directly login with your Github account via OAuth here [3].

To test this on your system you need to compile OpenOCD yourself:

$ git clone https://github.com/daniel-k/openocd.git
$ cd openocd
$ git checkout riot_patched
$ ./bootstrap
$ ./configure
$ sudo make install

Then merge my PR to your code and try it out.

Cheers,
Daniel

[1] https://github.com/RIOT-OS/RIOT/pull/4058
[2] http://openocd.zylin.com/#/c/3000/
[3] 
http://openocd.zylin.com/login/%23%2Fregister%2Fq%2Fstatus%3Aopen?id=gerrit-oauth-provider_-github-oauth

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

Re: [riot-devel] Support for Nordic nRF2401 RF Transceivers.

[Daniel Krebs]

Hi Rakendra,

just a short note from my personal experience. Don't mix these cheap 
chinese modules. I got a bunch of them (PCB antenna, external antenna, 
black, green, ...) and in some configuration I couldn't get them to 
interact. Turns out those are (all?) counterfeit products that have 
different silicon inside. So if you run into problems, first make sure 
you use all the same modules in your setup.


Cheers,
Daniel

Am 30.09.2015 um 10:25 schrieb rakendra thapa:
Oh Sorry for the typo. I was referring to the same nRF24L01+ 
Transceiver module.


And thanks for guiding to the available driver and the test. I already 
got the modules today,  will try them out first.


Thanks again.

Regards,
Rakendra

On Wed, Sep 30, 2015 at 12:12 AM, Peter Kietzmann 
> wrote:


Hi Rakendra,

I didn't find informations about "nRF120 transceiver boards",
could you provide a link? Anyway, we don't have support for that
board.

Regarding the nRF24L01+ you can find the driver here:
https://github.com/RIOT-OS/RIOT/tree/master/drivers/nrf24l01p

and a small test here:
https://github.com/RIOT-OS/RIOT/tree/master/tests/driver_nrf24l01p_lowlevel

Note that it is currently just low-level support. Did you check if
there is other hardware support in RIOT that might fulfil your
requirements?

Best,
Peter


Am 29.09.2015 um 20:29 schrieb rakendra thapa:

Hello Peter,

Thanks for your reply and pointing out the difference. Will take
care of this detail while buying these. (I don't think nRF2401A
will even be available now)

So, RIOT-OS does have low level support for nRF120 transceiver
boards. Is it ? That will be helpful to get started.

Thanks and Regards,
Rakendra


On Tue, Sep 29, 2015 at 3:04 PM, Peter Kietzmann
> wrote:

Hi Rakendra,

and welcome to RIOT! I think no one used the nRF2401A. We
only have (low-level) support for the nRF24L01+. Also note
Nordics recommendation:
" This product is not recommended for new designs. Nordic
recommends the nRF24L01+ or for a System-on-Chip solution
either the Nordic nRF24LE1 or nRF24LU1+."

Why do you need the "A" version? What's the benefit?

Best,
Peter


Am 29.09.2015 um 11:28 schrieb rakendra thapa:

Hello Everyone,

Has anyone been using nRF2401A already in their project ?

I don' t see it currently supported in RIOT. I am starting
to work with it and if any one else is already working on
it, do let me know. A head start will be great :)


*https://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF2401A*


Thanks and Regards,
Rakendra


___
devel mailing list
devel@riot-os.org  
https://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 
https://lists.riot-os.org/mailman/listinfo/devel




___
devel mailing list
devel@riot-os.org  
https://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 
https://lists.riot-os.org/mailman/listinfo/devel




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


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

Re: [riot-devel] question on a possibility for a netdev deadlock

[Daniel Krebs]

Hi Martin,

all the mentioned function are not called in interrupt context. Take a look at 
ng_at86rf2xx.c. There you find the real ISR that sends a msg to the next higher 
level notifying about the IRQ. Then from there everything else in the driver is 
executed from thread context.

So I guess this is unrelated to the problems you are having.

Cheers, 
Daniel

Am 24. Juni 2015 09:54:09 MESZ, schrieb Martin 
martin.landsm...@haw-hamburg.de:
Hi all,

I've tested the ng_ stack with samr21-xpro boards using the new 
ng_at86rf2xx driver.
Since I sometimes encountered hardfaults I took a look in the ISR 
handling of the driver [1].

There we handle incoming packets when the receiver has finished the RX 
process [2].
Since we are in a ISR, all other processes has been interrupted.

Now when we call _receive_data() function inside the ISR, that in turn 
calls pktbuf handling/manipulating functions [3],
we try to acquire the mutex protecting the pktbuf [4].

Since we are still inside of the ISR probably the mutex is acquired by 
someone else.
If true this leads to a deadlock since the ISR would wait forever to 
acquire the mutex and never return to leave the ISR.

Additionally if we successfully acquire the mutex,
we could produce inconsistencies iff the protection is not performed 
consistently.

Just wanted to ask if I'm mistaken here and missed something.

Best regards,
Martin

[1] 
https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L671
[2] 
https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L688
[3] 
https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L271
[4] 
https://github.com/RIOT-OS/RIOT/blob/master/sys/net/crosslayer/ng_pktbuf/ng_pktbuf.c#L81
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Implementing a new MAC protocol for IEEE 802.15.4

[Daniel Krebs]

Hi Emmanuel,

One question: do you expect that network membership is rather dynamic, 
or rather static? (i.e. do nodes come and go due to mobility for 
example, or due to really long sleeping periods).


Depending on the answer to this question, some mechanisms may be more 
applicable than others...




The network will be kind of static, that is my nodes won't be moving 
around. But I expect to have nodes joining and leaving from time to 
time, i.e. nodes going offline for a short amount of time, and 
completely new nodes joining the network.


I would be really happy for any advice you could give :)

Best regards,
Daniel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Implementing a new MAC protocol for IEEE 802.15.4

[Daniel Krebs]

Hi Oleg,

PAN coordinators are only required for the beacon enabled mode in IEEE
802.15.4. 6LoWPAN, for instance, does not require this mode (I'm not even sure
if it is supported by the spec) and thus, there is no need for a PAN
coordinator or star topology.
That's unfortunately not the case. Please refer to the specs [1] at 
Section 5.3, especially the second paragraph. According to the 
specification a PAN coordinator is always required, even in Mesh 
topology where it may get dynamically elected.


It get's even better (5.5.2.3 Peer-to-peer data transfers):
In a peer-to-peer PAN, every device may communicate with every other 
device in its radio sphere of
influence. In order to do this effectively, the devices wishing to 
communicate will need to either receive
constantly or synchronize with each other. In the former case, the 
device can simply transmit its data using
unslotted CSMA-CA. In the latter case, other measures need to be taken 
in order to achieve synchronization.

Such measures are beyond the scope of this standard.
As receiving all the time is no option because of energy consumption you 
need some kind of synchronization. but that's [...] beyond the scope of 
this standard. Thank you IEEE.


That's why I don't aim to be compatible with IEEE 802.15.4-2006 in terms 
of the MAC-layer. Either I have a PAN coordinator or it advises me to do 
what I want.


Best regards,
Daniel Krebs

[1] 
https://openwsn.atlassian.net/wiki/download/attachments/688143/ieee802154-2006.pdf

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

Re: [riot-devel] Implementing a new MAC protocol for IEEE 802.15.4

[Daniel Krebs]

Hi Oleg again,


There's a third inside the OpenWSN stack using the TSCH (Time Slotted 
Channel Hopping) as specified in the IEEE 802.15.4e amendment. I'm 
currently spending some time to see how it could be used separately 
from the remaining OpenWSN stack, but don't expect any results before 
next month. 

I'll have a look at it, thanks for the pointer.


As there is so much change in all over the network stack at the moment, it
would be nice to know which (for me relevant) parts of the stack I should
use that are not subject to change shortly.

The relevant parts for a MAC layer implementation are probably netdev [1]
describing the interface to the transceiver driver, currently implemented for
at86rf2xx and XBEE, and the netapi [2] describing the interface of any layer
in the network stack, including the MAC protocol. There's also a sketch of the
new architecture made by Hauke some time ago [3].

I don't think it's realistic to say that these APIs won't change any more, but
I guess they should be stable enough to start implementing against them.
Yesterday I had a look at all the APIs and also found [3] som etime ago 
on the mailing-list. This helped a lot, thanks Hauke!
I summarized my findings in a diagram, now attached to this mail. I also 
inlcudes the MAC hardware-feature abstraction that Jonas mentioned 
yesterday.






  * No need to comply with IEEE 802.15.4 MAC schemes

Can you elaborate on this point?
As pointed out in my previous mail, I don't aim for compatibility with 
devices that strictly implement the specification, i.e. need a PAN 
coordinator. Reasons given in the other mail.




  * Do we need broadcasting?

Depends on your use case - for a generic implementation, definitely yes.
Remember that typical radio devices in this domain are omnidirectional, hence,
you cannot really distinguish between unicast and broadcast on the physical
layer.
The probem with duty-cycling is, that packets are not broadcast anymore 
per-se. You (the sender) need to make sure that every node has woken up 
at least one time while you have been sending your packet.




  * Add multi-hop / routing later? Is this even reasonable?

That's independent from the MAC layer. Can you elaborate on this?
When having multi-hop networks, you essentially have nodes outside the 
radio scope of each others. But you also have nodes in between that are 
in the reach of both. This can create a need for scheduling, imagine 
both nodes, that don't see each other, try to communicate at the same 
time with the node in between. But I didn't think this through all the 
way, I just wanted to state that I'm going to ignore this for now.


I really shouldn't have used the term routing here :P



  * Do we really need adaption to traffic load?

One of the main issues with contention based MAC protocols is that they are
heavily affected by the traffic load, so you should at least consider
different scenarios.
That's right. I can't really estimate my load at the moment apart from 
the fact that I'm not going to stream videos and that it will be more 
than one sensor value per node every 5 minutes :



  * LPEAS = Implicit synchronization
I wonder if you really want to go for synchronization for a simple contention
based protocol. Don't underestimate this challenge.

Did you have a look at the paper that expalins LPEAS? It's a really 
simple synchronization scheme.



Cheers,
Daniel


MAC_Overview.pdf
Description: Adobe PDF document
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Implementing a new MAC protocol for IEEE 802.15.4

[Daniel Krebs]

Hi Joakim,


+1 We use mostly Contiki-based applications presently and it would be
a big improvement if it was possible to get ContikiMAC duty cycling
working in RIOT as well.

Who is we if I may ask? Just curious.


# Requirements

  * Mesh topology = no single-point-of-failure
Is this not a requirement of the routing?
Did you have a look at the IEEE 802.15.4 specification? It's assumed to 
have a so called PAN coordinator that forces the network to a star 
topology. It's extendable to a tree of stars, but still you need a PAN 
coordinator in every region. This node is the mentioned single point of 
failure and additionally has increased energy consumption.


This is exactly what I don't want.


# Ideas / Questions

  * Do we need broadcasting?

Routing protocols might need it. RPL sends solicitation messages to
ask for routing information.
There are broadcasting schemes for the implementation I aim for, but 
they don't come for free in terms of energy consumption, like e.g. on a 
network bus. I'll elaborate about this later if you want.



  * Add multi-hop / routing later? Is this even reasonable?

Some kind of routing will be necessary for any useful applications, at
least some kind of hardware address to IPv6 address mapping must exist
to fill the neighbor cache. (e.g. RPL, NDP)
Sure. Hardware addresses are needed anyway to get your data delivered to 
the destination node.



Best regards,
Daniel Krebs
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Implementing a new MAC protocol for IEEE 802.15.4

[Daniel Krebs]

Hi Jonas,

Better don´t look at [2] for now ;). Currently that PR is based on a 
deprecated proposal that does not poperly use the netdev interface. I 
hope I will have time for an update of this PR this week. Even if that 
is not what you are searching for, maybe it could be used to make this 
a base of an more advanced MAC layer. The intention of [2] is to 
provide an implementation of CSMA-mechanisms, random backoff-time when 
the channel is busy and acknowledge handling. Since this procedure is 
different for each driver (Hard-MAC vs. Soft-MAC) this [2] adaption 
MAC-layer will be necessary to avoid re-implementing in each 
radio-driver.


You're right that it's good idea to have some adaption layer on top of 
the device drivers that enables usage of hardware MAC mechanism s while 
providing a software approach for transceiver that don't support this. 
The question here is if it's possible to meet the tight timings. Need to 
investigate further.



We also made some research in this field. Since we want to use our 
sensor-nodes in combination with Linux, we came to the conclusion that 
a MAC layer accordingly to the IEEE 802.15.4 standard will fit most 
for us. The biggest benefit is the compatibility to all IEEE 802.15.4 
devices. Also a high configurability (e.g. the beacon interval length) 
is a feature of this standard. There are some optional mechanisms like 
GTS that don´t have to be implemented in the first step. But I agree, 
there might be easier duty-cycling MAC-layers. Since the architecture 
of the network stack allows to choose different MAC layers there is no 
problem of having different ones.


I'm going to need a Linux-bridge, too. The packets my MAC protocol will 
send will also be 802.15.4-2006(?) compatible, but the channel access 
scheme will be different. So at least sniffing should be no problem. In 
the end I hope to be able to use my RIOT implementation on native for 
this bridge, but didn't look into further.




BTW: Is this also publicly availble somewhere?


I did a quick search and wasn't able to find it publicly :(


As I understand it, the routing protocol is located on top of any MAC 
protocol. The mechanisms of the MAC protocol will be transparent to 
the upper layers.


That's right. But at least multi-hop networks have some implications on 
the MAC scheme. Just wanted to state that this is not my first priority, 
because I don't want to deal with this for now.



For the sleeping periods we might have to use a low-power timer 
(mostly low speed clock oscillator, 32khz or so), since most 16Mhz 
oscillators consume to much energy for long sleeping periods.


Sure. That's why I started familiarizing with RIOT by implementing the 
RTT peripheral for the samr21-xpro. The RTC, at least on this board, 
might be the only peripheral that can run in every power mode and wake 
up the MCU.


Best regards,
Daniel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] help

[Daniel Krebs]

I also intend to have OTA in my project. I'm going to help/implement it 
if that's neccessary, but it's still a milestone that's further down my 
roadmap.


Am 08.05.2015 um 09:04 schrieb Baptiste Clenet:
I would add that we all want this feature to be added to RIOT and we 
are pleased for any help to implement it :-)


2015-05-08 6:50 GMT+02:00 Ludwig Ortmann ludwig.ortm...@fu-berlin.de 
mailto:ludwig.ortm...@fu-berlin.de:


Hi,

This is often called firmware update or OTA for (firmware)
over the air.

We don't have support for this yet, but it is planned, and there
is some information in the wiki (look for OTA).

Cheers,
Ludwig

Am 8. Mai 2015 00:50:30 MESZ, schrieb Sonda Bousnina
sondabousn...@gmail.com mailto:sondabousn...@gmail.com:
Hi,
Thanks for your quick reply
yes exactly, that what I mean

On Fri, May 8, 2015 at 12:35 AM, Kaspar Schleiser
kas...@schleiser.de mailto:kas...@schleiser.de
wrote:

 Hi,

 On 05/08/15 00:23, Sonda Bousnina wrote:
  I'm wondering if it is possible to flash or update the code
in the
target
  board in real time while it is working without switching it off.
 Not sure I understand the question.

 You mean, add/replace code while the device is running?

 Are you referring to updating the device in the field?

 Kaspar
 ___
 devel mailing list
 devel@riot-os.org mailto:devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel


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




--
/Clenet Baptiste
FR: +33 6 29 73 05 39/
/Élève-Ingénieur ESEO Angers, dernière année, spécialisation: 
Architecte système temps réél embarqué//

/
/Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014

/


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


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