from:"Jonas Remmert"

Re: [riot-devel] TI CC1310 and CC2650

2015-11-19 Thread Jonas Remmert

Hi Adam,just the really low-level RF stuff is executed by the M0 RF core. I am not sure if the memory section that contains the code for the RF core is reprogrammable, the reference manual describes it as ROM [1, Chapter 1.1; 1.3.2.3]. From my understanding the code for the M0 RF core is stored in a pre-programmed ROM section. Chapter 7 [1] states that the ROM has a size of 115kB in addition to the 128kB Flash. This ROM section contains a Bootloader, a Driver Library and the RF stack (I assume both RF-versions at the same time). The reason is a cheaper price for ROM, compared to Flash, during silicon production.In [1; Chapter 23.1.1] you see a block containing "Modem, frequency synthesizer, and RF interfaces". An exact description of that block would be necessary to set up the RF-path (RF to Baseband conversion) according to the desired physical layer (BLE - 1Mbps GFSK, IEEE 802.15.4 - mostly O-QPSK with DSSS, any proprietary). You need to control the analog components (filter, PLL, RF-Demodulation and DSSS-Demodulation, ADC-sample rate) in order to get the Baseband signal, which is then digitalized by the CC26xx's internal ADCs. I have not found any description of the components of the internal RF-path in the reference manual. The description of the Radio [1, Chapter 23] exclusively describes the interface between the M3 and the M0.So I suggest to just use the default IEEE 802.15.4 PHY/MAC firmware for the M0 and implement a RIOT driver running on the M3 that uses the described interface to the M0 RF core. The features of the existing IEEE 802.15.4 configuration should roughly represent the features of common IEEE 802.15.4 transceivers (e.g. as in the KW2x or SAM R21).[1] - http://www.ti.com/lit/ug/swcu117d/swcu117d.pdfBest Jonas-"devel" <devel-boun...@riot-os.org> schrieb: -An: RIOT OS kernel developers <devel@riot-os.org>Von: Adam Hunt <voxa...@gmail.com>Gesendet von: "devel" <devel-boun...@riot-os.org>Datum: 18.11.2015 18:49Betreff: Re: [riot-devel] TI CC1310 and CC2650Jonas,I was wondering, can you comment on the possibility of loading custom images for the M0 RF core? While I don't doubt that the TI firmware would be sufficient for most uses the idea of loading an open source, RIOT based, MAC onto the M0 is interesting to me.Thanks,AdamOn Wed, Nov 18, 2015 at 5:32 AM Jonas Remmert <j.remm...@phytec.de> wrote:Hi Adam,the CC2650 based board has not yet been released officially. It will appear online in a few days. Nevertheless, you can order it right now.There are two options to purchase:1. Art-No.:(PN-00101-A-001.A1) - Only the CC2650 based evaluation board for 39€ + VAT.2. Art-No.:(KPW-IOT-002) - An IoT-Kit bundle for 69€ + VAT that comes with:- CC2650 based evaluation board- TI XDS110 Debug Adapter- BLE USB StickIf you are interested in samples for development, just contact me direclty.We will be in Nuremberg at the SPS IPC Drives by next week (24.11.-26.11; Hall 6, Booth 449), so if you are nearby visit us there.BestJonas-"devel" <devel-boun...@riot-os.org> schrieb: -An: RIOT OS kernel developers <devel@riot-os.org>Von: Adam Hunt Gesendet von: "devel" Datum: 18.11.2015 13:41Betreff: Re: [riot-devel] TI CC1310 and CC2650I searched Phytec's site but was unable to find a CC2650 based board.On Mon, Nov 16, 2015 at 5:54 AM Jonas Remmert <j.remm...@phytec.de> wrote:Hi RIOTers,we at Phytec offer the Evaluation board, described in the Wiki at [1], also with a CC2650 module. The yellow Board is the same as described in the Wiki, just the green PCB module differs by containing an TI CC2650 SoC instead of the Freescale KW2x SiP.The board is currently available for 39€ + VAT. Just write the Phytec sales team at: cont...@phytec.deWe don`t support RIOT on the CC2650 right now, but we are very interested in any effort to make RIOT available on the CC2650. Currently, we ship the board with an adapted version of the TI's SensorTag BLE example.If someone needs CC2650 hardware samples for porting or testing feel free to contact us.We would be happy to support your efforts.Best Jonas[1] - https://github.com/RIOT-OS/RIOT/wiki/Board%3A-Phytec-phyWAVE-KW22-"devel" <devel-boun...@riot-os.org> schrieb: -An: RIOT OS kernel developers <devel@riot-os.org>Von: "b...@vpt-systems.co.za" Gesendet von: "devel" Datum: 16.11.2015 10:23Betreff: Re: [riot-devel] TI CC1310 and CC2650
  

  
  
