If Im correct, you should set the socket to blocking s.setblocking(True) To make the program wait If that is not the case, then its probably a bug... Gijs

@malachib i know is a hold post but y reply for other is a bug in lmic-esp-idf in hal.c change io_conf.pin_bit_mask = (1<<lmic_pins.nss) | (1<<lmic_pins.rst); by io_conf.pin_bit_mask = (1<<lmic_pins.nss); if(lmic_pins.rst!=LMIC_UNUSED_PIN) io_conf.pin_bit_mask = (1<<lmic_pins.rst);

@gazmcghee Late server responses seem to be a problem for the Asia-Pacific region. Even here, with the TTN europe server almost in viewing distance - at least compared to Australian dimensions - the server responses are not too early, not even for the 5s time. They arrive just a few 100 ms before downlink time. And it's not the link. Traceroute for router.eu.thethings.network reports ~30ms at the last line and 21 hops. What I never addressed in the nanogateway code is the aspect, that the server changes the downlink message frequency and data rate. Using OTAA, the server can tell a node that setting. But using ABP, the node does initially not know. I never looked into the transfers logs for that case. The TTN server might still use the uplink configuration for downlink service messages. For me the non-blocking socket is fine, because I have an external watchdog which I feed right from the main loop. That way I know that this loop is running. Funny enough, I see on indcidence that the watchdog had to act. The -6000 value was the one I found accurate for LoPy4.

@beelzmon I thinkk there is a problem with the line from main.py import Logger in boot.py. That one causes main.py to be compiled and all statements at top level to be executed. So you get the main.py log messages eventually before the boot.py log messages in the log file. You could try to either: put the class logger into a separate file, or put the class logger into boot.py. Since both boot.py and main.py share the same name space, the class logger would be available to both. I prefer the separate file for the logger class.

@Gijs , oui effectivement c'est pour du LoRaWAN en otta , mais je n'arrive pas écrire le code pour envoyer mes donnée issue de mes deux capteurs. je n ai pas assez de compétence dans ce domaine.

We have the same page here: https://docs.pycom.io/gettingstarted/programming/safeboot/ If you can perhaps recommend a better location, let me know!

Well, it could also be a problem on my side, let me know what you get!

@StefanoF I made a few more tests with the most recent code I have posted (which is the initial goertzel code). a) test for phase jitter. Instead of reading the ADC, i just supplied a artificial 50Hz sine with an amplitude of 50 and an offset of range/2 into the algorithm. Result: constant 49.99993, which means that there is no phase jitter. b) I connected the interface network, but not the sensor. Result: Output values between 0.005 and 0.03. Since the output value of 1Veff is about 240, that is equivalent of ~60µVeff, or about 1 mA through the sensor. c) connect a battery with 1.5V to the input. Result: values of about 0.5 -> Noisy battery! d) connect the SCT013 with no current. Value of 0.04 +/- 0.03. That's about 160µVeff of 3 mA (or 0.5 W at 230V) through the sensor. So it looks as if the sensor picks up some noise, but still ok. e) Using an external ADC (mcp3201). Result: values of 0.05. Slightly worse than using the internal ADC. Lesson learned: I will stick with the initial solution. The challenge is to proper shield the interface network and the cable from picking up unwanted noise.

The 2 above comments are about OTAA, but ABP has a 'join' that has no transmit/listening AFAIK.

@jcaron I tried another lopy4 & got some metadata [image: 1602626890140-ttnmeta.jpg] it doesn't indicate if a join accept was sent but seems to show 3 gateways? The really weird thing is I terminated the program from network import LoRa import time, binascii, pycom pycom.heartbeat(False) pycom.rgbled(0x7f0000) #red app_eui = binascii.unhexlify('70B3D57ED00363A8') app_key = binascii.unhexlify('757CC90FE2A05ACA33C6FE8376F8DBD2') lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.AS923, public=1, adr=0, tx_retries=0) lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0) while not lora.has_joined(): pycom.rgbled(0x7f7f00) #yellow time.sleep(5) print('Trying to join TTN Network!') print('Network joined!') pycom.rgbled(0x007f00) #green or at least I thought I did (it was no longer printing 'Trying to join TTN Network!' but weirdly join requests kept appearing on the console every 37s. Code like that, beavering away in the background transmitting RF with no indication of what it is up to, terrifies me!

@kjm You were right about CFB mode. The issue you have is that you initialize the cipher with every message and use a random IV. Then you have to re-transmit the IV with every message, which is then expanded by 16 bytes. So you must avoid sending the IV all the time. But if you still want to save against message replay, you have to use other means of message sequencing and modification. The way you do it now is NOT save against message replay, because you send the IV in clear with the message. There are several ways to do so, but none of them is simple. a) Use a constant IV (like all 0) and CFB, but use an own counter, which is checked at the receiver side to be monotonic increasing (or decreasing). This counter will be added to message and encrypted with it. The size is up to you. Less than 2 bytes is maybe not helpful. That's what LoraWAN does. b) Use CTR mode with constant iv or CFB with a iv which varies in a known way (e.g. increasing). Do not transmit that variable element with the message. That would implicitly work as counter and so on. So far it's easy. The tricky part is synchronization ob both sides. That could be done with a challenge-response protocol (look that up: https://en.wikipedia.org/wiki/Challenge–response_authentication), where both side verify that the other side is authentic. As part of that protocol, new counter values can be set. The Kerberos example of the link above is a simple means, which could be used as part of that sync.

@Gijs I assume that not. I am running a version from months or years ago, and with the Loriot network. I can send you a copy of that nanogateway script.

@Thierry See https://esp32.com/viewtopic.php?t=9#p43120 for a discussion on the subject (note that this would be routing, not bridging). It seems you would need to recompile the firmware with different ESP-IDF settings, and there are some limitations due to limited routing capabilities (I'm not even sure how the default route would be set?). An alternative would be to do this on a higher layer, by running a proxy on the module to relay traffic. Depending on what exactly you are trying to achieve (raw TCP, raw UDP, HTTP, HTTPS...) there could be a number of options to achieve that. What exactly is your intended setup and what are you trying to forward?

@Gijs Ask me again new year's day!

It is better to buy WiPy3 with headers (less expensive, EUR20 x EUR35), as Pygate already has LoRa that can't be used at the same time with LoPy4 LoRa.

@StefanoF All tools I listed below except for FileZilla are sending scripts via UART,

@Thierry Glad to hear you got it fixed :)