Cannot connect to Maplin N96GY (WH1080)

[Lloyd]

Has anyone had any success connecting to a new (Autumn 2011) Maplin
N96GY weather station? I rebuilt the latest version to include the
magic number modification which has been reported as a bug, with no
joy.

In an attempt at some debugging I captured the usb trafffic from both
weathereye and cumulus, and these show very little relationship to
what wview is trying to do.

Happy to post the log files if anyone wants them.

Thanks

Lloyd

[lloyda]

I have now had this working successfully for the past couple of days,
after making a couple of tweaks to the code. Happy to share my
changes once I've been running for a while longer, and I've taken all
my debugging code out.

Lloyd

[slugboy]

Hi Lloyd,
I've got the same problems with the Maplin unit(s) so very interested
if you have a solution - please let me know what to do because i
installed it from the .deb
Atm the log shows there is an incorrect magic block with wview.

I tried pywws but it kept failing the connection after a random number
of days and needed the plug pulling (I don't use any batteries in it
so this resets it)

[lloyda]

Hi

 

The jist of my change was to simplify the magic number checking - it now only checks the first byte.  However there are a couple of othe mods which attempt to increase reliability and reduce invalid data.  Don't have access to my source at the moment, but will follow up in a few days.

 

Lloyd

[Mark S. Teel]

I have made similar changes to be in the next release. Will compare with
your changes.

Mark

> --
> You received this message because you are subscribed to the Google
> Groups "wview" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/wview/-/Ny355o--G5AJ.
> To post to this group, send email to wv...@googlegroups.com.
> To unsubscribe from this group, send email to
> wview+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/wview?hl=en.

[Thomas H Kristensen]

Hi Mark & Others

I have a similar ”magic number” issue with a USB Fine Offset Weather
Station. Can some of you perhaps provide me with a workaround?

Mark, do you have a beta or a quick-fix you can share. I have tried a
newly installed Ubuntu and CentOS, both with same error. Would you
like me to do some test and results/logiles?

WView looks great (in simulation mode) and I’m looking forward to the
next release. I will happily donate.

Thomas

[lloyda]

So my unofficial changes, that have been working a treat for me are

1) only test for 0x55 - forget the second magic byte

2) don't bother checking for first byte is 0x05 in data record

3) ignore any attempts to read from memory that are not a multiple of 16 (at certain times I found attempts were being made to read from duff memory locations, which caused spikes in the data)

 

I don't know what the 'official' changes are.

 

hope this helps

 

Lloyd

[Mark Teel]

The test release has a proposed fix for this issue. I encourage you to
try it.

Mark

On 2/12/12 1:11 PM, Thomas H Kristensen wrote:
> Hi Mark& Others
>
> I have a similar �magic number� issue with a USB Fine Offset Weather

> Station. Can some of you perhaps provide me with a workaround?
>
> Mark, do you have a beta or a quick-fix you can share. I have tried a
> newly installed Ubuntu and CentOS, both with same error. Would you
> like me to do some test and results/logiles?
>

> WView looks great (in simulation mode) and I�m looking forward to the

[Thomas H Kristensen]

Great news. Looking forward to get this up and running.
Where can I obtain the 5.20.0 test release? The ”latest stable” button
gives me:
*********
Not Found
The requested URL /wview-null.tar.gz was not found on this server.
Apache/2.2.17 (Ubuntu) Server at www.wviewweather.com Port 80
**********

/Thomas

On 19 Feb., 00:17, Mark Teel <mteel2...@gmail.com> wrote:
> The test release has a proposed fix for this issue. I encourage you to
> try it.
>
> Mark
>
> On 2/12/12 1:11 PM, Thomas H Kristensen wrote:
>
>
>
>
>
>
>
> > Hi Mark&  Others
>

> > I have a similar magic number issue with a USB Fine Offset Weather

> > Station. Can some of you perhaps provide me with a workaround?
>
> > Mark, do you have a beta or a quick-fix you can share. I have tried a
> > newly installed Ubuntu and CentOS, both with same error. Would you
> > like me to do some test and results/logiles?
>

> > WView looks great (in simulation mode) and I m looking forward to the

[Mark Teel]

Force a reload of the page: Shift-reload for example.

[Mark Teel]

Any insight into the protocol or needed refinements to wview for any of
these stations without a published protocol spec (WMRUSB, WH1080, TE923)
are always welcomed. I have used a combination of other open source
projects for examples and reverse engineering to develop the wview
interfaces.

Thanks,
Mark

[Baz]

Hi Lloyd,

Could you post your source please?

Brian

[Mark S. Teel]

If he only allows 0x55 XX then it will not match 0x09 0x27...

I reviewed these comments already, utilizing #2 and #3.

[Baz]

Hi Mark,

Ok thanks but if it works...

Just connected the station back onto my Windoze machine and the base
station has a full 4080 set of data; I just cannot get to it with
wview :(.

Anything else I could try?

Cheers

[Mark Teel]

It won't work because your magic number is currently 0x09 0x27. It will
be different I bet if you plug it back into the linux server.

If you can get a log of USB data between your station and the windoze SW
(starting with the launch of the SW) I can analyze what they are doing
differently. That *could* be very helpful. An open source sniffer is:
http://sourceforge.net/projects/usbsnoop/

Understand that my WH1080 works flawlessly now for more than a year with
the 5.19.0 code. I don't have a station exhibiting these magic number
issues. And it is hard to find someone like you who is willing to be my
testing "eyes". Thanks.

Attached is a version with more logging and more retries.

Mark

[Mark S. Teel]

Attached is a version which hardens the reading of records by requiring
that two reads in a row from the USB bus/console memory are identical. I
got this idea from the pywws source code (python, could be tried on
windows) which, BTW, only allows (0x55,0xAA) or (0xFF,0xFF) or
(0x55,0x55) or (0xC4,0x00) for magic numbers, much more restrictive than
what we are now using here...

If the improved reading method doesn't address your situation, I don't
know what to do short of allowing any magic number. Maybe that is OK. It
would be nice to know that is true.

Mark

[lloyda]

Attached is the source that I'm using.  I have had this running for 5  weeks or so now, and only one hang.  I'm not sure that there is anything different here to what has been said elsewhere.  Note that there is some logic to remove reads from 'silly' addresses, when the pointer is obviously pointing to the wrong pace - removes spikes I get in gusty wind (?!).  I have added comments where I made most changes, but my discipline when debugging is not very good, and I tend to make changes on the fly. Therefore, I'd recommend a diff.  Any questions, pleased to answer.

 

 

Lloyd

[simco...@gmail.com]

Sorry I've not commented on this sooner, but it would appear that this
change would render my Ambient Weather WS-1080 uncompatible. Mostly
because it likes to send magic bytes that start with 0xFF, 0x01 and 0x00
in addition to 0x55.

This makes me think that the magic numbers might have some manufacturer
specific meaning that is almost meaningless.

[Baz]

Attached is an export from the sniffer. Unfortunately, Vista <spit>
has now decided not to play and will not communicate with the weather
station. This data was though from startup and it said it read 4081
records. I was going to export the actual data as well but I can't do
that now. Will keep trying to get it to work again.

Ah, slight problem, how do I attach a file?

Cheers

>  wh1080Protocol.c
> 21KViewDownload

[Mark Teel]

Email it to mtee...@gmail.com and wv...@googlegroups.com.

[Baz]

Ok thanks. Tried that and I get this

Feb 20 22:47:56 revo wviewd[25089]: <1329778076870> : WH1080: read
data block failed!
Feb 20 22:47:56 revo wviewd[25089]: <1329778076871> : stationInit:
wh1080Init failed!
Feb 20 22:47:56 revo wviewd[25089]: <1329778076871> : stationInit
failed!

Cheers

>  wh1080Protocol.c
> 23KViewDownload

[Doug Otto]

> Sorry I've not commented on this sooner, but it would appear that this
> change would render my Ambient Weather WS-1080 uncompatible.  Mostly
> because it likes to send magic bytes that start with 0xFF, 0x01 and 0x00
> in addition to 0x55.
>
> This makes me think that the magic numbers might have some manufacturer
> specific meaning that is almost meaningless.

This.

The whole reason I use wview is because the other Mac compatible
offerings for my WS-2080 are unreliable as heck. Let's now mess up a
good thing. lol

[Mark Teel]

FWIW, I found this in a blog concerning N96GY stations:
"Finally managed to figure out how to connect the Sheevaplug up to the
N96GY weather station. The Weather station is similar to the WH1080 and
I managed to install the pywws software which then uploads the data to
Underground Weather. One thing to note is that if you get a problem with
the comms between the station and the software and it gives a �magic
number� error then clear the memory on the station. I found that my
station had recorded some data out of range or with all FFs in the
memory, on clearing the memory it picked up real data and connected
correctly."

Worth a try.

Mark

[Baz]

Tried all sorts of things.

This is what I am observing on the windows machine. Of the 256 byte
fixed block that jim-easterbrook describes, the first 32bytes are
repeated twice at the start, and 3 times at the end. So on each read
I see 32bytes, 256bytes, 32, 32, 32 where each 32 is the same as the
first 32 of the 256.

Having looked at the data, and maybe I am wrong, but it does not seem
to match jim's description. For instance, where the latest position
and data count items should be, these bytes do not seem to be
changing. I could be wrong though.

Have you looked at the pywws code to see how it is done there?

Cheers

Brian

On Feb 20, 11:06 pm, Mark Teel <mteel2...@gmail.com> wrote:
> FWIW, I found this in a blog concerning N96GY stations:
> "Finally managed to figure out how to connect the Sheevaplug up to the
> N96GY weather station. The Weather station is similar to the WH1080 and
> I managed to install the pywws software which then uploads the data to
> Underground Weather. One thing to note is that if you get a problem with

> the comms between the station and the software and it gives a magic
> number error then clear the memory on the station. I found that my

[Mark Teel]

Yes, I sent an email with the latest attachment citing pywws and the
idea of reading a block twice. Are you missing emails/posts?

The current position (offset 30 I believe) will not change more often
than once every 48 seconds or so if what I have read online is true.

Can I see the USB capture please?

Thanks,
Mark

[Mark Teel]

Did you try clearing the station memory?

On 2/20/12 7:45 PM, Baz wrote:

[Mark Teel]

The pywws code follows the data block definitions I sent in the earlier
email.

On 2/20/12 7:45 PM, Baz wrote:

[Brian Orpin]

Hi Mark, I had missed a couple of posts.

Situation is that the weather Station *was* working but I'm not sure why or which version of the Protocol I am using so I have included it here :)

The attached log files will show the various data protocols I have seen over the last few days. export 5 seemed to work.

A number of issues I have seen on the Window side; If the Vista machine goes to sleep when the EasyWeather is open then the Station freezes.  The Clear Memory command does not seem to do that and the software will often download a load of data.

To get this working I unplugged the station and took out a battery to 'reboot' it. On firing up on Windows I observed the Export 4/5 data (Magic Number looks good). I closed down the EasyWeather carefuly before unplugging the station.  Plugging it into Ubuntu box, then starting wview seemed to do the trick.

HOWEVER, stupidly, I tried to recreate what I did (no change to wview) and now it cannot read data. In it's current state (as seen on windows) is Export 6.

It is going out of the window soon!

What I really need to do is sniff the data on Ubuntu. Any simple ways of doing that?

-- 

Brian

--
You received this message because you are subscribed to the Google Groups "wview" group.
To post to this group, send email to wv...@googlegroups.com.

To unsubscribe from this group, send email to wview+unsubscribe@googlegroups.com.

[Mark S. Teel]

Brian,

I'm going to consider this issue closed for now. We now know a way to clear the bad magic number scenario by clearing the station's memory.  I've added a bit of text to that effect when it logs the bad magic number.

If we can ever get a definite protocol definition (including additional commands to clear memory, etc.) then I will update the driver to support them.

BTW, your capture files are not hex dumps of the data and thus not useful to me.

Thanks for all your help debugging this,
Mark

-- 

Brian

To unsubscribe from this group, send email to wview+un...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/wview?hl=en.

--
You received this message because you are subscribed to the Google Groups "wview" group.
To post to this group, send email to wv...@googlegroups.com.

To unsubscribe from this group, send email to wview+un...@googlegroups.com.