Skip to content

drivers/sx127x, sys: configure auto_init and improve netif adaption#7356

Closed
aabadie wants to merge 5 commits intoRIOT-OS:masterfrom
aabadie:auto_init_sx127x
Closed

drivers/sx127x, sys: configure auto_init and improve netif adaption#7356
aabadie wants to merge 5 commits intoRIOT-OS:masterfrom
aabadie:auto_init_sx127x

Conversation

@aabadie
Copy link
Copy Markdown
Contributor

@aabadie aabadie commented Jul 13, 2017

Another step toward better integration of LoRa into RIOT.

This PR provides adaption of Semtech SX1272/76 devices to gnrc_netdev, and gives the possibility to auto-initialize them and use shell commands (e.g ifconfig).
With this PR, the code should be ready to be used with LoRaWAN stacks (I guess).

There are obviously things that I made wrong because of my poor knowledge of the way gnrc and netapi works, so comments are welcome (especially the way packet snips are handled).

There are 2 shell commands provided when netdev_default and sx127x modules are loaded:

  • ifconfig: allows to configure the essential LoRa radio parameter (channel, bandwidth, SF, CR, etc).
  • lora: for setting the radio to RX mode or send raw packets.

Examples:

> ifconfig
Iface  4   Channel: 868299987Hz  TX-Power: 14dBm  State: 
           Bandwidth: 125kHz
           Spreading factor: 12 
           Coding rate: 4/8 
           Inverted IQ: off
> lora 4 listen
> lora 4 send test

The ifconfig command here is a pale adaption of the initial ifconfig command. I think there's room for improvement (and factorization), but since the _sc_netif.c is already huge, I didn't want to put more mess on it.

I applied the auto configuration for the b-l072z-lrwan1 board: this way, the examples/default can be used to interact with the radio on it without having to tweak anything.

@aabadie aabadie added Area: drivers Area: Device drivers Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation GNRC Area: network Area: Networking State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet labels Jul 13, 2017
@aabadie aabadie added this to the Release 2017.10 milestone Jul 13, 2017
Copy link
Copy Markdown
Member

@jia200x jia200x left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just did a quick review and added some comments. As soon as I have time I will continue with the review ;).

Cheers

@@ -302,10 +305,10 @@ static void _event_cb(netdev_t *dev, netdev_event_t event)
case NETDEV_EVENT_RX_COMPLETE:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a packet is received here, where is it hooked to gnrc_netdev?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, one might reuse the default gnrc_netdev _event_cb and the gnrc_netdev thread since gnrc_netdev->recv is pointing to sx127x_adpt_recv. We would need to find a way to handle LoRa specific NETDEV events though...

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(we could tag the pkt->type to a LoRaWAN packet, and automatically pass the packet to application with this line ). Any comments? :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This application is not part of gnrc_netdev. It's just here to show how the underlying thread communicate with the driver netdev interface.
gnrc_netdev has it's own thread here and the gnrc_netdev adaption of sx127x uses this one now, via the auto_init stuff.

@aabadie
Copy link
Copy Markdown
Contributor Author

aabadie commented Jul 14, 2017

Also notice the WIP label, since the lora send/listen command doesn't work yet (help appreciated here). I wanted to propose this before being on vacations to not block other interested people.

@aabadie
Copy link
Copy Markdown
Contributor Author

aabadie commented Jul 14, 2017

since the lora send/listen command doesn't work yet

actually it does work ;) I could exchange packet snips between 2 boards.

@aabadie aabadie force-pushed the auto_init_sx127x branch from 0ef04db to a6be0f2 Compare July 14, 2017 16:45
@aabadie aabadie removed the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Jul 14, 2017
@jia200x
Copy link
Copy Markdown
Member

jia200x commented Jul 14, 2017

@aabadie great :). I will do some tests today.
Cheers

@aabadie
Copy link
Copy Markdown
Contributor Author

aabadie commented Jul 14, 2017

