arduino / mkrwan1300-fw

22 stars 23 forks source link

MKR1310 won't transmitt data transparently #24

Open ghost opened 4 years ago

ghost commented 4 years ago

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).

#include <SPI.h>
#include <LoRa.h>

byte data[] = {0x00, 0x50, 0xD6, 0x02, 0xD0, 0x7E, 0xD5, 0xB3,
              0x70, 0x12, 0x77, 0x35, 0x30, 0x31, 0x0A, 0x61,
               0xA8, 0x21, 0xE7, 0x10, 0xD8, 0xD0, 0xE4
              };
void setup() {
  LoRa.begin(8681E5)
  LoRa.enableCrc();
  LoRa.setSyncWord(0x34); //SyncWord for private networks if using a SX127x Modem
  LoRa.setSpreadingFactor(7);
}
void loop() {
  LoRa.write(data, 23);
  LoRa.endPacket();
  delay(5000);
}

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 '**'

spreading factor: 11
**ff ea a0 4d 75 06 b1 cb 99 5c 7f 9e eb 4b ad bc c0** 54 9f a7 ff 05 8f 8f 44 fd 52 2d ac 3f 9d 6b d5 8c 7d 73 1a 18 b4 c2 7e 0c 0f f9 5a ac 01 49 5f b5 b1 35 8e 58 cc e2 e3 95 d3 68 cb 80 5a fa 84 89 ae 38 04 30 51 9d c7 e2 b7 f9 a7 bc 9d 7c 84 86 b5 d4 00 58 a0 b1 38 41 91 b9 25 68 c1 39 b3 f1 b9 93 3d b5 44 f0 f5 5f 2c 9c 54 7a ef ee 03 cc 8e 05 61 d0 fe d3 aa 63 8d 62 5a 84 0c 75 1a 2b cc b9 95 65 43 33 66 9f 28 f5 93 be e6 69 ed 5a f0 d4 9e 6b 76 04 96 a3 b6 6e 2e f8 d0 3f f1 d9 16 6a 03 11 b9 23 63 2b 19 01 67 23 34 a8 99 a7 92 8c 49 22 23 51 97 fa 3d 95 c0 4c 71 df b5 40 f6 cf ff c7 8b 94 ac 3c 5e 7a 60 58 46 0a f4 af ee 38 ec 5a 6a 37 07 1a 0d c8 5c d0 8f 3f b3 0c 9e da b0 7d 89 67 74 93 ca 43 ab e1 a2 8c 74 a9 3e e9 c1 1a 53 1a b7 bd 23 e7 33 75 43 c7 96 8a

**ff ea a0 4d 75 06 b1 cb 99 5c 7f 9e eb 4b ad bc c0** d6 1d 77 a6 63 1e 11 1f ef 4d b1 0d 83 3c f8 27 b1 90 ae fb 85 86 1a d1 37 a9 60 2c 25 89 81 c2 a2 c2 c9 24 c5 d5 2b 67 2c d8 e3 6b 3c ee 94 83 20 0d dc 90 c0 e7 e5 13 ac f7 f4 b6 a2 7c d7 aa d6 e0 17 a3 44 13 a5 ce 12 55 af d8 6d 5b 0f d4 75 85 10 70 47 90 b6 36 b6 f8 73 c6 95 96 4d 9b f5 d6 90 c8 b2 29 38 6a 3c 3f 03 43 43 6d 25 65 1d af 17 c5 fe af 38 27 13 29 a2 a3 7d 43 dd 41 ff de 18 ea 7b 24 1f bf 6e f6 66 81 45 29 0c a8 14 36 16 2c d3 59 d5 26 3b be b4 a1 41 65 c7 12 4d 3f 8e fe b5 d6 b3 82 88 b2 f3 b0 98 71 6d d3 2a 67 80 fb 74 34 67 a6 85 0f ce ce aa e6 b2 4c f4 27 41 8a fc a2 fc 53 4c 59 b6 64 05 ab d4 a8 98 19 b9 26 94 fd 2c cd ff eb 86 98 36 a1 c6 1d d6 eb 0b 20 6c 55 b2 cd bf c7 a7 3d 2c 06 02 f0 15

