@melkoutch the spreading factor determines the transmission speed, which in turn has an influence on range and resistance to interference (in theory at least). SF7 is the fastest, SF12 is the slowest. SF12 is so slow that it takes over a second to send a LoRaWAN frame with just a single data byte. In theory it gives a better range.

Nevermind, I solved it. I'm new to real time programming and apparently had to find out the hard way not to put code that's too time consuming into an ISR. I changed it so that the ISR just changes a flag and that the actual work is being done in the main loop.

@robert-hh Thanks for that will take a look

Okay this has answered my question! Looking forward to test the border router functionality.

@asb said in Firmware Over The Air (LPWAN): Hi, Im curious about the following: Reading in the things networks forums, there is some interesting material about work regarding firmware updates using LoRa. Let's say for example the things network implements over the air updates via lora in their console. Could existing LoPy's (4) use this feature, or could a manual firmware update from pycom enable this feature or not possible? Thanks Best regards We have user's who have implemented there own firmware OTA using lora in the past. I dont think anything got released for public use however. Ill try and find out what our plans are Re: Lora OTA.

@snehasg96 main.py is executed automatically when the device boots. If ouy wnat to run a script, like recv.py, manually, just enter at the REPL prompt (the one with >>>): import recv

@iplooky Hi, I think I am looking for the same concept to. My case is to implement a Lora Nano-GTW and use a SIM808 to backhaul the data via GPRS. Is it the same case you have? I am actually a the planning stage. If you have advanced something, please share your ideas. I am thinking to do it with an arduino module. I am going to try to create a serial connection with it and also connect other arduino's pins with the SIM808 and create another serial Then I guess hard code programming should be necessary in order to create the flux of information between the pycom to an arduino's logical buffer and then to the SIM808 to be transmitted to some internet server through GPRS cell network. Please, destroy my idea with anything. Thanks to all.

@crumble also, is it fine to use the utime.time() in the receiver as well or just use it in the sender? Also i tried running the code after removing time.sleep() in the receiver but for some reason i still experience the same issue.

@robert-hh thanks there is not much described here about the standard values in the initialiazation.

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

@snehasg96 Not without significant development effort. And honestly you would not want to. Lora just isnt setup for that kind of two way comm's without a ton of latency and bandwith issues.

@weingami Hi, I deployed hotfix and tested wifi, sigfox and lora connections. I correctly received the data. We need to test more things and there are a few more bugs, that we know and we're about to fix now.

@paul-thornton said in LoRa (Raw) & MQTT vs. LoRaWAN & private LoRaWAN server: Is this something that has to be completely self hosted? From the current state of things, yes, it has to. I need a solution that can scale up. We think about several hundrets of nodes with several gateways per application. Everything has to be self powered. And also for now, it's not clear if the gateways will have a permanent connection to the higher-level network, or will initially store all the information and load them up in fixed intervals. My first attempt was, to use TTN. But there are opinions that speak against it. Think of areas in the world where the Internet is not as free as it should be. Cheers, Thomas

@nagesh-divatagi please provide more details, including at least the hardware (modules, antennas) and firmware used, the relevant parts of your code on both sides, the distance, whether you’re indoors or outdoors, and what you actually get (logs, stats...).

@aniket_yeole you can change some of the parameters (including SF) using setsockopt. To change the frequency you’ll need to remove all channels and re-add channels with your chosen frequency. But beware, the network can change those settings via MAC commands.

@tve The original mesh announcement https://pycom.io/launching-mesh-networks/ said it was based on OpenThread https://openthread.io/ and includes links to the source on github. I'm in the process of setting up my own demo using a bunch of LoPy nodes. Andrew