we could tag the pkt->type to a LoRaWAN packet, and automatically pass the packet to application. Any comments?

I'm ok with the LoRaWAN packet type but I'm not sure with application. Do you mean application layer ?

@aabadie
Copy link
Copy Markdown
Contributor Author

aabadie commented Jul 14, 2017

I will do some tests today.

There's still an issue when changing channel, I'm investigating. Otherwise it works well when one plays with bandwidth, SF and CR.

@aabadie aabadie force-pushed the auto_init_sx127x branch 3 times, most recently from d61c502 to de1bc1d Compare July 14, 2017 17:27
@aabadie
Copy link
Copy Markdown
Contributor Author

aabadie commented Jul 14, 2017

There's still an issue when changing channel, I'm investigating

I think I fixed it: I can exchange packet after switching channels. My change is to switch to op_mode sleep before switching channel. Not sure it's the best solution.

@aabadie aabadie added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jul 14, 2017
@aabadie aabadie force-pushed the auto_init_sx127x branch 2 times, most recently from 3a7b931 to d6b2c9b Compare July 14, 2017 17:51
@jia200x
Copy link
Copy Markdown
Member

jia200x commented Jul 14, 2017

I think I fixed it: I can exchange packet after switching channels. My change is to switch to op_mode sleep before switching channel. Not sure it's the best solution.

I will check the regs to see why this is happening.

@jia200x
Copy link
Copy Markdown
Member

jia200x commented Jul 14, 2017

After a node receives a big payload, the channel set command crashes. Have you had the same issue?

Node 1:

2017-07-14 16:00:33,520 - INFO # send AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2017-07-14 16:00:33,527 - INFO # sending "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" payload (47 bytes)
> 2017-07-14 16:00:36,815 - INFO #  Transmission completed

Node 2:

2017-07-14 16:00:36,851 - INFO # {Payload: "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" (47 bytes), RSSI: 221, SNR: 9, TOA: 3023}
set channel 915000000
2017-07-14 16:00:44,667 - INFO # set channel 915000000
2017-07-14 16:00:44,670 - INFO # shell: command not found: set
> channel set 915000000
2017-07-14 16:00:48,707 - INFO #  channel set 915000000
2017-07-14 16:00:48,711 - INFO # Stack pointer corrupted, reset to top of stack
2017-07-14 16:00:48,712 - INFO # Misc
2017-07-14 16:00:48,714 - INFO # EXC_RET: 0xfffffffd

@jia200x
Copy link
Copy Markdown
Member

jia200x commented Jul 14, 2017

I'm having some problems with the sx1276 driver + samr21.
I tested an old implementation of the sx1276 driver and can send without problems:


2017-07-14 16:58:04,323 - INFO # tx_test asdasdasd
2017-07-14 16:58:04,327 - INFO # tx_test: sending "asdasdasd" payload (10 bytes)
2017-07-14 16:58:04,339 - INFO # tx_test: sended
> 2017-07-14 16:58:05,320 - INFO #  TX DONE
2017-07-14 16:58:04,323 - INFO # tx_test asdasdasd
2017-07-14 16:58:04,327 - INFO # tx_test: sending "asdasdasd" payload (10 bytes)
2017-07-14 16:58:04,339 - INFO # tx_test: sended
> 2017-07-14 16:58:05,320 - INFO #  TX DONE

With the master driver, I'm randomly having this kind of issues:

send aaa
2017-07-14 17:01:35,113 - INFO #  send aaa
2017-07-14 17:01:35,116 - INFO # sending "aaa" payload (4 bytes)
> send asdasd
2017-07-14 17:01:44,866 - INFO #  send asdasd
2017-07-14 17:01:44,869 - INFO # sending "asdasd" payload (7 bytes)
2017-07-14 17:01:44,873 - INFO # Cannot send: radio is still transmitting

I'm investigating the problem

@aabadie
Copy link
Copy Markdown
Contributor Author

