post icon

WMR100N + Mac == True (soon)

I’ve had enough with troubles trying to get wdconsole/consolewd running on my Mac mini with Ubuntu. And the only reason for Linux was that weather logging thing. So I gave up and am now building a mac native weather data logger, with proper USB handling, free from library dependencies and full plug and play as it should be on a mac. Have a working prototype capable of getting all data from WMR100N, but need to complete it with some DB update. Stay tuned!

Update: I’m putting up a new page for this.

12 Comments

Leave a comment
  1. Xander
    2009/06/19 at 07:51 #

    Hi,

    I’ve been hunting for the protocol used by the wmr100/rms300 ‘weather’ stations. (It’s driving me nuts!) Is there any chance of you sharing what you have so far?

    Thanks!

  2. Per
    2009/06/19 at 08:01 #

    Oh, a comment, how nice! :-)

    I still have an hour or two before first draft is ready – stay tuned! I’ll publish a little later today on page http://www.ejeklint.se/development/wmr100n-driver-for-mac-os-x/

  3. Xander
    2009/06/19 at 13:38 #

    Hope you enjoyed your lunch (nice cam :D )!

  4. Per
    2009/06/19 at 17:36 #

    Thanks, it was great. Celebrating midsummer with the traditional herring. Fell asleep after too many shots instead of working with my WMR100 thing…

  5. Per
    2009/06/19 at 18:46 #

    OK, I have published a first draft of the protocol description.

  6. Xander
    2009/06/20 at 06:48 #

    Thanks!

    I don’t know if it’s because i have a rms300 (which alledgedly speaks wmr100 protocol becaue it works with that setting in other sw) but there’s a difference in the protocol used by it and your description.

    The 01 length records do play a part, and the record seperator seems to be 0xff 0xff instead 0×00 0xff which your document describes. This way at least i get usable records. :D

  7. Per
    2009/06/20 at 08:23 #

    Yes, the 1 length records do play part as long as they come in the 8 byte long USB reports in which the actual data is transported, one or two bytes for each USB report. WMR100 also sends 1 byte long USB reports which I have found no meaning in.

  8. Xander
    2009/06/20 at 19:56 #

    Hi,

    I found this project on sourceforge. It has extensive wmr100 record descriptions (look for WMR100DataParser.cs in the sourcepackage).

    Enjoy!

  9. Per
    2009/06/21 at 06:41 #

    Excellent, a few more bits figured out. Have found several other projects but not this one, thanks!

  10. Weber
    2009/07/27 at 00:49 #

    Hi,

    I have a Windows program (called WSDL) for the WMR100 on SourceForge. This program is keying off of two bytes of 0xff for the record separator — but your protocol page says you are seeing “0×00,0xff” instead. Are you sure about this? I haven’t heard anyone complaining that WSDL is having trouble with the new WMR100N…but I’d really like to know if O.S. is changing the protocols on us…?

    – Weber

  11. Per
    2009/07/27 at 11:29 #

    I’m pretty sure, but I will have a look at your code and see if I might have missed something. My actual implementation looks more on frame identifiers and expected lengths than delimiters so it might be that I’ve overlooked something. And thanks for your comment!

  12. Per
    2009/07/28 at 18:20 #

    Have done some experimenting and I was wrong. In my data stream there is one FF between individual measurements, and FFFF once every minute. All single FF are preceeded by 00, 01 or 02 – have no idea what they mean but they come after the closing checksum byte in all measurements.

Leave a Reply