@Meric-NESSANGE said in INPUT ADC values and OUTPUT voltage: Worse or better than an arduino? Or the same order of magnitude ? If your arduion use ESP32 then the same. If you use digital output then it should be near max voltage 3.3. For the input read the docs, especially bottom green frame https://docs.pycom.io/firmwareapi/pycom/machine/adc/#app

@robert-hh took some debugging, but I did manage to make it work like you said. Thanks a lot!

@eric73 Yes, the sequence was exactly my problem. Disengaging solved it :)

@devinv it takes a while for a GPS chip to get a fix. You definitely won’t get a position right after wake up, the chip needs to receive ephemeris data, lock onto satellites, compute a position... This has been discussed several times in the forum, search for the relevant topics for details.

You can check out this company. They've got nice reviews and a great portfolio of resolved cases. I'm sure they'll be able to help.

Hi there, I got little more clarification to the issue. When I used I2C bus 1 (instead of default 0) and pins P10 + P11, I got the I2C bus to work. I've have the impression that I2C bus 0 and pins P9 + P10 might be reserved or something like this. Can anyone confirm if they're used by UART or button on Expansion board or something like this? Does anyone know, if 10x orange led blink on Expansion board is some error message? I did not find anything related to this while searching.

Hello, in this link they answer quickly to all the doubts. Sigfox Ask Regards,

Yes you can download your code wirelessly, have a look at https://docs.pycom.io/getting-started/programming/ftp But you still need some connection to power your Sipy And yes you can download via RX/TX wire but you need de FDTI 3.3V cable or something similar

To close this post, I wanted to say that the issues I found in the deep sleep shield, have already been reported before in this forum. My mistake was not to do an exhaustive search before posting. Conclusion: the deep sleep shield has quite a few problems when powered by a lipo battery. *bradnz hace 12 meses For any one interested, or has this issue in the future I have resolved this by doing the following: Rolled back firmware to 1.7.9.b3 Used version 1.0.0 of the deepsleep.py file from github. Works fine now.* post1 post2 post3

@eric73 thanks again. Indeed I was expecting like a popup or message or anything. I just did bluetooth.connect(mac_addr) ad if connected, print something. And it turns out to that the connection was indeed established but silently yes.

Hello @crasu if you use the pycom firmware tool and select "development" in the type dropdown on the communication page instead of "stable" you'll flash the latest release candidate that should have a fix for this.

@andreas said in ADC use to measure battery level / Vin level: We are getting reasonable readings when using the 1 MΩ / 1 MΩ values as resistor values (matching v3.2) @MKO just measured the resistor values and confirmed [1] that it's also 1 MΩ / 1 MΩ for the Pycom Expansion Board v3.1, as supposed. [1] https://community.hiveeyes.org/t/batterieuberwachung-voltage-divider-und-attenuation-fur-microypthon-firmware/2128/42

@juan_peroza JSON is not a protocol, it’s just a data representation. You can send whatever you want, but JSON is not very space efficient, and is usually not the best choice for data sent over a (very) low bandwidth link such as LoRa, SigFox, NB-IoT, or BLE. It’s usually better to use an optimised binary format in those cases.

@StijnK setup_sleep() is a function contained in the pycoproc.py library, and according to its code the maximum value is 2^24 - 1. So the maximum sleep time you could set is 16777215 seconds, which is about 4660 hours (more than six months). Here is the code of pycoproc.py in Github: https://github.com/pycom/pycom-libraries/blob/f848adcfb937e7b7bbc5f78db95840fa26dabe11/pybytes/pysense/lib/pycoproc.py#L24

@calvinblock44 Sigfox enforces that the devices that consume their service need to be registered manufacturers, the Pycom's Sigfox native library contains sensitive information and code that need to be packed and secured (As more as possible). From there you have two options, construct your wifi sniffing functionality over the official firmware or select a more appropriate hardware that fit your needs. Be aware also that if you are planning to create a final product using certified boards your are not allowed to modify the RF code because is highly possible to void the certification if the code modify the way of signal emission.