Re: [riot-devel] RIOT Research Seminar: a short report

Hi Ken, there used to be OpenWSN support in RIOT but due to a missing maintainer on our side (we did not find the time to adapt it to our rapidly changing APIs for timers and networking) we had to remove it for now [1]. Cheers, Martine [1] https://github.com/RIOT-OS/RIOT/pull/6359 2017-04-29

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Apr 25, 2017 5pm - 10pm (RIOT Events)

n;+HAW+Hamburg=en>) > > *Calendar* > RIOT Events > > *Who* > • > Martine Lenders - creator > > Invitation from Google Calendar <https://www.google.com/calendar/> > > You are receiving this email at the account peterschme...@gmail.com > because you ar

Re: [riot-devel] RFC: packaging "start_network.sh" on IoT-LAB

Hi, 2017-04-20 10:23 GMT+02:00 Alexandre Abadie : > Then it should be quite straightforward but not very useful since the > command on its own is already very simple. > Besides that the command can already been used from A8 nodes. > I think it's even simpler if I

Re: [riot-devel] RFC: packaging "start_network.sh" on IoT-LAB

Hi Gaëtan, This sounds great! Would it be possible to merge this with the current version of the script (say with an additional parameter), so we can use it in the `iotlab-term` target version of the border router [1]? Cheers, Martine [1]

Re: [riot-devel] Sending the udp packets does not work with the xbee module

Hi, 2017-03-21 11:09 GMT+01:00 Wiegel, Friedrich (IAI) : > […] I try to get my hands on the hardware, and try it out myself. > Is there a way to avoid the failed assertion when I increase the number of > interfaces to 2 but use one or is it only one interfaces

Re: [riot-devel] Sending the udp packets does not work with the xbee module

gt; Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Martine Lenders > Gesendet: Montag, 20. März 2017 17:07 > An: RIOT OS kernel developers <devel@riot-os.org> > Betreff: Re: [riot-devel] Sending the udp packets does not work with the xbee > module >

Re: [riot-devel] Sending the udp packets does not work with the xbee module

> Friedrich > > -Ursprüngliche Nachricht- > Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Martine Lenders > Gesendet: Montag, 20. März 2017 15:08 > An: RIOT OS kernel developers <devel@riot-os.org> > Betreff: Re: [riot-devel] Sending the udp packets do

Re: [riot-devel] Sending the udp packets does not work with the xbee module

Hi Friedrich, the xbee module has some tricky restrictions on sent packets. Did you make sure that the (link-layer) payload fits these? Regarding debugging: Try compiling with CFLAGS_OPT=-O0 and CFLAGS="-g3 -gdwarf-3". This usually leads to more satisfying results. I don't have an xbee module at

Re: [riot-devel] netdev2 is now netdev

Hi, 2017-03-15 11:54 GMT+01:00 Oleg Hahm <oliver.h...@inria.fr>: > Hi Martine! > > Thanks for the info. Just a short clarification question: > > On Wed, Mar 15, 2017 at 11:46:47AM +0100, Martine Lenders wrote: > > The only pitfall that might be a problem I was able t

[riot-devel] netdev2 is now netdev

Hi, with the last network device based on gnrc_netdev removed we were now able to rename netdev2 to netdev [1], which is now the only (network stack independent) API to access a network device. The only pitfall that might be a problem I was able to identify when porting is that the adaption layer

Re: [riot-devel] Socket #0

Hi Sam, 2017-01-12 14:06 GMT+01:00 Sam Kumar : > Hi Martine, > I will work on testing it with sock and PR #6004, but it may take some > time since I might need to port the interface from conn to sock. > It seems to me that conn is deprecated and that sock is its replacement

Re: [riot-devel] Socket #0

Hi Sam, can you try with PR #6004 which ports POSIX sockets from conn to sock? There are still some kinks in this PR, but I plan to fix them until the release. On another note: the conn implementation of sockets was never tested with TCP (since there was no TCP implementation then), but feel free

[riot-devel] New Event: CANCELLED @ Every 2 weeks from 2pm to 3pm on Wednesday (RIOT Events)

You have been invited to the following event. Title: CANCELLED When: Every 2 weeks from 2pm to 3pm on Wednesday Berlin Calendar: RIOT Events Event details:

Re: [riot-devel] Greetings from the 33c3 and Pointer to an interesting USB talk

Hi, I'll also be there. But I won't make it to a talk that is also interesting for ongoing discussions in the RIOT community: "Wheel of Fortune - Analyzing Embedded OS Random Number Generators" [1]. Streaming is at [2]. [1] https://fahrplan.events.ccc.de/congress/2016/Fahrplan/events/7949.html

[riot-devel] Canceled Event: Hack'n'ACK @ Tue Dec 27, 2016 5pm - 10pm (RIOT Events)

BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:CANCEL X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com BEGIN:VTIMEZONE TZID:Europe/Berlin X-LIC-LOCATION:Europe/Berlin BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200

Re: [riot-devel] SiLabs Gecko

Hi Akshay, I fear you have to be a bit more specific than that. What application are you using e.g., which network stack? Also, I might be mistaking but it seems like there is no RF support for the EZR32LG in master yet. Maybe that is the problem? Cheers, Martine 2016-12-08 8:34 GMT+01:00 Akshay

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Nov 29, 2016 5pm - 10pm (RIOT Events)

n;+HAW+Hamburg=en>) > > *Calendar* > RIOT Events > > *Who* > • > Martine Lenders - creator > > Invitation from Google Calendar <https://www.google.com/calendar/> > > You are receiving this email at the account peterschme...@gmail.com > because you ar

[riot-devel] GitHub's new features - A release managers assessment

Dear RIOTers, due to me being the release manager for the first release after GitHub rolled out a bunch of new features I came a lot in contact with them. I thought it might be beneficial to share my impressions and opinions about these features and how we could utilize them as the RIOT community

[riot-devel] RIOT Release 2016.10

Dear RIOTers, we are happy to announce the ninth official release of the RIOT: --- * RIOT 2016.10 * --- This release provides a lot of new features as well as it fixes several major bugs. Among these new features are the new simplified

[riot-devel] The state of 2016.10

Hi, as many of you might have noticed: we did not release yesterday. This was due to the fact that many errors were still found. As of the writing of this mail we now have 11 open bugfixes PR'd to master (without any backports yet) and 3 merged bugfixes that still need backporting to the

Re: [riot-devel] Fwd: TI-ez430-Chronos

Hi Harshad, I don't have any specific project in mind, but maybe using another device as a cc11xx border router you can use the on-board radio (I might be mistaking so if there is non, sorry for the noise) to sync your watching using our SNTP implementation [1]. Mind that IPv6 over cc11xx is not

Re: [riot-devel] Third party snippets

Hi Jose, the "RIOT way" or rather the GNRC way would be to extend (in the object oriented sense) `gnrc_netdev2_t`, similar how `gnrc_netdev2_ieee80215.c` and `gnrc_netdev2_eth.c` already did. Hope I was able to helpful. Cheers, Martine 2016-11-04 19:11 GMT+01:00 Anon Anonymous

Re: [riot-devel] Release 2016.10 - One more day

I meant of course 2016-11-01 17:00 +0100 Am 31.10.2016 7:51 nachm. schrieb "Martine Lenders" <mlend...@riot-os.org>: > Dear release-sprinting IoTlers, > the feature freeze is upon us, but there are still 17 PRs open (9 of > those non-bugfixes, one is just wait

Re: [riot-devel] Release 2016.10 - One more day

Dear release-sprinting IoTlers, the feature freeze is upon us, but there are still 17 PRs open (9 of those non-bugfixes, one is just waiting for Murdock to finish). Because of those 9 I move the feature freeze to tomorrow 5pm (2016-01-01 17:00 +0100). But everything that isn't merged by then will

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Oct 25, 2016 5pm - 10pm (RIOT Events)

Oops, sorry that was a little trigger happy (I just prepared that e-mail). We are not set-up yet. I'll notify you again when we are! Kind Regards, Martine 2016-10-25 16:39 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>: > Hi, > we are now set-up in Berlin for this month's.

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Oct 25, 2016 5pm - 10pm (RIOT Events)

n;+HAW+Hamburg=en>) > > *Calendar* > RIOT Events > > *Who* > • > Martine Lenders - creator > > Invitation from Google Calendar <https://www.google.com/calendar/> > > You are receiving this email at the account peterschme...@gmail.com > because you are subscribed

Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Oct 19, 2016 2pm - 3pm (RIOT Events)

