@bmarkus thanks, fixing it now.

@dbrgn Thanks for the notification, I can confirm that it works!

@bucknall Had a couple of hours on it and have all 5 units working. I'm not sure I fully understand the issue, but this is what I noticed: I have a wifi router connected to my laptop, that I'm using as a separate AP for the Lopy. If I disconnect the ethernet from the Laptop, this may remove the problem. So, I've wondering if there is RF EMC interference in the cables between the router/laptop/lopy. Also if I then reboot the Lopy the problem disappears.

I don't know of any alternative, but have you tried it on another computer?

This is really an issue, as maximum payload size can be 250 bytes according to LoraWAN specification.

@jmarcelino Thank you!!! you saved my day, it works!

I found that by doing a Factory reset the problem is fixed Factory reset the filesystem If you device’s filesystem gets corrupted (very unlikely, but possible), you can format it very easily by doing: import os os.mkfs('/flash')

I was seeing this developing a BT app for no apparent reason using 1.6 Updating to 1.7.3 solved it. Haven't seen it since.

@livius First i tried it in boot.py - then i moved it to main.py. Both with no success. Then i had an idea. I'm using a FritzBox with Wifi on 2.4 and 5 GHz with the same ssid. I think this is the root cause. I enabled the guest AP and tried to connect to this - and this is working. So at least i have workaround for me! But anyway , thanks a lot for your help!

I have to add some information: I can't use the lastest firmware because the modules are spread and so out of my reach :( I flashed all LoPy modules in April so that's the latest firmware I'm currently using. While searching the web for my problem I found this: https://github.com/Lora-net/LoRaMac-node/issues/104 It says that there is a bug in the SX1276 driver and so maybe in the SX1272, too. It misses a division by 4of the SNR value... And thats the factor I need. So: Does anyone know if this bug was a thing in the LoPy's too and had been fixed in the last weeks after my last update? I can't find anything about it in the last changelogs...

@jmarcelino Thanks! Good to know (and that only leaves one--brown-out reset, which isn't all that important).

Hmm ok I've flagged this internally and will investigate! Thanks for your patience!

@jmarcelino ok, thanks. The Lopy was in AP mode. I will give it a try in STA mode. Cheers Mark

@robert-hh said in Update LoPy firmware using Pysense as expansion board: So better never supply the board by the 3.3V Pin. That's an output, not an input. Use the Vin Pin for supply. @daniel: Please remove note, that the device can be supplied through the 3.3V pin. Even if that may work under certain conditions, the risk is too high that devices will be broken. I see that we disscuss this 6 months ago ;-) https://forum.pycom.io/topic/316/wipy-pin-3v3-not-work But conclusion was different. Now when we have schematic i do not see there any diode or something like LTC4357 And schematic(and description) for LM3281 does not bring light if there is some protection - especially that there is comparator output

@danielm said in Issue with pin interrupt?: Did referencing of the handler help to prevent those issues? Actually I don't remember the outcome of this test. But it must have been unsatisfying. Anyway, just found the following commit in github: https://github.com/danicampora/pycom-micropython-sigfox/commit/d78bec2191358e3392f878392a19b1d9e3f002bc Looks like this is exactly about the issue I ecountered. Going to compile this myself and test...

I just want to remind that this issue remains unsolved on 1.6.13.b1 Counter 1: 10009 Counter 2: 6449 Counter 3: 12757 Counter 1: 10024 Counter 2: 6459 Counter 3: 12778 Counter 1: 10040 Counter 2: 6470 Counter 3: 12798 Counter 1: 10055 Counter 2: 6480 Counter 3: 12818 Counter 1: 10070 Counter 2: 6490 Counter 3: 12838 Counter 1: 10086 Counter 2: 6501 Counter 3: 12858 Counter 1: 10101 Counter 2: 6511 Counter 3: 12878 Counter 1: 10116 Counter 2: 6521 Counter 3: 12899 Counter 1: 10132 Counter 2: 6531 Counter 3: 12919 Counter 1: 10147 Counter 2: 6541 Counter 3: 12939 Guru Meditation Error of type InstrFetchProhibited occurred on core 0. Exception was unhandled. Register dump: PC : 0xffffffff PS : 0x00060a30 A0 : 0x800eb2f0 A1 : 0x3ffe1f50 A2 : 0x3ffe28d0 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffe1f70 A6 : 0x00050823 A7 : 0x00000000 A8 : 0x800eb2ac A9 : 0x3ffe1f30 A10 : 0x3ffe28d0 A11 : 0x00000001 A12 : 0x00000000 A13 : 0x3ffe1f70 A14 : 0x00000003 A15 : 0x00060823 SAR : 0x00000012 EXCCAUSE: 0x00000014 EXCVADDR: 0xfffffffc LBEG : 0x400f753a LEND : 0x400f7543 LCOUNT : 0x00000000 Backtrace: 0x7fffffff:0x3ffe1f50 0x400eb2f0:0x3ffe1f70 0x400dccb8:0x3ffe1fa0 0x400e1672:0x3ffe1fc0 0x400d8244:0x3ffe2050 ================= CORE DUMP START ================= ...

It happens when it's connected to my router. I tried first with a static IP adress but I read there are some problems with that (because of DNS), so I use address reservation for DHCP clients in order to have it connected to a specific IP address.

@DvdGiessen That's brilliant, thanks for bringing this to our attention! Would you mind opening an issue on the GitHub repo for this particular bug? https://github.com/pycom/pycom-micropython-sigfox/issues Thanks!