The Pass to IP Layer .... string is generated into lwip library. I've added that string into the ethernet.c file that is part of the lwip library. I've built the wifi/scan project and then substituted the lwip.a file into the pycom-micropython project. The code used to generate that strings is something like this LWIP_DEBUGF(ETHARP_DEBUG, ("Pass to IP Layer \n")); Of course i've changed the ETHARP_DEBUG value from LWIP_DBG_OFF to LWIP_DBG_ON into lwipopts.h header file in order to enable the ETHARP DEBUG. The TCP - _send_receive ... string is generated at level application. I'm using a TCP Modbus external python library. I've added the following code into the library print('TCP - _send_receive - Receive %s' % response) The application (and the modbus tcp library of course) is frozen into the final build and then uploaded through pycom firmware update tool. TCP Modbus messages are managed from a manager that runs as a python thread. The log output is got from USB interface.

hi peeps I am super frustrated as Pycom is not responding to any messages about the problems of getting PyMesh running. Has anyone had success with this in recent weeks? I really need to get this running and Pycom have been essential silent in response to my questions for the last 2 months. I would really love some help from someone who has got this running - we want to train it to do species call recognition in the field. thanks in advance Garth

@techykermit You have to increase the partition sizes. There are two places which you have to change in the tools directory.: a) tools/size_chk.sh: line 14 has the limit for the image size. b) tools/script_8MB: That is the template for the partition table. Each entry contains the start and the size. Note that otadata sits between the factory and ota_0 partitions. If you change the partitions, the file system will have to be rebuilt. I do not know whether the encryption keys are affected. But there is a good chance that changing the partitions does not affect the encryption keys.

Hi @livius, thank you for pointing that out. Yes I had been running on RaspberryPi thinking it would be better than running on a substystem for Linux. I was initially struggling with using Windows Subsystem for Linux (WSL) and following the instructions listed on github. I had extracted the xtensa gcc compiler tar.gz file incorrectly, by using WinRAR onto my Ubuntu file system - this must've corrupted some of the data. This time, I copied the tar.gz file into the Ubuntu file system and extracted it using Linux commands, the process had run smoothly and I was able to build a binary file. Thank you very much!

@Gusti-Made-Arya-Wijaya As far as I recall, I used an indirect method with a sine wave generator, and oscilloscope and a HV probe with a known low capacity. So I built a RC-Circuit, with the known R and C being the addition of the probe C_probe and the board C_board. Then I could estimate via the relation amplitude at C over Frequency the value of C_board.

@mrks-tsk The capacitor has to be placed between ADC input and GND. In your diagram at the VBATT side.

@timh Hi, any chance that you have some examples for this? I tried the class that you linked, but its also calls i2cdev which from my research is made for a rasp pi? Thanks

The most recent post concernign ULP is here: https://forum.pycom.io/topic/7026/ulp-testing-pycom-firmware-with-ulp-support. From what I know we're still interested in implementing this feature, but again, we're interested in implementing a lot of features, with only limited time :)

@MarcosC Since you cannot read both outputs at the same time, you could as well simply use just one output from the AD7606, Output A. I would go for this one. As far as I understand the data sheet, you will read the data of outputB at outputA too. They just follow the first data set. That seems to be the easiest and fastest method.

@danielm Did you ever get an answer to WHY 'AT+CESQ' fails to return: RECEIVED SIGNAL STRENGTH LEVEL CHANNEL BIT ERROR RATE RECEIVED SINGAL CODE POWER RATIO OF RECEIVED ENERGY i.e. the first 4 parameters in the command?

@Andrew-Sinclair said in Problem on updating Expansion board V3.1: This worked for me on mac catalina brew unlink libusb brew unlink dfu-util brew install libusb --HEAD brew install dfu-util --HEAD using my old macAir with HighSiera, this solved the problem I had to 'brew uninstal'l the packages, unlink was not enough. libusb was installed with an extra patch. ==> Installing dependencies for libusb: m4, autoconf, automake and libtool ==> Installing libusb dependency: m4 ==> Patching ==> Applying secure_snprintf.patch patching file lib/vasnprintf.c Hunk #1 succeeded at 4858 (offset -11 lines). ==> ./configure --prefix=/usr/local/Cellar/m4/1.4.18 libusb: stable 1.0.24, HEAD dfu-util installed without problems and the result is: Rainers-MacBook-Air% dfu-util -D pysense_0.0.8.dfu dfu-util 0.10-dev Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2021 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ Match vendor ID from file: 04d8 Match product ID from file: f011 Deducing device DFU version from functional descriptor length Opening DFU capable USB device... Device ID 04d8:f011 Device DFU version 0100 Claiming USB DFU (Run-Time) Interface... Setting Alternate Interface zero... Determining device status... DFU state(2) = dfuIDLE, status(0) = No error condition is present dfu-util: WARNING: Device already in DFU mode? (bState=2 dfuIDLE) Claiming USB DFU Interface... Setting Alternate Interface #0 ... Determining device status... DFU state(2) = dfuIDLE, status(0) = No error condition is present DFU mode device DFU version 0100 Device returned transfer size 64 Copying data from PC to DFU device Download [=========================] 100% 16384 bytes Download done. DFU state(2) = dfuIDLE, status(0) = No error condition is present Done!

Me too, same issue. It is possible that Pycom is not aswering on this??

All the examples in the documentation should work on all devices (excluding the network examples that are not available on the GPy of course) As for the text messages, first, you'll have to get a carrier that supports text messages (SMS) over NB-IoT or CAT-M1 (they exist, and around the office I've seen it work in the past, not exactly sure how it works with the phonenumbers though) In the AT manual, https://docs.pycom.io/gitbook/assets/Monarch-LR5110-ATCmdRefMan-rev6_noConfidential.pdf, around section 6, there is a whole bunch of AT commands listed related to SMS. This is not built-in micropython functionality directly, as its not common to go the SMS route, but for farmes I get that you want to make it as convenient as possible. You can send the commands using lte.send_at_cmd('...') from the LTE api

@lmerza said in updating firmware remotely: r7 because our pycom devices are in remote places not easily accessible. firmware versions above that introduced the littlefs files system which would reformat the flash. We can update firmware remotely but if the files on the pycom were erased from a reformat then the remote device is lost. there will be no code to connect to the LTE much less add the files back that were lost in the reformat. I dont see a possible way to update the firmware with littlefs if you cannot get to a device. Is there a possible way to update to the latest firmware without formatting to littlefs? Unless its not working or not stable, I would honestly not recommend upgrading the firmware just in case it causes some other issues that would force you to physically retrieve the devices to fix them. From what I have seen, these firmware updates are more than just bug fixes, and could cause more harm than good to a system that is working fine if you aren't able to test and debug it.