wpanusb?

wpanusb?

[Christopher Friedt]

Hi all,

Bouncing around a bit, but in Zephyr, there is reference to a
"wpanusb" Linux kernel driver here:

https://docs.zephyrproject.org/latest/samples/net/wpanusb/README.html

This *might* be the driver in question:

https://github.com/finikorg/wpanusb

Just wondering if anyone has made any attempts to submit that, or
would that go directly upstream these days?

Hope you are well.

Incidentally, we're hoping to do a microconference at Linux Plumbers
again this year again, virtually of course.

C

Re: wpanusb?

[Stefan Schmidt]

Hello.

On 25.05.20 14:39, Christopher Friedt wrote:
> Hi all,
> 
> Bouncing around a bit, but in Zephyr, there is reference to a
> "wpanusb" Linux kernel driver here:
> 
> https://docs.zephyrproject.org/latest/samples/net/wpanusb/README.html
> 
> This *might* be the driver in question:
> 
> https://github.com/finikorg/wpanusb

It is.

> 
> Just wondering if anyone has made any attempts to submit that, or
> would that go directly upstream these days?

I had a chance to talk to the author a while back. Not much activity 
from his side.

For me this needs to be designed in a way where we could have bare 
metal, Zephyr, RIOT or Contiki based firmware implementing the interface 
and the driver would just work. The code available is a good start but 
needs more work.

I was, and somehow still am, planning on working on this. But with the 
world turned upside down there was always something else to look at 
before. Its on my list, just not very high. If anyone wants to have a 
stab at this feel free and let me know.

> Hope you are well.
> 
> Incidentally, we're hoping to do a microconference at Linux Plumbers
> again this year again, virtually of course.

Feel free to keep me in the loop. Would be happy to participate again if 
time allows.

regards
Stefan Schmidt

Re: wpanusb?

[Christopher Friedt]

Hi Stefan!

On Tue, May 26, 2020 at 3:38 PM Stefan Schmidt
<stefan@datenfreihafen.org> wrote:
> On 25.05.20 14:39, Christopher Friedt wrote:
> > Hi all,
> >
> > Bouncing around a bit, but in Zephyr, there is reference to a
> > "wpanusb" Linux kernel driver here:
> >
> > https://docs.zephyrproject.org/latest/samples/net/wpanusb/README.html
> >
> > This *might* be the driver in question:
> >
> > https://github.com/finikorg/wpanusb
> >
> > Just wondering if anyone has made any attempts to submit that, or
> > would that go directly upstream these days?
>
> I had a chance to talk to the author a while back. Not much activity
> from his side.

I was chatting with him as well on Zephyr Slack and let him know that
there was significant interest in it going upstream. I worry though
that it might not be a high priority for his employer.

Is there a linux-wpan IRC? Would be nice to chat in real-time at some point.

> For me this needs to be designed in a way where we could have bare
> metal, Zephyr, RIOT or Contiki based firmware implementing the interface
> and the driver would just work. The code available is a good start but
> needs more work.

I agree mostly. Of course each RTOS has their own headers, way of
declaring things, etc, but for the most part it could be platform
independent.

> I was, and somehow still am, planning on working on this. But with the
> world turned upside down there was always something else to look at
> before. Its on my list, just not very high. If anyone wants to have a
> stab at this feel free and let me know.

I'll bring it up in the Zephyr Slack. They want to incorporate it into
their "tools" repository, but it really should go into Linux at some
point.

We'll probably end up working on this for BB.O - even just having a
single driver that works for all boards in Zephyr is a pretty large
step.

Lastly, I feel like this is a recurring question, but a number of us
will likely need a bunch of 802.15.4 USB dongle to speak to our 15.4
nodes. I have a couple of ATUSB on my desk, but are there others in
our group that don't have any idea where to get parts, and likely
building one from scratch would be more time than they want to take.

Do you know of an off-the-shelf product that works with existing
drivers upstream?

M.f.G.

Chris

Re: wpanusb?

[Stefan Schmidt]

Hello.

On 29.05.20 21:33, Christopher Friedt wrote:
> Hi Stefan!
> 
> On Tue, May 26, 2020 at 3:38 PM Stefan Schmidt
> <stefan@datenfreihafen.org> wrote:
>> On 25.05.20 14:39, Christopher Friedt wrote:
>>> Hi all,
>>>
>>> Bouncing around a bit, but in Zephyr, there is reference to a
>>> "wpanusb" Linux kernel driver here:
>>>
>>> https://docs.zephyrproject.org/latest/samples/net/wpanusb/README.html
>>>
>>> This *might* be the driver in question:
>>>
>>> https://github.com/finikorg/wpanusb
>>>
>>> Just wondering if anyone has made any attempts to submit that, or
>>> would that go directly upstream these days?
>>
>> I had a chance to talk to the author a while back. Not much activity
>> from his side.
> 
> I was chatting with him as well on Zephyr Slack and let him know that
> there was significant interest in it going upstream. I worry though
> that it might not be a high priority for his employer.
> 
> Is there a linux-wpan IRC? Would be nice to chat in real-time at some point.

#linux-wpan at Freenode :-)

>> For me this needs to be designed in a way where we could have bare
>> metal, Zephyr, RIOT or Contiki based firmware implementing the interface
>> and the driver would just work. The code available is a good start but
>> needs more work.
> 
> I agree mostly. Of course each RTOS has their own headers, way of
> declaring things, etc, but for the most part it could be platform
> independent.

