[riot-devel] Transmission performance with CC1101 radio

[América Ramírez R .]

Hello,

I am trying to determine the highest datarate possible using the CC1101
radio.
My use case is the transmission of media files.
With the following configuration I have only been able to achieve *1.24KBps*
:
* modulation: 2-FSK
* Frequency: 869,25 MHz
* Datarate: 299.926 KBauds
* udp as transport protocol
* with gnrc_sixlowpan_iphc module disabled

To measure the data-rate I modified udp.c in examples/gnrc_networking

*@ udp.c*
I am printing the time between each packet sent, the time of all packets
sent and the total number of Bytes transmitted. I defined *y* and *n*:


 uint32_t *y* *=* xtimer_now*();*

*for* *(*unsigned int i *=* 0*;* i *<* num*;* i*++)* *{*

uint32_t *n* *=* xtimer_now*();*


And *m*, before the for ends and* x* after it finishes

uint32_t *m* *=* xtimer_now*();*

printf*(*"Time per packet (ms): %ld\n"*,(*m*-*n*)/*1000*);*

*}*

uint32_t *x* *=* xtimer_now*();*

printf*(*"Total Bytes sent: %u\n"*,* strlen*(*data*)**num*);*

printf*(*"Total time (ms): %ld\n"*,(*x*-*y*)/*1000*);*






*@Terminal*Packets are sent by:

2016-07-04 14:35:27,609 - INFO # > udp send fe80::ff:fe00:66 5
01234567890123456789 100 9500
which sends through port 5 packets of 20 Bytes, 100 times with a delay of
9500 *us* between them.

As a result I get this:

2016-07-04 12:09:48,179 - INFO # Time per packet (ms): 13
2016-07-04 12:09:48,180 - INFO # Total Bytes sent: 2000
2016-07-04 12:09:48,180 - INFO # Total time (ms): 1612
In addition, with this configuration, I am receiving 38 packets of the 100
packets sent.
When trying to reduce the delay time between each packet to 9 000 *us*, the
transmitter stops and does not send anymore even if I put back delay time
to 9 500 *us, *only transmits back again when I reset it.
The more packets I try to send in that loop the larger the delay between
packets needs to be.

How can I further investigate where the bottleneck comes from? Or if you
have any idea on this issue?

Thanks in advance,
-- 

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

Re: [riot-devel] Byte array should be uint8_t, not char

[Joakim Nohlgård]

Hi Kees,
Like Ludwig wrote, there are some places which haven't followed the coding
conventions because the CC weren't as clear before as they are now with
regards to this. Since RIOT is relying on its community for code
contributions, these kinds of clean ups may take a long time after the
documentation has been updated until someone decides to fix them.

The SPI periph driver is going through some rework, see
https://github.com/RIOT-OS/RIOT/pull/4780 and
https://github.com/RIOT-OS/RIOT/issues/4758, but it has not yet been merged
because of various other things getting in the way.

Best regards,
Joakimr

On Mon, Jul 4, 2016 at 7:23 AM, Ludwig Knüpfer  wrote:

> Hi Kees,
>
> Unless there is a good reason to deviate from this guideline all
> violations should be corrected. This particular rule was added relatively
> recently, so it would not surprise me if not all occurrences in RIOT have
> been adapted yet.
>
> Cheers,
> Ludwig
>
> Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker :
> >Hi,
> >
> >The Coding Convention is clear about it.
> >
> >"Guidelines for pointer types (as long as it is reasonable):
> >
> >  * use |char *| for strings and only for strings
> > * use |uint8_t[]| as type for arbitrary byte buffers, but use |void *|
> >to pass them around. |uint8_t[]| because we're dealing with bytes
> >and not characters, |void *| to avoid unnecessary casting shall the
> >need arise to have their content to have a certain type
> >  * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer
> >addresses, where it avoids unnecessary temporary variable
> >  * use |void *| for generic typing"
> >
> >
> >In the SPI driver however the transfer functions use char * parameters,
> >
> >but SPI is usually dealing with binary
> >information (bytes), not strings. This leads to unnecessary casts in
> >other parts of the code. (E.g. nvram_spi).
> >
> >What is our policy about this? Are we going to correct this at some
> >point? Is it too late already (I hope not)?
>
> ___
> 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] Problem with UDP and SAMR21-XPRO

[Martine Lenders]

Yes, well done +1 :-)

Cheers,
Martine

2016-07-04 16:49 GMT+02:00 MATTIA ANTONINI :
> Done! I hope I've done well, I followed your instructions.
>
> Cheers,
> Mattia
>
> 2016-07-04 15:49 GMT+02:00 Martine Lenders :
>>
>> Hi,
>> make a fork of master on GitHub [1] (hit the fork button in the upper
>> right corner) and clone the fork to your local machine:
>>
>> $ git clone g...@github.com:/RIOT.git
>>
>> or, if you already cloned the RIOT-OS repository just add it as another
>> remote
>>
>> $ git remote add mine g...@github.com:/RIOT.git
>> $ git fetch mine
>>
>> It's important to use the SSH-URL here so you have push rights to that
>> remote (I think instead of SSH you can actually also use the HTTP-URL
>> for push rights, but I'm not sure and never tried that).
>>
>> Create a new branch from master
>>
>> $ git checkout -b gnrc_ipv6/pr/udp-fix master
>>
>> Apply your changes and commit them
>>
>> $ git commit -am "gnrc_ipv6: fix UDP issue"
>>
>> Maybe describe the fix a little bit better but keep it under 72
>> characters in the subject line
>>
>> Push to your repo:
>>
>> $ git push -u mine gnrc_ipv6/pr/udp-fix
>>
>> Ideally there is a new button on GitHub [1] now, that gives you the
>> ability to create a Pull Request to the main repository for your
>> branch, but if not (might happen if your master branch was a little
>> older). You have two ways of fixing this. The harder, but cleaner
>> approach (which you might need to do anyways so better do it), would
>> be to rebase:
>>
>> $ git fetch origin
>> $ git rebase origin/master
>> # fix merge conflicts that might occure using if you are on ubuntu:
>> installing Meld (`sudo apt-get install meld`) provides a nice GUI to
>> resolve them
>> $ git mergetool # ... resolve merge-conflict (1)
>> $ git rebase --continue # ... resolve merge-conflict (2)
>> # you might have to repeat that step several times depending on the
>> number of commits that end up in your branch
>> $ git push -f # force-push to your branch
>>
>> The easier way is just to follow this piece of instruction [2]. But if
>> there is a merge conflict the reviewer might ask you to rebase anyway.
>>
>> [1] https://github.com/RIOT-OS/RIOT
>> [2] https://help.github.com/articles/creating-a-pull-request/
>>
>> 2016-07-04 15:25 GMT+02:00 MATTIA ANTONINI
>> :
>> > Hi Martine,
>> > I think I've fixed this problem. I've tested my scenario 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 :
>> >>
>> >> 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 :
>> >> > 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
>> >> >
>> >> > 2016-06-23 23:56 GMT+02:00 MATTIA ANTONINI
>> >> > :
>> >> >> Hi all!
>> >> >> I found the problem in the commit 0de34c9 [1]. Can anyone check this
>> >> >> commit?
>> >> >> I've also tried  the commit before ( f7bd237) and everything works.
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> Mattia
>> >> >>
>> >> >>
>> >> >>
>> >> >> [1]
>> >> >>
>> >> >>
>> >> >> https://github.com/RIOT-OS/RIOT/commit/0de34c91c618829a845feef753b3ea32683365ed
>> >> >>
>> >> >> 2016-06-22 15:14 GMT+02:00 Alexandre Abadie
>> >> >> :
>> >> >>>
>> >> >>> Hi,
>> >> >>>
>> >> >>> > though I do not have the same setup ready for testing, I _cannot_
>> >> >>> > confirm any
>> >> >>> > problems with UDP on latest RIOT master branch.
>> >> >>> >
>> >> >>> > I just tested UDP on a SAMR21-XPRO running gnrc_networking
>> >> >>> > example
>> >> >>> > and
>> >> >>> > successfully send and received UDP data from and to a RasPi with
>> >> >>> > Openlabs
>> >> >>> > transceiver running netcat on latest Raspbian-Linux.
>> >> >>> >
>> >> >>> > Could you clarify which RIOT branch/commit you use?
>> >> >>>
>> >> >>> Latest master. From what you say, the problem comes from the RIOT
>> >> >>> BR.
>> >> >>>
>> >> >>> Cheers,
>> >> >>>
>> >> >>> Alex
>> >> >>>
>> >> >>>
>> >> >>> >
>> >> >>> > Best,
>> >> >>> >   Sebastian
>> >> >>> >
>> >> >>> > > Am 21.06.2016 um 21:42 schrieb Alexandre Abadie
>> >> >>> > > :
>> >> >>> > >
>> >> >>> > > 

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

[MATTIA ANTONINI]

Done! I hope I've done well, I followed your instructions.

Cheers,
Mattia

2016-07-04 15:49 GMT+02:00 Martine Lenders :

> Hi,
> make a fork of master on GitHub [1] (hit the fork button in the upper
> right corner) and clone the fork to your local machine:
>
> $ git clone g...@github.com:/RIOT.git
>
> or, if you already cloned the RIOT-OS repository just add it as another
> remote
>
> $ git remote add mine g...@github.com:/RIOT.git
> $ git fetch mine
>
> It's important to use the SSH-URL here so you have push rights to that
> remote (I think instead of SSH you can actually also use the HTTP-URL
> for push rights, but I'm not sure and never tried that).
>
> Create a new branch from master
>
> $ git checkout -b gnrc_ipv6/pr/udp-fix master
>
> Apply your changes and commit them
>
> $ git commit -am "gnrc_ipv6: fix UDP issue"
>
> Maybe describe the fix a little bit better but keep it under 72
> characters in the subject line
>
> Push to your repo:
>
> $ git push -u mine gnrc_ipv6/pr/udp-fix
>
> Ideally there is a new button on GitHub [1] now, that gives you the
> ability to create a Pull Request to the main repository for your
> branch, but if not (might happen if your master branch was a little
> older). You have two ways of fixing this. The harder, but cleaner
> approach (which you might need to do anyways so better do it), would
> be to rebase:
>
> $ git fetch origin
> $ git rebase origin/master
> # fix merge conflicts that might occure using if you are on ubuntu:
> installing Meld (`sudo apt-get install meld`) provides a nice GUI to
> resolve them
> $ git mergetool # ... resolve merge-conflict (1)
> $ git rebase --continue # ... resolve merge-conflict (2)
> # you might have to repeat that step several times depending on the
> number of commits that end up in your branch
> $ git push -f # force-push to your branch
>
> The easier way is just to follow this piece of instruction [2]. But if
> there is a merge conflict the reviewer might ask you to rebase anyway.
>
> [1] https://github.com/RIOT-OS/RIOT
> [2] https://help.github.com/articles/creating-a-pull-request/
>
> 2016-07-04 15:25 GMT+02:00 MATTIA ANTONINI <
> mattia.antoni...@studenti.unipr.it>:
> > Hi Martine,
> > I think I've fixed this problem. I've tested my scenario 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 :
> >>
> >> 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 :
> >> > 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
> >> >
> >> > 2016-06-23 23:56 GMT+02:00 MATTIA ANTONINI
> >> > :
> >> >> Hi all!
> >> >> I found the problem in the commit 0de34c9 [1]. Can anyone check this
> >> >> commit?
> >> >> I've also tried  the commit before ( f7bd237) and everything works.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Mattia
> >> >>
> >> >>
> >> >>
> >> >> [1]
> >> >>
> >> >>
> https://github.com/RIOT-OS/RIOT/commit/0de34c91c618829a845feef753b3ea32683365ed
> >> >>
> >> >> 2016-06-22 15:14 GMT+02:00 Alexandre Abadie
> >> >> :
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> > though I do not have the same setup ready for testing, I _cannot_
> >> >>> > confirm any
> >> >>> > problems with UDP on latest RIOT master branch.
> >> >>> >
> >> >>> > I just tested UDP on a SAMR21-XPRO running gnrc_networking example
> >> >>> > and
> >> >>> > successfully send and received UDP data from and to a RasPi with
> >> >>> > Openlabs
> >> >>> > transceiver running netcat on latest Raspbian-Linux.
> >> >>> >
> >> >>> > Could you clarify which RIOT branch/commit you use?
> >> >>>
> >> >>> Latest master. From what you say, the problem comes from the RIOT
> BR.
> >> >>>
> >> >>> Cheers,
> >> >>>
> >> >>> Alex
> >> >>>
> >> >>>
> >> >>> >
> >> >>> > Best,
> >> >>> >   Sebastian
> >> >>> >
> >> >>> > > Am 21.06.2016 um 21:42 schrieb Alexandre Abadie
> >> >>> > > :
> >> >>> > >
> >> >>> > > Hi Mattia,
> >> >>> > >
> >> >>> > > Thanks for reporting this issue.
> >> >>> > >
> >> >>> > >> I've discovered a possible bug in RIOT. I'm working with 2
> >> >>> > >> samr21-xpro: on
> >> >>> > >> the first is running gnrc_border_router (I'll call it A) and on
> >> >>> > >> the
> >> >>> > >> other
> 

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

[Martine Lenders]

Hi,
make a fork of master on GitHub [1] (hit the fork button in the upper
right corner) and clone the fork to your local machine:

$ git clone g...@github.com:/RIOT.git

or, if you already cloned the RIOT-OS repository just add it as another remote

$ git remote add mine g...@github.com:/RIOT.git
$ git fetch mine

It's important to use the SSH-URL here so you have push rights to that
remote (I think instead of SSH you can actually also use the HTTP-URL
for push rights, but I'm not sure and never tried that).

Create a new branch from master

$ git checkout -b gnrc_ipv6/pr/udp-fix master

Apply your changes and commit them

$ git commit -am "gnrc_ipv6: fix UDP issue"

Maybe describe the fix a little bit better but keep it under 72
characters in the subject line

Push to your repo:

$ git push -u mine gnrc_ipv6/pr/udp-fix

Ideally there is a new button on GitHub [1] now, that gives you the
ability to create a Pull Request to the main repository for your
branch, but if not (might happen if your master branch was a little
older). You have two ways of fixing this. The harder, but cleaner
approach (which you might need to do anyways so better do it), would
be to rebase:

$ git fetch origin
$ git rebase origin/master
# fix merge conflicts that might occure using if you are on ubuntu:
installing Meld (`sudo apt-get install meld`) provides a nice GUI to
resolve them
$ git mergetool # ... resolve merge-conflict (1)
$ git rebase --continue # ... resolve merge-conflict (2)
# you might have to repeat that step several times depending on the
number of commits that end up in your branch
$ git push -f # force-push to your branch

The easier way is just to follow this piece of instruction [2]. But if
there is a merge conflict the reviewer might ask you to rebase anyway.

[1] https://github.com/RIOT-OS/RIOT
[2] https://help.github.com/articles/creating-a-pull-request/

2016-07-04 15:25 GMT+02:00 MATTIA ANTONINI :
> Hi Martine,
> I think I've fixed this problem. I've tested my scenario 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 :
>>
>> 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 :
>> > 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
>> >
>> > 2016-06-23 23:56 GMT+02:00 MATTIA ANTONINI
>> > :
>> >> Hi all!
>> >> I found the problem in the commit 0de34c9 [1]. Can anyone check this
>> >> commit?
>> >> I've also tried  the commit before ( f7bd237) and everything works.
>> >>
>> >> Cheers,
>> >>
>> >> Mattia
>> >>
>> >>
>> >>
>> >> [1]
>> >>
>> >> https://github.com/RIOT-OS/RIOT/commit/0de34c91c618829a845feef753b3ea32683365ed
>> >>
>> >> 2016-06-22 15:14 GMT+02:00 Alexandre Abadie
>> >> :
>> >>>
>> >>> Hi,
>> >>>
>> >>> > though I do not have the same setup ready for testing, I _cannot_
>> >>> > confirm any
>> >>> > problems with UDP on latest RIOT master branch.
>> >>> >
>> >>> > I just tested UDP on a SAMR21-XPRO running gnrc_networking example
>> >>> > and
>> >>> > successfully send and received UDP data from and to a RasPi with
>> >>> > Openlabs
>> >>> > transceiver running netcat on latest Raspbian-Linux.
>> >>> >
>> >>> > Could you clarify which RIOT branch/commit you use?
>> >>>
>> >>> Latest master. From what you say, the problem comes from the RIOT BR.
>> >>>
>> >>> Cheers,
>> >>>
>> >>> Alex
>> >>>
>> >>>
>> >>> >
>> >>> > Best,
>> >>> >   Sebastian
>> >>> >
>> >>> > > Am 21.06.2016 um 21:42 schrieb Alexandre Abadie
>> >>> > > :
>> >>> > >
>> >>> > > Hi Mattia,
>> >>> > >
>> >>> > > Thanks for reporting this issue.
>> >>> > >
>> >>> > >> I've discovered a possible bug in RIOT. I'm working with 2
>> >>> > >> samr21-xpro: on
>> >>> > >> the first is running gnrc_border_router (I'll call it A) and on
>> >>> > >> the
>> >>> > >> other
>> >>> > >> (I'll call it B) is running gnrc_networking. I've well configured
>> >>> > >> my
>> >>> > >> scenario infact I can ping both my nodes from linux shell. But,
>> >>> > >> when
>> >>> > >> I
>> >>> > >> send
>> >>> > >> a UDP packet to B (with nc) it is forwarded correctly on tap
>> >>> > >> interface (I
>> >>> > >> seen it on wireshark) but it arrives corrupted (wrong checksum)
>> >>> > >> to B
>> >>> > >> and
>> 

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

[MATTIA ANTONINI]

Hi Martine,
I think I've fixed this problem. I've tested my scenario 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 :

> 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 :
> > 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
> >
> > 2016-06-23 23:56 GMT+02:00 MATTIA ANTONINI <
> mattia.antoni...@studenti.unipr.it>:
> >> Hi all!
> >> I found the problem in the commit 0de34c9 [1]. Can anyone check this
> commit?
> >> I've also tried  the commit before ( f7bd237) and everything works.
> >>
> >> Cheers,
> >>
> >> Mattia
> >>
> >>
> >>
> >> [1]
> >>
> https://github.com/RIOT-OS/RIOT/commit/0de34c91c618829a845feef753b3ea32683365ed
> >>
> >> 2016-06-22 15:14 GMT+02:00 Alexandre Abadie  >:
> >>>
> >>> Hi,
> >>>
> >>> > though I do not have the same setup ready for testing, I _cannot_
> >>> > confirm any
> >>> > problems with UDP on latest RIOT master branch.
> >>> >
> >>> > I just tested UDP on a SAMR21-XPRO running gnrc_networking example
> and
> >>> > successfully send and received UDP data from and to a RasPi with
> >>> > Openlabs
> >>> > transceiver running netcat on latest Raspbian-Linux.
> >>> >
> >>> > Could you clarify which RIOT branch/commit you use?
> >>>
> >>> Latest master. From what you say, the problem comes from the RIOT BR.
> >>>
> >>> Cheers,
> >>>
> >>> Alex
> >>>
> >>>
> >>> >
> >>> > Best,
> >>> >   Sebastian
> >>> >
> >>> > > Am 21.06.2016 um 21:42 schrieb Alexandre Abadie
> >>> > > :
> >>> > >
> >>> > > Hi Mattia,
> >>> > >
> >>> > > Thanks for reporting this issue.
> >>> > >
> >>> > >> I've discovered a possible bug in RIOT. I'm working with 2
> >>> > >> samr21-xpro: on
> >>> > >> the first is running gnrc_border_router (I'll call it A) and on
> the
> >>> > >> other
> >>> > >> (I'll call it B) is running gnrc_networking. I've well configured
> my
> >>> > >> scenario infact I can ping both my nodes from linux shell. But,
> when
> >>> > >> I
> >>> > >> send
> >>> > >> a UDP packet to B (with nc) it is forwarded correctly on tap
> >>> > >> interface (I
> >>> > >> seen it on wireshark) but it arrives corrupted (wrong checksum)
> to B
> >>> > >> and
> >>> > >> it
> >>> > >> is dropped by UDP thread. I've enabled packet dump and the packet
> >>> > >> arrives
> >>> > >> with different packet lengths in ipv6 and udp headers (fixed to
> 8, it
> >>> > >> is
> >>> > >> the UDP header length) and the udp payload is removed.
> >>> > >
> >>> > > I have the exact same problem although I didn't track it as deep as
> >>> > > you
> >>> > > did.
> >>> > >
> >>> > >> How can I fix this problem?
> >>> > >
> >>> > > A regression was introduced 2 or 3 weeks ago in master and you
> could
> >>> > > first
> >>> > > "git bisect" to try to identify the incriminated commit.
> >>> > >
> >>> > > Thanks,
> >>> > >
> >>> > > Alex
> >>> > > ___
> >>> > > 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
> >>
> >>
> >>
> >> ___
> >> 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] Transceiver : Reception level

[Martine Lenders]

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" :

> Thanks Martine, I'll try when I've got time
>
> 2016-07-02 12:27 GMT+02:00 Martine Lenders :
> > Hi Baptiste,
> > if you can read it on the driver level, you can adapt
> > gnrc_netdev2_hdr_t to add that value as a field and add it via the
> > rx_info struct handed to the recv function of the netdev2-driver.
> >
> > Hope that was helpful feel free to ask for further details.
> >
> > Cheers,
> > Martine
> >
> > 2016-07-01 21:57 GMT+02:00 Baptiste Clenet :
> >> Hi,
> >> When I receive a UDP frame, may I see the level (dB) of the received
> frame ?
> >> I know that we can see it in driver source code but How can I acces it
> from
> >> socket level ?
> >> Cheers，
> >>
> >>
> >> ___
> >> 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
>
>
>
> --
> 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

Re: [riot-devel] Transceiver : Reception level

[Baptiste Clenet]

Thanks Martine, I'll try when I've got time

2016-07-02 12:27 GMT+02:00 Martine Lenders :
> Hi Baptiste,
> if you can read it on the driver level, you can adapt
> gnrc_netdev2_hdr_t to add that value as a field and add it via the
> rx_info struct handed to the recv function of the netdev2-driver.
>
> Hope that was helpful feel free to ask for further details.
>
> Cheers,
> Martine
>
> 2016-07-01 21:57 GMT+02:00 Baptiste Clenet :
>> Hi,
>> When I receive a UDP frame, may I see the level (dB) of the received frame ?
>> I know that we can see it in driver source code but How can I acces it from
>> socket level ?
>> Cheers，
>>
>>
>> ___
>> 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



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

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

[Martine Lenders]

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 :
> 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
>
> 2016-06-23 23:56 GMT+02:00 MATTIA ANTONINI 
> :
>> Hi all!
>> I found the problem in the commit 0de34c9 [1]. Can anyone check this commit?
>> I've also tried  the commit before ( f7bd237) and everything works.
>>
>> Cheers,
>>
>> Mattia
>>
>>
>>
>> [1]
>> https://github.com/RIOT-OS/RIOT/commit/0de34c91c618829a845feef753b3ea32683365ed
>>
>> 2016-06-22 15:14 GMT+02:00 Alexandre Abadie :
>>>
>>> Hi,
>>>
>>> > though I do not have the same setup ready for testing, I _cannot_
>>> > confirm any
>>> > problems with UDP on latest RIOT master branch.
>>> >
>>> > I just tested UDP on a SAMR21-XPRO running gnrc_networking example and
>>> > successfully send and received UDP data from and to a RasPi with
>>> > Openlabs
>>> > transceiver running netcat on latest Raspbian-Linux.
>>> >
>>> > Could you clarify which RIOT branch/commit you use?
>>>
>>> Latest master. From what you say, the problem comes from the RIOT BR.
>>>
>>> Cheers,
>>>
>>> Alex
>>>
>>>
>>> >
>>> > Best,
>>> >   Sebastian
>>> >
>>> > > Am 21.06.2016 um 21:42 schrieb Alexandre Abadie
>>> > > :
>>> > >
>>> > > Hi Mattia,
>>> > >
>>> > > Thanks for reporting this issue.
>>> > >
>>> > >> I've discovered a possible bug in RIOT. I'm working with 2
>>> > >> samr21-xpro: on
>>> > >> the first is running gnrc_border_router (I'll call it A) and on the
>>> > >> other
>>> > >> (I'll call it B) is running gnrc_networking. I've well configured my
>>> > >> scenario infact I can ping both my nodes from linux shell. But, when
>>> > >> I
>>> > >> send
>>> > >> a UDP packet to B (with nc) it is forwarded correctly on tap
>>> > >> interface (I
>>> > >> seen it on wireshark) but it arrives corrupted (wrong checksum) to B
>>> > >> and
>>> > >> it
>>> > >> is dropped by UDP thread. I've enabled packet dump and the packet
>>> > >> arrives
>>> > >> with different packet lengths in ipv6 and udp headers (fixed to 8, it
>>> > >> is
>>> > >> the UDP header length) and the udp payload is removed.
>>> > >
>>> > > I have the exact same problem although I didn't track it as deep as
>>> > > you
>>> > > did.
>>> > >
>>> > >> How can I fix this problem?
>>> > >
>>> > > A regression was introduced 2 or 3 weeks ago in master and you could
>>> > > first
>>> > > "git bisect" to try to identify the incriminated commit.
>>> > >
>>> > > Thanks,
>>> > >
>>> > > Alex
>>> > > ___
>>> > > 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
>>
>>
>>
>> ___
>> 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] Progress of port to SODAQ Autonomo

[Thomas Eichinger]

All,

I am a little concerned the coding conventions getting too pedantic 
lately.


While I agree magic numbers should be avoided, I disagree to introduce 
#defines
for every single one of them as I do with introducing a static check for 
it.
(Using a #define for a number only used once in HW initialization for 
example

seems too much to me.)

I agree however with putting a comment with an explanation or data sheet 
reference

to each occurrence.
(Register initializations should use or'ed bit defines from vendor 
headers anyways.)
To me it is the duty of the maintainer reviewing the code to decide if 
it makes
sense to use a #define or a comment is enough. Thus I'd prefer a best 
practice

instead of a rule.

Best, Thomas

On 4 Jul 2016, at 9:20 CEST(+0200), Ludwig Knüpfer wrote:


On Mon, Jul 04, 2016 at 07:44:21AM +0200, Ludwig Knüpfer wrote:

Am 2. Juli 2016 13:21:19 MESZ, schrieb Kees Bakker :
While going through the code I notice that there are too many 
"magic"

constants. Hard coded numbers that are obvious for some, but not
obvious
for others. My advise: always try to use defines and add a comment
about
what constants mean. Or point to datasheet sections explaining the
constants.


Thank you for bringing this up.

I am uncertain if there is something that can be done about it in the 
existing code base, but at least we should find a way to prevent such 
issues in the future:


There is an "immediately" missing in the sentence above... I guess
there's quite a few of these ;)

Cheers,
Ludwig
___
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] Progress of port to SODAQ Autonomo

[Ludwig Knüpfer]

On Mon, Jul 04, 2016 at 07:44:21AM +0200, Ludwig Knüpfer wrote:
> Am 2. Juli 2016 13:21:19 MESZ, schrieb Kees Bakker :
> >While going through the code I notice that there are too many "magic"
> >constants. Hard coded numbers that are obvious for some, but not
> >obvious
> >for others. My advise: always try to use defines and add a comment
> >about
> >what constants mean. Or point to datasheet sections explaining the 
> >constants.
> 
> Thank you for bringing this up.
> 
> I am uncertain if there is something that can be done about it in the 
> existing code base, but at least we should find a way to prevent such issues 
> in the future:

There is an "immediately" missing in the sentence above... I guess
there's quite a few of these ;)

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