-
Notifications
You must be signed in to change notification settings - Fork 744
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Added support for SX1301AP2 reference design (with FPGA and additional SX1272). When a FPGA is detected at startup, the HAL automatically adapt SPI communication requests (using SPI header or not). * Added util_spectral_scan diagnostic tool to scan the spectral band in background, where the LoRa gateway operates. (can only be used with SX1301AP2 or similar design). By default it uses the same SPI device as the one used by the HAL, but it can be changed depending on the hardware architecture on which it is used. * Removed SPI FTDI support due to lack of performances to properly handle heavy packet traffic. Only native SPI suage is recommended. * HAL: added a check that SX1301 firmwares have been properly loaded at startup.
- Loading branch information
Showing
26 changed files
with
1,934 additions
and
813 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1 @@ | ||
3.1.0 | ||
3.2.0 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
a48215d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean that Semtech SX1301 Reference Board (usb-connected) can no longer be used with lora_gateway library?
a48215d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, or at least, we don't support it anymore because it was unreliable in term of performances.
We generally use a raspberry pi as host (but any other similar host can do), connected with the reference board through their native SPI connectors.
a48215d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. Is more information available on in what way it is unreliable? We have seen a few cases were packets get lost or are never transmitted. However our packet load is not particularly heavy, there is 5 seconds or more between packets.
a48215d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the transfer rate between the SX1301 board and the host is too slow, the SX1301 FIFO can get full, and from there packet loss happens. If a gateway receives packets from many nodes, the traffic may be too heavy.
Also we are planning to perform some scheduling of downlink transfers, handled by the host, and this need a low latency connection between the host and the SX1301 board which cannot be expected through a USB connexion.
a48215d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a48215d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:) I don't have a number. But it could be a problem if you have lots of them emitting very frequently (corner case).
But the main (and concrete) issue with USB/FTDI is the latency issue. As I said before, if we want to optimize downlink programming, we need to have a low latency (order of 10ms) between host and sx1301. Which is not verified at all when using FTDI.