I would still expect that each RTOS has their own firmware to adapt 
their ieee802154 abstraction and supported hw to the generic wpanusb 
driver. The USB interface they expose would be the same, and behave the 
same though.

>> I was, and somehow still am, planning on working on this. But with the
>> world turned upside down there was always something else to look at
>> before. Its on my list, just not very high. If anyone wants to have a
>> stab at this feel free and let me know.
> 
> I'll bring it up in the Zephyr Slack. They want to incorporate it into
> their "tools" repository, but it really should go into Linux at some
> point.

I agree.

> We'll probably end up working on this for BB.O - even just having a
> single driver that works for all boards in Zephyr is a pretty large
> step.

If work is going on for this and you are getting an idea on the level of 
abstraction I would be happy to discuss how this should result in a 
generic wpanusb driver.

> Lastly, I feel like this is a recurring question, but a number of us
> will likely need a bunch of 802.15.4 USB dongle to speak to our 15.4
> nodes. I have a couple of ATUSB on my desk, but are there others in
> our group that don't have any idea where to get parts, and likely
> building one from scratch would be more time than they want to take.
> 
> Do you know of an off-the-shelf product that works with existing
> drivers upstream?

ATUSB are still being produced and sold:
http://shop.sysmocom.de/products/atusb

Sysmocom is doing small batches (100-200 pieces) whenever their stock 
goes low. The price is not really making money for them and is mostly 
covering their expenses. Its one of their many contributions to help 
Open Source projects with hardware. (As you most likely can read from 
this I am _very_ happy they are handling all the hardware manufacturing 
and logistics for this).

I am flashing every single one of these atusb's by hand as well (for 
free, just to keep the supply alive). :-)

The available CC2531 dongles would be available for ~10 USD from China, 
but there is no driver support (it would be a perfect candidate for the 
wpanusb driver with a bare-metal firmware).

If the need it not USB but SPI there are plenty to choose from.

regards
Stefan Schmidt

Re: wpanusb?

[Christopher Friedt]

On Sat, May 30, 2020 at 7:33 AM Stefan Schmidt
<stefan@datenfreihafen.org> wrote:
> On 29.05.20 21:33, Christopher Friedt wrote:
> > On Tue, May 26, 2020 at 3:38 PM Stefan Schmidt
> > <stefan@datenfreihafen.org> wrote:
> >> On 25.05.20 14:39, Christopher Friedt wrote:
> >>> Hi all,
> >>>
> >>> Bouncing around a bit, but in Zephyr, there is reference to a
> >>> "wpanusb" Linux kernel driver here:
> >>>
> >>> https://docs.zephyrproject.org/latest/samples/net/wpanusb/README.html
> >>>
> >>> This *might* be the driver in question:
> >>>
> >>> https://github.com/finikorg/wpanusb
> >>>
> >>> Just wondering if anyone has made any attempts to submit that, or
> >>> would that go directly upstream these days?
> >>
> >> I had a chance to talk to the author a while back. Not much activity
> >> from his side.
> >
> > I was chatting with him as well on Zephyr Slack and let him know that
> > there was significant interest in it going upstream. I worry though
> > that it might not be a high priority for his employer.
> >
> > Is there a linux-wpan IRC? Would be nice to chat in real-time at some point.
>
> #linux-wpan at Freenode :-)

I see some familiar nicks there ;-)

> >> For me this needs to be designed in a way where we could have bare
> >> metal, Zephyr, RIOT or Contiki based firmware implementing the interface
> >> and the driver would just work. The code available is a good start but
> >> needs more work.
> >
> > I'll bring it up in the Zephyr Slack. They want to incorporate it into
> > their "tools" repository, but it really should go into Linux at some
> > point.
>
> > We'll probably end up working on this for BB.O - even just having a
> > single driver that works for all boards in Zephyr is a pretty large
> > step.
>
> If work is going on for this and you are getting an idea on the level of
> abstraction I would be happy to discuss how this should result in a
> generic wpanusb driver.

Sounds good. If you want to email me directly I can see if I can fit
it into the current project, or even see if I can work with the
original wpanusb author.

> > Lastly, I feel like this is a recurring question, but a number of us
> > will likely need a bunch of 802.15.4 USB dongle to speak to our 15.4
> > nodes. I have a couple of ATUSB on my desk, but are there others in
> > our group that don't have any idea where to get parts, and likely
> > building one from scratch would be more time than they want to take.
> >
> > Do you know of an off-the-shelf product that works with existing
> > drivers upstream?
>
> ATUSB are still being produced and sold:
> http://shop.sysmocom.de/products/atusb
>
> Sysmocom is doing small batches (100-200 pieces) whenever their stock
> goes low. The price is not really making money for them and is mostly
> covering their expenses. Its one of their many contributions to help
> Open Source projects with hardware. (As you most likely can read from
> this I am _very_ happy they are handling all the hardware manufacturing
> and logistics for this).
>
> I am flashing every single one of these atusb's by hand as well (for
> free, just to keep the supply alive). :-)

That is dedication ;-) Hopefully this winter I should have some
dedicated manufacturing space, so I'm looking forward to spinning out
a few OSHW boards too.

> The available CC2531 dongles would be available for ~10 USD from China,
> but there is no driver support (it would be a perfect candidate for the
> wpanusb driver with a bare-metal firmware).

