@Mr-Admin said in syntax question: mqtt_publish(client, "home-assistant/altitude", str(alt.altitude).encode('utf-8')) thank you, this looks like what I need

Hi, same happening here!, after various days working normally , it suddenly appeared. ForoLopy4.jpeg image url)

Thank you I will look into that. I would like to get one GPS location per second, or at least every 2 seconds if possible. I was thinking of some internal buffer in the GPS running full or something. I am now trying to read out more of the buffer and process only parts as you suggested. this still shows a delay of 1-2 seconds, but that would be acceptable.

@g0hww Sorry for the delay, it was holliday in my country yesterday ^^ I thought of doing something like you described but the problem is that I want to do an FFT so I have to collect samples with the minimun sample time I can get, currently I'm limited with a rate of 250Hz because when I call the 'acceleration()' method it takes arrounds 3200 us. That's one of the reason I wanted to use threading. Currently, my solution is to get the maximun of sample I can get without exceeding the Lopy's 4 memory of the Lopy4 (arround 14 second) and then sending it even if it takes a lot of time. If someone has a solution for threading, I would be glad to hear it.

@jcaron thank you for the reply. I will test code with timestamps and report back.

@Morten-Guldager Power consumption in deep sleep is a recurring topic and there are quite a few possible causes: The FiPy does not actually go to deep sleep The LTE modem is still active The GPS is still active at full power See https://forum.pycom.io/topic/7020/fipy-pytrack-2-0-deepsleep-power-consumption/6 and https://forum.pycom.io/topic/6839/fipy-deepsleep-methods/20?page=1 for a few hints. Make sure you have the right versions of firmware of the FiPy and PyTrack and modem.

This is an old topic but would like to add some comments that can be useful to someone having this kind of issues. I have an expansion board 3 with a Wipy, using the SD card and some sensors, and everything is working well being powered throu USB or battery. I had some issues that were fixed by following these steps: When powered by battery, P19 and P20 are affected by RTS and CTS respectively, and it was blocking one sensor I have connected to those pins. Removing those jumpers from Expansion Board resolved this issue. Don't use P8 with any sensor if you are using SD card. Looking at the Wipy3 pinout, I suppose the same is true for P3, P9 and P10. Even thou, P10 is also connected to the user button, then I configured it as an input pin with pull=PULL-UP, and avoid read/write SD operations and user button clicks at the same time. Also, this post helped me with a weird behavior of user button when using the battery: https://forum.pycom.io/topic/7364/exp-board-user-push-button/3?_=1648562954689 I connected the 10K pull-up resistor to P8 as indicated in the expansion board documentation, but honestly, I don't understand why it's needed. Most of these "tricks" are not clearly documented and I found them reading several posts and connecting ideas between them. In my opinion, Pycom boards are very good in general (with a very few details that could be improved), but as said in many places, its documentation should be reviewed to add many things like these that one has to chase reading somewhere else or by try/fail methods.

@robert-hh hi, thanks very much, i think updating did the thing. Works now fine.

You are welcome. :) Now we need to get back to the problem. It may be stuck on a mode somehow. I will investigate this, talk to my friends and try to get back to you within next week.

@jcaron okay, thank you. I hadn't found this question before, but now I see, that searching on IC2 bus, there are in fact several posts on this topic. Thanks again.

@HAMMOUTI try to change the name of your file "valeurenmv.py" by "valeurenmv.txt" ! Jiemde

@Gijs Same problem here, I bought some Lopy4 + expansion board for my students in the lab. None of the devices work on on any machine with Windows 10. The same devices work fine on Linux. I updated the board to the latest firmware and nothing changed.

@Louis-CONVERT Note that IIRC the difference is minimal. It's not like it's going to be 0, the PIC still draws a few µA, around 10-12 I believe. In ESP32 deep sleep mode I think it's more like 15-20, but it's definitely in the same ballpark (but you should definitely test all variations in your own specific setup). Depending on how often you wake up and how much your draw when you wake up, as well as as any other sensors you may have drawing power while in sleep, this may make nearly no difference. If you really want even lower power you will likely have to switch to different hardware.

@jcaron wii that was it. I can’t tell you how happy I am that after many days of trying it finally works! : D

Hi @jcaron, Thanks for your reply. Effectively it seems the GNSS is connected via I2C directly to the ESP32. I was fooled by the fact that the L76 library needs a pycoproc/pycoproc2 object as argument for the initialization. So I thought it was connected via the PIC, which doesn't seems to be the case. I will try to implement binary communication and let you know if it improves the GNSS usage.

@Anders-H yes, you could. If it's a 3.7V type like this one, it should work. It will take some time to get fully charged, but that is not critical. Take care, like @jcaron said, about the connector polarity. Of that is wrong it will damage your board.