[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f1967750-0a42-0e76-2d7d-da293bc351af@suse.de>
Date: Thu, 9 Aug 2018 02:50:39 +0200
From: Andreas Färber <afaerber@...e.de>
To: Jian-Hong Pan <starnight@...cu.edu.tw>
Cc: netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, Jiri Pirko <jiri@...nulli.us>,
Marcel Holtmann <marcel@...tmann.org>,
"David S. Miller" <davem@...emloft.net>,
Matthias Brugger <mbrugger@...e.com>,
Janus Piwek <jpiwek@...oweurope.com>,
Michael Röder <michael.roeder@...et.eu>,
Dollar Chen <dollar.chen@...ec.com>,
Ken Yu <ken.yu@...wireless.com>,
Konstantin Böhm <konstantin.boehm@...ud.de>,
Jan Jongboom <jan.jongboom@....com>,
Jon Ortego <Jon.Ortego@...t.de>, contact@...otlab.com,
Ben Whitten <ben.whitten@...rdtech.com>,
Brian Ray <brian.ray@...k-labs.com>, lora@...balsat.com.tw,
Alexander Graf <agraf@...e.de>,
Michal Kubeček <mkubecek@...e.cz>,
Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org,
Steve deRosier <derosier@...il.com>,
Mark Brown <broonie@...nel.org>, linux-spi@...r.kernel.org,
Pieter Robyns <pieter.robyns@...sselt.be>,
Hasnain Virk <Hasnain.Virk@....com>,
Alan Cox <gnomes@...rguk.ukuu.org.uk>,
linux-wpan <linux-wpan@...r.kernel.org>,
Stefan Schmidt <stefan@...enfreihafen.org>,
Daniele Comel <dcomel@...ot.com>,
Xue Liu <liuxuenetmail@...il.com>,
Sebastian Heß <shess@...sware.de>
Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa
Am 05.08.2018 um 02:11 schrieb Andreas Färber:
> Am 03.07.2018 um 17:11 schrieb Jian-Hong Pan:
>> 2018-07-01 19:07 GMT+08:00 Andreas Färber <afaerber@...e.de>:
>>> 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?
[...]
> Independently of what LoRaWAN does, the
> user needs to be able to send on the physical layer from a selection of
> LoRa, GFSK, FSK, OOK, GMSK and MSK.
> Supposedly Wireless M-Bus and IEEE 802.15.4 can be implemented via those
> according to the SX1276 datasheet.
>
> This opens a can of worms...
>
> SX127x has a single channel, so I don't think there should be six
> network interfaces lora0, gfsk0, fsk0, ook0, gmsk0 and msk0 exposed to
> the user.
> Having a lora0 interface speak non-LoRa modulations may be confusing,
> but since the chip is sold as LoRa transceiver it might be acceptable.
>
> SX130x has 8+2 channels, with IF9 dedicated to GFSK/FSK. It appears to
> use one FIFO for receiving (up to 16 packets) and can only transmit one
> packet at a time. So I think this should be one lora0 interface, too.
>
> With a view to supporting non-LoRa RF chipsets such as Si4xxx (GFSK,
> FSK, OOK) or nRF905 and nRF24L01+ (both GFSK) at a later date, I don't
> think those modulations should be some netlink option on a PF_LORA
> interface but cleanly distinguished as ETH_P_GFSK or something.
> For example, the Chistera Pi HAT has both an RFM95W and an RFM22 module.
Answering myself here: MSK is a special case of FSK, and GMSK a special
case of GFSK. SX1276 allows to switch between LoRa and FSK/OOK modes,
and in FSK/OOK mode between FSK and OOK modulation types and for FSK
modulation allows to set Gaussian filter values. I assume (G)MSK is
selected indirectly through BitRate and Fdev settings or something.
So we would just need ETH_P_FSK and ETH_P_OOK plus some skb fields for
ETH_P_FSK.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Powered by blists - more mailing lists