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

@securigy Pycom is notoriously slow on responses. Try to mail to bettina@pycom.io (I hope remember the address right).

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

@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

@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

@Gijs said in Alter lora frequency without reset: Also, setting a timeout does not alleviate the issue of the taken semaphore. No, but on timeout the semaphore could be released too.

@mikestanley464 Pycom Ltd. ceased operation. There will not be a reply.

@gael-cobert RST is required. Did you check that you connected the flat cable between HAT and display the right way around? Checking the board it seems that the Pinout paper is wrong. The PIN where the white cabel is connected to is actually P10. left to it is P4, right to it P2. The rows in the Pinout are swapped.

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

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