This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Pro2 Compact not starting at times
#11
(15-04-2019, 10:15)engolling Wrote: So I think this it not directly related with the software used but with the driver initializing the com port in Windows.

The driver, or the way the software uses the driver to open the COM port: for sure that CumulusMX and Cumulus1 are doing it differently, because the former always causes the freeze while the last not.

I don't remember for what purpose, but I have a very vague memory that some years ago I had to look on WeeWx serial driver code, to change from hardware handskake to Xon/ Xoff.


(15-04-2019, 16:27)hornychz Wrote: I wouldn't worry about this problem myself ...  Cool

I would like that it not happen, but I'm also not to worried with it.  Smile

(15-04-2019, 16:27)hornychz Wrote: I can also confirm this phenomenon for a long time and very probably with all versions of Arduino. On the other hand,
I think the idea - the CumulusMX on Raspberry PI is the best, even if it doesn't do everything like the Cumulus. In principle,
Linux reboots never happen randomly, and many of my servers run for years without rebooting. And Raspbian behaves equally
steadily.

Windows PC also can be quite stable.
   

Under the last 3 years, this PC has restarted only a few times, always forced by my action. It doesn't do automatic updates, and is used exclusively to run Cumulus 1 and Kodi as a media center (PC and WeatherDuino connected through a 1500VA UPS).
Mini ITX board, consumes only 17W, no fan, 128Gb in SDD.
A little more expensive than a Rpi but a lot more versatile (at least for me... working with Linux is always an adventure...  ReadManual )
MeteoCercal - Air Quality Data
Click here to watch at my ThingSpeak channel



Reply
#12
(15-04-2019, 18:16)Werk_AG Wrote:
(15-04-2019, 16:27)hornychz Wrote: I can also confirm this phenomenon for a long time and very probably with all versions of Arduino. On the other hand,
I think the idea - the CumulusMX on Raspberry PI is the best, even if it doesn't do everything like the Cumulus. In principle,
Linux reboots never happen randomly, and many of my servers run for years without rebooting. And Raspbian behaves equally
steadily.

Windows PC also can be quite stable.


Under the last 3 years, this PC has restarted only a few times, always forced by my action. It doesn't do automatic updates, and is used exclusively to run Cumulus 1 and Kodi as a media center.
Mini ITX board, consumes only 17W, no fan, 128Gb in SDD.
A little more expensive than a Rpi but a lot more versatile.

I can approve this - I also have a Windows server running for data storage and it only reboots when there is a power outage. Especially Windows server ist in the end very stable. Cool
Reply
#13
(15-04-2019, 18:16)Werk_AG Wrote:
(15-04-2019, 10:15)engolling Wrote: So I think this it not directly related with the software used but with the driver initializing the com port in Windows.
The driver, or the way the software uses the driver to open the COM port: for sure that CumulusMX and Cumulus1 are doing it differently, because the former always causes the freeze while the last not.
I don't remember for what purpose, but I have a very vague memory that some years ago I had to look on WeeWx serial driver code, to change from hardware handskake to Xon/ Xoff.


What I wanted to say is I think the issue is caused by the driver on a USB3 port - it also brings my WD unit to freeze on reboot.
CumulusMX is only the trigger doing some action to "highlight" the problem.
Reply
#14
(15-04-2019, 18:44)engolling Wrote: What I wanted to say is I think the issue is caused by the driver on a USB3 port  - it also brings my WD unit to freeze on reboot.
CumulusMX is only the trigger doing some action to "highlight" the problem.

I understand what you want to say, however I'm not sure if the problem is the driver, or only the driver.
On my laptop (Dell Precision 7710) no matter how many times I plug the Pro2 Compact (or the WD units) on an USB3 port, they always boot up correctly and never goes to the blank screen.
After boot up if I open the serial monitor, or Cumulus 1, I never get the blank screen too, however, if I open CumulusMX, I will get the blank screen. So seems the software have its role.
Strange is that the blank screen only occurs the first time I start CumulusMX after a receiver boot up, subsequent re-starts of CumulusMX will not cause the blank screen.

It may be the USB driver, however seems that the behaviour isn't the same on all PC's

