Sub 1GHz band support and hardware

[omicronns]

Hello,

Does linux-wpan project support sub 1GHz bands? If so, is there any hardware compatible that I can use like ATUSB stick for 2.4GHz?

If not, is it planned to add such support?

Thanks!

[Stefan-Schmidt]

We driver support for at86rf212 and at86rf212b. In terms of an USB device featuring these I only know about a discontinued device. Busware HUL v1.1

https://busware.de/tiki-browse_image.php?galleryId=18&imageId=316

[davidahoward]

might it be straight forward to update to at86rf215? Thats in production and eval boards available. if new chip support, maybe silabs efr32bg family - already supported in zephyr so lots of reusable code there... https://docs.zephyrproject.org/2.7.0/boards/arm/efr32_radio/doc/index.html

[Stefan-Schmidt]

I have not checked the 215 chip so I can not comment on how close it is to the 212. If its close enough, adding support for it in the at86rf* driver in the kernel might not be to hard.

There is also the wpanusb kernel driver and zephyr sample application, to make use of zephyr supported boards. The concept is very nice, but the USB interface and driver in general needs more work. Nobody stepped up yet to do so. If you are interested, let me know.

[omicronns]

I guess this is more about dongle firmware compatibility rather than radio chip itself. I can imagine one could write USB compatible device on TI chip, that would work as dongle with Atmel chip. Please correct me if I'm wrong.

[Stefan-Schmidt]

Sure, the combinations are not limited here. The base idea is to have a generic USB device driver for 15.4 device (kind of like the host controller interface for bluetooth). Whatever firmware implements that would just work (TM).

On the firmware side the has been a proof of concept for zephyr, but its not limited to it.

[omicronns]

Thank you for the responses. I'm not linux driver expert, but I looked at atusb driver implementation and noticed it uses at86rf230 spi driver.

