cloudy

Author Topic: Found a new way to handle the HID USB using API  (Read 966 times)

0 Members and 2 Guests are viewing this topic.

Offline ejeklint

  • Posts: 25
  • OS/Browser:
  • Mac OS X 10.7.3
  • Safari 5.1.3
Re: Found a new way to handle the HID USB using API
« Reply #15 on: January 23, 2012, 09:08:54 PM »
Cool. Let me know if I can assist. Remote debugging is kind of fun.  :D

Offline Weather Display

  • Posts: 65,579
  • OS/Browser:
  • Win 7/Srvr 2008R2
  • Firefox 9.0.1
Re: Found a new way to handle the HID USB using API
« Reply #16 on: January 23, 2012, 09:17:19 PM »
am trying to work out from your project code how to call to get data
can you post a code snippet?
thanks
I do see you have had to check on the type of data for the expected length etc

Offline ejeklint

  • Posts: 25
  • OS/Browser:
  • iOS 5.0.1
  • Safari 5.1
Re: Found a new way to handle the HID USB using API
« Reply #17 on: January 23, 2012, 09:44:19 PM »
Ok, will get some code to you tomorrow. Must get some sleep now.

Offline ejeklint

  • Posts: 25
  • OS/Browser:
  • Mac OS X 10.7.3
  • Safari 5.1.3
Re: Found a new way to handle the HID USB using API
« Reply #18 on: January 24, 2012, 07:04:09 AM »
am trying to work out from your project code how to call to get data
can you post a code snippet?
thanks
I do see you have had to check on the type of data for the expected length etc

OK, the thing is that you don't call anything to get data, you get called to receive data. The callback function Handle_IOHIDDeviceInputReportCallback is there for that. Easiest thing to do is move that function to your own code and just leave an external declaration of it in hiddevice.c. After calling Setup_HIDManager, data should start to come in.

Data is packed in a "report", where the first byte tells how many of the consecutive bytes are valid data. It's usually 1 byte for each report (at least for Oregon stuff), but you shouldn't rely on it. This example is in Objective-C, but you'll get the point on how to extract valid bytes and assemble data: https://github.com/ejeklint/Cloudya/blob/master/daemon/WMR100NDeviceController.m#L136

An alternative solution that makes assumptions of package lengths for assembling a complete data package from Oregon stations, which I just wrote in JavaScript for node.js, is this:


WMR100Controller.prototype.weatherData = function (error, data) { // "data" is the buffer with the Device Input Report
    if (ffs === 2) { // ffs is a counter
        // Two consecutive 0xff is detected, we are in sync! Start saving data until next two 0xff
        for (var i = 0; i < data[0]; i++)
            inbuf[ii++] = data[1 + i]; // Keep saving valid bytes in a buffer
           
        // Check expected lengths. We know what from looking at the second byte after the sync-ffs.
        if (expectedLength === 0 && ii > 5) {
            switch (inbuf[1]) {
                case 0x41:
                    expectedLength = 17;
                    break;
                case 0x42:
                    expectedLength = 12;
                    break;
                case 0x46:
                    expectedLength = 8;
                    break;
                case 0x47:
                    expectedLength = 6;
                    break;
                case 0x48:
                    expectedLength = 11;
                    break;
                case 0x60:
                    expectedLength = 12;
                    break;
                default:
                    // Unknown. Trash it and start looking for new frame
                    ii = ffs = expectedLength = 0;
            }
        }
       
        if (ii === expectedLength) {
            // Complete reading from weather station is acquired, toss it on!
            this.emit('sensor' + inbuf[1].toString(16), inbuf.slice(0, expectedLength));
            // Start looking for new frame
            ii = ffs = expectedLength = 0;
        }
    } else if (ffs === 1 && data[1] !== 0xff) {
        ffs = 0;
    } else if (data[1] === 0xff) {
        ffs++;
    }
    // Re-bind this callback to node-hid module
    this.hid.read(this.weatherData.bind(this));
}


HTH.

Offline Weather Display

  • Posts: 65,579
  • OS/Browser:
  • Win 7/Srvr 2008R2
  • Firefox 9.0.1
Re: Found a new way to handle the HID USB using API
« Reply #19 on: January 24, 2012, 05:41:04 PM »
ah, gotcha, is basicly an interupt call
I will try that
I did see where you had put, put your code here...

let me see what I can do (C or C++ is not my prefered language, but google is great!)

Offline Weather Display

  • Posts: 65,579
  • OS/Browser:
  • Win 7/Srvr 2008R2
  • Firefox 9.0.1
Re: Found a new way to handle the HID USB using API
« Reply #20 on: February 14, 2012, 07:57:52 AM »
Hi
I have upgrade to snow leopard, 10.6.6
i.e with a new Xcode upgrade etc
so should have more chance of compiler your sample code
do you think you could send me a simple program to get data from the wmr100 so that I can use that as a basis to work on?
Thanks!