Excellent!

I also found this which seems like it should be supported (with
something out of linux-firmware maybe?)

http://www.ti.com/tool/CC2531EMK

C

Re: wpanusb?

[Koen Zandberg]

[-- Attachment #1.1: Type: text/plain, Size: 2075 bytes --]

Hello all,

Long term RIOT maintainer here.

On 30-05-2020 17:08, Christopher Friedt wrote:
> On Sat, May 30, 2020 at 7:33 AM Stefan Schmidt
> <stefan@datenfreihafen.org> wrote:
>> On 29.05.20 21:33, Christopher Friedt wrote:
>>> On Tue, May 26, 2020 at 3:38 PM Stefan Schmidt
>>> <stefan@datenfreihafen.org> wrote:
>>>> On 25.05.20 14:39, Christopher Friedt wrote:
>>>>> Hi all,
>>>>>
>>>>> Bouncing around a bit, but in Zephyr, there is reference to a
>>>>> "wpanusb" Linux kernel driver here:
>>>>>
>>>>> https://docs.zephyrproject.org/latest/samples/net/wpanusb/README.html
>>>>>
>>>>> This *might* be the driver in question:
>>>>>
>>>>> https://github.com/finikorg/wpanusb
>>>>>
>>>>> Just wondering if anyone has made any attempts to submit that, or
>>>>> would that go directly upstream these days?
>>>> I had a chance to talk to the author a while back. Not much activity
>>>> from his side.
>>> I was chatting with him as well on Zephyr Slack and let him know that
>>> there was significant interest in it going upstream. I worry though
>>> that it might not be a high priority for his employer.
Most of our developers have of-the-shelve development boards such as the
nrf52840dk and the samr21-xplained pro. For us a generic firmware +
Linux kernel driver would be a very welcome addition to the tool set.
>>>> For me this needs to be designed in a way where we could have bare
>>>> metal, Zephyr, RIOT or Contiki based firmware implementing the interface
>>>> and the driver would just work. The code available is a good start but
>>>> needs more work.
>>> I'll bring it up in the Zephyr Slack. They want to incorporate it into
>>> their "tools" repository, but it really should go into Linux at some
>>> point.

I'm willing to work on this for a RIOT implementation, assuming there is
some documentation available on the USB protocol side :)
I think I should be able to get a relative generic firmware application
able to run on any of our hardware boards as long as they have a radio
and a USB interface.

Koen



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: wpanusb?

[Christopher Friedt]

Hi Koen,

On Sat, May 30, 2020 at 2:10 PM Koen Zandberg <koen@bergzand.net> wrote:
>
> Hello all,
>
> Long term RIOT maintainer here.
>
> I'm willing to work on this for a RIOT implementation, assuming there is
> some documentation available on the USB protocol side :)
> I think I should be able to get a relative generic firmware application
> able to run on any of our hardware boards as long as they have a radio
> and a USB interface.

That's great news!

Also, I heard from the original wpanusb author and he said he'll put
submitting a patch any day now.

Cheers,

C

Re: wpanusb?

[Stefan Schmidt]

Hello.

[Putting Adrei in CC as well, not sure if he is subscribed to linux-wpan]

On 31.05.20 18:13, Christopher Friedt wrote:
> Hi Koen,
> 
> On Sat, May 30, 2020 at 2:10 PM Koen Zandberg <koen@bergzand.net> wrote:
>>
>> Hello all,
>>
>> Long term RIOT maintainer here.
>>
>> I'm willing to work on this for a RIOT implementation, assuming there is
>> some documentation available on the USB protocol side :)
>> I think I should be able to get a relative generic firmware application
>> able to run on any of our hardware boards as long as they have a radio
>> and a USB interface.
> 
> That's great news!
> 
> Also, I heard from the original wpanusb author and he said he'll put
> submitting a patch any day now.

Happy to see that we finally have the critical mass to get this moved 
forward. :-)

Here is my take on what I think needs to be done.

On a first review I found nothing wrong with the design. It needs 
further extending and flexibility in my opinion, though.

o Add a GET_EXTENDED_ADDR command to receive the extended address 
provided by the transceiver itself, or firmware in some way.

o Adding a GET_CAPABILITIES command to query device capabilities
  during init to enable and set needed ieee802154_ops based on the 
device. Given that we aim to support as many transceivers as possible we 
can't rely on static device knowledge to configure wpanusb correctly.

o Add opcode for set_lbt in USB spec

o Add opcode for set_frame_retries USB spec. (If a transceiver does not 
support AutoACK in hardware do Zephyr and RIOT support a software 
fallback to handle AutoACK?)

o How are we going to handle transceiver which allow MTUs > 127? Not a 
high priority as the kernel part does not support this either right now.

o Do Zephyr or RIOT expose additional functionality we should support here?

o Koen, you offered to look into implementing the firmware support for 
the USB spec in RIOT. Does the spec fit what RIOT has as abstraction for 
ieee802154?

o Adrei, Chris, I understand it you would work on the wpanusb as well as 
the Zephyr firmware side, correct?

o I see additional use cases for a bare metal firmwares (a different fw 
to support wpanusb on the atusb device or CC2531 comes to mind). But 
none of those are critical in the beginning.

regards
Stefan Schmidt

Re: wpanusb?

[Koen Zandberg]

