@josua Glad you got it working by doing the firmware upgrade procedure again

Actually I did not find one which would suit. Theer are plenty at any quality for the acquiring side, but no device buffers the output, and that is the same problem you have with the internal ADC - accepting and handling the data in real time w/o any loss. Even if you limit the bandwith to e.g. 5 kHz, you have to process 10k samples per channel. at least.

@livius Great that is working. I believe it is something nasty/delays with the Win10 routing table. Careful on closed loop: if you have your laptop wired/lan connected on the same Wifi router and your laptop connected to WiPy.

@michalt38 to do this you need run Wipy in mode WLAN.STA_AP but for me it can connect to router but i can not connect to it as AP. But i do not tested this in the current firmware - maybe it work now

@robert-hh Yes, it's important what Robert writes! The kind of connection--and IP(!!)--is related to the network the WiPy is connected. In case the WiPy is started default it will start as access point. In this case the IP is 192.168.1.1 In case you have connected the WiPy to a home network and the WiPy is now a station and not an access point any more, the device gets the IP from the network. I had a look at my Fritz box dashboard and could so figure out the IP but I think you can also gather the IP via a serial connection?

@sledge That's true unfortunatelly for the "raw" Py boards also because they have no input number on the PCB also. ;-) And--it is really a bit dangerous--the old version had a 180° rotated label with the pycom writing. So in case you garb the first picutre you get on google it is the wrong, old one and you feed your Py on the wrong side and pins with power. Luckily all is still working but it could also go bad ... So yes, an "origin" fritzing part would be nice, but dealing with standard parts is better then waiting. ;-)

@pchirouze no, it should be: https://docs.pycom.io/pycom_esp32/library/machine.WDT.html

Maybe this can help you! http://forum.micropython.org/viewtopic.php?f=11&t=1228

@gertjanvanhethof The '.pem' is more a convention in my office of labeling all certificate related files with that file type. It is the rootCA certificate. I've been able to use the same certificate files to connect to AWS MQTT via a desktop client, so it shouldn't be an issue on the cloud side.

@robert-hh Hey Robert, Big thanks for all those ideas!!. I have completed upgrade in Win 7 so definetily WiPy is OK. I am executing "dialog" with superuser terminal, however I am not sure if udev might cause the issue, my Linux knowledge is not that deep. exciting to dig on udev rules as well mate!! Note: I will give a go to use the picocom a go, so as to learn more Cheers again ColombianAus

@livius and it works fine I copy the file from ftp client NB: I did the upgrade to 1.6.x

@acheesehead Correct, GPIO4 (P3 on the WiPy) is one of the 6 "strapping pins" on the ESP32 you need to be aware of when booting. P9 • MTDI/GPIO12: internal pull-down P2 • GPIO0: internal pull-up P8 • GPIO2: internal pull-down P3 • GPIO4: internal pull-down P4 • MTDO/GPIO15: internal pull-up P5 • GPIO5: internal pull-up https://espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf#page16 P3 in particular seems to trigger a chip test mode

@sk said in Detecting a device's Hotspot: updated my Sipy last wednesday, so it should all be up to date. check version by calling os.uname()

Hello @katesfb, I do not know using WiPy1 with pymakr over USB. I tried it shortly with WiFi, but I had to modify pymakr to get it working. Pymakr as a product is about to be abandoned, so do not expect any further support. It seems that most people just give it a try and then use other methods. Resolving the USB error depends on the operating system you use. Since you mention screen, it seems to be OS X or Linux. The error indicates that you either specified the wrong port or pymakr is not allowed to use it. WiPy will also not appear as flash drive. For file exchange, you have to use ftp or other tools which use the USB/REPL connection like ampy, rshell, mpfshell.

@daniel I just test this and the behaviour is still as before. Trying to initialize the SD card without a SD inserted raises a OSError exception, which is OK. my English is bad and when i wrote Something was changed. than this was only assumption - i do not test this with current 1.6.3 firmware i tested this on 1.5.0 and it worked - and if for @kanu it does not work then i supposed that he tested this with current firmware Card detection is simply done via a GPIO pin good point - i must connect it :)

Good Day, I have exactly the same issue as pchirouze. I tried to upgrade the WiPy firmware as on the /gettingstarted instructions. Unfortunately, this made the WiPy unusable. When I start up the device, the red heartbeat light just stays on. Even if I do a factory reset (3.3V to Pin28) the heartbeat light flashes for 3 seconds, then faster for another 3 seconds, then even faster for another 1.5 seconds. Then the static red heartbeat light goes on again. Ive searched forums and asked around. My Dealer said I should contact you. Please can you help me. I was going to prototype a new alarm system (specifically for South African Homes) using this device, but with its failure I had to switch over to Raspberry Pi.

Bump - anyone else seen this, or something similar? Pete