Hey. What issue are you having? Is it failing to attach, or attaching but failing to make any external connections?

@shedaim I'd agree with @robert-hh. Such "test points" are often incorporated into a PCB for automatic testing during production. Most boards pass through an automatic testing stage during manufacture and at that time it can be "pressed down" onto a jig that makes contact with these test points and allows for full testing and quite often the loading of any boot code required. Here are some similar looking test points inside, of all things, and electric toothbrush. Note that they have helpfully labelled a lot of the test points on the silkscreen (Hint hint, Pycom)

@stevo52 Yes, from the distance, it sounds like a hardware problem with the board. Maybe a broken wire or a bad solder point at the P2 pin.

@elizar I wouldn't have expected it since the Putty output looked fine, but it does appear to be issues related to poor signal quality. I took the breadboard out of the loop and attached the FTDI headers directly to the board headers with Molex cables and the flash finally took! Thanks for the suggestion!

Hi, I am currently working on development board with ESP32-WROVER and Quectel BC66 NB-IoT module. BC66 module contains MTK2625 modem. Not sure if this might help you somehow. https://forum.micropython.org/viewtopic.php?f=18&t=5778

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

Hi Drop an email to sales@pycom.io with the details :)

@robert-hh I used the large hammer as per your suggestion & load user software as main.py with the boot.py below. import machine, pycom red=0x7f0000; green=0x007f00; orange=0xff5100; blue=0x00007f; off=0x000000; white=0x7f7f7f; magenta=0x7f007f; cyan=0x007f7f; lowhite=(0x101010); yellow=(0x7f5100) hook='main.py' print('trying for', hook) pycom.heartbeat(False) pycom.rgbled(white) cycle=pycom.nvs_get('cycleboot'); cycle+=1; pycom.nvs_set('cycleboot', cycle) wdt=machine.WDT(timeout=20000) # 20s for main.py to run & extend the wdt timeout machine.main(hook) Because there are independent cycle counters in main.py & boot.py I can see how often boot.py fails to run main.py Timestamp observed Timestamp received Value 2019-01-17 8:24 AM 2019-01-17 8:24 AM 1 cycle boot fail found @ cycle 161 2019-01-17 1:17 AM 2019-01-17 1:17 AM 1 cycle boot fail found @ cycle 87 Results much as before

From the pycom module documentation : "pycom.nvs_erase_all() Erase the entire NVRAM memory area." AFAIK, there is no way to see all of the contents of nvram on ESP32/Pycom boards.

@kjm upip is meant to install (micro)python packages on a micropython device. So it downloads and extracts micropython packages. You have to tell yourself whether it is useful for you. But at least it is a good example. Paul is an excellent Python specialist and programmer. There is a upip.help() telling how to use it. And upip.tarfile is, as far as I understand it, the tarfile extractor.

@robert-hh said in AT cmd for band or frequency: http://niviuk.free.fr/lte_band.php thnx Rob

An effort to bring all documentation inline is ongoing at the moment and things should be clearer going forward. We are aware of a few conflicting pieces of information that need clearing up. Ill pass along the feedback about schematics being made available to the public.

@reidfo No I've got everything in try/except loops so it can't crash. This is always when it wakes from deepsleep, instead of running boot or main .py it jumps into dreaded 4s blue flash mode. Grim!

@paul-thornton There it is. Thanks.

@kjm So you are averaging over 1000 values. You can also use a low pass filter, which is a little bit simpler See also the lessons and analysis by Bernd Boser: https://github.com/bboser/IoT49 and especially https://github.com/bboser/IoT49/blob/master/doc/analog_io.md which shows a noise of about 25 LSB. So your averaging of 1024 values (25*25=625) matches that. B.t.w: good ADCs have a noise <= 1 LSB.

Hi @kevin, From the Southern of Sweden - via Telia's NB-IOT Network - I get this: >>> send_at_cmd_pretty('AT+SQNHPLMN?') +SQNHPLMN: "23820","23820","23820" OK >>> and for you who would like to look it up: http://www.numberportabilitylookup.com/networks?s=

I'm going to let someone who actually works at pycom answer licensing related questions other than pointing you at https://pycom.io/licensing/ . Hey @Paul-Thornton .