Hi, find attached the cleaned up version of the minutes of the meeting. You can find it also in the Wiki [1]. The live notes can be found in the previously linked etherpad [2]. Cheers, Martine Attendees * Martine (FU Berlin) * Peter (HAW Hamburg) * Cenk (HAW Hamburg)

Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Oct 19, 2016 2pm - 3pm (RIOT Events)

Hi, due to the usual problems we changed over to Mumble [1] now. Please join us at Server: riot-labs.de Port: 64738 PW: riot Sorry and cheers, Martine [1] http://wiki.mumble.info/wiki/Main_Page 2016-10-19 13:56 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>: > Hi, > for thi

Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Oct 19, 2016 2pm - 3pm (RIOT Events)

2016-10-18 17:30 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>: > Hi, > > I prepared an agenda at [1]. If anyone likes to add to that, please feel > free. Apart from that (see first agenda item) I like to propose to move from > PlaceCam to Mumble. Apart from some setu

Re: [riot-devel] Release 2016.10

ed during the release but are no new features or platforms. Since both "Known issue" and the "Under review for release" columns are rather large now, I'll to get things a little bit more manageable in the next few days. @maintainers: The project panel is now free to be edited by any

Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Oct 19, 2016 2pm - 3pm (RIOT Events)

Hi, I prepared an agenda at [1]. If anyone likes to add to that, please feel free. Apart from that (see first agenda item) I like to propose to move from PlaceCam to Mumble. Apart from some setup problems (which can easily be documented in the Wiki) my experience with Mumble was much more

Re: [riot-devel] gnrc tcp not working

Hi, what board are you using (we support multiple arduino boards) and what kind of network device are you using to communicate? Also, since gnrc_tcp_srv isn't merged yet: can you try gnrc_networking (if it fits) on master? Cheers, Martine 2016-10-13 13:17 GMT+02:00 Doni Pradana

Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Oct 5, 2016 2pm - 3pm (RIOT Events)

Hi, 2016-10-05 15:27 GMT+02:00 Oleg Hahm <oliver.h...@inria.fr>: > Hi! > > Sorry, couldn't make it, but some comments/questions: > > On Wed, Oct 05, 2016 at 03:16:11PM +0200, Martine Lenders wrote: >>* How to prevent server problems we had at the weekend? >>

Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Oct 5, 2016 2pm - 3pm (RIOT Events)

Dear RIOTers, as the Google Calendar reminds is: tomorrow is our "biweekly" virtual meeting. I started an agenda at [1]. Feel free to add to it if you think something needs to be discussed. Cheers, Martine [1] http://www.yourpart.eu/p/riot-2016-10-05-virtual-meeting 2016-10-04 14:00 GMT+02:00

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Sep 27, 2016 5pm - 10pm (RIOT Events)

s.google.com/maps?q=FU+Berlin;+HAW+Hamburg=en>) > > *Calendar* > RIOT Events > > *Who* > • > Martine Lenders - creator > > Invitation from Google Calendar <https://www.google.com/calendar/> > > You are receiving this email at the account peterschme...@gmail.

Re: [riot-devel] Easy ping

Hi Baptiste, that depends on what you mean by reachable. Even for ICMPv6 ping (which is used with the shell ping command) you need some "server", that handles the request and issues a reply. If that server is not present the node will not reply to pings, even if it is reachable in the sense that

Re: [riot-devel] Easy ping

Hi Baptiste, have you had a look at the implementation of the ping shell command? Another way would be to (re-)implement ping using conn_ip (or sock if merged). In that case, if you want it relly easy you don't even have to implement ICMPv6 ping but can do whatever you want ;-). Cheers,

Re: [riot-devel] char* to int and vice versa

Hi, sprintf (and it's siblings) should be avoided in production code though, since in newlib these functions are quite large. I'm not sure if this exist on all platforms, but there is also atoi()'s counterpart itoa(). Cheers, Martine Am 05.09.2016 6:44 nachm. schrieb "Marc"

Re: [riot-devel] Canceled Event: Biweekly virtual meeting @ Wed Dec 28, 2016 2pm - 3pm (RIOT Events)

Oops, sorry. I was cleaning out my calendar and forgot that was connected to the official one... But I guess nobody else wants to meet at that day, too. Best regards, Martine Am 05.09.2016 6:30 nachm. schrieb "Martine Lenders" <authmille...@gmail.com >: > This even

Re: [riot-devel] arduino-uno support

common and difference lives in > boards/arduino-uno and boards/arduino-duemilanove. > > Should I push -f on original PR [1] ? > Or it is cleaner to close [1] and open a new PR ? > > Regards, > Laurent > > [1]https://github.com/RIOT-OS/RIOT/pull/5451 > > 2016-05-25 22:

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Aug 30, 2016 5pm - 10pm (RIOT Events)

Hi Oleg, 2016-08-30 16:14 GMT+02:00 Oleg Hahm : > I'm still in Dagstuhl the whole week. I know :-). Cheers, Martine ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] BorderRouter: Global IPV6 address lost in ncache after UDP message sent

icuss with OpenThread > implementation? > > Cheers, > > 2016-08-29 19:56 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>: >> Hi, >> can you check if this is https://github.com/RIOT-OS/RIOT/issues/5467? >> >>> Why or how can a node be removed

Re: [riot-devel] BorderRouter: Global IPV6 address lost in ncache after UDP message sent

Hi, can you check if this is https://github.com/RIOT-OS/RIOT/issues/5467? > Why or how can a node be removed from ncache? Why the node does not automatically reconnect with BR? As the implementer of the neighbor discovery I can say this: because the neighbor discovery is sh** ;-). It was written

[riot-devel] gprof for non-native boards

Hi, for stack memory optimizations in GNRC I need some kind of tool to analyze the call-path of its threads (the stackusage of each function itself can easily determined using GCC [1]). After some experiments with some static solutions (I basically went through the list here [2]) I wasn't able to

Re: [riot-devel] RFC: development procedures

Hi Kaspar, 2016-08-19 22:34 GMT+02:00 Kaspar Schleiser <kas...@schleiser.de>: > Hi, > > On 08/19/2016 08:05 PM, Martine Lenders wrote: > >>> Not necessarily. I would put such links to comments in the commit body > >>> anyway and that is ignored by --aut

Re: [riot-devel] RFC: development procedures

Hi, Am 19.08.2016 7:51 nachm. schrieb "Kaspar Schleiser" <kas...@schleiser.de>: > > Hey, > > On 08/19/2016 05:54 PM, Martine Lenders wrote: > > Not necessarily. I would put such links to comments in the commit body > > anyway and that is ignored by --aut

Re: [riot-devel] RFC: development procedures

Hi, 2016-08-19 17:25 GMT+02:00 Kaspar Schleiser : > Hey, > > On 08/19/2016 05:15 PM, Oleg Hahm wrote: > > Hence, I would propose to somehow reference the addressed > > comment in the commit message. What do you think? > > That would rule out --fixup commits (and thus

Re: [riot-devel] Fragmentation support in IP

Hi Adeel, What do you mean by "lost fragment recovery"? To my knowledge there is no such thing in 6LoWPAN fragmentation. Regards, Martine Am 19.08.2016 12:59 vorm. schrieb "Adeel Mohammad Malik" < adeel.mohammad.ma...@ericsson.com>: > Hi again Thomas, > > Do you mean that 6LoWPAN in RIOT does

Re: [riot-devel] conn f2f (+ remote) meeting

8:25:50AM +0200, Martine Lenders wrote: > > Hi, > > > > 2016-08-17 19:28 GMT+02:00 Oleg Hahm <oliver.h...@inria.fr>: > > > > > Hey folks, > > > > > > On Mon, Aug 15, 2016 at 04:11:48PM +0200, Martine Lenders wrote: > > > > as promi

Re: [riot-devel] conn f2f (+ remote) meeting

Hi, 2016-08-17 19:28 GMT+02:00 Oleg Hahm <oliver.h...@inria.fr>: > Hey folks, > > On Mon, Aug 15, 2016 at 04:11:48PM +0200, Martine Lenders wrote: > > as promised: here is the agenda for the meeting next Wednesday: > > http://yourpart.eu/p/netapp-api-riot

Re: [riot-devel] conn f2f (+ remote) meeting

s, Martine 2016-08-16 15:26 GMT+02:00 Peter Kietzmann <peter.kietzm...@haw-hamburg.de>: > Mi Martine, > > no objections from my side. I would like to join virtually. > > Regards > Peter > > > Am 16.08.2016 um 14:12 schrieb Martine Lenders: > >> Hi, >> a

Re: [riot-devel] conn f2f (+ remote) meeting

://wiki.mumble.info/wiki/Main_Page 2016-08-15 16:11 GMT+02:00 Martine Lenders <m.lend...@fu-berlin.de>: > Hi, > as promised: here is the agenda for the meeting next Wednesday: > http://yourpart.eu/p/netapp-api-riot > > Cheers, > Martine > > 2016-08-11 15:33 GMT+02:00

[riot-devel] conn f2f (+ remote) meeting

Hi all, we finally want to discuss the overhaul of conn next week. The meeting will be held on Wednesday next week (August 17th) at 1pm (UTC+0200). Remote participation will be possible, we'll try to find a tool that everyone is comfortable with. I'll provide you with an agenda for the meeting

Re: [riot-devel] qemu-i386 port

r up to date with the other platform implementations, >>especially the stdio is very hacky on that board. >> >>/Joakim >> >>On Aug 9, 2016 12:51, "Martine Lenders" <m.lend...@fu-berlin.de> wrote: >>> >>> Hi, >>> we now have the thir

[riot-devel] qemu-i386 port

Hi, we now have the third person wondering about the qemu-i386 port. Fact is, it doesn't work (we do not even have the unittests activated anymore). Is there a reason why we did not drop it yet (except making all the good work by René void)? Or are we planning to provide better support for it in

Re: [riot-devel] Problem with "make" -lm missing.

Oops, forgot to provide the link for [1]: https://github.com/RIOT-OS/RIOT/wiki/Family%3A-native#dependencies 2016-08-09 9:19 GMT+02:00 Laurent Navet : > Hi, > > Have you multilib support enabled and installed ? > > https://github.com/RIOT-OS/RIOT/wiki/Family:-native > >

Re: [riot-devel] Problem with "make" -lm missing.

Hi, have you installed gcc-multilib and the other dependencies [1]? Cheers, Martine 2016-08-09 9:02 GMT+02:00 MiTsArAs Jimaras : > Hello to all. > I am trying to build an app with "make clean all flash term" on native > platform, and all I get as a result that: > >

Re: [riot-devel] MRF24J40 radio module driver - not used States

Hi Neo, the general fallback for an unsupported option is to return `-ENOSUP` for an unsupported option type and `-EINVAL` for an unsupported option value. Hope that was helpful. Cheers, Martine 2016-08-08 23:10 GMT+02:00 Neo : > Hello everyone, > I have just a question about the

Re: [riot-devel] My plans for 2016.10 release

Hi, 2016-07-16 17:11 GMT+02:00 Martine Lenders <mlend...@riot-os.org>: > * Network layer/NDP overhaul: expect a model proposal and [sic] of July. I did this as promised about a week ago btw [1]. Might have been got lost in the mail storm during the release ;-). > L

Re: [riot-devel] Απ: Απ: Απ: Απ: Make bootable .elf file!

to run it through > terminal, on native architecture. > > Now I want to do the same with qemu-i386 architecture! That's all! > > > > > -- > *Από:* devel <devel-boun...@riot-os.org> εκ μέρους του Martine Lenders < > m...@martine-len

Re: [riot-devel] Απ: Απ: Απ: Make bootable .elf file!

Hi, can you please clarify what you are trying to achive? As Ludwig already pointed out to you [1] RIOT isn't meant to run in a VM (or on a PC for that matter). Running RIOT as native (in a normal process, not in a VM!) should suffice for most use-cases that involve virtualization, and for running

Re: [riot-devel] Hack'n'ACK July 2016

Hi, after some (still not 100% solved) technical difficulties I was finally able to establish a conference call at the usual address: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- Feel free to join! Cheers, Martine [1]

[riot-devel] Hack'n'ACK July 2016

Hi, tomorrow we have our monthly Hack'n'ACK again. Oleg and I will most likely sit together at FU Berlin and are happy about any other dev from Berlin that likes to join. Hamburg & Saclay are you holding a Hack'n'ACK at your location, too? Cheers, Martine

[riot-devel] My plans for 2016.10 release

Hi, at the strategy meeting today the (bigger) topics of what is still on my plate came up. So this is my list from most complex to least time consuming, to least: * Network layer/NDP overhaul: expect a model proposal and of July. Let's discuss this then and I'll provide an actual implementation

Re: [riot-devel] Global IPV6

Hi Baptiste, as of now no such event handler exist, but I note such feature it down for the network layer overhaul (previously known as neighbor discovery overhaul). Expect some early API proposals the week after IETF. Cheers, Martine 2016-07-13 16:51 GMT+02:00 Baptiste Clenet

Re: [riot-devel] LITTLE_ENDIAN conflicts

Hi Kees, I think there was some problem with this macro in newlib, that's why we define it only in certain cases. From the usage point it only seems to be used by `sys/quad_math/` and the PCI implementation of the x86 port. Both were introduced by René Kijewski, maybe he can shed some light on

Re: [riot-devel] Organizing device drivers

Hi Peter, I think I prefer the `common` solution most, though we need to be careful how interaction between the `common` module and the actual driver would work. #ifdef different variants is as you said to use a mixture of radio devices (e.g a samr21-xpro with an OpenLabs RaspPi hat attached) and

Re: [riot-devel] devel Digest, Vol 41, Issue 7

;2. Re: Byte array should be uint8_t, not char (Kees Bakker) >>3. Re: Byte array should be uint8_t, not char (Kees Bakker) >>4. Is samr21-xpro SPI working (Kees Bakker) >>5. Re: Auto-configure interface on RIOT - SAMR21-xpro >> (Martine Lenders) >>

Re: [riot-devel] Problem with UDP and SAMR21-XPRO

Yes, well done +1 :-) Cheers, Martine 2016-07-04 16:49 GMT+02:00 MATTIA ANTONINI <mattia.antoni...@studenti.unipr.it>: > Done! I hope I've done well, I followed your instructions. > > Cheers, > Mattia > > 2016-07-04 15:49 GMT+02:00 Martine Lenders <m...@martine-len

