Author Topic: EasyWeatherIP and WS1001 Protocol  (Read 7808 times)

0 Members and 1 Guest are viewing this topic.

Offline jeff.kowalski

  • Member
  • *
  • Posts: 3
Re: EasyWeatherIP and WS1001 Protocol
« Reply #50 on: October 12, 2018, 11:43:39 PM »
@wx5020
Hi Bill,

I love the perl script you wrote to get data from WS1001 consoles.
It has enabled me to create a similar system to retrieve weather for storage in influxdb and visualization in grafana.

I'm curious about the contents of msg-tcp-nowrec-req.dat and msg-udp-srch.dat.
How did you determine those?

From what I can tell, the format is similar to the header in the responses.
PC2000\0\0      - HP_HEAD null padded to 8 bytes
SEARCH\0\0      - HP_CMD null padded to 8 bytes
or
PC2000\0\0      - HP_HEAD null padded to 8 bytes
READ\0\0\0\0\0  - HP_CMD null padded to 8 bytes
NOWRECORD\0..\0 - HP_TABLE null padded to 24 bytes

Your msg-tcp-nowrec-req.dat is as I would expect: PC2000\0\0READ\0\0\0\0NOWRECORD\0\0\0\0\0\0\0\0\0\0\0\0\0

However, in your .msg-udp-srch.dat file, I see you have data in the areas where I would have expected padding nulls.
msg-udp-srch.dat:       PC2000\0\0SEARCH\0\0\0,Pw\0\0\0\0\0ݿw
Is that ",Pw" and "ݿw" data significant?  Was it empirically derived?  What does it mean?  Where did you find the description of these messages?

Thanks in advance for your help,
Jeff

Offline Aussie Susan

  • Senior Member
  • **
  • Posts: 52
Re: EasyWeatherIP and WS1001 Protocol
« Reply #51 on: October 14, 2018, 10:45:50 PM »
If you want a few more details on the packets passed back and forth, have a look at the header of the main Python file in the HP1000 driver on Github (https://github.com/AussieSusan/HP1000).
I've 'decoded' the ones that allow the driver to work.
Susan

Offline jeff.kowalski

  • Member
  • *
  • Posts: 3
Re: EasyWeatherIP and WS1001 Protocol
« Reply #52 on: October 15, 2018, 03:08:00 AM »
Thanks so much for your prompt reply Aussie Susan.

I've seen your code, which was very helpful.  Nonetheless, I don't understand the messages in Bill's example.
I was specifically asking about the non-null bytes of the transmissions.

In the UDP broadcast, his code sends:
PC2000^@^@SEARCH^@^@^@M-MM-}M-^T,M-{M-c^K^LM-{M-c^KPM-+M-%w^@^@^@^@^@M-]M-?w⏎
I would have expected "PC2000" and "SEARCH" each null-padded (^@) to 8 bytes, followed by 24 nulls, but there's "stuff".

Similarly, in the TCP request for current data, I see
PC2000^@^@READ^@^@^@^@NOWRECORD^@^@^@^@^@^@^@M-8^A^@^@^@^@^@^@⏎
Again here I would have expected "PC2000" and "READ" each null padded to 8 bytes, and "NOWRECORD" null padded to 24 bytes.

What's the extra stuff where I expected those trailing nulls in the 24 byte table field?  Does it have meaning?
Are there documents for any of this, or was it all empirically deduced?

Jeff

Offline Dr__Bob

  • Member
  • *
  • Posts: 26
Re: EasyWeatherIP and WS1001 Protocol
« Reply #53 on: October 15, 2018, 01:46:16 PM »
A long time ago, I asked Ed at Ambient Weather for some documentation.  He passed on the following two files, with no other information.  With Bill's help, along with a lot of help from Matthew Wall, I started to put together a driver.  But then, Susan beat me to the punch with her driver.  But yeah, it wasn't so easy trying to understand the protocol, with basically only those two files as guidance.  Some of it is empirical... [ You are not allowed to view attachments ]  [ You are not allowed to view attachments ]

Offline jeff.kowalski

  • Member
  • *
  • Posts: 3
Re: EasyWeatherIP and WS1001 Protocol
« Reply #54 on: October 15, 2018, 02:28:56 PM »
That is super-helpful, Dr_Bob!  Thank you!  I can see exactly what's going on in the SEARCH phase of the communication.
I can see from the sprintf_s calls that the data that trails the HP_TABLE is likely junk.  sprintf_s doesn't change anything after it writes just one null.
You included one file, but mentioned there were two.  What was the other file?  Was it a header describing the HEAD structure, or maybe the NOWRECORD phase of communication?

 

anything