I understand that spi driver is present in the kernel and if I had (i don't) at86rf212 I could just plug it via spi to linux machine (eg. raspberry pi) configure the kernel and it would work?

Does that mean atusb driver just proxies spi commands for the transceiver? So if one designed atusb-like board with at86rf212 transceiver instead of at86rf231 and compatible antenna it would also work?

I know that at86rf212 is eol, but I just want to understand architecture here.

Thanks!

[Stefan-Schmidt]

Thank you for the responses. I'm not linux driver expert, but I looked at atusb driver implementation and noticed it uses at86rf230 spi driver.

They share some common code, but atusb is not using the SPI driver as-is.

I understand that spi driver is present in the kernel and if I had (i don't) at86rf212 I could just plug it via spi to linux machine (eg. raspberry pi) configure the kernel and it would work?

Yes.

Does that mean atusb driver just proxies spi commands for the transceiver?

No. We tried this design initially but it turned out to be to slow with the USB interrupts involved.

The current atusb driver does handle some of the SPI logic to transmit and read out a frame in firmware to speed this up. Register writes for configuration (not time critical) are done from the driver side.

So if one designed atusb-like board with at86rf212 transceiver instead of at86rf231 and compatible antenna it would also work?

You would need to design a board and write a atusb compatible firmware. That is exactly what happened for Busware HUL v1.1

[ekawahyu]

I am sorry if I am hijacking this ticket. Please do let me know if there is a better place to share what I am working on.

I am prototyping ATmega32U2 + AT86RF212, which is the closest I can get to port ben-wpan source code to get a working SubGHz ATUSB. Hardware-wise, I am keeping all of interfacing pins identical to ATUSB. The only difference would be: the SubGHz chip and ATmega32U2 has its own crystal oscillator.

Now, with ben-wpan's fork, I created a new HWTYPE: ATUSB_HW_TYPE_EKAUSB, but it does not seem to get recognized by the kernel, obviously. It shows AT86RF231 instead of AT86RF212, so no chance to get this dongle running on my PC (Ubuntu 20.04.5 LTS):

[ 5804.193808] usb 1-1: new full-speed USB device number 13 using xhci_hcd
[ 5804.343604] usb 1-1: New USB device found, idVendor=20b7, idProduct=1540, bcdDevice= 0.01
[ 5804.343620] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[ 5804.343627] usb 1-1: SerialNumber: 4630333438371511210f
[ 5804.346204] usb 1-1: ATUSB: AT86RF231 version 3
[ 5804.346404] usb 1-1: Firmware: major: 0, minor: 4, hardware type: UNKNOWN (5)
[ 5804.346712] usb 1-1: Firmware: build #108 Thu Jul 20 21:46:33 PDT 2023
[ 5804.346723] usb 1-1: failed to fetch extended address, random address set
[ 5804.346734] usb 1-1: atusb_probe: initialization failed, error = -524
[ 5804.346747] atusb: probe of 1-1:1.0 failed with error -524

Temporary hack by adopting ATUSB_HW_TYPE_110131, shows a promising result. It recognizes AT86RF212 attached to ATUSB:

[ 5956.581238] usb 1-1: USB disconnect, device number 13
[ 5995.252973] usb 1-1: new full-speed USB device number 14 using xhci_hcd
[ 5995.402725] usb 1-1: New USB device found, idVendor=20b7, idProduct=1540, bcdDevice= 0.01
[ 5995.402740] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[ 5995.402747] usb 1-1: SerialNumber: 4630333438371511210f
[ 5995.405221] usb 1-1: ATUSB: AT86RF212 version 3
[ 5995.405423] usb 1-1: Firmware: major: 0, minor: 4, hardware type: ATUSB (2)
[ 5995.405731] usb 1-1: Firmware: build #109 Thu Jul 20 21:50:48 PDT 2023
[ 5995.405963] usb 1-1: no permanent extended address found, random address set

I have two sets of Raspberry Pi + AT86RF212 SPI daughter board, and they can ping to each other flawlessly. I can even SSH from one to another, which is very cool! But I am not able to ping from my PC with this ATUSB + AT86RF212 just yet. If you guys can give me a pointer on what to look for and what I may have missed, that would be great. I really appreciate your help on this matter.

Once this dongle can send/receive packets, like getting ping to work and responding, I am gonna start documenting this work somewhere. This has been a great learning experience so far, and thank you for all of your effort to put this 6LoWPAN stack as part of Linux kernel.

More logs, if you care looking at it, the loaded kernel modules:

~$ lsmod
Module                  Size  Used by
nhc_udp                20480  0
nhc_routing            16384  0
nhc_mobility           16384  0
nhc_ipv6               16384  0
ieee802154_6lowpan     28672  0
nhc_fragment           16384  0
nhc_dest               16384  0
nhc_hop                16384  0
6lowpan                40960  8 nhc_fragment,nhc_dest,nhc_ipv6,nhc_hop,nhc_udp,nhc_mobility,nhc_routing,ieee802154_6lowpan
at86rf230              40960  0
atusb                  24576  0
mac802154             102400  2 at86rf230,atusb
ieee802154            110592  2 mac802154,ieee802154_6lowpan
rfcomm                 81920  4
cmac                   16384  3
algif_hash             16384  1
algif_skcipher         16384  1

iwpan list log, I am wondering about why it shows phy9 instead of phy0?

~$ iwpan list
wpan_phy phy9
supported channels:
    page 0: 0,1,2,3,4,5,6,7,8,9,10 
    page 2: 0,1,2,3,4,5,6,7,8,9,10 
current_page: 0
current_channel: 5,   914 MHz
cca_mode: (1) Energy above threshold
cca_ed_level: -86
tx_power: 5
capabilities:
    iftypes: node,monitor 
    channels:
        page 0: 
            [ 0] 868.3 MHz, [ 1]   906 MHz, [ 2]   908 MHz, 
            [ 3]   910 MHz, [ 4]   912 MHz, [ 5]   914 MHz, 
            [ 6]   916 MHz, [ 7]   918 MHz, [ 8]   920 MHz, 
            [ 9]   922 MHz, [10]   924 MHz  
        page 2: 
            [ 0] 868.3 MHz, [ 1]   906 MHz, [ 2]   908 MHz, 
            [ 3]   910 MHz, [ 4]   912 MHz, [ 5]   914 MHz, 
            [ 6]   916 MHz, [ 7]   918 MHz, [ 8]   920 MHz, 
            [ 9]   922 MHz, [10]   924 MHz  
    tx_powers: 
            5 dBm, 4 dBm, 3 dBm, 2 dBm, 1 dBm, 0 dBm, 
            -1 dBm, -2 dBm, -3 dBm, -4 dBm, -5 dBm, -6 dBm, 
            -7 dBm, -8 dBm, -9 dBm, -10 dBm, -11 dBm, -12 dBm, 
            -13 dBm, -14 dBm, -15 dBm, -16 dBm, -17 dBm, -18 dBm, 
            -19 dBm, -20 dBm, -21 dBm, -22 dBm, -23 dBm, -24 dBm, 
            -25 dBm, -26 dBm, 
    cca_ed_levels: 
            -100 dBm, -98 dBm, -96 dBm, -94 dBm, -92 dBm, -90 dBm, 
            -88 dBm, -86 dBm, -84 dBm, -82 dBm, -80 dBm, -78 dBm, 
            -76 dBm, -74 dBm, -72 dBm, -70 dBm, 
    cca_modes: 
        (1) Energy above threshold
        (2) Carrier sense only
        (3, cca_opt: 0) Carrier sense with energy above threshold (logical operator is 'and')
        (3, cca_opt: 1) Carrier sense with energy above threshold (logical operator is 'or')
    min_be: 0,1,2,3,4,5,6,7,8 
    max_be: 3,4,5,6,7,8 
    csma_backoffs: 0,1,2,3,4,5 
    frame_retries: 0,1,2,3,4,5,6,7 
    lbt: false,true

Please let me know if you need further info or more logs. Thank you.

[ekawahyu]

So, after rebuilding the kernel module, finally I made everything to work! ATmega32U2 + AT86RF212B can smoothly do ICMPv6 ping and socket communication seems to work perfectly as well.

@Stefan-Schmidt I spotted a bug that might affect HULUSB communication with the radio. It requires a patch for the radio interrupt IRQ_MASK to be set 0xFF. Otherwise, the kernel will never get notified of the sent messages, stalling. At least that's in my case.

I am new to Linux kernel development, I tried to send an email to linux-wpan@vger.kernel.org to show my progress, but it bounced back to me. Any help on how to submit a patch? Thank you.

[Stefan-Schmidt]

Sorry @ekawahyu that I missed your comments and questions here. I just saw them. No idea how I missed them initially.

First of all, this is really great progress you made here! I am happy to review and include your patches for the atusb driver as well as the firmware (also the hulusb fix). Could you give sending them to linux-wpan another try? If it still fails for you just send them to me directly (stefan@datenfreihafen.org).

Do you have any plans to sell your hardware? I get asked regularly about linux-wpan compatible SubGHz USB dongles. If you are putting them p for sale I would be happy to list them in our hardware page: https://linux-wpan.org/hardware

[ekawahyu]

Hi @Stefan-Schmidt, sorry, for some reason I also missed your response. Yes, I am planning to sell the hardware, will be released as open source hardware.

At the moment everything seems to work just fine with v0.4, ping is functional, but SSH does not seem to work unfortunately. I have ATUSB to use as comparison/reference and I can confirm that SSH is functional on ATUSB. I'll try to post some SSH verbose log here.

[Stefan-Schmidt]

Hi @Stefan-Schmidt, sorry, for some reason I also missed your response. Yes, I am planning to sell the hardware, will be released as open source hardware.

That is great to hear! Keep us posted when it is available. Happy to add a link for it to the linux-wpan.org doc pages.

At the moment everything seems to work just fine with v0.4, ping is functional, but SSH does not seem to work unfortunately. I have ATUSB to use as comparison/reference and I can confirm that SSH is functional on ATUSB. I'll try to post some SSH verbose log here.

Hmm, nothing really comes in mind why SSH might be problematic.