Re: [riot-devel] Sillicon Labs "Thunderboard Sense" - missing documentation

[Matthias Kolja Miehl]

Hi Alf,

thanks a lot for the documents – that's just what I looked for :)

Is it okay to publish the PDF file, containing the schematic, on the
internet as part of the board's description or is that information/ file
confidential?

Best regards
Matthias


On 08/28/2016 09:37 PM, Alf Petter Mossevig wrote:
> Hi,
> 
> You can get the basic documentation (assembly drawing, schematic and
> BOM) here: https://www.dropbox.com/s/90hhnswiktcfjzz/BRD4160.zip?dl=0
> 
> You should also be able to get it through the latest version of
> Simplicity Studio (V4). The user guide and official example code should
> be available in a couple of weeks.
> 
> ​Best regards,​
> 
> Alf Petter
> ​ Mossevig
> Silicon Labs
> Product Manager ​- 32-bit microcontrollers
> 
> 
> 2016-08-24 0:00 GMT+02:00 Matthias Kolja Miehl  >:
> 
> Hello everyone,
> 
> I am looking for documentation (protocol specification) regarding the
> sensors on the Sillicon Labs development board "Thunderboard Sense"
> (SLTB001A). I did not find anything online and wondered whether the
> documentation is just not available yet or if I am missing something.
> 
> Did anybody else look into this? Does anybody know of a timeframe within
> which we can expect component and board documentation?
> 
> 
> Related: pull request #5652 opened by Bas Stottelaar (basilfx)
> 
> > Add support for the Sillicon Labs Thunderboard Sense
> > https://github.com/RIOT-OS/RIOT/pull/5652
> 
> 
> 
> Best regards
> Matthias
___
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

[Martine Lenders]

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 in a haste and has
a lot of design flaws. I'm working on a replacement (see
https://github.com/RIOT-OS/RIOT/issues/5704, happy to hear your
thoughts ;-)), but sadly I did not find some time to put heavy
implementation efforts into this yet (hopefully in autumn though, so
we have something for the October release, fingers crossed).

Thanks for reporting and kind regards,
Martines

2016-08-29 17:54 GMT+02:00 Baptiste Clenet :
> Hi,
> I'm using two SAMR21, one with BR (on A) and the other (on B) with
> gnrc_networking example.
> I'm on April release.
> Switch on A (border router) then switch on B, I'm able to send UDP
> message from Linux to 2001:db8 address of B.
> If I try to send lot of data (every 100ms), it works for a while and
> then B does not receive message anymore. After I see it failed, I
> stopped the loop sending UDP message, I checked on BR and 2001:db8
> address of B was not here anymore. I can ping B with fe80:: address on
> iface 6 but can't with 2001:db8.
>
> Why or how can a node be removed from ncache? Why the node does not
> automatically reconnect with BR?
>
> Cheers
>
> --
> Baptiste
> ___
> 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] BorderRouter: Global IPV6 address lost in ncache after UDP message sent

[Baptiste Clenet]

Hi,
I'm using two SAMR21, one with BR (on A) and the other (on B) with
gnrc_networking example.
I'm on April release.
Switch on A (border router) then switch on B, I'm able to send UDP
message from Linux to 2001:db8 address of B.
If I try to send lot of data (every 100ms), it works for a while and
then B does not receive message anymore. After I see it failed, I
stopped the loop sending UDP message, I checked on BR and 2001:db8
address of B was not here anymore. I can ping B with fe80:: address on
iface 6 but can't with 2001:db8.

Why or how can a node be removed from ncache? Why the node does not
automatically reconnect with BR?

Cheers

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

Re: [riot-devel] Netdev2 - mechanism for building transmit frames

[Peter Kietzmann]

Hi Neo,

has it already clarified? I'm not sure I got the problem, but let's have 
a look at the following code lines.


https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx.c#L202

at86rf2xx_tx_load() is called with an offset parameter and it writes the 
SRAM at position offset+1. The function returns the offset plus the 
written data length. In the next iteration (in _send()) where the load 
function is called, the previous return value (aka start point) is used 
as offset parameter for at86rf2xx_tx_load() and inside this function, 
the SRAM access will start at offset+1 again.


https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L119

So I don't see how the last byte can get overwritten in a second 
iteration. Am I mistaken?


Best
Peter



Am 18.08.2016 um 21:22 schrieb Neo:

Helle to all developers,
I'm at the moment debugging a new netdev2-radio-module driver and while
debugging
I have seen a mysterious behaviour - maybe it's that I have not a
complete understanding
about the netdev2 structur.
As far as I've seen the transmission of a frame ist done in the
_send(..) function
(e.g. at86rf2xx_send(..)).
The process is splitt into three phases .._tx_prepare(dev),
.._tx_load(dev, data, len,0) and .._tx_exec.

The phase of interest for me is at the moment the .._tx_load(..) step.
In the function _send we see that the .._tx_load(..) is involked inside
the for-look to build the
transmit frame date.

Now my thought: the loop fills the transmit buffer.
Logically for me the frame will be filled step by step
- second part of the frame following the first part
without address overlapping or gap - is this correct.

The mysterious thing I see is as follows: The second
loop pass is overwriting the end of the first "loop-data" . The third
loop access is overwriting the end of the second FIFO-access
and so on..

Could this be a valid behaviour?

Best regards,
Neo

___
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

Re: [riot-devel] Porting a robot to RIOT

[Martin]

Hi Loïc,


your experiment to substitute Aversive++ with RIOT as HW abstraction 
looks great to me.
Its nice to see an example of coordinated actuators steered by a remote 
wireless RIOT node.

Actually I would love to see your robot running on the ground.
I think its a really nice example for a one hop and one way 
communication between nodes,
and It might give a good impression of the RIOT hardware abstraction 
possibilities

(Similar to the RC car example of @haukepetersen [1]).


> I was wondering if it was worth adding this to the RIOT's wiki. Maybe 
it is not complete enough. What do you think ?


IMHO I think the RIOT wiki would not be the right place for it.
Some time ago we also made an example project [2] which is also not 
present in the wiki pages of RIOT.
One reason why its not there is that it "just" uses a bunch of 
documented and described features provided by RIOT, such as RPL, CoAP etc.
The other and even more important reason is that the blog offers a lot 
of additional and,
regarding the RIOT wiki, redundant information which could confuse a new 
user searching for specific help on a topic.



I think if you could give more details on migrating from Aversive++ to 
RIOT,
like give a step by step guide for someone that wants to move to RIOT 
but does not know how to begin, it could perfectly fit in the RIOT wiki.

Maybe something comparable to [3].


Best regards,

Martin

[1] https://github.com/haukepetersen/Petabot
[2] http://watr.li/
[3] 
https://github.com/RIOT-OS/RIOT/wiki/How-to-install-6LoWPAN-Linux-Kernel-on-Raspberry-Pi



Am 08/18/2016 um 10:41 AM schrieb Loïc Dauphin:

Hello,

Some month ago, I made an experiment to make my personal robot work 
with RIOT. I should have done this sooner, but I just made a small 
document that describes how I did that :
https://github.com/astralien3000/test_riot_buggybot/wiki/From-AversivePlusPlus-to-RIOT 



I was wondering if it was worth adding this to the RIOT's wiki. Maybe 
it is not complete enough. What do you think ?


Cheers,

Loïc
___
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