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

@cmrosero I realize this is an old post but did you ever figure out how to attach Gpy to OAI network?

@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 Thanks for the reply! So basically an unstable power supply can lead to flash errors. Good to know. (And you had it, I was using a Li-Ion 3.6V battery. I'll make sure to mention that next time)

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 .

@curtis-hendrix I have no spec but I once tried to connect a small LCD display to that power pin. That was an instructive failiure. Even 400 mA is optimistic (may only be reachable at the limit of 5.5 V Gpy supply). You can safely use that 3.3 V pin to supply some I²C chips but nothing that needs power.