Re: Firmware upgrade - Oh Noes!!
Posted: Fri Jan 05, 2018 2:52 pm
teken,
thank you for the suggestions.
of the 10 GEMs that i have installed so far, only two have been problematic. unfortunately they are both at the same site, and i typically only get there to physically diagnose/fix issues maybe once in a year.
one of them decided to change its serial number. one day the serial number simply changed from a normal 01000xxx number to 02904626. nothing i have done has changed it back: updating firmware, resetting the hardware, etc. so i now have a special case in btmon to map that serial back to its proper number. that GEM also has a flaky power connector - if you push the barrel connector down, the power cycles. so over time, gravity pulls the connector down, and the GEM randomly power cycles. so we switched to mini-usb connector to power that GEM.
the other one is the one i have been describing in this thread. i had comm problems with 5 of the GEM when the Adaptor caps started going bad. but this one seems to have not ever really recovered.
i usually install direct serial connections, with btmon pulling the data from the GEM and sending it to influx or emoncms or mysql. all of the environments are windows-free, so having to spin up a windows vm to run some windows-only software is a pain. one of these days i'll rewrite btcfg so that we have a simple, run-anywhere tool to get the entire GEM configuration into a .ini file, and to configure the entire GEM from a single .ini file, that works whether you run it on a mac, linux, or windows machine.
i've got 3 sites using WIZnet just fine, but at one site they simply won't work reliably. we've tried rewiring, recrimping, changing network topology to use dedicated switches, VLANs to isolate the GEMs, ... they just stop talking to the GEM after a day or a month. you can still ping the WIZnet, and you can still talk to the WIZnet, but the WIZnet won't talk to the GEM.
i have considered releasing a weeWX driver for the GEM (and ecm1240). weeWX has more overhead than the single btmon script, but it also introduces better logging, more error handling/recovery, local reporting, local storage, more upload opportunities.
anyway, my frustration in this case is that i have not been able to reliably make this particular GEM communicate, and the process for resetting seems to be much more complicated than it should be.
i've got btmon collecting data from the GEM via WIZnet right now. but it is *not* a clean communication (every third packet or so has unexpected characters).
i'm trying to set up both serial (COM2) and WIZnet (COM1) on each GEM so that when the WIZnets fail again in a month or two, i can get in with a serial connection to reset/diagnose/whatever.
so far i have been able to get data from COM1 or COM2, but not both.
i have one more day at this site, so i'll probably have a go with the latest "GEM Network Utility" instead of the old version 6 i was using.
m
thank you for the suggestions.
of the 10 GEMs that i have installed so far, only two have been problematic. unfortunately they are both at the same site, and i typically only get there to physically diagnose/fix issues maybe once in a year.
one of them decided to change its serial number. one day the serial number simply changed from a normal 01000xxx number to 02904626. nothing i have done has changed it back: updating firmware, resetting the hardware, etc. so i now have a special case in btmon to map that serial back to its proper number. that GEM also has a flaky power connector - if you push the barrel connector down, the power cycles. so over time, gravity pulls the connector down, and the GEM randomly power cycles. so we switched to mini-usb connector to power that GEM.
the other one is the one i have been describing in this thread. i had comm problems with 5 of the GEM when the Adaptor caps started going bad. but this one seems to have not ever really recovered.
i usually install direct serial connections, with btmon pulling the data from the GEM and sending it to influx or emoncms or mysql. all of the environments are windows-free, so having to spin up a windows vm to run some windows-only software is a pain. one of these days i'll rewrite btcfg so that we have a simple, run-anywhere tool to get the entire GEM configuration into a .ini file, and to configure the entire GEM from a single .ini file, that works whether you run it on a mac, linux, or windows machine.
i've got 3 sites using WIZnet just fine, but at one site they simply won't work reliably. we've tried rewiring, recrimping, changing network topology to use dedicated switches, VLANs to isolate the GEMs, ... they just stop talking to the GEM after a day or a month. you can still ping the WIZnet, and you can still talk to the WIZnet, but the WIZnet won't talk to the GEM.
i have considered releasing a weeWX driver for the GEM (and ecm1240). weeWX has more overhead than the single btmon script, but it also introduces better logging, more error handling/recovery, local reporting, local storage, more upload opportunities.
anyway, my frustration in this case is that i have not been able to reliably make this particular GEM communicate, and the process for resetting seems to be much more complicated than it should be.
i've got btmon collecting data from the GEM via WIZnet right now. but it is *not* a clean communication (every third packet or so has unexpected characters).
i'm trying to set up both serial (COM2) and WIZnet (COM1) on each GEM so that when the WIZnets fail again in a month or two, i can get in with a serial connection to reset/diagnose/whatever.
so far i have been able to get data from COM1 or COM2, but not both.
i have one more day at this site, so i'll probably have a go with the latest "GEM Network Utility" instead of the old version 6 i was using.
m