[-- Attachment #1.1: Type: text/plain, Size: 3441 bytes --]

Hello

On 03-06-2020 20:18, Stefan Schmidt wrote:
> Hello.
>
> Happy to see that we finally have the critical mass to get this moved
> forward. :-)
>
> Here is my take on what I think needs to be done.
>
> On a first review I found nothing wrong with the design. It needs
> further extending and flexibility in my opinion, though.
I would suggest using USB bulk endpoints for both the tx and rx paths.
An interrupt IN endpoint might be useful for events from the radio back
to the host such as ack information from a transmit. This way we can
keep the control messages to configuration only. This is similar to how
USB ethernet devices are using different USB endpoints. I also see
issues with transferring large 802.15.4g frames over control endpoints.
Something similar like CDC-ECM would be my preference here: Split the
frame in multiple bulk transfers and detect the end of the frame by a
transfer size not equal to the endpoint size.
>
> o Add a GET_EXTENDED_ADDR command to receive the extended address
> provided by the transceiver itself, or firmware in some way.
+1
>
> o Adding a GET_CAPABILITIES command to query device capabilities
>  during init to enable and set needed ieee802154_ops based on the
> device. Given that we aim to support as many transceivers as possible
> we can't rely on static device knowledge to configure wpanusb correctly.
Does it make sense to include also a "protocol" version here, to allow
extending the feature set of the driver later without causing
compatibility issues between the firmware and the kernel?
>
> o Add opcode for set_lbt in USB spec
This requires some clarification for me how the radio should be
configured. Is this just a CSMA/CCA switch?
>
> o Add opcode for set_frame_retries USB spec. (If a transceiver does
> not support AutoACK in hardware do Zephyr and RIOT support a software
> fallback to handle AutoACK?)
This can be implemented in RIOT. I don't think there is something in
place at the moment, most of our radios support this in hardware, but I
see no technical reason why not to support this.
>
> o How are we going to handle transceiver which allow MTUs > 127? Not a
> high priority as the kernel part does not support this either right now.
There is some preliminary support for 802.15.4g radios in RIOT. I know
some developers that would prefer not to have to have the MTU limited to
127 bytes :)
>
> o Do Zephyr or RIOT expose additional functionality we should support
> here?
>
> o Koen, you offered to look into implementing the firmware support for
> the USB spec in RIOT. Does the spec fit what RIOT has as abstraction
> for ieee802154?

Yes, implementing configuration settings as USB control messages makes
glueing them to the radio abstraction layer very easy. For now RIOT has
configuration for:

 - reading and writing channel/page settings
 - read/write to addresses, both long and short
 - PAN ID
 - TX power settings
 - reading the max PSDU size
 - Ack config settings
 - CCA and CSMA configuration, enabling/disabling, retries and backoff
exponent (max/min)
 - CCA threshold and mode

Furthermore, it is possible to get frame metadata such as the received
signal strength and the number of retries required for the frame
transmit. All these settings depend a bit on the radio hardware features
of course, but thats what we have the GET_CAPABILITIES for.

Koen



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: wpanusb?

[Stefan Schmidt]

Hallo.

On 05.06.20 13:07, Koen Zandberg wrote:
> Hello
> 
> On 03-06-2020 20:18, Stefan Schmidt wrote:
>> Hello.
>>
>> Happy to see that we finally have the critical mass to get this moved
>> forward. :-)
>>
>> Here is my take on what I think needs to be done.
>>
>> On a first review I found nothing wrong with the design. It needs
>> further extending and flexibility in my opinion, though.
> I would suggest using USB bulk endpoints for both the tx and rx paths.
> An interrupt IN endpoint might be useful for events from the radio back
> to the host such as ack information from a transmit. This way we can
> keep the control messages to configuration only. This is similar to how
> USB ethernet devices are using different USB endpoints. I also see
> issues with transferring large 802.15.4g frames over control endpoints.
> Something similar like CDC-ECM would be my preference here: Split the
> frame in multiple bulk transfers and detect the end of the frame by a
> transfer size not equal to the endpoint size.

That sounds fine to me. Adrei, what do you think about this change?

>>
>> o Add a GET_EXTENDED_ADDR command to receive the extended address
>> provided by the transceiver itself, or firmware in some way.
> +1
>>
>> o Adding a GET_CAPABILITIES command to query device capabilities
>>   during init to enable and set needed ieee802154_ops based on the
>> device. Given that we aim to support as many transceivers as possible
>> we can't rely on static device knowledge to configure wpanusb correctly.
> Does it make sense to include also a "protocol" version here, to allow
> extending the feature set of the driver later without causing
> compatibility issues between the firmware and the kernel?

I was hoping that we could cover what we need with the current spec and 
we could just add more capability flags for new things. We could got the 
full way to have a protocol version during the init as well.

>>
>> o Add opcode for set_lbt in USB spec
> This requires some clarification for me how the radio should be
> configured. Is this just a CSMA/CCA switch?

 From what I have seen this listen before talk is often (always?) a 
hardware feature of sub GHz (where its needed) transceivers. I would 
assume this just makes sure we pass the config from linux stack through 
the driver to the firmware.

>>
>> o Add opcode for set_frame_retries USB spec. (If a transceiver does
>> not support AutoACK in hardware do Zephyr and RIOT support a software
>> fallback to handle AutoACK?)
> This can be implemented in RIOT. I don't think there is something in
> place at the moment, most of our radios support this in hardware, but I
> see no technical reason why not to support this.

