@dda Do both device have the same firmware version?

@paul-thornton Hi again, any News?

@nervencid You can use any name for your scripts. Only boot.py and main.py are executed as part of the boot process. If you want to run your script then, you have to add a statement like: import myscript e.g. to main.py. You should be able to stop your script with Ctr-C from the console, unless you disable that in your code. To isolate the problems, try running your code with a simple terminal like Putty. Note: You can change the name of the file which is run instead of main.py with machine.main(). The only useful place for that command is in boot.py.

@nervencid The attenuation setting change the input voltage range for the ADC. With ATTN_D its is 0-1V, with ATTN_11DB it is ~0-3V. The range of the numbers you read form the ADC is always 0-4095, only at a different input voltage. The factor associated with a dB attenuation number is 10**(dB_number/20). So for 0 it is 1, for 11 it is 3.548, for 6 it is 1.995

@robert-hh Hi, we don't officially support nb-iot in Pybytes yet. But it's on our roadmap for this year.

@arneme Yup. Thats Correct.

Experimenting with watchdogtimer (WDT) instead of or next to deepsleep: Using the WDT with infinite machine.deepsleep() : Get stuck after anumber of cycles just like timed deepsleeps. Combination of WDT (at boot) and deepsleep: The program seems to run forever. It now made over 14000cycles in 24 hours time. Output: ets Jun 8 2016 00:22:57 rst:0x7 (TG0WDT_SYS_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff8028,len:8 load:0x3fff8030,len:1984 load:0x4009fa00,len:0 load:0x4009fa00,len:19088 entry 0x400a05e4 Initializing filesystem as FatFS! wake 0 sleep: 14974, DS: 2805, WD: 12167 Weird observation: In 18.7% it waks from deepsleep(2000). In the majority of cases it wakes form WDT(5000). As the deepsleep is 3 seconds shorter in this test progam than the WDT, it should always wake form depesleep (100%) I guess there is some race condition in programming the wake timers. Any help is appreciated. Obviously this unpredictible behaviour is not giving sufficient reassurance to build a remote sensor that should be able to perform unattended for years.

Found a start of an answer here: https://forum.pycom.io/topic/3624/machine-pin_deepsleep_wakeup-function-is-not-working-in-lopy4-firmware-version-1-19-0-b2 Link to developemtn documentation on github: https://github.com/pycom/pycom-documentation/tree/development_release/firmwareapi/pycom/machine The method is renamed to pin_sleep_wakeup()

So I think I found my problem As I said in another post the problem wasn't in the software, but hardware. I don't use a expansion board, I use a ttl converter like this one https://www.ebay.com/itm/5V-3-3V-FTDI-FT232RL-USB-to-TTL-Serial-Converter-Adapter-Module-Arduino-Mini-Hot/182736917146 With this converter 3.3V is not enough to power on stably the board, so, I used it in 5V mode, but it seem that 5v for serial communication is ok for the python REPL, but have problem when flashing the modem or use the LTE modem. Finally, I changed my design by using another 5v power source, and use the ttl converter un 3v3 mode with common ground. And then it just works fine ;)

Hello @iwahdan, I put the LoRa Init after the LTE connection and it works now ! Thank you. Best Regards, Malo

@dnear1 said in Fipy issues with IF statements: ') Cleaned up and comments added import os import math from machine import UART uart = UART(1, 9600) # init with given baudrate uart.init(9600, bits=8, parity=None, stop=1) # init with given parameters #while True: # data = uart.readall() # if data is not None: # print(data) while 1: data = uart.readall()# get everything from the serial buffer if data is not None:#make sure it's not an empty buffer bytestream=data.split(b'BM')[1][0:31]# HPMA sends 32 byte packets that start with \x42\x4D ('BM') if len(bytestream)==30:#check that we actually got 30 bytes (excluding the data we split out) if bytestream[0:2]==b'\x00\x1c':#HPMA packet is always 28 data bytes(excluding start header and checksum) checksum=143#since split command removed the \x42\x4D, add them back to get correct checksum validated=0 for i in range(0,28): checksum+=bytestream[i]#cycle thru the data values and add them up validated=int(bytestream[28])*256+int(bytestream[29])#read checksum bytes from packet and make them a 2-byte integer if checksum==validated:# both values should match, else we have a corrupt packet pm25=int(bytestream[4])*256+int(bytestream[5])#these two bytes represent the particulate detected that's 2.5um large pm10=int(bytestream[6])*256+int(bytestream[7])#these two bytes represent the particulate detected that's 10um large print('pm2.5 = ',pm25) print('pm10 = ',pm10) else: print('checksum failed') else: print('invalid packet length') else: print('incomplete packet')

Hey Thanks for the reply. 1 - executing dfu-util-static.exe -D pytrack.dfu solves my problem each time without doing anything else before hand 2 - I only checked this in Device Manager, but nothing at all changed in any window, I'll check through command line or any other method you recommend when I get back to work on Monday. 3 - This is actually an assumption based on the fact that executing dfu-util-static.exe -D pytrack.dfu fixes the problem. I'm not sure how I could check this, maybe I'll try a different FiPy on top of the Pytrack although I don't see how that would change anything, I'll try whatever you think can verify this. I'm planning on putting out 20 + units for static tests in the coming weeks so I'll get a better idea of whats happening but it seems to only effect this particular board so I haven't been too worried.

@robert-hh Thanks for your reply, you have true. I searched components during the starting. And I comment this lines codes : #wlan = WLAN() #wlan.deinit() #bt = Bluetooth() #bt.deinit() #serveur_ftp = Server() #serveur_ftp.deinit() I don't test with each line only, but now it's working. I have fix coordinate when the Fipy powered by Lipo.

@jcaron Yes, and it works! Now I am trying to figure out where to put my module. In the ESP8266 version there is a file called ESP8266.ld which contains the list of C files. Where is the equivalent for ESP32? If there is no equivalent, what shall I look for?

@testos Yes, you need to connect to the external IO header below the fipy. And you have to specify these Pins, when you open the UART, most likely UART1. On a Fipy, two of the three UARTs are already used by the firmware UART0 and maybe UART2. You have to try.

@robert-hh OK, I set up some code to try this out, several timers at different periods and several threads including one to start LTE, send an SMS and then deinit. From what I can see, the timers do NOT get interupted by the LTE device. It seems the timer counts are retained and dumped to REPL as soon as possible (buffered apparently). There is some corruption/mixup of REPL lines but all the timer flags are there I will investigate a bit further and see if I can use this to my advantage. One thread/timer I will need will be at 11uS preferably, so as it is too fast to capture by eye, I'll have to write to a file to a file to evaluate any impact by the LTE device. Biggest constraint might be the actual time to write to disk. A FIFO data buffer is probably a good solution - some work to do there. The test code was pretty rough and ready so its needs a lot of refinement to be truly useful as a valid test.