@catalin Ok, I will try the licensing then. Thank you very much.

@Colateral said in Lopy4 433Mhz example: Does anybody have 433Mz lora initialization? I don't actually know any details about this, but just stumbled over [1] the other day. So, @robert-hh might be the right one to ask about this. Please also see [2], where you might find more appropriate details to go ahead on this. [1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/robert-hh/LoPy4-1.20.0.rc13-eu433.tar.gz [2] https://github.com/pycom/pycom-micropython-sigfox/issues/345

@papasmurph Use the socket.bind( x ) where x is your desired port before doing the send

@Eric73 Great, thanks for your help !

@robert-hh Thanks for clearing this out !

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.