I am very new to this sort of thing so any help would be appreciated. I've spent 2 days trying to correct the errors I'm getting but I am still having no luck. I am following this tutorial here http://www.themakersworkbench.com/tutorial/how-use-amazon-alexa-control-linknode-r4-esp8266-4-channel-relay-board. I am using the same cables he linked in the tutorial (://amzn.to/2h7PdEz) (usb to uart cable) (://amzn.to/2h7RDDf) (5v 2a power supply). I gathered the code from the link provided and updated it with the relevant information for it to connect to my wifi, other than that I made no changes to the code. (they wont let me put links in as this is my first post just add http to the front of the links)
The problem I am having is when I try to upload my code to the board its not working, the code compiles fine then encounters the error listed below. I'm sure this is something simple and I've scoured everywhere ensuring proper settings but im still unable to upload the code. I even tried the serial monitor at 115200 entering "AT" and getting the output `UC. Just to cover some of the basics i connected the tx to the rx on the board and the rx to the tx on the board, and ground to ground. The power is on and I can see the power led indicator lit, this is plugged directly into the wall. I downloaded 1.8.3 arduino ide and installed the ESP8266 board manager and I am using the generic version flash mode QIO at 115200 baud rate.
Thanks for taking the time to look at this and again I'm very new so please direct me in the right direction if this question has already been answered (I searched myself ALOT).
Arduino: 1.8.3 (Windows 10), Board: "Generic ESP8266 Module, 80 MHz, 40MHz, QIO, 115200, 512K (64K SPIFFS), ck, Disabled, None"
Build options changed, rebuilding all
Archiving built core (caching) in: C:\Users\Bro2D2\AppData\Local\Temp\arduino_cache_585316\core\core_esp8266_esp8266_generic_CpuFrequency_80,FlashFreq_40,FlashMode_qio,UploadSpeed_115200,FlashSize_512K64,ResetMethod_ck,Debug_Disabled,DebugLevel_None_____f179b2dc0cd843b50353b7c87d0452e9.a
Sketch uses 250081 bytes (57%) of program storage space. Maximum is 434160 bytes.
Global variables use 37816 bytes (46%) of dynamic memory, leaving 44104 bytes for local variables. Maximum is 81920 bytes.
C:\Users\Bro2D2\AppData\Local\Arduino15\packages\esp8266\tools\esptool\0.4.9/esptool.exe -vv -cd ck -cb 115200 -cp COM3 -ca 0x00000 -cf C:\Users\Bro2D2\AppData\Local\Temp\arduino_build_953054/wemos.ino.bin
esptool v0.4.9 - (c) 2014 Ch. Klippel <ck#atelier-klippel.de>
setting board to ck
setting baudrate from 115200 to 115200
setting port from COM1 to COM3
setting address from 0x00000000 to 0x00000000
espcomm_upload_file
espcomm_upload_mem
setting serial port timeouts to 1000 ms
opening bootloader
resetting board
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
serialport_receive_C0: E0 instead of C0
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
serialport_receive_C0: E0 instead of C0
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
serialport_receive_C0: E0 instead of C0
resetting board
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
serialport_receive_C0: E0 instead of C0
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
serialport_receive_C0: E0 instead of C0
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
serialport_receive_C0: E0 instead of C0
resetting board
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
serialport_receive_C0: E0 instead of C0
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
serialport_receive_C0: E0 instead of C0
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
serialport_receive_C0: E0 instead of C0
warning: espcomm_sync failed
error: espcomm_open failed
error: espcomm_upload_mem failed
error: espcomm_upload_mem failed
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
I don't know how to fix your specific problem, but I was running into the same error and ultimately it was the drivers for my usb cord. I believe the drivers for your cord can be found here.
Related
I'm trying to analyse my Sniffer Capture and to get information about the STA, who sends deauth packets. Actually I'm doing it with my laptop and my AP to test my WLAN security
aireplay-ng [wlan inteface] --deauth 1000 -a {BSSID}
But where in this wireshark capture should I look for the MAC Adress from the station who sends deauth packets (my laptop)? All I can see here, it's like my AP sends packets to himself. Maybe it's a silly question, but I do not get it.
You send deauth to broadcast if command is used like this:
aireplay-ng [wlan inteface] --deauth 1000 -a {BSSID}
When this command is running from the laptop, packets will be sent with the AP address of the point specified in the "-a" option:
Source address = Transmitter Address = AP BSSID
Explanation of addresses:
Receiver Address: immediate recipient of the frame
Destination Address: final recipient of the data
Transmitter Address: STA that transmitted the frame
Source Address: source of the data
I was testing my Ethernet connection on my i.MX6 Board in u-boot
I used the following commands:
setenv ipaddr xx.xx.xx.xx
setenv serverip xx.xx.xx.xx
setenv netmask xx.xx.xx.xx
setenv gatewayip xx.xx.xx.xx
setenv ethaddr xx:xx:xx:xx:xx:xx
When I do a ping to my address it fails
=> ping xx.xx.xx.xx
Using FEC device
ARP Retry count exceeded; starting again
ARP Retry count exceeded; starting again
=> mii info
PHY 0x00: OUI = 0x209A, Model = 0x01, Rev = 0x00, 100baseT, FDX
=> mii dump 0 0
0. (3100) -- PHY control register --
(8000:0000) 0.15 = 0 reset
(4000:0000) 0.14 = 0 loopback
(2040:2000) 0. 6,13 = b01 speed selection = 100 Mbps
(1000:1000) 0.12 = 1 A/N enable
(0800:0000) 0.11 = 0 power-down
(0400:0000) 0.10 = 0 isolate
(0200:0000) 0. 9 = 0 restart A/N
(0100:0100) 0. 8 = 1 duplex = full
(0080:0000) 0. 7 = 0 collision test enable
(003f:0000) 0. 5- 0 = 0 (reserved)
What can be the error. I have seen in NXP Website, that fake MAC Address will not work with ping.. How to make it work..
First of all, we need to check whether the MAC address is properly written into H/W register, i.e. basically SpecAdd1top and SpecAdd1bottom registers (which holds the MAC address). Read the value of these 2 registers and whether they are perfectly matching with assigned MAC address or not.
Need to verify whether ARP request is reaching on server PC by running Wireshark on server side PC. If it is reaching, then it's not getting ARP response to target board within its ARP timeout timing is 5 ms. It seems like ARP request is not reaching to the server side, which means it is not sending ARP request properly.
Check the ENET MAC successfully sending ARP request or not from the u-boot ethernet MAC driver.
Increase the ARP timeout time from 5ms to some more ms.
Use wireshark or tcpdump to validate what is actually happening on the "wire". As modern ethernet is switched you need to find a way to actually see that particular ethernet segment. This is easy if your device is connected via a cross over cable and you have your laptop on the other side. Otherwise you might have to configure your switch so it copies traffic from a certain port to the port where your laptop is attached.
You might want to setup the network adapter using the dhcp command instead of using setenv.
Using dhcp you verify that you have a working network connection and you can display the correct values for the environment variables that you are currently setting manually using printenv.
If a basic ping doesn't work with a static IP address, what makes you think a DHCP request has a better chance of success?
Static addresses can be set up incorrectly. E.g. if the wrong gateway or network mask is specified you may not be able to ping a target.
Question update: In addition to the problem below, it seems our client/server application using the Linux PLPMTUD mechanism gets too large path MTU. Has anyone seen this, i.e. actual path MTU being 1500, but getsockopt() w TCP_MAXSEG returning the MTU:s of the endpoints, in our case 3000? I have tried turning of GRO, GSO and TSO with ethtool but the error persists. Normal ping only manages to push through packets 1472 bytes or smaller. Also worth mentioning is that PLPMTUD works perfectly for smaller MTU:s. For example, w endpoints at 1500 MTU and one interface of the intermediate router set to e.g 1200 MTU, the kernel TCP probes and reports correct TCP_MAXSEG (1200 - headers).
I am using the Linux RFC4821-compliant packetization layer path MTU discovery in an application. Basically, the client does a setsockopt on a TCP socket:
setsockopt(fd, SOL_IP, IP_MTU_DISCOVER, &sopt, sizeof(sopt));
with option value set to IP_PMTUDISC_PROBE. The setsockopt() does not return an error.
The client sends large tcp packets to a discard server, and the path MTU is calibrated by Linux kernel - tcpdump shows tcp packets with DF bit set being sent, packet size varies until the kernel knows the path MTU. However, to get this to work in the other direction (listening server accept:ing connections from clients, sending data and calibrating PMTU in direction from server to client) I have to set the global option for tcp path mtu discovery, /proc/sys/net/ipv4/tcp_mtu_probing. If I do not, server will stupidly continue to send too large packets, which get discarded by an intermediate router without ICMP sent back. Both endpoints have an MTU set to 3000, while the intermediate hops have MTU 1500.
I hope someone has an idea on what goes wrong. If more info is needed, let me know and I edit the question. Problems exist on both Linux kernel 4.2.0 and 3.19.0, both are stock Kubuntu LTS kernels. (x86/x86-64)
I do set the same socket option server-side as well, on all accept:ed sockets, before sending data in reverse direction.
FWIW, I have found workarounds/solutions for the problems, will do more testing but shortly describe my findings here, in case it helps someone else.
The problem with not being able to set path mtu discovery per socket was fixed, brute force, by enabling it system-wide during execution of my program, then disabling again.
The second problem, of incorrect path mtu returned by getsockopt TCP_MAXSEG, was fixed by waiting for TCP ACK of sent TCP data, also using getsockopt (tcp_info.tcpi_unacked). That way, I can be sure that probing has finished before I get TCP_MAXSEG.
Finally, there was a patchset for improving path mtu probing accuracy merged to mainline Linux kernel in March 2015. Without those patches, the probing is very imprecise. Patchset is part of 4.1.y-series kernels and onward.
What I want to do
I need to test the presence and status of a GPS module on a specific serial port
/dev/ttyS2
but I can't find any command that do so.
Additionnal informations
I'm running on a fedora 15 distro.
I can successfully launch a gps daemon with
gpsd -G -n /dev/ttyS2
and check the daemon informations with
cgps
Everything is fine with the values returned (my module is alive and connected). However, this command doesn't allow an external program to easily check if it's working as it should.
Any suggestions? Thanks !
Write a program (inside the external program) that connects with the specified serial port and baud rate.
Asuming the GPS chip is configured to send in NMEA format via the serial port,
you will receive NMEA sentences once a second.
Each such NMEA line starts with $GP (for GPS chips).
If you receive that then the chip is working.
To receive more detailed configuration settings, you have to read the manual of the GPS chip manufacturer.
I want to send some commands to my RN42 Bluetooth Module over the serial port using hterm. But i does not respond. I can connect to the bluetooth modul and the status LED blinks right.
I tried to send $$$ to change to command mode (modul should respond with cmd but does nothing) and 0x00 to disconnect.
Do you guys know what could be wrong?
A couple things that I have run into that you could try:
Ensure that the baud rate of hterm is set to the default 115k
Depending on the firmware version of the RN42 you may have to enter command mode within a one minute time frame. Try power cycling the module and sending the $$$ as soon as possible