> > > > the timeouts seem to happen when the station has stopped spewing on the > usb. if that is the root cause of timeouts, then the question is "how do > we get it to start spewing again?" i have only seen the timeout when > starting weewx. starting weewx a second time resulted in normal behavior. > so using loop_on_init is a workaround for that, but it does not tell us > what part of the driver initialization causes the station to start usb > spewage. more significantly, there might be cases where someone is getting > timeouts, and multiple attempts at starting weewx does not make the > timeouts go away. > > I have posted in the other thread in the weewx-development area what triggers the wmr300 to start spitting out data. But when I put in the code to do this, it then starts timing out when I try to write the ACKs So as soon as I make it talk, it stops listening!
> localization comes into play in the detection of the USBError type. when > we get a 'no data available' or 'no error' USBError, we ignore them. these > are not really errors (especially not the 'no error' "error"), so we do not > want to raise exceptions. when localization changes the string from 'No > data available' to the equivalent in de, es, or fr, an exception is raised > instead of being ignored. > > so there are two things to sort out: > > 1) how to determine the USBError type without: > a) using the member args, which is dependent on libusb/pyusb version > b) parsing for a 'no data available' string that depends on locale > My modified code traps all the possible timeouts, however, from how you describe what used to work in v0.9 I think my changes are probably not backward compatible with those older versions of pyusb. However, chasing the error number seems to me a better option. > 2) how to get the station to start jabbering (assuming that the timeouts > are because the station is not jabbering). of course, this might be more > complicated if the root cause is a more subtle usb comm issue rather than > just getting the station to start talking. > > so what do we do? > > - for each test, we need to know: > - what version of libusb > - what version of pyusb > - what version of weewx > - what version of wmr300 > > - test the following: > - start up weewx > > - test permutations > - weewx versions: 3.5.0, 3.6.2 > - wmr300 versions: 0.9, 0.15rc2, 0.15rc3 > - libusb versions: 1.0.x, 0.1.x > - pyusb versions: 0.4, 1.0 > > > As well as all that, there is the issue of error state being different whether or not the kernel release fails. It would be simple enough to write a bit of code that starts the spewing and run it directly before starting weewx. That would at least standardise the starting point. It is also worthwhile finding out what versions people are using from teh point of view that if there are old versions nobody is using any more then we can ignore those for the wmr300. Cameron. -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
