@MusteDaniel Sorry, but I don't understand what you are trying to do. If you want to send data from your device to your PC you can: Either install MQTT Broker on your PC or send the data to an existing broker in the cloud like broker.hivemq.com or CloudMQTT. Then write the code on your PC either in C# or Python that connects to the broker (that runs either on your PC or even better in the cloud) that subscribes to topic you used to send the messages to the broker. The client code samples for your PC is widely available - just search it on stackoverflow.com

@catalin Yes it's an open source project that is working, at the moment only on boards without CE/ FCC approval, which is why it would be interesting to get it on the Lopy. "All files in this repository are dual-licensed under both GPLv3 and AGPLv3" at the bottom of: https://github.com/sudomesh/LoRaLayer2

@berryskies My bad! Stupid error (as usual?). I misread the socket.SO_CONFIRMED option. I thought this was a constant boolean and didn't set the trailing 0 to 1 (slap to forehead). All working as expected.

@Tamaga I tried receiving data on LoPy4 over WiFi and then sending them to another LoPy4 over LoRa and it worked just fine. I recommend having 2 separate threads - one for receiving and one for sending, although if it is slow data (say one per second) then you can just have it all in one big while loop sequentially...

Any News?

@robert-hh I changed P8 to P9 and it works great! Thank you so much!

@jcaron Yes, I know, just used it for few minutes for testing.

In general, rejoining for every payload is bad practice. Instead you should always try to restore the LoRa status in favor of a rejoin. I'm also guessing that you heavily violate TTNs Fair Access Policy [1] especially when join requests are added to the air time allowed. Forget this comment in case you are operating on a different LoRaWAN backend provider where other policies apply. Secondly, you should give lora.join() some time before testing on has_joined, e.g. in a while loop as proposed here [2]. If your concern is running out of FrameCounters I'd go along with the tx_counter from lora.stats() and rejoin only if you get close to the limit. Here's some untested example code: lora = LoRa(mode=LoRa.LORAWAN, adr=False, device_class=DEVICE_CLASS, region=REGION_US, tx_retries=3) #setup the channels specified in my lorasever config [lora.remove_channel(channel) for channel in range(0,72)] [lora.add_channel(channel, frequency=thisFreq, dr_min=0, dr_max=3) for channel, thisFreq in zip(CH_RANGE, FREQ_RANGE)] lora.nvram_restore() stats = lora.stats() if not lora.has_joined() or stats['tx_counter'] > 65000: lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=some_timeout) while not lora.has_joined(): time.sleep(2.5) print('Not yet joined...') s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setsockopt(socket.SOL_LORA, socket.SO_DR, my_dr) [1] https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy-guidelines/1300 [2] https://docs.pycom.io/tutorials/lora/lorawan-otaa/

Dear Jim, I was running a simple pymesh with 3 LoPy4s. Unless you would be running Pymesh, you might be able to succeed following the same route as @sita within [1]. So, if you don't absolutely depend on Pymesh, you might want to try one of our Dragonfly firmware builds [2]. Some have been successful mitigating spurious core panics with it. If core panics are still happening, I will be happy to receive respective core dumps from it. If you could share the MicroPython code it would even be better in order to reproduce the problem. With kind regards, Andreas. [1] https://forum.pycom.io/topic/5560/guru-meditation-error [2] https://community.hiveeyes.org/t/dragonfly-firmware-for-pycom-esp32/2746

@Eric73 Thanks for the info

@romeotango Importing as_GPS on a Fipy returns the proper set of class members: Pycom MicroPython 1.20.1.r1 [ed31fe1] on 2019-11-16; FiPy with ESP32 Type "help()" for more information. >>> import as_GPS >>> dir(as_GPS) ['__class__', '__name__', 'const', '__file__', 'LONG', 'modf', 'asyncio', 'DD', 'DMS', 'DM', 'KML', 'KPH', 'MPH', 'KNOT', 'MDY', 'DMY', 'RMC', 'GLL', 'VTG', 'GGA', 'GSA', 'GSV', 'POSITION', 'ALTITUDE', 'DATE', 'COURSE', 'AS_GPS'] >>> You could try to erase your module and make a fresh new start.

@Wolli01 start by checking you actually didn’t get it as bytes initially, it is often the case. Otherwise you can use the ˋubinascii.unhexlify` method.

Thank you all. I am mostly interested in a stability and reliability. Then on performance and power consumption. From your responses and other threads, as well as documentation I gather that memory management can be an issue. However, it seems that there are no obvious practical implications (within some limits?) of running either of the options above, as both external flash memory and external RAM are cached to internal RAM. [image: 1577794123511-pycom_system_block_diagram_annotated.pdf]

Found the error, I had chosen the wrong antenna site. Now it works. Thanks for the food for thought.

@bmarkus For example, with a LoRaWAN 1.1 device one would be able to send RejoinRequests via MAC commands (I see that my chirpstack loraserver supports 1.1 and RejoinRequest) This would help obtain new keys, as to avoid the FrameCounter from reaching its limit (65535) and causing the device data to be unable to be accepted by the server.