Good

>>
>> o How are we going to handle transceiver which allow MTUs > 127? Not a
>> high priority as the kernel part does not support this either right now.
> There is some preliminary support for 802.15.4g radios in RIOT. I know
> some developers that would prefer not to have to have the MTU limited to
> 127 bytes :)

While we do not support this in the Linux stack yet, we should still 
make sure the spec here is capable of supporting this.

>>
>> o Do Zephyr or RIOT expose additional functionality we should support
>> here?
>>
>> o Koen, you offered to look into implementing the firmware support for
>> the USB spec in RIOT. Does the spec fit what RIOT has as abstraction
>> for ieee802154?
> 
> Yes, implementing configuration settings as USB control messages makes
> glueing them to the radio abstraction layer very easy. For now RIOT has
> configuration for:
> 
>   - reading and writing channel/page settings
>   - read/write to addresses, both long and short
>   - PAN ID
>   - TX power settings
>   - reading the max PSDU size

Hmm, we do not have that. But getting the info from the firmware would 
be useful.


>   - Ack config settings
>   - CCA and CSMA configuration, enabling/disabling, retries and backoff
> exponent (max/min)
>   - CCA threshold and mode

Is there a way to the device in promiscuous mode?

> 
> Furthermore, it is possible to get frame metadata such as the received
> signal strength and the number of retries required for the frame

Currently the spec only covers LQI, but getting extra stats on the 
reliability could bring in some extra benefit for routing decisions.

> transmit. All these settings depend a bit on the radio hardware features
> of course, but thats what we have the GET_CAPABILITIES for.

Yes, exactly, with the capabilities we get during init from the firmware 
it can be signalled what it supports and we would enable the needed 
device ops for the Linux stack ased on this.

regards
Stefan Schmidt

Re: wpanusb?

[Stefan Schmidt]

Hello.

Bumping this thread again.

On 07.06.20 14:17, Stefan Schmidt wrote:
> Hallo.
> 
> On 05.06.20 13:07, Koen Zandberg wrote:
>> Hello
>>
>> On 03-06-2020 20:18, Stefan Schmidt wrote:
>>> Hello.
>>>
>>> Happy to see that we finally have the critical mass to get this moved
>>> forward. :-)
>>>
>>> Here is my take on what I think needs to be done.
>>>
>>> On a first review I found nothing wrong with the design. It needs
>>> further extending and flexibility in my opinion, though.
>> I would suggest using USB bulk endpoints for both the tx and rx paths.
>> An interrupt IN endpoint might be useful for events from the radio back
>> to the host such as ack information from a transmit. This way we can
>> keep the control messages to configuration only. This is similar to how
>> USB ethernet devices are using different USB endpoints. I also see
>> issues with transferring large 802.15.4g frames over control endpoints.
>> Something similar like CDC-ECM would be my preference here: Split the
>> frame in multiple bulk transfers and detect the end of the frame by a
>> transfer size not equal to the endpoint size.
> 
> That sounds fine to me. Adrei, what do you think about this change?

I heard back from him directly that he agrees with the idea of using 
bulk endpoints. He is working on other parts right now and does not have 
a working 15.4 setup at all. Unclear when he can come back to this.

If we want this moving forward we need to push it ourselves. 
Christopher, as you brought this up I am wondering if you have any plan 
to work on the wpanusb driver side? Koen offered to work on the RIOT 
side, but this does need the linux kernel driver as well.

If nobody plans any work on wpanusb I would need to see if I can free up 
time for it and do it myself. Not sure if and when this will be possible 
though.

With the other changes we discussed as changes before we should have a 
first target of what we wanted to get implemented. (and see what we 
forgot when the pieces are coming together)

regards
Stefan Schmidt

>>>
>>> o Add a GET_EXTENDED_ADDR command to receive the extended address
>>> provided by the transceiver itself, or firmware in some way.
>> +1
>>>
>>> o Adding a GET_CAPABILITIES command to query device capabilities
>>>   during init to enable and set needed ieee802154_ops based on the
>>> device. Given that we aim to support as many transceivers as possible
>>> we can't rely on static device knowledge to configure wpanusb correctly.
>> Does it make sense to include also a "protocol" version here, to allow
>> extending the feature set of the driver later without causing
>> compatibility issues between the firmware and the kernel?
> 
> I was hoping that we could cover what we need with the current spec and 
> we could just add more capability flags for new things. We could got the 
> full way to have a protocol version during the init as well.
> 
>>>
>>> o Add opcode for set_lbt in USB spec
>> This requires some clarification for me how the radio should be
>> configured. Is this just a CSMA/CCA switch?
> 
>  From what I have seen this listen before talk is often (always?) a 
> hardware feature of sub GHz (where its needed) transceivers. I would 
> assume this just makes sure we pass the config from linux stack through 
> the driver to the firmware.
> 
>>>
>>> o Add opcode for set_frame_retries USB spec. (If a transceiver does
>>> not support AutoACK in hardware do Zephyr and RIOT support a software
>>> fallback to handle AutoACK?)
>> This can be implemented in RIOT. I don't think there is something in
>> place at the moment, most of our radios support this in hardware, but I
>> see no technical reason why not to support this.
> 
> Good
> 
>>>
>>> o How are we going to handle transceiver which allow MTUs > 127? Not a
>>> high priority as the kernel part does not support this either right now.
>> There is some preliminary support for 802.15.4g radios in RIOT. I know
>> some developers that would prefer not to have to have the MTU limited to
>> 127 bytes :)
> 
> While we do not support this in the Linux stack yet, we should still 
> make sure the spec here is capable of supporting this.
> 
>>>
>>> o Do Zephyr or RIOT expose additional functionality we should support
>>> here?
>>>
>>> o Koen, you offered to look into implementing the firmware support for
>>> the USB spec in RIOT. Does the spec fit what RIOT has as abstraction
>>> for ieee802154?
>>
>> Yes, implementing configuration settings as USB control messages makes
>> glueing them to the radio abstraction layer very easy. For now RIOT has
>> configuration for:
>>
>>   - reading and writing channel/page settings
>>   - read/write to addresses, both long and short
>>   - PAN ID
>>   - TX power settings
>>   - reading the max PSDU size
> 
> Hmm, we do not have that. But getting the info from the firmware would 
> be useful.
> 
> 
>>   - Ack config settings
>>   - CCA and CSMA configuration, enabling/disabling, retries and backoff
>> exponent (max/min)
>>   - CCA threshold and mode
> 
> Is there a way to the device in promiscuous mode?
> 
>>
>> Furthermore, it is possible to get frame metadata such as the received
>> signal strength and the number of retries required for the frame
> 
> Currently the spec only covers LQI, but getting extra stats on the 
> reliability could bring in some extra benefit for routing decisions.
> 
>> transmit. All these settings depend a bit on the radio hardware features
>> of course, but thats what we have the GET_CAPABILITIES for.
> 
> Yes, exactly, with the capabilities we get during init from the firmware 
> it can be signalled what it supports and we would enable the needed 
> device ops for the Linux stack ased on this.
> 
> regards
> Stefan Schmidt

Re: wpanusb?

[Stefan Schmidt]

Hello.

On 21.07.20 19:11, Christopher Friedt wrote:
> +Erik
> 
> Sorry for my late response.
> 
> On Mon, Jul 6, 2020 at 10:42 AM Stefan Schmidt 
> <stefan@datenfreihafen.org <mailto:stefan@datenfreihafen.org>> wrote:
> 
>     If we want this moving forward we need to push it ourselves.
>     Christopher, as you brought this up I am wondering if you have any plan
>     to work on the wpanusb driver side? Koen offered to work on the RIOT
>     side, but this does need the linux kernel driver as well.
> 
> 
> Erik is also actively looking at wpan-usb for the BeagleConnect currently.
> 
> I'm sure I could get it up to snuff. In particular, it should be 
> straight-forward to do with the nice list of TODO items that Stefan 
> outlined earlier in the thread :-) 
> [1]<https://marc.info/?t=159041047800001&r=1&w=2>

Koen will also have some time in August and expressed interest in 
working on it. I will be away on vacation first half of August. It would 
be great if you three can coordinate this a bit.

> 
>     With the other changes we discussed as changes before we should have a
>     first target of what we wanted to get implemented. (and see what we
>     forgot when the pieces are coming together)
> 
> 
> Exactly.
> 
> I had one question, specifically because it impacts the BeagleConnect 
> project, but also because it's been a while since I've done any 15.4 
> hacking in Linux.
> 
> Does Linux already support the 900 MHz phy and IEEE bits?
> 
> If possible, we're hoping to be able to use it for the 2.4 GHz band and 
> the 900 MHz band.

We have drivers for the sub-GHz band (at86rf212 and the HUL USB support 
in atusb which also uses the 212). We also have support for a 
listen-before-talk (LBT) driver operation to make that part work with 
the drivers.

To be honest I have not done sub-GHz testing myself here, but given the 
work people put into the at86rf212 support I would think it should work 
for some first tries. Reports welcome!

regards
Stefan Schmidt

Re: wpanusb?

[Stefan Schmidt]

Hello

On 21.07.20 19:11, Christopher Friedt wrote:
> 
> Does Linux already support the 900 MHz phy and IEEE bits?
> 
> If possible, we're hoping to be able to use it for the 2.4 GHz band and 
> the 900 MHz band.

As follow up from what I wrote on the 900 MHz stuff before here is a 
link where we are adding sub GHz support to the atusb driver

https://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next.git/commit/?id=d5dd29e4dafef4baad7bf529ad73cafeb13e1aa8

regards
Stefan Schmidt

Re: wpanusb?

[Stefan Schmidt]

Hello.

[Added Erik here to be part of the discussion]

This mostly goes to Koen and Erik. Please coordinate how you are wanting 
to work on this. And be pro-active. Waiting for the other one to start 
will just lead to starving :-)


I started to hack together some parts as I would do them. Really not 
working at all right now and only compile tested. I will give more 
details below. I am not sure if I will find time to work more on this 
next week before I go on vacation, so here is what I have:

https://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next.git/log/?h=wpanusb-original

Feel free to use any of it or ignore it if you have something better.
Really just my take in a really rushed break.

