From: Helmut Tschemernjak <helmut@helios.de>
To: "Stefan Schmidt" <stefan@datenfreihafen.org>,
"Andreas Färber" <afaerber@suse.de>,
netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
"Jian-Hong Pan" <starnight@g.ncu.edu.tw>,
"Jiri Pirko" <jiri@resnulli.us>,
"Marcel Holtmann" <marcel@holtmann.org>,
"David S . Miller" <davem@davemloft.net>,
"Matthias Brugger" <mbrugger@suse.com>,
"Janus Piwek" <jpiwek@arroweurope.com>,
"Michael Röder" <michael.roeder@avnet.eu>,
"Dollar Chen" <dollar.chen@wtmec.com>,
"Ken Yu" <ken.yu@rakwireless.com>,
"Konstantin Böhm" <konstantin.boehm@ancud.de>,
"Jan Jongboom" <jan.jongboom@arm.com>,
"Jon Ortego" <Jon.Ortego@imst.de>,
contact@snootlab.com, "Ben Whitten" <ben.whitten@lairdtech.com>,
"Brian Ray" <brian.ray@link-labs.com>,
lora@globalsat.com.tw, lora@radioshuttle.de,
"Alexander Graf" <agraf@suse.de>,
"Michal Kubeček" <mkubecek@suse.cz>,
"Rob Herring" <robh@kernel.org>,
devicetree@vger.kernel.org, "Steve deRosier" <derosier@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
linux-spi@vger.kernel.org
Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa
Date: Thu, 5 Jul 2018 12:43:36 +0200 [thread overview]
Message-ID: <5aac9ea5-484c-1b3b-8058-50e11e8d7a9a@helios.de> (raw)
In-Reply-To: <487df785-ddf5-ed81-a253-6afb7f2de811@datenfreihafen.org>
Dear Andreas,
I put the kernel support for the SX1276 LoRa chip in question. I don’t
think that this kind of device should be in the Linux kernel.
Here are a few facts to consider:
- A LoRa transaction is very slow (e.g. SF7 needs about 210 ms, for
SF12 6280 ms) for 12 bytes user data with acknowledge.
- There are many different implementations for the antenna switch,
switching between receiving/sending, PA-BOOST, 433, 868/915 MHz. (I know
SX1276 Heltec ESP32, SX1276 Murata, RFM95-(1276), SX1276 Heltec
STM32-L4) they are all different regarding this.
- The LoRa chip device ID is only 8-bit which is not sufficient for
larger networks, e.g. our RadioShuttle protocol uses compressed 32-bit
device IDs.
- The chip can do MTU sizes up to 2048 bytes, most protocols use less
than 250 bytes.
- Applications do on-the-fly channel and spreading factor switching
which makes it more difficult for the configuration.
- The chip supports Lora modulation as well as FSK, GFSK, MSK, GMSK,
and OOK modulation, for some use cases the other modulations are of
interest, e.g. to communicated with other devices.
- Power saving modes, like sleep, suspend may be required for battery
operation.
- Cad detection is very flexible and can be differently used.
- LoRa preamble may be different depending on the protocol used.
- The new Lora chip SX1262 / 68 (successor of the SX1276) has different
hardware and all different registers, it is driver incompatible with the
SX1276. It needs an entire new driver.
- The device is not multi-process capable (only a single process can
communicate with it).
- There are SX1276 LoRa modules with a build-in protocol (LoRaWAN and
RAW) via a serial connection only, again complete different API compared
the SX1276 chip. Software updates for this devices are difficult.
- I am even convinced that the LoRaWAN protocol with the concentrator
concept is not good, the peer to peer communication and a standard MQTT
gateway (what we do) is way more flexible.
For all this reasons, I feel a user level driver task implementation is
way more flexible. I did a lot of work/enhancements on the SX1276 link
level driver from Semtech, it is available and maintained on mbed.org
and supports mbed-os, Arduino and is prepared for Linux.
https://os.mbed.com/users/Helmut64/code/SX1276GenericLib/
Protocols e.g. our RadioShuttle LoRa peer to peer protocol or the
LoRaWAN protocol can run on top of the SX1276GenericLib. We may should
focus on such a driver library getting supported for multiple OS's (Win,
Linux, mbed, Ardino, etc.)
Again I feel a Linux kernel device driver for the SX1276 chip make
little sense for me.
Regards
Helmut Tschemernjak (www.radioshuttle.de, www.helios.de)
WARNING: multiple messages have this Message-ID (diff)
From: Helmut Tschemernjak <helmut@helios.de>
To: "Stefan Schmidt" <stefan@datenfreihafen.org>,
"Andreas Färber" <afaerber@suse.de>,
netdev@vger.kernel.org
Cc: "Michal Kubeček" <mkubecek@suse.cz>,
"Konstantin Böhm" <konstantin.boehm@ancud.de>,
contact@snootlab.com, "Ken Yu" <ken.yu@rakwireless.com>,
"Michael Röder" <michael.roeder@avnet.eu>,
"Rob Herring" <robh@kernel.org>,
lora@globalsat.com.tw, "Alexander Graf" <agraf@suse.de>,
"Jan Jongboom" <jan.jongboom@arm.com>,
"Janus Piwek" <jpiwek@arroweurope.com>,
"Jon Ortego" <Jon.Ortego@imst.de>,
"Jian-Hong Pan" <starnight@g.ncu.edu.tw>,
devicetree@vger.kernel.org, "Jiri Pirko" <jiri@resnulli.us>,
"Marcel Holtmann" <marcel@holtmann.org>,
"Mark Brown" <broonie@kernel.org>,
"Dollar Chen" <dollar.chen@wtmec.com>,
"Brian Ray" <brian.ray@link-labs.com>,
linux-arm-kernel@lists.infradead.org, lora@radioshuttle.de,
"Matthias Brugger" <mbrugger@suse.com>,
"Ben Whitten" <ben.whitten@lairdtech.com>,
linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org
Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa
Date: Thu, 5 Jul 2018 12:43:36 +0200 [thread overview]
Message-ID: <5aac9ea5-484c-1b3b-8058-50e11e8d7a9a@helios.de> (raw)
In-Reply-To: <487df785-ddf5-ed81-a253-6afb7f2de811@datenfreihafen.org>
Dear Andreas,
I put the kernel support for the SX1276 LoRa chip in question. I don’t
think that this kind of device should be in the Linux kernel.
Here are a few facts to consider:
- A LoRa transaction is very slow (e.g. SF7 needs about 210 ms, for
SF12 6280 ms) for 12 bytes user data with acknowledge.
- There are many different implementations for the antenna switch,
switching between receiving/sending, PA-BOOST, 433, 868/915 MHz. (I know
SX1276 Heltec ESP32, SX1276 Murata, RFM95-(1276), SX1276 Heltec
STM32-L4) they are all different regarding this.
- The LoRa chip device ID is only 8-bit which is not sufficient for
larger networks, e.g. our RadioShuttle protocol uses compressed 32-bit
device IDs.
- The chip can do MTU sizes up to 2048 bytes, most protocols use less
than 250 bytes.
- Applications do on-the-fly channel and spreading factor switching
which makes it more difficult for the configuration.
- The chip supports Lora modulation as well as FSK, GFSK, MSK, GMSK,
and OOK modulation, for some use cases the other modulations are of
interest, e.g. to communicated with other devices.
- Power saving modes, like sleep, suspend may be required for battery
operation.
- Cad detection is very flexible and can be differently used.
- LoRa preamble may be different depending on the protocol used.
- The new Lora chip SX1262 / 68 (successor of the SX1276) has different
hardware and all different registers, it is driver incompatible with the
SX1276. It needs an entire new driver.
- The device is not multi-process capable (only a single process can
communicate with it).
- There are SX1276 LoRa modules with a build-in protocol (LoRaWAN and
RAW) via a serial connection only, again complete different API compared
the SX1276 chip. Software updates for this devices are difficult.
- I am even convinced that the LoRaWAN protocol with the concentrator
concept is not good, the peer to peer communication and a standard MQTT
gateway (what we do) is way more flexible.
For all this reasons, I feel a user level driver task implementation is
way more flexible. I did a lot of work/enhancements on the SX1276 link
level driver from Semtech, it is available and maintained on mbed.org
and supports mbed-os, Arduino and is prepared for Linux.
https://os.mbed.com/users/Helmut64/code/SX1276GenericLib/
Protocols e.g. our RadioShuttle LoRa peer to peer protocol or the
LoRaWAN protocol can run on top of the SX1276GenericLib. We may should
focus on such a driver library getting supported for multiple OS's (Win,
Linux, mbed, Ardino, etc.)
Again I feel a Linux kernel device driver for the SX1276 chip make
little sense for me.
Regards
Helmut Tschemernjak (www.radioshuttle.de, www.helios.de)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: helmut@helios.de (Helmut Tschemernjak)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC net-next 00/15] net: A socket API for LoRa
Date: Thu, 5 Jul 2018 12:43:36 +0200 [thread overview]
Message-ID: <5aac9ea5-484c-1b3b-8058-50e11e8d7a9a@helios.de> (raw)
In-Reply-To: <487df785-ddf5-ed81-a253-6afb7f2de811@datenfreihafen.org>
Dear Andreas,
I put the kernel support for the SX1276 LoRa chip in question. I don?t
think that this kind of device should be in the Linux kernel.
Here are a few facts to consider:
- A LoRa transaction is very slow? (e.g. SF7 needs about 210 ms, for
SF12 6280 ms) for 12 bytes user data with acknowledge.
- There are many different implementations for the antenna switch,
switching between receiving/sending, PA-BOOST, 433, 868/915 MHz. (I know
SX1276 Heltec ESP32, SX1276 Murata, RFM95-(1276), SX1276 Heltec
STM32-L4) they are all different regarding this.
- The LoRa chip device ID is only 8-bit which is not sufficient for
larger networks, e.g. our RadioShuttle protocol uses compressed 32-bit
device IDs.
- The chip can do MTU sizes up to 2048 bytes, most protocols use less
than 250 bytes.
- Applications do on-the-fly channel and spreading factor switching
which makes it more difficult for the configuration.
- The chip supports Lora modulation as well as? FSK, GFSK, MSK, GMSK,
and OOK modulation, for some use cases the other modulations are of
interest, e.g. to communicated with other devices.
- Power saving modes, like sleep, suspend may be required for battery
operation.
- Cad detection is very flexible and can be differently used.
- LoRa preamble may be different depending on the protocol used.
- The new Lora chip SX1262 / 68 (successor of the SX1276) has different
hardware and all different registers, it is driver incompatible with the
SX1276. It needs an entire new driver.
- The device is not multi-process capable (only a single process can
communicate with it).
- There are SX1276 LoRa modules with a build-in protocol (LoRaWAN and
RAW) via a serial connection only, again complete different API compared
the SX1276 chip. Software updates for this devices are difficult.
- I am even convinced that the LoRaWAN protocol with the concentrator
concept is not good, the peer to peer communication and a standard MQTT
gateway (what we do) is way more flexible.
For all this reasons, I feel a user level driver task implementation is
way more flexible. I did a lot of work/enhancements on the SX1276 link
level driver from Semtech, it is available and maintained on mbed.org
and supports mbed-os, Arduino and is prepared for Linux.
https://os.mbed.com/users/Helmut64/code/SX1276GenericLib/
Protocols e.g. our RadioShuttle LoRa peer to peer protocol or the
LoRaWAN protocol can run on top of the SX1276GenericLib. We may should
focus on such a driver library getting supported for multiple OS's (Win,
Linux, mbed, Ardino, etc.)
Again I feel a Linux kernel device driver for the SX1276 chip make
little sense for me.
Regards
Helmut Tschemernjak (www.radioshuttle.de, www.helios.de)
next prev parent reply other threads:[~2018-07-05 10:52 UTC|newest]
Thread overview: 173+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-01 11:07 [RFC net-next 00/15] net: A socket API for LoRa Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 01/15] net: Reserve protocol numbers " Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 02/15] net: lora: Define sockaddr_lora Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 03/15] net: lora: Add protocol numbers Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 04/15] net: Add lora subsystem Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 05/15] HACK: net: lora: Deal with .poll_mask in 4.18-rc2 Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-02 16:22 ` Jiri Pirko
2018-07-02 16:22 ` Jiri Pirko
2018-07-02 16:59 ` Andreas Färber
2018-07-02 16:59 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 06/15] net: lora: Prepare for device drivers Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 07/15] net: lora: Add Semtech SX1276 Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 12:02 ` Andreas Färber
2018-07-01 12:02 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 08/15] net: lora: sx1276: Add debugfs Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-02 16:26 ` Jiri Pirko
2018-07-02 16:26 ` Jiri Pirko
2018-07-02 17:57 ` Andreas Färber
2018-07-02 17:57 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 09/15] net: lora: Prepare EUI helpers Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 10/15] net: lora: Add Microchip RN2483 Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:08 ` [RFC net-next 11/15] net: lora: Add IMST WiMOD Andreas Färber
2018-07-01 11:08 ` Andreas Färber
2019-01-06 14:57 ` Heinrich Schuchardt
2019-01-06 14:57 ` Heinrich Schuchardt
2019-01-07 11:29 ` Andreas Färber
2019-01-07 11:29 ` Andreas Färber
2018-07-01 11:08 ` [RFC net-next 12/15] net: lora: Add USI WM-SG-SM-42 Andreas Färber
2018-07-01 11:08 ` Andreas Färber
2018-07-01 11:08 ` [RFC net-next 13/15] net: lora: Prepare RAK RAK811 Andreas Färber
2018-07-01 11:08 ` Andreas Färber
2018-07-01 11:08 ` [RFC net-next 14/15] net: lora: Prepare Semtech SX1257 Andreas Färber
2018-07-01 11:08 ` Andreas Färber
2018-07-01 11:08 ` [RFC net-next 15/15] net: lora: Add Semtech SX1301 Andreas Färber
2018-07-01 11:08 ` Andreas Färber
2018-07-02 11:51 ` Ben Whitten
2018-07-02 11:51 ` Ben Whitten
2018-07-03 3:01 ` Andreas Färber
2018-07-03 3:01 ` Andreas Färber
2018-07-05 8:59 ` Ben Whitten
2018-07-05 8:59 ` Ben Whitten
2018-07-05 8:59 ` Ben Whitten
2018-07-02 16:12 ` Mark Brown
2018-07-02 16:12 ` Mark Brown
2018-07-02 16:12 ` Mark Brown
2018-07-02 17:34 ` Andreas Färber
2018-07-02 17:34 ` Andreas Färber
2018-07-02 20:43 ` Ben Whitten
2018-07-02 20:43 ` Ben Whitten
2018-07-03 3:21 ` Andreas Färber
2018-07-03 3:21 ` Andreas Färber
2018-07-03 3:21 ` Andreas Färber
2018-07-05 8:43 ` Ben Whitten
2018-07-05 8:43 ` Ben Whitten
2018-07-05 8:43 ` Ben Whitten
2018-07-03 14:50 ` Mark Brown
2018-07-03 14:50 ` Mark Brown
2018-07-03 15:09 ` Andreas Färber
2018-07-03 15:09 ` Andreas Färber
2018-07-03 15:09 ` Andreas Färber
2018-07-03 15:31 ` Mark Brown
2018-07-03 15:31 ` Mark Brown
2018-07-03 15:31 ` Mark Brown
2018-07-03 16:40 ` Andreas Färber
2018-07-03 16:40 ` Andreas Färber
2018-07-04 11:43 ` Mark Brown
2018-07-04 11:43 ` Mark Brown
2018-07-04 13:41 ` Ben Whitten
2018-07-04 13:41 ` Ben Whitten
2018-07-04 13:41 ` Ben Whitten
2018-07-04 14:32 ` Mark Brown
2018-07-04 14:32 ` Mark Brown
2018-07-04 14:32 ` Mark Brown
2018-07-03 15:11 ` [RFC net-next 00/15] net: A socket API for LoRa Jian-Hong Pan
2018-07-03 15:11 ` Jian-Hong Pan
2018-07-03 15:11 ` Jian-Hong Pan
2018-08-05 0:11 ` Andreas Färber
2018-08-05 0:11 ` Andreas Färber
2018-08-05 0:11 ` Andreas Färber
2018-08-08 20:36 ` Alan Cox
2018-08-08 20:36 ` Alan Cox
2018-08-08 20:36 ` Alan Cox
2018-08-08 22:42 ` Andreas Färber
2018-08-08 22:42 ` Andreas Färber
2018-08-08 22:42 ` Andreas Färber
2018-08-09 11:59 ` Alan Cox
2018-08-09 11:59 ` Alan Cox
2018-08-09 11:59 ` Alan Cox
2018-08-09 15:02 ` Jian-Hong Pan
2018-08-09 15:02 ` Jian-Hong Pan
2018-08-09 15:02 ` Jian-Hong Pan
2018-08-09 15:21 ` Alexander Aring
2018-08-09 15:21 ` Alexander Aring
2018-08-09 15:21 ` Alexander Aring
2018-08-10 15:57 ` Alan Cox
2018-08-10 15:57 ` Alan Cox
2018-08-10 15:57 ` Alan Cox
2018-08-11 18:30 ` Stefan Schmidt
2018-08-11 18:30 ` Stefan Schmidt
2018-08-11 18:30 ` Stefan Schmidt
2018-08-12 16:49 ` Andreas Färber
2018-08-12 16:49 ` Andreas Färber
2018-08-12 16:49 ` Andreas Färber
2018-08-12 16:37 ` Jian-Hong Pan
2018-08-12 16:37 ` Jian-Hong Pan
2018-08-12 16:37 ` Jian-Hong Pan
2018-08-12 17:59 ` Andreas Färber
2018-08-12 17:59 ` Andreas Färber
2018-08-12 17:59 ` Andreas Färber
2018-08-13 12:36 ` Alan Cox
2018-08-13 12:36 ` Alan Cox
2018-08-13 12:36 ` Alan Cox
2018-08-09 15:12 ` Alexander Aring
2018-08-09 15:12 ` Alexander Aring
2018-08-09 15:12 ` Alexander Aring
2018-08-09 15:12 ` Alexander Aring
2018-08-09 0:50 ` Andreas Färber
2018-08-09 0:50 ` Andreas Färber
2018-08-09 0:50 ` Andreas Färber
2018-07-04 18:26 ` Stefan Schmidt
2018-07-04 18:26 ` Stefan Schmidt
2018-07-04 18:26 ` Stefan Schmidt
2018-07-05 10:43 ` Helmut Tschemernjak [this message]
2018-07-05 10:43 ` Helmut Tschemernjak
2018-07-05 10:43 ` Helmut Tschemernjak
2018-07-11 2:07 ` Andreas Färber
2018-07-11 2:07 ` Andreas Färber
2018-07-11 2:07 ` Andreas Färber
2018-07-11 11:45 ` Helmut Tschemernjak
2018-07-11 11:45 ` Helmut Tschemernjak
2018-07-11 11:45 ` Helmut Tschemernjak
2018-07-11 15:21 ` Ben Whitten
2018-07-11 15:21 ` Ben Whitten
2018-07-11 15:21 ` Ben Whitten
2018-07-15 18:13 ` Andreas Färber
2018-07-15 18:13 ` Andreas Färber
2018-07-15 18:13 ` Andreas Färber
2018-07-18 11:28 ` Ben Whitten
2018-07-18 11:28 ` Ben Whitten
2018-07-18 11:28 ` Ben Whitten
2018-07-18 11:28 ` Ben Whitten
2018-08-02 7:52 ` Jian-Hong Pan
2018-08-02 7:52 ` Jian-Hong Pan
2018-08-02 7:52 ` Jian-Hong Pan
2018-08-02 7:52 ` Jian-Hong Pan
2018-08-03 8:44 ` linux-lora.git and LoRaWAN (was: [RFC net-next 00/15] net: A socket API for LoRa) Andreas Färber
2018-08-03 8:44 ` Andreas Färber
2018-08-05 12:49 ` Jian-Hong Pan
2018-08-05 12:49 ` Jian-Hong Pan
2018-08-05 12:49 ` Jian-Hong Pan
2018-08-05 12:49 ` Jian-Hong Pan
[not found] ` <20180803150258.791b9942@alans-desktop>
2018-08-05 14:08 ` Jian-Hong Pan
2018-08-05 14:08 ` Jian-Hong Pan
2018-08-05 13:49 ` [RFC net-next 00/15] net: A socket API for LoRa Andreas Färber
2018-08-05 13:49 ` Andreas Färber
2018-08-05 13:49 ` Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5aac9ea5-484c-1b3b-8058-50e11e8d7a9a@helios.de \
--to=helmut@helios.de \
--cc=Jon.Ortego@imst.de \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=ben.whitten@lairdtech.com \
--cc=brian.ray@link-labs.com \
--cc=broonie@kernel.org \
--cc=contact@snootlab.com \
--cc=davem@davemloft.net \
--cc=derosier@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dollar.chen@wtmec.com \
--cc=jan.jongboom@arm.com \
--cc=jiri@resnulli.us \
--cc=jpiwek@arroweurope.com \
--cc=ken.yu@rakwireless.com \
--cc=konstantin.boehm@ancud.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=lora@globalsat.com.tw \
--cc=lora@radioshuttle.de \
--cc=marcel@holtmann.org \
--cc=mbrugger@suse.com \
--cc=michael.roeder@avnet.eu \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=robh@kernel.org \
--cc=starnight@g.ncu.edu.tw \
--cc=stefan@datenfreihafen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.