aabadie commented Jul 14, 2017

After a node receives a big payload, the channel set command crashes. Have you had the same issue?

With what payload size ? I had this at one point when working on the driver integration but thought I fixed it.
BTW your are running the test application (tests/drivers_sx127x) which is not what this PR is meant for. If you have the ST b-l072z-lrwan1 board, you can test the examples/default application.

@aabadie
Copy link
Copy Markdown
Contributor Author

aabadie commented Jul 14, 2017

With the master driver, I'm randomly having this kind of issues

This is not an issue but a feature ;) One cannot send packet while the radio is in TX state. This is because with big payload and SF 12 the transmission can take several seconds. So there's a check on the device state. If it's TX, the transmission is skipped with the message:

Cannot send: radio is still transmitting

Maybe we can bufferize this but this is not the case now.

@@ -0,0 +1,101 @@
/*
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dito

Copy link
Copy Markdown
Contributor Author

@aabadie aabadie Jul 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get this. It's done the same way in a lot of other places.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was referring to #7356 (comment) here (to make this gnrc_netdev_lora.c instead)

@@ -0,0 +1,586 @@
/*
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not extend sc_netif.c instead?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried but it was becoming a mess with other #ifdef in this file. I thought splitting the 2 would make the code more readable. Maybe we can factorize the interface list and config commands.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#7370 will cause a vast simplification of sc_netif.c anyway. Let's see if we can fix it then.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

out of topic: do you know a way to access the device handler (pointer to netdev_t or sx127x_t) from sc_sx127x.c or other shell commands ? I wanted to provide more CLI features such as access time on air of a packet or device internal temperature which require direct access to driver API whereas I only have access to thread pid there.

@aabadie aabadie force-pushed the auto_init_sx127x branch from f709380 to 258abc6 Compare July 17, 2017 17:10
@jia200x
Copy link
Copy Markdown
Member

jia200x commented Jul 17, 2017

@aabadie:

out of topic: do you know a way to access the device handler (pointer to netdev_t or sx127x_t) from sc_sx127x.c or other shell commands ? I wanted to provide more CLI features such as access time on air of a packet or device internal temperature which require direct access to driver API whereas I only have access to thread pid there.

Not sure if solved, but you can use gnrc_netapi_get for this purpose (and declare new NETOPTs if needed).

@@ -0,0 +1,42 @@
/*
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please call this file sys/include/net/gnrc/netdev/lora.h to be more in line with gnrc/netdev/ieee802154.h and gnrc/netdev/eth.h. xbee_adpt.h is a special case, since it is IEEE 802.15.4 but uses its own communication protocol to interact with the device.

@miri64
Copy link
Copy Markdown
Member

miri64 commented Aug 2, 2017

In lieu of the netif rework (see #7370): can you reduce this to the auto-initialization and the LoRA adaption layer? I'm still thinking, that the shell command should be merged into ifconfig (new [#7404] or old, I don't care ^^), so let's discuss this in a separate PR.

@aabadie aabadie changed the title drivers/sx127x, sys: configure auto_init and add shell commands drivers/sx127x, sys: configure auto_init and improve netif adaption Aug 17, 2017
@aabadie
Copy link
Copy Markdown
Contributor Author

aabadie commented Aug 17, 2017

In lieu of the netif rework (see #7370): can you reduce this to the auto-initialization and the LoRA adaption layer?

Done

the shell command should be merged into ifconfig (new [#7404] or old, I don't care ^^), so let's discuss this in a separate PR.

Ok, I'll come up with another PR soon.

@aabadie
Copy link
Copy Markdown
Contributor Author

aabadie commented Dec 10, 2017

Closing this one in favour of #8159 and #8160.

@aabadie aabadie closed this Dec 10, 2017
@aabadie aabadie deleted the auto_init_sx127x branch February 26, 2018 10:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: drivers Area: Device drivers Area: LoRa Area: LoRa radio support Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants