@eric-waai Yes, I know this promise. I already registered, but it' s not there yet. Sequans may not have provided the firmware yet, and Pycom did not start with the device replacement yet.

@rskoniec The typos have been fixed in the docs and the firmware will have the extra R removed in the next release, thanks for reporting this.

@seb I wasn't aware of github releases, this is ok for me. Regarding vscode, I installed without problems so far, running correctly but pylint is always complaining (although the firmware works). I'm new to micropython and don't know if I must download the entire firmware and place it somewhere.. or steps needed to correctly setup my dev environment in order to activate code completion and linter (if both are possible).

@robert-hh I was thinking about that however I am not aware of a straightforward way how individual parameters could be updated by the application. The script would be frozen anyway. I was also thinking to move all parameters to NVS however the config also contains few strings which are not directly supported by the NVS right now. I think that the best solution will be to put default parameter values into Python script which will be frozen during build process. After boot it will be tested if NVS contains "init" flag and if not an initialization method will be called. Within this method individual parameters will be loaded from Python script to a dictionary which will then be dumped into json file stored in the internal file system. This will happen only during first boot after last firmware flashing.

@agotsis said in AT commands for FiPy cellular modem: https://docs.pycom.io/datasheets/development/fipy/ Thanks for the pointer.

@seb It's my bad. I have missed that service was listening just on localhost, that's why I was not able to receive any file.

address 0x08 in the PIC microcontroller on the Pytrack/sense so it is supposed to be there. When I tested this out on a LoPy4 with the latest firmware and a Pytrack with the latest firmware it worked fine the first time. So are you completely unable to talk to the PIC without errors?

@robert-hh Yes, i have seen it before. Great work :) But it require to store somewhere font in particular size. This is simple alternative.

Thank you for your insight @xykon, I read your command and it came up to my mind. I wasn't using "sudo" and either I have a special group for handling serial connections in this computer. So you gave me the solution, I didn't add a dialout group but I just used sudo to run the app. Running one of the tools with sudo made the trick: $ sudo ./update Thank you again for your help. I will mark this thread as solved (if I can). Regards and have a great friday! Javier

@daniel @Xykon I also updated to the latest version but sigfox is not working. Do you have any idea what could be the reason? Is it bricked?

$ wget https://software.pycom.io/key=wipy.wipy with esp32&redirect=false&type=all [1] 8582 [2] 8583 $ --2018-01-07 09:41:37-- https://software.pycom.io/key=wipy.wipy with esp32 Auflösen des Hostnamens »software.pycom.io (software.pycom.io)« … 18.218.9.81 Verbindungsaufbau zu software.pycom.io (software.pycom.io)|18.218.9.81|:443 … verbunden. HTTP-Anforderung gesendet, auf Antwort wird gewartet … 404 Not Found 2018-01-07 09:41:39 FEHLER 404: Not Found.

@daniel Wipy2 I give another try with recent software compared to 1.7.2.b1 {which is stablest for me for wipy2}. After flash (today): connection to router give me timeout (30seconds) but if i ignore this i can connect to the socket in the network - i use static ip setting. i2c (i2c=I2C(0, I2C.MASTER, baudrate=100000, pins=("P9", "P10"))) bh1750 ok, pcf8574 ok read from bmp180 read only 0 for preasure but temperature is ok flashed 3 times and tested 30 times with removing cables (5 times and also simple reset 5 for every flash). downgraded to 1.7.2.b1 all work ok. I must bring back my logic analyser to see issue on i2c but maybe you have some hint here? And also what can be the reason of issue from point 1?

@seb A) FiPy+PyTrack+LiPo-Battery (Not-Attached-to-USB3.0) 
Vin = 4.09~4.10 V 3V3 = 3.32 V B) PyTrack+USB-Serial-device (Attached-to—USB3.0) same port as A)
 Vin = 4.85 V 3V3 = 0.23 V C) PyTrack+USB-Serial-device (Attached-to—USB3.0) + Hotswap-in-FiPy same port as A) & B)
 Vin = 4.55 V 3V3 = 3.32 V D) PyTrack+FiPy+NO-USB-Serial-device (Attached-to—USB3.0) same port as A) & B) & C) same combo as C) Just unplugged USB from PyTrack, and re-attached it…
 Vin = 1.69~2.51 V 3V3 = 1.15~1.91 V Also, worth nothing is that if my hand slips with the measuring probes, I get it to “boot-up” by accidentally shorting GROUND & 3V3, and I get a USB-Serial-Devices on my computer [ergo like A), B) & C) …] … And then, I get the same Vin & 3V3 as C) Which makes me conclude that you’ve guys have a Firmware issue!!! … and not a “bad usb-cable” or “bad usb-port” … etc etc. For some reason, in the boot-sequence of the PyTrack Firmware, it choose not to boot-up FiPy and enable USB-Serial … And, again, it’s odd that I can short GROUND & 3V3 with my measuring probes, and then it boots up FiPy and enables USB-Serial…

Hi @smeedy, We should have NB-IoT news around middle of January (next month).

@marto Hi thanks for pointing that you, you are correct the updater tool only shows instructions for the expansion board at the moment. I have passed this on and it should hopefully be changed soon. I will now remove the text about carefully reading the updater instructions because that clearly caused confusion. I will also pass on your OS details so make sure it gets investigated at the same time as the Mac OS issues.

@Smeedy it will be available in a new release today or tomorrow.

We're hoping to use Telstra Australia

Hi @mongkol, so you have this error every time you try to update? Or just once in a while? I would suspect the PC USB port to be the problem, you could: change the USB-microUSB cable use the PC direct USB port, not thru a USB hub; remove other USB peripherals from PC The firmware update packages are sent over DFU protocol, which runs over USB bulk transfer channel, it might happen that the CRC of a package was wrong (or delayed).