Hi Adam

I'm looking at the CC13xx and as far as I remember is has a
Coretex-M3 running.  I have 2 CC1350's on my desk and will most
likely start to run them in the next 2 weeks, If all is goes well
with my current projects.

We are running Contiki on our MSP430 with CC1120 and CC1190 (PA) for
our OpenWSN mesh network implementation.  Debugging is a major issue
on Contiki so I will be loading RIOT and see what is r

Re: [riot-devel] TI CC1310 and CC2650

2015-11-18 Thread Jonas Remmert

Hi Adam,the CC2650 based board has not yet been released officially. It will appear online in a few days. Nevertheless, you can order it right now.There are two options to purchase:1. Art-No.:(PN-00101-A-001.A1) - Only the CC2650 based evaluation board for 39€ + VAT.2. Art-No.:(KPW-IOT-002) - An IoT-Kit bundle for 69€ + VAT that comes with:	- CC2650 based evaluation board	- TI XDS110 Debug Adapter	- BLE USB StickIf you are interested in samples for development, just contact me direclty.We will be in Nuremberg at the SPS IPC Drives by next week (24.11.-26.11; Hall 6, Booth 449), so if you are nearby visit us there.BestJonas-"devel" <devel-boun...@riot-os.org> schrieb: -An: RIOT OS kernel developers <devel@riot-os.org>Von: Adam Hunt <voxa...@gmail.com>Gesendet von: "devel" <devel-boun...@riot-os.org>Datum: 18.11.2015 13:41Betreff: Re: [riot-devel] TI CC1310 and CC2650I searched Phytec's site but was unable to find a CC2650 based board.On Mon, Nov 16, 2015 at 5:54 AM Jonas Remmert <j.remm...@phytec.de> wrote:Hi RIOTers,we at Phytec offer the Evaluation board, described in the Wiki at [1], also with a CC2650 module. The yellow Board is the same as described in the Wiki, just the green PCB module differs by containing an TI CC2650 SoC instead of the Freescale KW2x SiP.The board is currently available for 39€ + VAT. Just write the Phytec sales team at: cont...@phytec.deWe don`t support RIOT on the CC2650 right now, but we are very interested in any effort to make RIOT available on the CC2650. Currently, we ship the board with an adapted version of the TI's SensorTag BLE example.If someone needs CC2650 hardware samples for porting or testing feel free to contact us.We would be happy to support your efforts.Best Jonas[1] - https://github.com/RIOT-OS/RIOT/wiki/Board%3A-Phytec-phyWAVE-KW22-"devel" <devel-boun...@riot-os.org> schrieb: -An: RIOT OS kernel developers <devel@riot-os.org>Von: "b...@vpt-systems.co.za" Gesendet von: "devel" Datum: 16.11.2015 10:23Betreff: Re: [riot-devel] TI CC1310 and CC2650
  

  
  
Hi Adam

I'm looking at the CC13xx and as far as I remember is has a
Coretex-M3 running.  I have 2 CC1350's on my desk and will most
likely start to run them in the next 2 weeks, If all is goes well
with my current projects.

We are running Contiki on our MSP430 with CC1120 and CC1190 (PA) for
our OpenWSN mesh network implementation.  Debugging is a major issue
on Contiki so I will be loading RIOT and see what is required in
terms of porting

TI suggested that I wait for version 2 of the silicon of the CC1350
It should have been release end of Q3 of this year, I'm still
waiting..  The TI rep will be here today  I hope ..

Any suggestions on the porting process?

Kind regards
Ben

On 2015-11-14 04:33 PM, Adam Hunt
  wrote:


  Has anyone taken a look at TI's CC2560 or  C1310
