> Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa > > + linux-wireless + Stefan + Seth > > Am 11.07.2018 um 17:21 schrieb Ben Whitten: > >> This patchset is clearly not ready for merging, but is being > >> submitted for > >> discussion, as requested by Jiri, in particular of the design > >> choices: > >> > >> 1) PF_LORA/AF_LORA and associated identifiers are > >> proposed to represent > >> this technology. While for an SX1276 - case a) above - it > >> might work to > >> layer LoRaWAN as a protocol option for PF_LORA and > add > >> LoRaWAN address > >> fields to the union in my sockaddr_lora, how would that > >> work for devices > >> that only support LoRaWAN but not pure LoRa? Do we > >> need both AF_LORA and > >> AF_LORAWAN, or just a separate ETH_P_LORAWAN or > >> ARPHRD_LORAWAN? > >> > >> 2) PF_LORA is used with SOCK_DGRAM here. The > >> assumption is that RAW mode > >> would be DGRAM plus preamble plus optional > checksum. > >> > >> 3) Only the transmit path is partially implemented > already. > >> The assumption > >> is that the devices should go into receive mode by > default > >> and only > >> interrupt that when asked to transmit. > >> > >> 4) Some hardware settings need to be supplied > externally, > >> such as the radio > >> frequency for some modules, but many others can be > >> runtime-configured, > >> such as Spreading Factor, Bandwidth, Sync Word, or > which > >> antenna to use. > >> What settings should be implemented as socket option > vs. > >> netlink layer > >> vs. ioctl vs. sysfs? What are the criteria to apply? > >> > >> 5) Many of the modules support multiple modes, such as > >> LoRa, LoRaWAN and FSK. > >> Lacking a LoRaWAN implementation, I am currently > >> switching them into LoRa > >> mode at probe time wherever possible. How do we > deal > >> with that properly? > >> > >> a) Is there any precedence from the Wifi world for > >> dynamically selecting > >> between our own trusted Open Source > implementation > >> vs. hardware/firmware > >> accelerated and/or certified implementations? > >> > >> b) Would a proof of concept for FSK (non-LoRa) modes > be > >> required for > >> merging any LoRa driver for chipsets that support > both? > >> Or is there any > >> facility or design guidelines that would allow us to > focus > >> on LoRa and > >> LoRaWAN and leave non-LoRa radio modes to later > >> contributors? > > > > Down the line I think we should also plan for a CRDA style > regdb somewhere in the path for raw LoRa transceivers > operating as softMAC, much like with WiFi. > > Yes, I had raised the topic of wireless-regdb for Stefan's > conference - > currently it seems to only cover 2.4 GHz, 5 GHz and 60 GHz. > Not sure if > we can easily extend that to cover 433 MHz, 868 MHz, 915 > MHz and 923 MHz > bands or whether we'd just need something similar... Is > 802.15.4 able to > share this database with Wifi? Well the README in the wireless-regdb doesn't bind itself to 80211, there are references to the other ETSI EN specs so this would be the place rather than duplicating. There would need a bit of additional information to capture duty-cycle requirements, however the SRD spec states the maximum bandwidths can be 'The whole band', so with a flag set we could hijack this band information for duty-cycle. I am unsure if 802.15.4 uses this database, most of the naming seems geared towards 80211, nl80211, cfg80211 so perhaps we need our own versions of these with a common component, I hope the maintainers can give some guidance here. > An argument to share with Wifi might be that Semtech's > SX1280 and SX1281 > 2.4 GHz transceivers claim to support LoRa modulation, too. > Having two > different regulatory DBs interact with LoRa drivers seems a > bad idea, > and duplicating 2.4 GHz into a new DB doesn't sound > appealing either. Well I'm not sure if the modulation affects regulatory information, just bands, power, and techniques like DFS. As these chips are 2.4GHz only I expect they are bound by the existing regulatory information we would just need a path to access it. > https://www.semtech.com/products/wireless-rf/24-ghz- > transceivers > > Meanwhile my attempt to play with netlink during SUSE > Hackweek has been > going slow and I could use some guidance or a volunteer to > contribute: I > have a bare skeleton of registration, commands, attributes > and multicast > groups, but no plan yet how to connect that to the actual > drivers to > query or apply the settings... Happy to help, I will be starting from zero on netlink but I can contribute my existing work incorporating Marks comments for sx1301 etal. > https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/li > nux-lora.git/tree/net/lora/netlink.c?h=lora-next > > > LoRa radios used in Gateway devices are typically relatively > high power (capable of 27dBm) and operate in bands with > certain restrictions, eg the EU has keep out areas within > 868MHz for alarms and SRD devices must abide by certain > duty cycle restrictions, there are also maximum powers to > consider for sub-bands. (ETSI EN 300 220-2 V3.2.1, Bands K, > L, M, N, P, Q) > > > The certified AT style modules will (should) already have > this regulatory data baked in so it only applied to situations > where we drive the transceivers directly, but it wouldn't > hurt to check that the frequency being asked to transmit on > doesn't spill into a restricted band. > > Some do have configuration options that will need to be set > or checked. > > Regards, > Andreas > > -- > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg) ��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