On 05.06.20 13:07, Koen Zandberg wrote:
> Hello
> 
> On 03-06-2020 20:18, Stefan Schmidt wrote:
>> Hello.
>>
>> Happy to see that we finally have the critical mass to get this moved
>> forward. :-)
>>
>> Here is my take on what I think needs to be done.
>>
>> On a first review I found nothing wrong with the design. It needs
>> further extending and flexibility in my opinion, though.
> I would suggest using USB bulk endpoints for both the tx and rx paths.
> An interrupt IN endpoint might be useful for events from the radio back
> to the host such as ack information from a transmit. This way we can
> keep the control messages to configuration only. This is similar to how
> USB ethernet devices are using different USB endpoints. I also see
> issues with transferring large 802.15.4g frames over control endpoints.
> Something similar like CDC-ECM would be my preference here: Split the
> frame in multiple bulk transfers and detect the end of the frame by a
> transfer size not equal to the endpoint size.

For the above I completely ignore the move to bulk. This still needs doing.

>> o Add a GET_EXTENDED_ADDR command to receive the extended address
>> provided by the transceiver itself, or firmware in some way.
> +1

My take on this is in the above branch.

>> o Adding a GET_CAPABILITIES command to query device capabilities
>>   during init to enable and set needed ieee802154_ops based on the
>> device. Given that we aim to support as many transceivers as possible
>> we can't rely on static device knowledge to configure wpanusb correctly.

I started to work on this. The real questions is are we passing all the 
frequency bands and others settings through the USB spec or are we going 
with tables for these inside the firmware and driver and only reference 
them? The later is more efficient the first one is more flexible and 
likely more extensible for future changes.


> Does it make sense to include also a "protocol" version here, to allow
> extending the feature set of the driver later without causing
> compatibility issues between the firmware and the kernel?

How about we are using the USB version part of the descriptor for this? 
We would identify a newer version device not only the spec. The device 
handling could work on both.

>>
>> o Add opcode for set_lbt in USB spec

Added a first take on this.

> This requires some clarification for me how the radio should be
> configured. Is this just a CSMA/CCA switch?
>>
>> o Add opcode for set_frame_retries USB spec. (If a transceiver does
>> not support AutoACK in hardware do Zephyr and RIOT support a software
>> fallback to handle AutoACK?)

Added a first take on this. Needs USB helper functions to handle the 
config data being passed to the device.

> This can be implemented in RIOT. I don't think there is something in
> place at the moment, most of our radios support this in hardware, but I
> see no technical reason why not to support this.
>>
>> o How are we going to handle transceiver which allow MTUs > 127? Not a
>> high priority as the kernel part does not support this either right now.
> There is some preliminary support for 802.15.4g radios in RIOT. I know
> some developers that would prefer not to have to have the MTU limited to
> 127 bytes :)

This is completely ignored for now.

>> o Do Zephyr or RIOT expose additional functionality we should support
>> here?
>>
>> o Koen, you offered to look into implementing the firmware support for
>> the USB spec in RIOT. Does the spec fit what RIOT has as abstraction
>> for ieee802154?
> 
> Yes, implementing configuration settings as USB control messages makes
> glueing them to the radio abstraction layer very easy. For now RIOT has
> configuration for:
> 
>   - reading and writing channel/page settings
>   - read/write to addresses, both long and short
>   - PAN ID
>   - TX power settings
>   - reading the max PSDU size
>   - Ack config settings
>   - CCA and CSMA configuration, enabling/disabling, retries and backoff
> exponent (max/min)
>   - CCA threshold and mode
> 
> Furthermore, it is possible to get frame metadata such as the received
> signal strength and the number of retries required for the frame
> transmit. All these settings depend a bit on the radio hardware features
> of course, but thats what we have the GET_CAPABILITIES for.

If I have time to do more work on this I will update you folks. As I 
wrote above. Read over it and feel free to use any of the above or 
implement it yourself.

Looking forward to the progress on this when back from my vacation. :-)

regards
Stefan Schmidt

Re: wpanusb?

[Stefan Schmidt]

Hello.

On 24.07.20 15:41, Stefan Schmidt wrote:
> Hello.
> 
> [Added Erik here to be part of the discussion]
> 
> This mostly goes to Koen and Erik. Please coordinate how you are wanting 
> to work on this. And be pro-active. Waiting for the other one to start 
> will just lead to starving :-)

With silence from both of you on this I would assume neither had time to 
look over this. Correct?

> I started to hack together some parts as I would do them. Really not 
> working at all right now and only compile tested. I will give more 
> details below. I am not sure if I will find time to work more on this 
> next week before I go on vacation, so here is what I have:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next.git/log/?h=wpanusb-original 

If nobody else has time I will start looking into this again over the 
next weeks.

regards
Stefan Schmidt

Re: wpanusb?

[Christopher Friedt]

On Sat, Sep 26, 2020 at 8:28 AM Stefan Schmidt
<stefan@datenfreihafen.org> wrote:
> On 24.07.20 15:41, Stefan Schmidt wrote:
> > [Added Erik here to be part of the discussion]
> >
> > This mostly goes to Koen and Erik. Please coordinate how you are wanting
> > to work on this. And be pro-active. Waiting for the other one to start
> > will just lead to starving :-)
>
> With silence from both of you on this I would assume neither had time to
> look over this. Correct?

On the contrary, Erik & I are working on it right now (although mostly
from the Zephyr side) ;-)

We expect to have something demonstrable with the cc1352r within a
week or 2, at which point I would very much like to work on
upstreaming wpanusb with the additional features.

In Zephyr, I recently got Sub GHz IEEE 802.15.4g running on the
cc1352r1_launchxl. Did a fairly big overhaul of the 2.4 GHz driver as
well. SubG should be able to run simultaneously to 2.4 GHz, and beyond
that, the driver is written so that BLE will work concurrently at 2.4
GHz (with arbitration).