spreading factor: 7
**ff ea a0 4d 75 06 b1 cb 99 5c 7f 9e eb 4b ad bc c0** 72 1f 35 16 ac 57 9e 62 a8 84 66 08 96 bb 29 a3 b2 32 80 15 1d 20 37 7c 86 7a 2b f7 f1 a3 a1 b3 78 c9 fe 5b 34 0e f1 81 03 54 b5 1b 18 ff 62 1f 95 e3 d4 f6 04 11 57 f4 39 43 23 99 fd c3 2b f1 b4 a4 f5 cf f9 3c 19 00 4b 3d e2 41 64 99 7d 5f c8 83 28 b9 af c8 ed e0 11 21 61 c1 e4 44 c6 f8 ca 91 21 dd c4 79 80 78 a7 85 de 17 50 ee 5b 3a 36 da cc a3 3a ed 93 ad 22 ba 07 39 18 2f 77 2d 44 fa 18 d4 7e 97 78 68 ee a4 d9 e8 fd 4f 6a be b9 3e 6d 47 5a 74 f7 7c 1e 8a e4 7b d2 4a 40 e1 f1 48 4d 54 b2 b1 0c 2a 16 a4 f5 80 ac 6d 9f c7 e2 45 22 b7 4d 7b 8d ef 4e a6 bf d4 30 31 47 43 21 1b a3 71 e6 f2 ac 82 11 a5 23 50 46 60 34 fb 14 24 17 72 28 47 7b 65 52 ef 86 91 ca 2e ad f5 fd 9f 8b 4d 02 f8 20 d4 fb a2 84 e1 6a f0 ff c9 92

**ff ea a0 4d 75 06 b1 cb 99 5c 7f 9e eb 4b ad bc c0** d7 1d 77 ba 4d 78 a7 3c 4f ce 5b 3b 2d 85 f7 1f bc b3 a0 67 3d 62 54 10 d7 02 57 05 63 25 68 07 99 63 c7 d1 40 78 c2 e6 14 1c 6b 3b 32 13 6f f2 44 6c 3c 11 ad 13 50 6a 5a 7e 83 cf 72 a5 99 4f 06 f0 b0 e0 1f 2d a2 6b ac 05 8e 0c 47 c4 c4 e4 0c 4d 8e cd 0b cc 57 2e a6 1a dd f1 ff 3a c7 d3 be 92 1c 82 75 45 6b 5b 3a a0 48 7a d3 6f 34 0a 8a 87 23 46 b7 1f 88 29 ad 9b c8 96 01 7c 07 88 90 a8 32 b2 0d 79 68 78 d8 d9 a9 a1 e2 63 bf 10 21 e2 18 1d 9e a7 b8 5c 1e 57 c8 23 8d 8c b9 fc aa b9 9f 3f 10 22 2b 10 e1 00 52 b0 93 9b d4 90 99 77 80 2a a0 a1 ee df 08 23 19 e0 c7 9a 0d 22 ac 92 d0 1c 44 f1 32 b7 05 c6 c1 da a1 b6 d1 04 e2 55 6f 83 56 aa e5 79 d3 78 9c 6c 05 27 5a 80 e3 18 2e 4d 73 bc 77 7b 1d 7b da 76 2e 6b ef c9 c0

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.

cstratton commented 3 years ago

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.

zougloub commented 3 years ago

@gom-dot-sh did you modify the 1310 in order to try and use https://github.com/sandeepmistry/arduino-LoRa ? According to the schematics, and my own use of the board, it seems that the MISO is disconnected from the radio module. I can see that the firmware gets 0x12 from register 0x42 (SX1276 chip version), but trying to do the same SPI read, I don't get a response.

image

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.

cstratton commented 3 years ago

According to the schematics, and my own use of the board, it seems that the MISO is disconnected from the radio module.

If you want to operate the radio directly from your own code you should target the STML073 in the Murata module, not the SAMD21

so you can only talk UART to the module with its MCU

It looks like I2C is the intended means of inter-processor communication

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.

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.

zougloub commented 3 years ago

If you want to operate the radio directly from your own code you should target the STML073 in the Murata module, not the SAMD21

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

It looks like I2C is the intended means of inter-processor communication

Isn't this firmware using UART?

It looks like the STM32L073 in the Murata module, and not the SAMD21 owns that flash. Probably there to support LoRaWAN FUOTA or similar

And yet the flash chip select is connected on SAMD21 only ?

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.

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.

zougloub commented 3 years ago

@cstratton and you did say:

[the firmware] is made to stop so that the host processor running the Arduino sketch can directly operate the radio via SPI.

And don't see how it is possible given the MKR schematics, but maybe I'm wrong.

facchinm commented 3 years ago

@zougloub @cstratton @gom-dot-sh just to clarify what is going on. The serial ports on SAMD chips are SERCOM so thay can be used as SPI with no effort. When we want to communicate with the Semtech chip directly, the Murata module is being rebooted via gpio so it only executes this routine (aka passthrough). Since it's being bitbanged, performance is not excellent but theoretically it should work for every speed. If you have further questions let me know :wink: