First of all, I won't go into details, cause there are a lot of them, and I dont want to write (a too long) essay. There is TL;DR section at the end, because I have a specific question, but maybe some additional info can help.
I have a device that is made of a GRU (glass room unit) and espressif (esp8266).
GRU and esp8266 communicate via serial, with GRU as master. GRU is programmed with an internal tool, and I can monitor everything on it, including the info it gets from esp8266.
There is a test/development device, that has espressif on top of the GRU, so I can easily take it off, reprogram/reconfigure it, and put it on.
Espressif is inside of a GRU, and downloading stuff to flash is a real pain. There is whole process including a OS switch (from Win7 to Linux and back). Console output on espressif cannot be done, or at least not in the time frame I have.
For esp8266 I use non-os SDK V2.0.0_16_08_10.
Espressif can be configured with downloading a configuration to flash, or via UDP (over a network if connected, over its AP if its not connected).
Algorithm for Wifi:
1. Try to connect to a network from configuration
2. If it succeeds, raise a flag for that
3. If it fails, enter dual (STATION+AP) mode and raise a flag for that
The reason espressif is not always in dual mode is that it affects multi-cast operations.
Configuration over network is done by a Java aplication I wrote.
Scenario 1
I've configured a wifi router, configured all (x19) of the devices (espressif in devices that is) to connect to its network. When I turned them on, they would connect one by one. The ones that didn't entered dual mode and could be configured via the app.
All well.
Scenario 2
I've wanted to test the system in real world, so I reconfigured them to connect to the our firms network. Additionally when I was already going thru the whole process I've downloaded latest firmare to flash.
I expected that they would connect or enter dual mode and create their own APs. But they did not.
I tested then the code and configuration on espressif whose console output I could monitor, and everything worked.
I tested then the code and configuration on the test device, and it worked again.
I've then redownloaded the code and configuration to one device, and it didn't work.
TL;DR
I have two devices, espressif on a GRU and espressif inside of a GRU. Both connected to one network. Esp on a GRU work for another, Esp inside of a GRU doesn't work for that other network.
They have identical code and configuration, so it shouldn't be a software issue.
Does having espressif inside of a device jams its signal enough that it can't go trough? Device is not big (5x5x2cm).
UPDATE 1:
While I was writing, the espressif inside of a GRU managed to connect to network. I then restarted it so I can check that it can do it again, and it can't connect again.
It took me about 10 minutes to write the whole question.
There are two things that seem to have caused the problem.
When I removed gpio_init(), network stuff became faster, much much faster. Everything on it, connecting to AP, creating AP etc...
I've changed my config and wifi code, so that it now stores the ap and station config to flash via API.
I only check if its internal config is the same as mine from flash. If it isn't, it saves it. Now, I only control the current opmode.
Related
My work involves interacting with legacy hardware that uses serial ports. I often have to monitor more than one serial line, and for the purpose I have a couple of the common USB serial adaptors. When I connect both of them to the same (Windows 10) machine, irregularities show up. Both ports show up in device manager, but only the first one that I plug in to the USB connector works. The other one indicates port not open when I try to send data via RealTerm.
I have also seen the situation where when I plug the second adaptor in, its port comes up, but the one for the other adaptor disappears. Does anyone know a way that two devices can happily coexist on the one machine? Thanks in advance.
Just ion case this helps anyone in the future......
The problem seems to be caused by the fact that one of the adaptors was coming in via a (powered) USB hub. When I liberated another native port on the machine so I could host both serial adaptors directly, everything worked fine.
Not worth hunting the cause down, a solution is at hand.
I'm really having trouble connecting to my ESP8266. I was working with this setup for long time now and I didn't have to flash my boards. Now after having to use a different wifi i needed to flash the board. After doing the following
Updating to the newest ConfigurableFirmata
Using FirmataBuilder to download fitting firmata
Uploading the Firmata to the ESP8266
I can't connect via Johnny-Five anymore (getting the usual timeout error). I couldn't narrow down what it exaclty is (and I have been trying all day) but these are things that I have noticed (Using ConfigurableFirmata directly as well as using firmatabuilder and StandardWifiFirmata, all with the same behaviour)
an open Hotspot gets created even though I'm in Client Mode
when scanning for ports I do find the Module connected to my Wifi (Serial Monitor in Debug tells me the same too) but no open port is found, even though it's specified in the firmata.
I just can't narrow down the reason. I hope you guys can.
OK,
this was a simple user mistake. But since I lost a whole day searching for the error and I think others might too, I'll share my mistake here.
As I pointed out I created the Firmata as Client (thinking its a client to my Hotspot). But you will have to create it as a server (as you want to connect to the board)
It's as simple as that. If you are on http://firmatabuilder.com/ make sure you choose TCP Server if you want to connect to your board.
I am controlling a device over serial connection using LabVIEW (version 7.0). It is connected using USB, and is installed as a virtual serial port on the computer (running Windows XP). Every now and then my device crashes when my program sends a command, and it is unable to accept any more input (the device itself also stops working) until it has timed out.
I've looked at the serial port traffic using Portmon. Whenever the device crashes the serial driver sends the command I send using my program four times instead of just once, with an IOCTL_SERIAL_GET_COMMSTATUS command in between. I cannot see what this last command returns, but I assume something happens in the communication earlier on. I'm thinking my configuration of the port is not entirely right, but I have no idea how or why. I open and close the connection to my device every time I want to write something to it.
For completeness' sake: it has a baud rate of 9600, 8 bits, no parity, 1 stop bit, and no flow control. I'm aware that the correct settings of these parameters depend on the device, but the manufacturer has not supplied any recommended settings.
The driver is a DLL of some sort? If so, this is the most likely source of your problem, and you likely will need to contact the author of the driver. LabVIEW does have crashing bugs, but by far the most common source of crashes in simple communications apps is a buggy third-party DLL.
In other words, I doubt this is a LabVIEW problem at all and that you would have the same difficulty if you wrote a C program to talk to this driver. I only know what you've posted here about your system, but after many years of chasing down such issues, I would start with the device manufacturer/driver author.
If you have evidence to the contrary, please share.
I have a Microsoft Surface Book that I've dual booted Linux Mint on. I'm writing a program that needs to read in data from a serial port, but my serial ports don't seem to be working. The behavior is consistent across Mint and Windows (Testing done through Cygwin). It gets a bit of data the first 2-5 seconds that the device is plugged in (viewing the data through screen, same thing happens if I just use pyserial to print data incoming from serial port), then nothing.
What could be happening? I think I've isolated the problem to the serial ports - the Surface Book has 2 USB ports and the same thing happens on both of them, and I've tested the hardware that I'm plugging into it on 2 other computers (One Linux and one Mac OS), and it works fine on both of those.
Your MS Surface, seemingly, has a yellow triangle exclamation mark icon (over the adapter icon) without any driver to install/download. And properties in the device status box window say This device cannot start. (Code 10) or A device which does not exist was specified. Right?
If it's so you should wait for an update from MS. It's notorious problem.
I ended up getting the computer replaced on warranty for an unrelated issue months later, and what do you know, on the new computer the serial ports work fine. That indicates to me some sort of hardware problem, given that the issue persisted across OS's.
maybe this will help:
see Arduino examples for serial port communication - search google:
arduino serial c++
arduino serial c#
arduino serial c++ linux
the point is to open port properly you need to open a file, not a port. not with usual c - assembly write to port code.
another option you are using an unintentionally bought fake USB to serial cable with a Fake PL2303 chip
then you need to install the old version of the driver.
search in google:
Fake PL2303 + your os name:
install driver Fake PL2303 windows 10
another option is maybe it conserves energy and closes the port because it feels it is unused.
in windows> device manager,> properties of a device - usually USB root hub > power management - allow the computer to turn off this device to save power - uncheck it.
https://superuser.com/questions/408683/why-my-usb-mouse-gets-suspended-after-3-seconds-of-inactivity
https://blogs.msdn.microsoft.com/usbcoreblog/2013/11/08/help-after-installing-windows-8-1-my-usb-device-doesnt-charge-or-it-disconnects-and-reconnects-frequently/
also, you could look in windows events - to see what happens. usually, failures like this are registered in the events log.
an unlikely option is it consumes too much current, like a short circuit. and the device protection circuit shuts the chip off. also probably it does not have such circuit. one possibility is to try with an external powered hub.
the most probable of these is the power saving mechanism
I was experiencing the same problem - came across the solution on another site. The USB 3 ports on Surface Book aren't compatible with something or other to do with Com Port but running the device through a cheap USB hub solved my problem straight away and it was instantly recognised by the Arduino IDE
I have a number of Windows 2000 systems that we are trying to use to program the new Arduino Uno and Mega devices. These boards now come with a USB connection, an upgrade from the prior FTDI. I'm not able to download the Arduino code into the board from a Windows 2000 system
The supplied drivers are *.inf files that modify the standard USB driver that comes with Windows (in this case Windows 2000).
I go through the process of setting the port, setting the device and doing the download. The download fails, and the apparent error is that the PC can not communicate with the board. I've checked the port, adjusted the baud rates, etc. I've even moved the port number from a high port number (ie COM12) to a lower port (COM2) without any success. I do see activity on the rec/xmt lights on the Arduino board, so some type of data is being sent and received.
I'm looking for:
Someone who has been able to download files from Windows 2000 to the Arduino
or
A way to shim inside the USB driver to be able to watch the traffic going up and down to the board so I can continue to debug this.
or
Some general tips for things to look at in the .inf file that need to be set/not set to make it work on Windows 2000.
I know the boards work I've used them on a different set of Windows XP systems. So I know to some extent the install is good and that most of what I have works.
Full dumps can be found on the Arduino forum, http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1291090110/.
This is the information produced by the AVRDude program while it's trying to download the code.
this could be a long shot, but I jsut recentlz had problems uploading too. Fist of all, how long is the USB cabele you are uploading from? Mine in one case was too long and th arduino woul lose sync. Secondly, and this might just be a silly oversight (like i did) do you have things wired in the digital pin 0 and 1? These are used for the communication, and if there is anything else plugged in to them the upload will also fail.
As I said, long shot but those were two errors I had.