[riot-devel] Open WSN

Ben@vpt-systems.co.za ben at vpt-systems.co.za
Wed Sep 23 05:35:43 CEST 2015

Hi Thomas

Thank you

I have with keen interest followed the development of RIOT is and see 
progress is great.

Currently I have a product running on Contiki where I use the mesh 
network side to route my data through if I can not see a break out. 
Coupled with "Drowsy"  I can get a decent battery life out of my nodes.  
All is fine but debugging and documentation is the biggest problem with 

I'm in an investigation phase where I evaluate all the OS's out there 
(embedded of course) to address my developing needs.
I need to run on a few platforms
with preference to the CC13xx.

I would maybe like "donate" some time to RIOT and the mesh networking 
side but can only do so after 16 /10 /2015
Where can I start or I can I just download from GITHUB and start? 
Obviously there must be a co-ordinated effort as I have seen things get 
done by RIOT'ers
Once I have something to add, to whom can I submit for approval?

Kind regards
Ben Duvenage

On 2015-09-21 09:12 PM, Thomas Eichinger wrote:
> Hi Ben,
> great to hear from you and about your interest in RIOT. First of all
> I am really sorry for the delayed reply.
> In our current approach we pull in the network stack part of OpenWSN
> and apply patches with an adaption layer to map OpenWSN's hardware
> abstraction to RIOT's driver model. Unfortunately the current version
> used in RIOT master is quite outdated but we plan to change this and
> address problems we found during the last plug test soon.
> Right now we are kept busy getting a new RIOT release ready but it
> improvements to OpenWSN support have a very high priority for the time
> after the release is out.
> (This should happen in the next couple of days)
> There are also plans to improve interaction between RIOT applications
> and the OpenWSN network stack. If you could imply what your specific
> requirements are we can take these into account of future planning.
> I hope this gives you an overview, for any further questions don't
> hesitate to ask.
> Best, Thomas
> On 17 Sep 2015, at 8:35 CEST(+0200), Ben at vpt-systems.co.za wrote:
>> Hi All
>> Not sure if this is the correct channel to start , but will never 
>> know unless I try.
>> Currently I'm running Contiki OS for my applications with all the 
>> problems (biggest is debugging the OS)
>> My applications are relying heavily on Open WSN that Contiki provide 
>> for the mesh network.
>> What are the status of OpenWSN on RIOT?
>> My solutions needs
>> 1) Low power consumption
>> 2) Wireless Mesh
>> Any input will be appreciated.
>> Kind regards
>> Ben Duvenage
>> Development Engineer
>> On 2015-09-14 03:25 PM, Evan Dietz wrote:
>>> Hi Oleg,
>>> I would be happy to give the new feature a try. When you create the 
>>> issue, could you point to some similar implementations as 
>>> references? This will help me implement the "riot" way.
>>> I imagine getting the periph_uart* unit tests working on native 
>>> would be a good start?
>>> Thanks for the help.
>>> Evan
>>> On Sep 14, 2015 3:20 AM, "Oleg Hahm" <oliver.hahm at inria.fr 
>>> <mailto:oliver.hahm at inria.fr>> wrote:
>>> Hi Evan!
>>> > This is a first time post to the forum so please excuse any newbie
>>> > language/etiquette.
>>> Welcome to the RIOT community and no worries about any RIOT
>>> specific language
>>> or etiquette.
>>> > I'd like to test some uart-related code using native before
>>> flashing to a
>>> > specific board.  However it doesn't look like native cpu
>>> supports uart.
>>> >
>>> > Am I missing something or is this the correct assessment?
>>> Nope, you are correct. We just recently switched to periph/uart
>>> support for
>>> all boards, but since the native getchar/putchar implementation
>>> are mapped to
>>> the host's implementation of these functions there was no urgent
>>> need for a
>>> periph/uart implementation on native.
>>> > Is there any work being done on adding uart emulation to
>>> native?  Is this
>>> > an issue already being tracked (i tried to check but didn't see
>>> anything)
>>> I guess you're right here, too: there is indeed no issue for this.
>>> I'll open
>>> one. Do you have interest in working on this by any chance?
>>> Cheers,
>>> Oleg
>>> -- 
>>> printk(KERN_CRIT "Whee.. Swapped out page in kernel page table\n");
>>>         linux-2.6.6/mm/vmalloc.c
>>> _______________________________________________
>>> devel mailing list
>>> devel at riot-os.org <mailto:devel at riot-os.org>
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>> _______________________________________________
>>> devel mailing list
>>> devel at riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

More information about the devel mailing list