processors? They're both based on an a Cortex-M3 processor
clocked up to 48 MHz and work in the 2.4 GHz and sub-1 GHz bands
respectively. I haven't had a chance to read all the
documentation yet but they appear similar to the CC2538, aside
from one part, they both have a Cortex-M0 based "RF Core"
softMAC supporting 802.15.4, 6lowpan, BLE, and ZigBee stacks.. 


Unfortunately, the datasheets state "The ARM
  Cortex-M0 processor is not programmable by customers." While
  this may mean that it's not possible to write a custom MAC or
  port RIOT's to the M0 these could still prove to be useful
  chips. The documentation states that an image for the softMAC
  is stored in an chip ROM but it does seem to be field
  upgradeable but I'm not clear if this is only possible by
  patching the image stored in ROM each boot or if the patch is
  permanent opening a potential avenue for custom M0 firmware.
  The documentation doesn't include complete register
  documentation for the M0 but it at least includes the names of
  the registers. I'm not sure if debug access is enabled on the
  M0 but I would be fairly surprised if it were.
  
  
  Both chips also contain a "sensor controller" CPU that
can be configured to monitor various peripherals even while
the main processor is in standby mode which sounds like a
nice way to further reduce power consumption. I haven't had
time to investigate how this processor is configured and
programmed.



Anyways, even if the embedded softMAC isn't user
  programmable these look like interesting chips. Seeing as they
  only cost US$29 I'll probably buy TI's CC2650 bas

Re: [riot-devel] TI CC1310 and CC2650

2015-11-16 Thread Jonas Remmert

