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

Thanks @eric73 I will call them Best regards Jiemde

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.

Could you confirm this is an issue still in the 1.20rc builds. It should now be fixed :)

@prx The basic range of the ADC is 0-about 1 V as input voltage, which returns a numeric range of 0-4095. That's what is returned with apin.value(). The ESP32 has a switchable attenuator, by which the voltage range can be changed, up to 0-about 3.3 V. The built-in ADC of the ESP32 is very bad. It is noisy and nonlinear, and there is some variation between the devices. So the lower value is not 0V but about 0.05V, and the upper value also varies, and there is an substantial temperature drift. Effectively, the resolution is 8-9 bits. The Pycom API contains some serve functions. First of all to deal with the upper level variation, caused by the varying internal Vref, consisting of adc.vref_to_pin() which connects the internal Vref to an external Pin, so you can determine the value with an voltage meter. And then you can call adc.vref() to store that value in the API data. This value will then in combination with the attenuator setting be used by adcchannel.voltage() or adcchannel.value_to_voltage(value) to convert a raw ADC value into a voltage reading. The newer Pycom devices (WiPy3, LoPy4, FiPy) with a Rev1 ESP32 chip are told to be calibrated for a lower non-linearity, but that does not reduce the noise. If you need a precise ADC, use an external one.

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

@dmayorquin Interesting observation. It would be so much easier to understand these things if Pycom would make the schematic available. Thanks for posting!

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

@james-matthews struct.unpack work with "byte" objet. As we have to unpack a float this "byte" object must have a size of 4 bytes. [https://docs.python.org/2/library/struct.html] This float , have been packed in a binary form '''s.send(struct.pack('f',float(latitude)) + struct.pack('f',float(longitude)))''' then sent to sigfox backend data and showed in hexadecimal '''d5034f42b552a0bf''' so, to have original value you just have to unpack it from hexadecimal to float ''' lat=b'\xd5\x03\x4f\x42' '''this is the way to create and assign hexadecimal value to a 'python byte object' with len=4

What is the interest level in an MP implementation? There are many things to be taken care of besides just the Hub connection (DPS, Twin, etc).

Hi @Colateral, Did you select pybytes as "Type"? If you select stable, it won't ask for a token. Let me know if this helped