Re: [riot-devel] Problem with UDP and SAMR21-XPRO

io with gnr_networking > and microcoap_server and all is working :) > Which is the procedure to push the code? I've never done it before :) > > Cheers, > Mattia > > > 2016-07-04 10:56 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>: >> >> Hi, >> I finally will have s

Re: [riot-devel] Transceiver : Reception level

Oops just saw I made an error there: the type is called gnrc_netif_hdr_t Cheers, Martine Am 04.07.2016 12:29 nachm. schrieb "Baptiste Clenet" <bapcle...@gmail.com>: > Thanks Martine, I'll try when I've got time > > 2016-07-02 12:27 GMT+02:00 Martine Lenders <m...

Re: [riot-devel] Problem with UDP and SAMR21-XPRO

Hi, I finally will have some time to look into it, but it would also be great if there would be an issue for that on GitHub and maybe to involve Takuo, since it is their PR that seem to have broken it. Cheers, Martine 2016-06-24 12:01 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>

Re: [riot-devel] RIOT, Windows, and Code Composer Studio

Hey Clark, that sounds something like the path to your make installation isn't set in the environment variable PATH. I know from the past, that you can set them somewhere in the system config, but I haven't used Windows in years and when I did I had it in German, so don't ask me were exactly (in

Re: [riot-devel] Problem with UDP and SAMR21-XPRO