I might need to send you one more dev board though for testing
purposes, because the cc1352r requires a second chip for USB.
BeagleBoard.org is currently preparing for manufacturing of the
BeagleConnect which includes the cc1352 and the USB chip The official
release date is not announced yet.

I have not touched MLME yet unfortunately due to contractual obligations.

Also, somewhat annoying, but a shoddy USB hub damaged my ATUSB :( I
ordered 2 more, so hopefully they get to me shortly!

C

Re: wpanusb?

[Stefan Schmidt]

Hello.

On 26.09.20 14:47, Christopher Friedt wrote:
> On Sat, Sep 26, 2020 at 8:28 AM Stefan Schmidt
> <stefan@datenfreihafen.org> wrote:
>> On 24.07.20 15:41, Stefan Schmidt wrote:
>>> [Added Erik here to be part of the discussion]
>>>
>>> This mostly goes to Koen and Erik. Please coordinate how you are wanting
>>> to work on this. And be pro-active. Waiting for the other one to start
>>> will just lead to starving :-)
>>
>> With silence from both of you on this I would assume neither had time to
>> look over this. Correct?
> 
> On the contrary, Erik & I are working on it right now (although mostly
> from the Zephyr side) ;-)
> 
> We expect to have something demonstrable with the cc1352r within a
> week or 2, at which point I would very much like to work on
> upstreaming wpanusb with the additional features.

Perfect, glad to hear! If I am going to touch the wpanusb driver in my 
branch I will let you know.

> 
> In Zephyr, I recently got Sub GHz IEEE 802.15.4g running on the
> cc1352r1_launchxl. Did a fairly big overhaul of the 2.4 GHz driver as
> well. SubG should be able to run simultaneously to 2.4 GHz, and beyond
> that, the driver is written so that BLE will work concurrently at 2.4
> GHz (with arbitration).

Oh, so we need to think about having 2.4 and SubG phy's exposed in one 
wpanusb driver instance.

> I might need to send you one more dev board though for testing
> purposes, because the cc1352r requires a second chip for USB.
> BeagleBoard.org is currently preparing for manufacturing of the
> BeagleConnect which includes the cc1352 and the USB chip The official
> release date is not announced yet.

OK, fair enough.

> Also, somewhat annoying, but a shoddy USB hub damaged my ATUSB :( I
> ordered 2 more, so hopefully they get to me shortly!

Sorry to hear. :(

regards
Stefan Schmidt

Re: wpanusb?

[Christopher Friedt]

On Sun, Sep 27, 2020 at 4:59 AM Stefan Schmidt
<stefan@datenfreihafen.org> wrote:
> > Also, somewhat annoying, but a shoddy USB hub damaged my ATUSB :( I
> > ordered 2 more, so hopefully they get to me shortly!

I received my 2 ATUSB :-)

Here is a question though - the cc1352r supports 802.15.4g (GFSK /
2-FSK / 4-FSK / OQPSK) and does not support BPSK for 868 MHz or 915
Mhz.

Erik confirmed today that our wpanusb solution is working today both
at 2.4 GHz and SubGHz, but we are using channels 0-11 for SubGHz. I
think those are reserved for the BPSK phy though.

Do we have pages / channels that cover the 802.15.4g PHYs in the wpan
stack? Are there any suggestions for which page / channels to use? We
have been looking through the spec, but of course it's quite dense
nowadays.

Also, since these radios can theoretically work simultaneously, we are
considering exposing that as two separate and simultaneous PHYs and
data paths. Is that something that would be desirable in wpanusb?

Cheers,

C

Re: wpanusb?

[Stefan Schmidt]

Hello.

Sorry for the delay. I tagged the mail but still forgot about it. :(

On 15.10.20 22:16, Christopher Friedt wrote:
> On Sun, Sep 27, 2020 at 4:59 AM Stefan Schmidt
> <stefan@datenfreihafen.org> wrote:
>>> Also, somewhat annoying, but a shoddy USB hub damaged my ATUSB :( I
>>> ordered 2 more, so hopefully they get to me shortly!
> 
> I received my 2 ATUSB :-)
> 

Yay :-)

> Here is a question though - the cc1352r supports 802.15.4g (GFSK /
> 2-FSK / 4-FSK / OQPSK) and does not support BPSK for 868 MHz or 915
> Mhz.
> 
> Erik confirmed today that our wpanusb solution is working today both
> at 2.4 GHz and SubGHz, but we are using channels 0-11 for SubGHz. I
> think those are reserved for the BPSK phy though.
> 
> Do we have pages / channels that cover the 802.15.4g PHYs in the wpan
> stack? Are there any suggestions for which page / channels to use? We
> have been looking through the spec, but of course it's quite dense
> nowadays.

Hmm, I would need to check the spec as well. ieee802154 and mac802154 
should not really limit the used pages or channels. We have no regulator 
daemon or such in place (me might should though). IIRC we simply let the 
driver define its channel table.

> Also, since these radios can theoretically work simultaneously, we are
> considering exposing that as two separate and simultaneous PHYs and
> data paths. Is that something that would be desirable in wpanusb?

Yes, if these could work simultaneously we should allow to expose both 
phy's. Exposing two USB devices from the firmware and let the kernel 
have two wpanusb instances using them would what I first off.

regards
Stefan Schmidt