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

@jcaron said in What is the realistic range of LoRaWAN?: So if you have both antennas exactly vertical and exactly at the same height, you do get the 15 dB gain. But if the one antenna is even slightly higher or lower than the other, the gain very quickly drops, and even becomes negative in some directions. Here's an example (different frequency, but the principle is most certainly the same): Thanks for the reply, I did not know such antennas actually existed! Generally its cheap Alixpress crap that oversells itself and actually has worse SWR than a piece of wire for the specified frequency range. Indeed you have to be wary of the antenna heights with such narrow beams

@stevo52 Yes, from the distance, it sounds like a hardware problem with the board. Maybe a broken wire or a bad solder point at the P2 pin.

Hello! I am having issue with activating using method otaa lopy with ttn gateway fot US915. whats correct code i should use I searched a lot of topics over weekend and could not find correct code. Thank you Same time using ttn node US915 with ttn gateway activation worked as shown.

@robert-hh Yes, it looks like better choise. You could try if the figure changes if you add a smaller pull-up resistor, like 4k7 Ohm. I use already 4k7.

@robert-hh Hope you are doing well and had a good weekend. Thank you for your support. In one of the reply, you mentioned that "the data rates for join should be handled automatic. It starts with the highest data rate (lowest sf), and if that fails, the data rate is lowered until eventually a join happens. Join always succeeds here, so it is hard test it." Is there a way to test this? like debug messages? The scenario being near my house, there are no TTN Gateway, so, i bought a Indoor gateway (which works fine). So, I tested sending data using different spreading factor using s.setsockopt(socket.SOL_LORA, socket.SO_DR, data_rate). When I set it to SF12BW125, the gateway far away was also able to receive the message. I was wondering if there's a way to set SF12 for the join request, so that the far gateway gets my Join request. (avoiding buying of a Indoor gateway) and increasing the reach-ability. Kind regards, bitvijays

Yes, as the reading is only caught on the interrupt, before the microcontroller wakes up, we cannot see the data

@dicktonyboy You could check, whether P2 is connected at least to the RGB Led. It is one of the connections faced to the LoPy Shield, opposite to P2.

About FFT, there is 'ulab' module (a micro NumPy/SciPy) for Pycom MicroPython, see the topic "Pycom firmwares with single/double precision and ulab module".

@jcaron I have fiddled around more and more using your questions and came to this conclusion: one of the solder points on the SSD1306 was not completely right. This mostly manifested when cables were bent differently, but must have also thrown problems when the bus was being used for other sensors somehow. The exact reason as to why i2c.scan() had an extremely high correlation with the display working - I don't know. Electricity is weird. Other nodes that had I2C problems also suffered mostly from badly soldered contact points, and it seems like all problems have been resolved now. Thanks for the patience and questions as it ultimately led me to the real culprit. Case closed - lesson learned: always check your contact points even if it works.

@nadvorvo said in T-Mobile NB-IoT in the Netherlands? [SOLVED]: Could you comment, please [AT] 939910, [AT-OK] +9509 I do not know meaning. [AT] 939910 means an AT command was submitted at timestamp 939910 [AT-OK] +9509 means an OK response was received after elapsed time 9509 both values are in milliseconds

@robert-hh Unreal Rob! I'm used to artefacts (mainly missing events) on a DSO due aliasing but I haven't had a lot of experience with spectrum analysers. This experience of seeing frequencies that aren't really there is bothersome. But then any instrument beyond a ruler is probably measuring not what you are interested in but some other metric supposedly indicative of what you are interested in, so anomalies are only to be expected I guess. Really interesting that the artefacts vanish at zero IF. I might get myself a HackRF1 as a Christmas present & see what it has to say about side lobes as a function of bytes sent from the SX1272/1276. Regardless of lobes/no lobes lora is pretty impressive. I ran a swept frequency source over the top of a raw lora link here on the bench & the link ploughed on regardless. I'm sure if I fiddled the timing I could break the link but I don't much see the point. Thnx to you & jcaron for your contributions these last few years, always constructive & enlightening.

@acheesehead The new pinouts are now available and we also included them at docs.pycom.io.

@jcaron Sorry, yes you are correct, looks like I need a stronger morning coffee! @combaindeft The Pytrack has the same functionality as the deepsleep shield built in, the example code should be very similar and can be found here: https://docs.pycom.io/chapter/pytrackpysense/apireference/sleep.html

@kjm I spoke too soon. I've got 2 x GPYs now that won't attach & all I've done is to try the lte.send_at_cmd('AT+CEREG=2;+CEREG?;+CEREG=0') cmd on them. Seems an improbable result I know but 2 out of 2 is enough for me, I'm not about to try it on a 3rd GPY just to get the hat trick & prove my point!

@colateral It's in the development branch.

Hello @braulio. I think the extra milliseconds are from Lopy info processing, you can try with a different number (10 seconds, 20, 30 etc) and the "extra" time is the same then you have a solution. Also you hsould try to make a new post, the topic is quite different from this one.

@sealyons I made a test with the calibrated temperature mesurement device: Calibrated device: 21.7 21.8 DS18B20: 21.9 21.9 DHT22: 21.8 21.9 SI7021: 21.7 21.8 BMP085: 22.4 22.5 BME280: 21.8 21.9 Besides the BMP085, all devices were on the spot = within 1 digit variance. That status was stable for 5 hours testing. Only the BMP085 was always ~0.6 °C above, but still that at the limits of it's spec.

@robert-hh I decided to not use esp32 cam as it can only operate at voltage above 4V, which is not useful for my setup. I have a question related to ESP32-WROVER-IE(16MB) chip. On which expansion board I should attach it and flash? This chip offers 16MB Flash and 8MB SPIRAM, somehing that I need for my project, but still no available boards on which this chip is attached.