-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MKR1310 won't transmitt data transparently #24
Comments
There seems to be some confusion here. When the Sandeep Mistry library is used, the MKRWAN firmware from this repository has no role in operating the radio at all, rather it is made to stop so that the host processor running the Arduino sketch can directly operate the radio via SPI. So any issue would be in that repo, not this one. That said, it looks a bit like your "raw" packet is being treated as a LoRaWAN application payload, which should indeed be encrypted before transmission, given header and trailer, etc. That this is happening suggests that the code being run is probably not the code intended or that which would be appropriate to send raw packets with Sandeep Mistry's library. |
@gom-dot-sh did you modify the 1310 in order to try and use https://github.com/sandeepmistry/arduino-LoRa ? It is my understanding (which is quite disappointing to me) that the LoRa module SPI and serial lines are kind-of shorted together, so you can only talk UART to the module with its MCU, ie. can't talk directly to the radio transceiver chip (and the radio DIO pins are not used and not easily reachable). And if you talk with a SPI flash that's on the board, you have to make sure that the module MCU is not talking with the radio chip. |
If you want to operate the radio directly from your own code you should target the STML073 in the Murata module, not the SAMD21
It looks like I2C is the intended means of inter-processor communication
It looks like the STM32L073 in the Murata module, and not the SAMD21 owns that flash. Probably there to support LoRaWAN FUOTA or similar Anyway, your comments concern the hardware, they have nothing to do with this repository for the firmware, and very little if anything to do with the actual issue to which this page is devoted. |
Yeah, that's quite clear to me at this point, but somehow I was wondering how @gom-dot-sh seemed to have gotten LoRa.h kind-of working
Isn't this firmware using UART?
And yet the flash chip select is connected on SAMD21 only ?
A part of the comment concerns the Arduino hardware (and is keeping my observations from looking at the schematics and code), but I think it's quite on topic with this issue: a user tried to use the LoRa.h and I am puzzled on how it was used, so I asked. And commenting was a way to subscribe. I do think it's a good idea to have the firmware handle PHY-level with AT commands. |
@cstratton and you did say:
And don't see how it is possible given the MKR schematics, but maybe I'm wrong. |
@zougloub @cstratton @gom-dot-sh just to clarify what is going on. |
Hardware: Arduino MKR1310
Firmware: 1.1.9
Library: LoRa.h 0.7.2 from https://github.com/sandeepmistry/arduino-LoRa
##Abstract
MKR1310 scrambles data instead of transmitting it unaltered.
LoRa Protocol reminder:
LoRa Protocol, PHY-Layer:
Preamble | SyncWord | Header | PHY-Payload | CRC of PHY-Payload
###What was done (non relevant clutter removed from source):
Trying to send "data" to the LoRa Modem. data equals the MAC-Layer of an LoRa Package. The Package was captured with an LoRa Concentrator (Gateway).
Expected behaviour
By using LoRa.h, I expected, that the Modem uses "data" as PHY Payload and adds the components of the PHY Layer as specified (Preamble, SyncWord, Header in front and CRC at the End of PHY-Payload). By using the same "data" every time, the transmitted package should be exactly the same.
Failure / current behaviour
It's not possible to receive the LoRa Package send by the MKR1310 with a gateway. The Arduino module does not handle "data" as PhyPayload, but does something with the data.
Details
I used a software defined radio and https://github.com/rpp0/gr-lora to have a look on the transmitted LoRa packages. The Packages are always starting with identical 17bytes, but are scrambled after that. Also, the 23byte of "data" are inflated to 258bytes. Some inflation was to be expected, because gr-lora exposes the physical signal including whitening, parity bits, but something odd is going on in this case.
Captured packages with sf 11 and 7, the first 17bytes are within '**'
Whish / Suggestion
The firmware should provide a mode, where the Semtech modem only handels the PHY-Layer and PHY-Payload passed to the modem is transmitted transparently.
The text was updated successfully, but these errors were encountered: