@Chandan-Verma see https://forum.pycom.io/topic/6963/pytrack-s-accelerometer-sampling-rate/4 for a discussion on the topic.

@snehasg96 Can you try the same thing with utime.sleep() instead? I haven't tried it myself yet, but I plan to do so.

@snehasg96 said in Data Rate of LoRa experiments: @bmarkus Thank you! So if I understood you correctly, sending a packet of payload say less than 64 bytes should be good? Also do you mean i should include the SF to a value between 6-12 in my code? Appreciate your feedback. I say use payload which is within the allowed size and represent a typical size let say around 8-10 bytes. Use the lowest DR (highest SF) which is DR0/SF12 for EU868 and add other DR, DR1...DR5 to see how distance varies by DR. SF6 is not valid for SX127x device chipsets and for Gateways. Please note, LoRa packets can be travel for a long distance randomly, but do not expect that long distance you see for few packets will work in a production environment. Be conservative and base your decision on larger number of samples.

@re Yes. The SX1272 of the LoPy of SX1276 of the Lopy4 can only listen to one frequency and one SF/BW setting at a time. The target platform for these chips is motes (= Lora nodes, AFAIK), not gateways. Gateways use typically a different chip set, like the combination of Semtech SX1257 and SX1301/SX1308. If you need a full service gateway, you must get one. There are raspi add-on boards Like the IC880a from ICMP and the RAK831 which offer full service. Or you buy a ready gateway. Look at the The Things site for product lists. ICMP offers also a ready built box with raspi, receivber & software for testing.

@jcaron The Rising HF RHF301, on the frequencies described here: https://account.thethingsnetwork.org/api/v2/frequency-plans/US_902_928 So, it looks like that's 903900000 904100000 904300000 904500000 904700000 904900000 905100000 905300000 all on 125 kHz bw.

@robert-hh There is a PR for that to fix the issue OK, thank you for the heads up

Hi @daniel, just wanted to make sure these two issues will be addressed in the next release: save/restore channel mask fix MAC command buffers restore Let me know if you need/want issues filed in GitHub and/or PRs.

@bucknall I was wondering the same. I found that the necessary changes are on this line: { MODEM_LORA, REG_LR_PAYLOADMAXLENGTH, 0x40 },\ As 0x40 is 64 and is this that is limiting the payload size.