Hi Mattia, hi Alex, due to having my head mostly on the defense of my master thesis I have next monday I wasn't able to look into this as promised. :( Thanks however Mattia for the in-depth analysis and the bisect! As soon as I find some head space I will look into it, too. Cheers, Martine

Re: [riot-devel] MAC Layer Implementation in RIOT

he features provided by the device. Hope this made things clearer for you. Best regards, Martine Lenders [1] https://github.com/RIOT-OS/RIOT/pull/3730 [2] https://github.com/RIOT-OS/RIOT/pull/4180 [3] https://github.com/RIOT-OS/RIOT/pull/4184 [4] https://github.com/RIOT-OS/RIOT/pull/4213 [5] https://openws

Re: [riot-devel] RIOT Vs Iotivity, AllJoyn, Thread

Hi, 2016-06-08 20:29 GMT+02:00 Iván Briano : > On Wed, 08 Jun 2016 19:58:50 +0200, Baptiste Clenet wrote: > > 2016-06-08 17:14 GMT+02:00 Emmanuel Baccelli >: > > > > > Hi Ivan, > > > it would be great to have it as a pkg indeed! > > > That's

Re: [riot-devel] API CHANGE: msg_t now carries void pointers

Hi again, sorry, forgot to quote the PR that changed it: [2]. Cheers, Martine [2] https://github.com/RIOT-OS/RIOT/pull/5498 2016-06-03 14:02 GMT+02:00 Martine Lenders <authmille...@gmail.com>: > Hello revising IOTlers, > > another day another API change: After some discussion in

[riot-devel] API CHANGE: msg_t now carries void pointers

Hello revising IOTlers, another day another API change: After some discussion in [1] we decided to unify the typing of pointers of unspecified type. The first fall-out from that discussion was the changing of the pointer of the `content.ptr` field of `msg_t`. It is now `void *` instead of `char

[riot-devel] API change in netdev2

Hi, quick note to all network device driver and MAC protocol developers: The API of netdev2 was changed slightly [1] in that the event_callback now doesn't expect a `void *` argument anymore. This argument has proven to be superfluous, since the data was always stored in the `netdev2_t` struct

Re: [riot-devel] Notification: Hack'n'ACK @ Tue May 31, 2016 5pm - 10pm (RIOT Events)

Hi, we finally managed to set-up here in Berlin. If you like to join via PlaceCam [1] feel free to do so at http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- Cheers, Martine [1] https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation

Re: [riot-devel] arduino-uno support

Hi Laurent, don't want to discourage you, but you do not have to update on this mailing list for every step you do. Just the major ones are enough ;-). Those of us interested (as for example me) will most likely follow your PR anyways. BTW: when you write your wiki page on the board can you add a

Re: [riot-devel] Murdock and merge commits

Yes 2016-05-25 15:13 GMT+02:00 Kaspar Schleiser <kas...@schleiser.de>: > Hey, > > On 05/25/2016 03:03 PM, Martine Lenders wrote: > >> What was the original intention of testing for "rebaseability"? Isn't > > that implicitly checked by github's merge

Re: [riot-devel] Murdock and merge commits

Hi Kaspar, > What was the original intention of testing for "rebaseability"? Isn't that implicitly checked by github's merge test? It's not the rebaseability that is checked, but to help against the problem you cited: including changes from master. On the other hand, I would also say that

Re: [riot-devel] Propagation of prefix

Hi Jose, If you set a prefix at the LoWPAN interface (just add a /64 prefixed address to it), router advertisements should start to disseminate the prefix throughout the LoWPAN. To set-up something like that automatically you would need a uhcp (dist/tools/uhcpd) server somewhere reachable for the

Re: [riot-devel] [riot-users] Unable to ping gnrc_border_router using Zolertia RE-Mote

* > > Regards, > Suman > > On Wed, May 18, 2016 at 8:58 PM, Martine Lenders <authmille...@gmail.com> > wrote: > >> Hi, >> I already answered this mail on the devel-mailinglist, but just to be >> complete and for people only r

Re: [riot-devel] gnrc_border_router issue on OpenMote-cc2538

** > *** > Please suggest what should I try. > > Regards, > Suman > > On Wed, May 18, 2016 at 8:21 PM, Martine Lenders <m...@martine-lenders.eu> > wrote: > >> Hi Alessandro, >> have you checked out the

Re: [riot-devel] gnrc_border_router issue on OpenMote-cc2538

Hi Alessandro, have you checked out the README? You have to run the `gnrc_border_router` example with the `dist/tools/ethos/start_network.sh` script, since it parallelises stdio and network traffic over the same UART. With pyterm your input might be interpreted as network packets. Cheers, Martine

Re: [riot-devel] Border-router and multicast

net <bapcle...@gmail.com>: > > 2016-05-12 21:03 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>: > >> Thanks Martine, I will try tomorrow > >> > >> 2016-05-12 14:10 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>: > >>> Hi, > >>&

Re: [riot-devel] arduino-uno support

Hi Laurent, definitely! If you have a working port, provide a PR as soon as you see fit. I personally only have a Arduino Leonardo, but it shouldn't be hard to find an Arduino Uno. Also: the simulated one could be helpful for future testing runs. Keep us in the loop :-). Cheers, Martine

Re: [riot-devel] Border-router and multicast

interface (wasn't able to test that) it should work. Cheers, Martine 2016-05-12 13:34 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>: > Hi Baptiste, > yeah in that case multicast seems like the best thing to go. But how about > using an actual global address then: (ff:1e::1 e.g.;

Re: [riot-devel] Border-router and multicast

t;kas...@schleiser.de>: > > Hey, > > > > On 05/11/2016 09:42 PM, Martine Lenders wrote: > >> (2) I'm not sure you add multicast routing entries this way in Linux. > > > > You don't. If really desired, you have to use the "local" routing table.

Re: [riot-devel] Border-router and multicast

Hi again, 2016-05-11 21:42 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>: > Hi Baptist, > > First of all, sorry for the late reply. > > 2016-05-11 10:05 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>: > >> Ok Martine, >> >> In the start_net

Re: [riot-devel] Border-router and multicast

Sorry, was (and still am) otherwise occupied. Will look into it tonight, tomorrow at the latest though. Regards, Martine 2016-05-10 18:05 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>: > Ok Martine, Have you found any solution yet? > > 2016-05-10 9:48 GMT+02:00 Martine Lender

Re: [riot-devel] Border-router and multicast

Hi Baptiste, since IEEE 802.15.4 itself is not a multicast medium (it only supports broadcast), and we don't have MLD implemented at this point (which configures routers for multicast), multicast is indeed tricky at the moment. Let me try something out and I come back to you. Cheers, Martine

Re: [riot-devel] MIPS port

Hey Leon, we have a "WIP" label for PRs so if you have something that *you* deem presentable: go for it ;-). In general I always think its better to be transparent to the community about what you do. This way duplicate work is prevented and you benefit from input from the community. Regards,

Re: [riot-devel] PowerProfiler

Hi, 2016-04-22 15:44 GMT+02:00 Michael Andersen : > I'm back on Monday, I'll set it up ASAP for you when I arrive. > Since I had some problems measuring power consumption with the IoT-Lab, using this might be really great to get some energy consumption measurements on the

Re: [riot-devel] STM32+CC1101+Border Router error

Hi, make sure you really have the newest master. A fix for that [1] was just merged yesterday. Cheers, Martine [1] https://github.com/RIOT-OS/RIOT/commit/8968b7602f3422 2016-04-21 12:29 GMT+02:00 Viet Hoang : > Hello Riot. > I was cloned newest version of RIOT and

[riot-devel] Fwd: Re: Border Router using tunslip error

Can somebody help further? -- Weitergeleitete Nachricht -- Von: "Viet Hoang" <hoangthevie...@gmail.com> Datum: 20.04.2016 9:30 nachm. Betreff: Re: [riot-devel] Border Router using tunslip error An: "Martine Lenders" <authmille...@gmail.com> Cc: Hi M

Re: [riot-devel] Help needed: iotlab-m3 accessory quest.

Hi Paul, as far as I know the solution most other developers used were to just solder cables directly to the plug. But maybe we can find a nicer solution with the help of the IoT-Lab people :D. Cheers, Martine Am 19.04.2016 19:08 schrieb "Andreas "Paul" Pauli" < andreas.pa...@haw-hamburg.de>: >

[riot-devel] RPL as fix for the border router issue

Hi, at the f2f meeting today we Oleg proposed to have RPL run on the border router as an alternative to [1] (since RPL always uses link-local addresses as next hop, the neighbor cache would never be asked for GUAs). This seemed to work (it ran for about 30 min), but we (Cenk, Hauke and I)

<    1   2   3   4   >