In terms of hardware I already found what is causing the blank screen:
It happens every time the usb to serial chip (CH340) on the Wemos, activates  the DTR line, which on the Wemos causes that the GPIO0 pin goes to low state. The GPIO0 pin is used as D/C line for the TFT.
MeteoCercal - Air Quality Data
Click here to watch at my ThingSpeak channel



Reply
#15
(15-04-2019, 20:28)Werk_AG Wrote: In terms of hardware I already found what is causing the blank screen:
It happens every time the usb to serial chip (CH340) on the Wemos, activates  the DTR line, which on the Wemos causes that the GPIO0 pin goes to low state. The GPIO0 pin is used as D/C line for the TFT.

Looking at the source code for CumulusMX


Quote:comport = new SerialPort(cumulus.ComportName, cumulus.DavisBaudRate, Parity.None, 8, StopBits.One) {Handshake = Handshake.None, DtrEnable = true};

DTR is probably used for genuine Davis equipment which is why it is enabled
I am not sure if there is much you can do about it.

I think I noticed the problem with my setup when I was experimenting but I blamed it on my inexperience and the WeatherDuino normally runs independent of the PC so I didn't look further.

Jim
Reply
#16
(15-04-2019, 22:37)TassyJim Wrote: comport = new SerialPort(cumulus.ComportName, cumulus.DavisBaudRate, Parity.None, 8, StopBits.One) {Handshake = Handshake.None, DtrEnable = true};

DTR is probably used for genuine Davis equipment which is why it is enabled
I am not sure if there is much you can do about it.

[/quote]

ah ah, very good, thanks  Smile. I remember I saw that some years ago when I was working on another project.
When I will have the time I will try to change DtrEnable to false to see if it will make any difference.

Yes, if I'm not wrong, first Davis models use a real serial port.
MeteoCercal - Air Quality Data
Click here to watch at my ThingSpeak channel



Reply
#17
(15-04-2019, 20:28)Werk_AG Wrote:
(15-04-2019, 18:44)engolling Wrote: What I wanted to say is I think the issue is caused by the driver on a USB3 port  - it also brings my WD unit to freeze on reboot.
CumulusMX is only the trigger doing some action to "highlight" the problem.

I understand what you want to say, however I'm not sure if the problem is the driver, or only the driver.
On my laptop (Dell Precision 7710) no matter how many times I plug the Pro2 Compact (or the WD units) on an USB3 port, they always boot up correctly and never goes to the blank screen.
After boot up if I open the serial monitor, or Cumulus 1, I never get the blank screen too, however, if I open CumulusMX, I will get the blank screen. So seems the software have its role.
Strange is that the blank screen only occurs the first time I start CumulusMX after a receiver boot up, subsequent re-starts of CumulusMX will not cause the blank screen.

It may be the USB driver, however seems that the behaviour isn't the same on all PC's

In terms of hardware I already found what is causing the blank screen:
It happens every time the usb to serial chip (CH340) on the Wemos, activates  the DTR line, which on the Wemos causes that the GPIO0 pin goes to low state. The GPIO0 pin is used as D/C line for the TFT.
Hi All,
I have switched over to the raspberrypi and all works as it should. So I presume it must be a windows10 error.
Thanks
Philip
Reply
#18
Hello folks,

I did some investigation with my WD unit seconds ago and made the following observations (OS Win10, CH340 driver V 3.4.2014.8, HTERM as Com Terminal):

I have no reaction when activation DTR but I get a white screen as long as RTS is activated on a USB 2 port.
On a USB 3 port I get a white screen when I change the baud rate when the serial port is opened which stays as long as I force a reboot toggling RTS on and off.

I just found here - and I also tested it that DTR has to be deactivated that toggling RTS can force a reboot.
https://hallard.me/esp8266-autoreset/

So I searched for a new driver from the CH340 manufacturer:
http://www.wch.cn/download/CH341SER_EXE.html

Installed the new version and the bad behaviour on a USB 3 Port ist solved - it also might solve your cumulus problem because I think CumulusMX opens the serial port and then changes the baud rate bringing the SH340 driver to make bad things.

I did not check it with CumulusMX since I have no Compact receiver but maybe Werk can check it out with the new driver.

Regards,
engolling
Reply




Users browsing this thread: 1 Guest(s)