Hi RIOTers,we at Phytec offer the Evaluation board, described in the Wiki at [1], also with a CC2650 module. The yellow Board is the same as described in the Wiki, just the green PCB module differs by containing an TI CC2650 SoC instead of the Freescale KW2x SiP.The board is currently available for 39€ + VAT. Just write the Phytec sales team at: cont...@phytec.deWe don`t support RIOT on the CC2650 right now, but we are very interested in any effort to make RIOT available on the CC2650. Currently, we ship the board with an adapted version of the TI's SensorTag BLE example.If someone needs CC2650 hardware samples for porting or testing feel free to contact us.We would be happy to support your efforts.Best Jonas[1] - https://github.com/RIOT-OS/RIOT/wiki/Board%3A-Phytec-phyWAVE-KW22-"devel"  schrieb: -An: RIOT OS kernel developers Von: "b...@vpt-systems.co.za" Gesendet von: "devel" Datum: 16.11.2015 10:23Betreff: Re: [riot-devel] TI CC1310 and CC2650
  

  
  
Hi Adam

I'm looking at the CC13xx and as far as I remember is has a
Coretex-M3 running.  I have 2 CC1350's on my desk and will most
likely start to run them in the next 2 weeks, If all is goes well
with my current projects.

We are running Contiki on our MSP430 with CC1120 and CC1190 (PA) for
our OpenWSN mesh network implementation.  Debugging is a major issue
on Contiki so I will be loading RIOT and see what is required in
terms of porting

TI suggested that I wait for version 2 of the silicon of the CC1350
It should have been release end of Q3 of this year, I'm still
waiting..  The TI rep will be here today  I hope ..

Any suggestions on the porting process?

Kind regards
Ben

On 2015-11-14 04:33 PM, Adam Hunt
  wrote:


  Has anyone taken a look at TI's CC2560 or  C1310
processors? They're both based on an a Cortex-M3 processor
clocked up to 48 MHz and work in the 2.4 GHz and sub-1 GHz bands
respectively. I haven't had a chance to read all the
documentation yet but they appear similar to the CC2538, aside
from one part, they both have a Cortex-M0 based "RF Core"
softMAC supporting 802.15.4, 6lowpan, BLE, and ZigBee stacks.. 


Unfortunately, the datasheets state "The ARM
  Cortex-M0 processor is not programmable by customers." While
  this may mean that it's not possible to write a custom MAC or
  port RIOT's to the M0 these could still prove to be useful
  chips. The documentation states that an image for the softMAC
  is stored in an chip ROM but it does seem to be field
  upgradeable but I'm not clear if this is only possible by
  patching the image stored in ROM each boot or if the patch is
  permanent opening a potential avenue for custom M0 firmware.
  The documentation doesn't include complete register
  documentation for the M0 but it at least includes the names of
  the registers. I'm not sure if debug access is enabled on the
  M0 but I would be fairly surprised if it were.
  
  
  Both chips also contain a "sensor controller" CPU that
can be configured to monitor various peripherals even while
the main processor is in standby mode which sounds like a
nice way to further reduce power consumption. I haven't had
time to investigate how this processor is configured and
programmed.



Anyways, even if the embedded softMAC isn't user
  programmable these look like interesting chips. Seeing as they
  only cost US$29 I'll probably buy TI's CC2650 based
  "SensorTag"[1] dev platform and if I'm feeling especially
  adventurous give porting RIOT to it a try.


--adam 


[1]  www.ti.com/sensortag
  
  
  
  
  ___devel mailing listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel


  

___devel mailing listdevel@riot-os.orghttps://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] IEEE802.15.4 discovery

2015-05-20 Thread Jonas Remmert


Hi,

Yes, that was the intention. However, I had some issues and didn´t 
really made huge progress. Will hopefully come to a clean solution for a 
csma_mac-layer that we need as a basis for further MAC layer. This will 
include message dispatching mechanisms, cca-mechanisms (backoff-time 
implementation when needed) and acknowledge handling (when needed).


As it seems, there are many people that would need an IEEE 802.15.4 
MAC-layer. Had also a discussion with Johann; we think an IEEE 
802.15.4-MAC layer task force might be a good idea. As a first step we 
could make a todo list, like [2] and a Wiki-page for further for further 
explanations.


What do you think of the idea of an IEEE 802.15.4-MAC layer task 
force? Maybe we can discuss that later in the bi-weekly meeting?


---
Some of my current considerations, for those who are interested.

# Message dispatching problem:
When a node will be associated to an PAN-coordinator, the transmitting 
and receiving time is guided on the superframe architecture. That means 
there will be timespans, where the node can not send messages. 
Nevertheless, there will be incoming task-messages from upper-layer to 
the MAC layer task.

1. Messages from upper layer  (Low-prio)
2. Messages from driver (isr-events)(High-prio)
3. Messages from timer(High-prio)
There must be a mechanism that (i) keeps the message queue empty. (ii) 
Takes care of the current MAC-layer state (just try to send a new packet 
when the MAC layer handled the previous one).


# Storing state variables for the MAC-layer state machine.
1. Static variables: Problem when we have more than one MAC-layer
2. Store them in the device-descriptor: The same device-descriptor may 
be used in different MAC-layer. How to choose the fitting variable set 
(at compile time)?

3. ?

# When these problems are solved, the discovering and associating 
mechanism will include the following tasks.


1. The handling of the incoming and outgoing packets has to be handled 
in the mac layer (currently this is done in each driver implementation). 
This should not be a big thing, as this is already prepared by hauke.


2. Some missing parts in ng_ieee802154. MAC layer settings that describe 
the device capability information field [1, section 5.3.1.2] 
(battery/stationary powered; Receiver on when Idle; security capability).


3. Introduce a new statemachine for current association state. The 
statemachine in the csma_mac-layer will be nested into this.


[1] - IEEE 802.15.4 Standard
[2] - https://github.com/RIOT-OS/RIOT/issues/2278

Best
Jonas


On 20.05.2015 10:28, Hauke Petersen wrote:

Hi,

@Jonas, is your 802.15.4 MAC layer implementation planned to cope with 
this?


Cheers,
Hauke


On 19.05.2015 20:18, Kaspar Schleiser wrote:

Hey,

is anybody working on or are there plans for support for discovering
802.15.4 PANs?

Kaspar
___
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] IEEE802.15.4 discovery

2015-05-20 Thread Jonas Remmert


Hi again ;),

We just opened an Issue [1] 802.15.4(e) MAC-Layer Task Force where we 
can discuss further steps.


Even if this issue might be related to an 802.15.4(e) MAC-Layer, some 
parts of that could also be of interest for other (future) MAC-layer.


From our perspective an IEEE 802.15.4(e) MAC layer will be most 
beneficial. The most important points would be (i) official 
standardization and (ii) interoperatiblity (RIOT - other OS).


What would be your opinion on IEEE 802.15.4e. Is the amendment (e) a 
straight forward extension to the basic 802.15.4 standard or does this 
extention omit the basic mechanisms such as beacon-mode and the 
superframe-architecture?
Does it makes more sense to implement firstly an basic IEEE 802.15.4 and 
then the amendment (e) or begin directly with the amendment (e)? 
Reference for amendment (e) could be OpenWSN.


[1] - https://github.com/RIOT-OS/RIOT/issues/3039

Best
Johann, Jonas

On 20.05.2015 10:28, Hauke Petersen wrote:

Hi,

@Jonas, is your 802.15.4 MAC layer implementation planned to cope with 
this?


Cheers,
Hauke


On 19.05.2015 20:18, Kaspar Schleiser wrote:

Hey,

is anybody working on or are there plans for support for discovering
802.15.4 PANs?

Kaspar
___
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] Implementing a new MAC protocol for IEEE 802.15.4

2015-05-11 Thread Jonas Remmert


Hi Daniel,



I want to use RIOT for a low-power 802.15.4 network project. Having a 
bit familiarized with RIOT and my samr21-xpro boards now I want to 
tackle my next milestone, i.e. I need a MAC protocol that fits my 
requirements (see below).


As it seems that there are only 2 MAC implementations for now [1,2], 
both not what I'm searching for and also not merged, I decided to try 
this on my own.
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.


Therefore I studied some papers and existing MAC schemes to not 
reinvent the wheel. There is one nice paper [3] that sums up quite 
nicely the most basic duty-cycling schemes (p. 4ff).


There are some adaptions and refinements to these protocols which 
might improve the throughput or energy-saving further, but I think 
that these basic schemes already provide a good starting point. Namely 
there is ContikiMAC [4] that incorporates these improvements.


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.
While I want to start implementing a basic and simple protocol first, 
I wonder if it could be nice for RIOT to have some 
ContikiMAC-compatible MAC layer later.


I can't promise anything for now on how well this will work in the 
end, but I wanted to inform you about my undertaking and maybe you 
have some thought or pointers that could help me. 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.


I gathered some notes and requirements, please find them below.

Best regards,
Daniel Krebs

[1] https://github.com/rousselk/RIOT/commits/s-cosens
[2] https://github.com/RIOT-OS/RIOT/pull/2467

BTW: Is this also publicly availble somewhere? [2]

[3] http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4539479
[4] http://dunkels.com/adam/dunkels11contikimac.pdf


Requirements for MAC-layer
==

# Requirements

 * Mesh topology = no single-point-of-failure
 * Low energy consumption
 * Relatively small single-hop network (~10 nodes)
 * New nodes can join and leave the network
 * No need to comply with IEEE 802.15.4 MAC schemes
 * No need for hard realtime
 * Should be reasonibly simple to implement

# Ideas / Questions

 * Do we need broadcasting?
 * Add multi-hop / routing later? Is this even reasonable?
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.

 * Do we really need adaption to traffic load?
 * Find out which APIs to use in RIOT to have a modular MAC protocol 
that might

   work with multiple transceivers

# Observations

 * Requirements seem to match ContikiMAC, so maybe aim for compatibility?

# Implementation

 * Duty cycle nodes for energy saving
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.

 * LPEAS = Implicit synchronization
 * Use 802.15.4 features, so this might only work with 802.15.4 networks
___
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] Radio duty cycling

2015-03-18 Thread Jonas Remmert


Hi Joakim,

What is the current state of radio duty cycling in RIOT?
I know that radio drivers implement on and off functions for the chip, but
how do we make the best use of them?
In order to reduce power consumption it will be necessary to duty cycle
the radio

I would agree with Martine: usually, duty cycling should be rather part of the 
MAC
layer than of the driver. However, embedded transceiver devices usually are
designed for one particular MAC layer and splitting this up in a sensible way
is not always easy/feasible.

Do you have any concrete ideas of functionality for a generic radio
transceiver the driver (netdev) API should provide?

We are facing the same problem. Without radio duty-cycling, a battery 
powered operation seems not useful. Most transceivers consume a current 
of at least 10mA in receive mode (excluding MCU).


I implemented a CSMA/CA-MAC layer using the ng_netdev interface. It 
should fit for most transceivers. But up to a certain part, hardware 
support in the transceiver is neccessary.


I have done some HW tests on that topic:

1. Approach: There was a problem when I triggered CCA in software and in 
case of an idle channel the TX-state was triggered. The timespan between 
CCA-ready and TX-begin turned out to be too long. The result was 
interruptions in the middle of the transmit process, which leads to 
garbage on the channel.


2. Approach: Most transceivers support automatic CCA before TX, even 
most old ones. The approach to do it in Hardware works very well. I 
tested this with using the default values for backoff-intervalls, retry 
counts... defined in the IEEE 802.15.4 standard.


I will update the CSMA-MAC PR in the end of the week, maybe after Thomas 
opened the PR for the Atmel driver.



For comparison, in
Contiki there are multiple RDC drivers that can be switched between at
compile time, the most well-known is ContikiMAC [1]. Something similar
would be very useful in battery powered scenarios for RIOT.

There's definitely a need for generic MAC layer solutions in RIOT, besides the
specific solutions like CSMA in the cc110x driver or TiSCH for 802.15.4e as
part of the OpenWSN stack. As far as I know, at least two people are currently
working on MAC layer implementations for RIOT. I will also take a look into
this topic with the goal to use only the MAC layer part of the OpenWSN stack
as a standalone module in RIOt.
If the CSMA-MAC layer and the ng_radio driver for the KW2x device is 
ready I will focus on implementing a beacon enabled MAC layer according 
to the IEEE 802.15.4 standard. I discussed that already with Johann, 
maybe we will face some problems there. The problem could be to find a 
timer that runs in sleep modes, consumes very low power and has a 
sufficently high resolution for the beacon enabled mode. Using a high 
resolution timer (32mHz or so, depending on the hardware) will not work, 
as it consumes to much power. Maybe a 32kHz clock in combination with an 
RTC or so could work.


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

Re: [riot-devel] Network Stack Task Force

2015-02-03 Thread Jonas Remmert


Hi RIOTers,

sry for my late reply.  I would like to attend the Network Stack Task 
Force personally and will be in Berlin on Thursday and Friday.


Oleg told me that the meeting will most likely take place at the 
University instead of C-Base.


Could someone provide the location and time for the meeting?

Tanks,

Best
Jonas


On 29.01.2015 19:23, Hauke Petersen wrote:

Hi RIOTers,

as Martine already posted, the network stack task force will meet next 
week Thursday and Friday (Feb 56). Following I tried to draft the 
main goals as well as a preliminary schedule:


GOALS:
--
- synchronize everyone involved on the ongoing activities
- collect use cases
- map them on the current state of the architecture and see if the 
architecture holds

- refine the network stack architecture
- detail out a concrete work-plan

As mentioned earlier, the goal is not to end up with a prototypical 
implementation or similar - we should really focus on the concepts and 
architecture, so we end up with a clear idea (and plan) for the 
implementation afterward.



PRELIMINARY SCHEDULE:
--
Thursday before lunch:
Martine and me will present in detail the current state of the network 
stack architecture and concepts, so everyone involved is synchronized. 
The current state can then be used as a base-line for further 
discussion and refinement (or we end up by completely re-designing it...)


Thursday after lunch:
We collect use cases for the network stack (as in: what happens in 
this situation, what module is needing what kind of data, who is 
talking to whom). We then map these use cases to the proposed 
architecture to identify short-comings and come up with a list of open 
topics that need to be discussed further.


Friday:
Based on the open topics and design short-comings, I suggest we go 
through them item by item and come up with solutions :-)



Please append anything that we should add to the discussion or any 
ideas for making the 'workshop' as efficient as possible!


See (hear) you next week,
Hauke



On 27.01.2015 08:26, Martine Lenders wrote:

Hello Paul,
the workshop will be held at Freie Universität Berlin and (probably, 
as far as I can see from the attendees) HAW Hamburg, simultaneously, 
but will also provide the PlaceCam-Link [1] that will connect the two 
events and allow for remote participation.


Details for the schedule will be posted in the next few days.

Cheers,

Martine

[1] placecam.de http://placecam.de

Am 26.01.2015 19:05 schrieb gnu...@dds.nl mailto:gnu...@dds.nl:

Is this a webbased meeting or a meeting in Berlin ?.

Paul.

Peter Kietzmann peter.kietzm...@haw-hamburg.de
mailto:peter.kietzm...@haw-hamburg.de schreef:

Hi,

I'm fine.

Cheers,
Peter

Am 26.01.2015 um 10:56 schrieb Martine Lenders:

Hi,
looks like it's gonna be February 5th and 6th (a Thursday
and a Friday). Martin is the only one that is not
available on Thursday. Is everyone okay with that?

Cheers,
Martine

2015-01-19 17:30 GMT+01:00 Hauke Petersen
hauke.peter...@fu-berlin.de
mailto:hauke.peter...@fu-berlin.de
mailto:hauke.peter...@fu-berlin.de
mailto:hauke.peter...@fu-berlin.de:

   Hi everyone,

   sandwiching the HA is indeed not a good idea, I agree.

   Thanks Martine for the doodle, let's wait until
Thursday and
   decide on the dates based on the outcome of the doodle
then.

   Cheers,
   Hauke



   On 19.01.2015 13:17, Martine Lenders wrote:


   Hi,
   Since this thread has gained some traction now I
would propose to
   use to dudle it out. The two days adjacent to each
other where
   most are available would be the date:
https://dudle.inf.tu-dresden.de/RIOT-NSFT1/

   Cheers,
   Martine

   Am 19.01.2015 12:29 schrieb Emmanuel Baccelli
   emmanuel.bacce...@inria.fr
mailto:emmanuel.bacce...@inria.fr
mailto:emmanuel.bacce...@inria.fr
mailto:emmanuel.bacce...@inria.fr:

   Hi Thomas,
   damn, your right, I misread the dates. So
Hack'nAck would be
   sandwiched inside the workshop, and I guess
that's not
   great. How about 28-29, or 29-30, then?
   Best
   Emmanuel

   On Mon, Jan 19, 2015 at 11:24 AM, Thomas Eichinger
   thomas.eichin...@fu-berlin.de
mailto:thomas.eichin...@fu-berlin.de
   mailto:thomas.eichin...@fu-berlin.de

Re: [riot-devel] 802.15.4 for Linux

2015-01-30 Thread Jonas Remmert


Hi Oleg,

we are using an IEEE 802.15.4 transceiver-module that uses an 
CC2520-device. Currently its used as an add-on module for our Wega SBC, 
but we are planning to build an USB-stick like device as well.
The transceiver was tested, using the the latest available Linux-kernel 
(net-next).


We can see the packets in promiscous-mode, but currently we are facing 
problems in receiving them in Userspace. This is an status of November, 
currently we are picking up this topic again and I hope we will have 
some news about that soon.


For testing purposes we could provide some hardware devices for 
RIOT-Developers.


Best,
Jonas


On 30.01.2015 11:02, Oleg Hahm wrote:

Dear reasoning IoTlers,

I know, we had this question already several times before , but I'm not sure
about the current state and if some of you have made new experiences in this
domain: is there any off-the-shelf hardware available that provides an IEEE
802.15.4 interface for Linux systems - preferable something like a USB stick?
If yes, does this hardware work with a standard Linux vanilla kernel and which
version is required? Or does it need any custom/developer version of a driver?
How well are upper layers like 6lowpan supported by Linux in the meantime? And
has anyone ever tried to connect such a device to a RIOT driven device?

Thanks,
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] Reference Radio-driver Implementation

2015-01-06 Thread Jonas Remmert


Dear RIOTers,

at Phytec, we are currently working on a Radio-driver implementation for 
the Freescale Kinetis-MKW2x CPU. Basic Radio-functionalities exists 
using the old RIOT-network interface. Before we start a pull request, we 
want to adapt the driver to the new RIOT-network interface.


I´ve also looked at PR/1733, that provides the adaption of the CC2420 
driver to the new network interface. But in this Radio-driver, 
transceiver.h is also included. Thats a bit confusing to me. Is the 
transceiver interface needed for the CC2420-driver?


As I understand it, the old transceiver interface must not be used anymore?

Is there currently any driver interface that can be used as reference, 
to understand the complete system?


Thanks in advance,

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

Re: [riot-devel] TI CC1310 and CC2650

Re: [riot-devel] TI CC1310 and CC2650

Re: [riot-devel] TI CC1310 and CC2650

Re: [riot-devel] IEEE802.15.4 discovery

Re: [riot-devel] IEEE802.15.4 discovery

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

Re: [riot-devel] Radio duty cycling

Re: [riot-devel] Network Stack Task Force

Re: [riot-devel] 802.15.4 for Linux

[riot-devel] Reference Radio-driver Implementation

10 matches

Site Navigation

Mail list logo

Footer information