BP Monitor Reading Freezes on Windows
Closed this issue · 28 comments
I've been trying all day with Swing and CMake to create a DLL that can be can be called via any .Net code (i.e. C#)
Can anyone possibly point me in the right direction, or if your "really" nice ;) compile a DLL for me?
regards
Gavin
Oh, yeah, that was on the to do list anyways. I still need to add export function calls. Is this 32-bit or 64-bit?
I am not sure to be honest. For the moment being I'd say 32bit but I'm not sure if that'll work on an 64bit OS?
I'd really appreciate your help with this. I've managed to reverse engineer the bilink software but I can't get occlib.dll to work properly, so now I need to look at using your hard work ;)
Thanks again ;)
A quick update: I got reworked the Win32 HID code and got DLLs building in the libusb-2 branch tonight, so I'll hopefully have a DLL for you to try tomorrow. If you can direct github msg me your email address, I'll email a package with the headers and libraries to you (it's not quite ready for full release yet). I'm not exactly sure how C# deals with libraries that return pointers these days (I did some p/invoke work with it waaaaaaaaaaaaaaay back in like, 2005, I'm sure things have changed since then), but I'm hoping you have a good explanation for how to do that. :)
Sorry about the delay, it seems git was being a pain and said it was offline.
I'm not 100% sure either... I'm assuming that if I knew the header names and their parameters, I could use pinvoke to call them.
If your going to create a dll for me, could you provide some instructions on how you done it? I actually have a Omron 7080IT (M10-IT) but it appears the commands are all similar, so I'm hoping what you've done already will work a treat.
If not, then I will need to have a play.
Urgh.. I'm running Vista which means I can't really use USBSnoop or similar to record the output of the devices. I might end up using vmware or similar to try and get the commands if your's don't work.
Again, I really appreciate your help on this one!
Things should work with the M10-IT, or at least, I figure as much by the lack of complaints I've gotten from people who've said they have one. The only difference may be in output units.
As for the instructions on how to create the DLL, well, the only reason I'm compiling it for you is because I don't really have the full compilation system finished. But I'll see what I can do. For starters, you're going to need to download the WDK if you want to compile, since it requires HID headers. :)
Does Vista/Win7 not work with USBSnoop anymore?
I've dropped you my email via the email address listed against your profile mate.
I've come across the following http://www.lvr.com/hidpage.htm and have something in C# running but I can't for the life of me follow the protocol notes (http://docs.nonpolynomial.com/libomron/devel/asciidoc/omron_protocol_notes.html)
Have you had any luck with creating a DLL?
Cheers
Gav
Huh. Well, I've got a DLL created and a ton of other stuff cleaned up (just check out the commit log for the last two days :) ), but the 790IT test program seems to be locking up on windows (works fine on OS X). Once that's debugged, I think I may just throw out a 0.9.0 version (with DLLs for you) for now, since I'd still like more usability before 1.0 (csv/json/xml output if nothing else), but I may not have time for it for another couple of weeks.
I've noticed lock up's when sending data to the device.
I try sending feature reports and it just returns 7 bytes all 0 every time.
I'm happy to work with raw data and attempt to write the xml/csv output whilst I develop my own code.
I'll check it out ASAP thanks again ;)
Well I finally got cmake, python, wdk etc installed and finally seeing each other, but now I have the following errors whilst trying to build:
[code]Using compily_buildd git submodule C:/Users/Gavin/Documents/Projects/Omron_git/libomron/compily_buildd/cmake
CMake Error at compily_buildd/cmake/BuildSysCMakeLib.cmake:41 (FILE):
file FILE([TO_CMAKE_PATH|TO_NATIVE_PATH] path result) must be called with
exactly three arguments.
Call Stack (most recent call first):
CMakeLists.txt:45 (INITIALIZE_BUILD)
Building Static Libraries for LIBOMRON
Building Shared Libraries for LIBOMRON
Setting build RPATH for LIBOMRON
CMake Error at compily_buildd/cmake/CMakeFunctions.cmake:171 (INSTALL):
install TARGETS given no ARCHIVE DESTINATION for static library target
"omron_STATIC".
Call Stack (most recent call first):
src/CMakeLists.txt:17 (BUILDSYS_BUILD_LIB)
CMake Error at compily_buildd/cmake/CMakeFunctions.cmake:171 (INSTALL):
install Library TARGETS given no DESTINATION!
Call Stack (most recent call first):
src/CMakeLists.txt:17 (BUILDSYS_BUILD_LIB)
CMake Error at compily_buildd/cmake/CMakeFunctions.cmake:301 (INSTALL):
install TARGETS given no RUNTIME DESTINATION for executable target
"omron_720IT_test".
Call Stack (most recent call first):
examples/CMakeLists.txt:12 (BUILDSYS_BUILD_EXE)
CMake Error at compily_buildd/cmake/CMakeFunctions.cmake:301 (INSTALL):
install TARGETS given no RUNTIME DESTINATION for executable target
"omron_790IT_test".
Call Stack (most recent call first):
examples/CMakeLists.txt:12 (BUILDSYS_BUILD_EXE)
Configuring incomplete, errors occurred![/code]
Configuration of CMake at the point of the errors:
http://www.flickr.com/photos/55104739@N06/sets/72157625112529687
I think once these are handled, I can finally build and do something with the code.
If I can create my own DLL's then maybes once I have developed the code for my own use, i will contribute it (it might be useful) lol
That was a bug in the build system, just pushed a fix for it. You'll need to update the compily_buildd submodule.
I updated compily_buildd and reran... errors gone although unfortunately, they are replaced with the following.
I have no idea what cmake is unfortunately, otherwise I'd have a try at fixing this my self.
Using compily_buildd git submodule C:/Users/Gavin/Documents/Projects/Omron_git/libomron/compily_buildd/cmake
Install Directory Prefix:
Include Install Directory: /include
Library Install Directory: /lib
Runtime Install Directory: /bin
Building Static Libraries for LIBOMRON
Building Shared Libraries for LIBOMRON
Setting build RPATH for LIBOMRON
Configuring done
Generating done
CMake Error: Unknown Target referenced : REQUIRED_DEPENDENCIES_TARGET
CMake Error: Target: omron_720IT_test depends on unknown target: REQUIRED_DEPENDENCIES_TARGET
CMake Error: Unknown Target referenced : REQUIRED_DEPENDENCIES_TARGET
CMake Error: Target: omron_790IT_test depends on unknown target: REQUIRED_DEPENDENCIES_TARGET
CMake Error: Unknown Target referenced : REQUIRED_DEPENDENCIES_TARGET
CMake Error: Target: omron_SHARED depends on unknown target: REQUIRED_DEPENDENCIES_TARGET
CMake Error: Unknown Target referenced : REQUIRED_DEPENDENCIES_TARGET
CMake Error: Target: omron_STATIC depends on unknown target: REQUIRED_DEPENDENCIES_TARGET
Actually, I decided to try and look at the source code and noticed that the test application "omron_790it_test" compiled and built, although as you said, it's freezing on attempting to read.
Sorry to bombard you. I finally managed to get a virtualbox setup going with WXP. With this I recorded the Omron software doing it's thing and also recorded your 790it test. it appears (in the log) that your not sending a clearing block after setting the mode.
Created using SnoopyPro -
http://www.gav-roberts.co.uk/omron/7080it.usblog - Downloading ALL data from management suit
http://www.gav-roberts.co.uk/omron/omron_test.usblog - Running your 790IT test program
I accidently saved one as an XML file originally, not sure if it's of any use what so ever.
http://www.gav-roberts.co.uk/omron/m10-it.xml
Hope that helps!
Ok, first off, fixed and pushed compily_buildd again. Sorry for the issues with that, I have no idea how I managed to build stuff with it over the weekend with those bugs there.
As for the clearing block, huh, weird that it works with the pedometer but not the BP monitor on windows. I was pretty sure those both use the same mode functions. I'll try to take a look at that tonight and fix it.
Thanks Kyle!
It seems ALL hid.dll/winusb related code hangs on reading. I think I've gone through absolutely every HID class to try and read/write.
There has been only one instance where I've had a response from the device and that was simply returning 7-9 bytes all 0.
It might be worth looking at the usblog's I created earlier. If your able to match that with your findings, we might find where it's going wrong?
All of the other libraries I have used, always send 7-9 bytes where as the recorded commands when setting the mode only send two. I think that might be the cause of my issues.
Thank you for contributing on this ;)
I'll have a look at that tonight, but if you look in the repo's doc/logs directory, there's old logs of the BP monitor which is what the library was originally built off of, so that's where that information came from in the first place. If that doesn't match up with what you're seeing, then yeah, that might be the issue.
I think my problem is I'm struggling to find a method of accessing my device and returning a result.
I've not had much exposure to C/C++, but I have a feeling I will have to dive into either accessing the hid.dll/winusb directly via pinvoke in C# or via C/C++.
I'll have another play tomorrow with the new changes, see if that makes any difference, seems odd it's not reading, which means we're not initializing the device correctly, although I don't see anything special going on that's different to what they are doing.
Are you able to run your pedometer in Windows?
According to the 790it protocol, you have to go through the mode's before you can read data? I think you need to run 01 01 first, where as your PEDOMETER_MODE is 01 02.
I wonder if setting 01 02 before 01 01, isn't tellin the device to return the correct initial response?
I'll have a play tomorrow ;)
You probably won't have to get into hid.dll too much, assuming I can just generate a C# SWIG class based on this stuff.
And, yes, the pedometer works on linux, mac, windows, the blood pressure monitor works on linux and mac, but not windows. That's the part that's most confusing, I don't understand what the platform difference is that's causing it not to run on just windows. Honestly, I don't remember how far back in the code I put in BP monitor support, either. I need to rewind back to my initial work on the BP monitor in June 2009 and see what's changed since then that might've broken.
Ok, didn't have a lot of time to work on this tonight, but: Changing PEDOMETER_MODE to 0x0101 didn't do anything, and neither did trying to send a clear first. Something is really wrong here and I'm not sure what. Basically, there's /some/ signal that's sent, possibly when opening the device, that turns on the unit so it'll start talking. That's not happening on windows anymore. Not sure what would be different on other platforms, but, well, such is the fun of cross platform drivers. Will start looking through old code and see if I'm missing something from that.
Ok, backing ALL the way out to commit a0f7a41... and building a VS project by hand made the communication with the bp monitor work again on WinXP using the current WDK, so I need to figure out what the differences in the code are that caused this. Thursday is gonna be the earliest I can get to that, gonna be busy all evening tomorrow.
It's odd that your pedometer works as they are both running on similar firmware.
Are you able to control voltage with your code? I recall seeing somewhere the voltage increasing.
I'll have a fiddle today to see if I can track it down.
Thanks again ;)
Might be going on a whim here but I'm using the ddk and not the wdk. Would make any difference?
It appears I pressed the wrong comment button and closed this. How do I undo that lol
Great that you got it working on WXP!
Just when you can mate, I am in a rush but I can wait. I just want something I can start developing with lol
Again, thanks for your help!
I managed to get some of my own code working... finally.
Most, if not all of the examples of HID implementation out there in C# is asyncronous, which isn't very useful for an application like this.
I finally managed to make it syncronous but as a result, if you call Read on the handle before data is available, it causes a blocking effect on the device.
Fingers crossed, your code will be available soon ;)
Fixed! The return codes from the libusb and win32 omron_set_mode functions were different. win32 would return 0 on success, libusb would return the number of bytes it received. When I did the libusb integration, I changed the logic to check whether the return value was > 0 instead of ==0, so the win32 version was skipping the post mode-set clearing. Update your branch, see if you can get this to work, and I'll go ahead and close this out if so. Note that you may have to have the BP monitor on to get it to not freeze up. If it looks like it's freezing, hit the sun/moon buttons and that should start it up. That's another bug that I'm going to file against myself here, but doesn't directly relate to this (because that happens on all platforms)
The device sends data when you press the memory, day/night and start buttons, so thst could be setting off your code?
With my code it doesn't matter if its turned on or not. In fact, the software I've created so far uses the auto start button to start connecting.
Once the reading has been taken, the device allows you to start reading.
I'll have another look at your code now I have an idea of what to look for. The whole process in my app looks very messy lol it'd be great to get your code working to clean it up.
I'll download it all shortly and let you know what happens.
Ps can you reopen the issue again? I'm sending this from my phone and the silly touch screen hit comment and close lol
Looking good ;)
Found 1 omron 790ITs
Opened omron 790IT
Device serial: M7080IT 207J
Device version: 0310100000♥J
AJR data count: 23
28/10/2010 09:53:20 SYS: 100 DIA: 61 PULSE: 72
28/10/2010 14:00:53 SYS: 122 DIA: 65 PULSE: 69
28/10/2010 14:01:52 SYS: 105 DIA: 60 PULSE: 69
28/10/2010 16:49:30 SYS: 116 DIA: 72 PULSE: 67
28/10/2010 16:56:39 SYS: 115 DIA: 70 PULSE: 76
28/10/2010 17:36:54 SYS: 111 DIA: 70 PULSE: 71
28/10/2010 17:38:49 SYS: 111 DIA: 74 PULSE: 70
28/10/2010 17:41:57 SYS: 107 DIA: 60 PULSE: 79
28/10/2010 17:43:44 SYS: 104 DIA: 67 PULSE: 66
28/10/2010 17:45:24 SYS: 103 DIA: 66 PULSE: 69
28/10/2010 17:48:01 SYS: 109 DIA: 66 PULSE: 74
28/10/2010 17:51:43 SYS: 100 DIA: 72 PULSE: 76
28/10/2010 17:58:20 SYS: 110 DIA: 61 PULSE: 71
28/10/2010 17:59:36 SYS: 110 DIA: 71 PULSE: 72
28/10/2010 18:01:11 SYS: 110 DIA: 70 PULSE: 69
29/10/2010 10:25:21 SYS: 117 DIA: 71 PULSE: 68
29/10/2010 10:46:33 SYS: 115 DIA: 63 PULSE: 65
29/10/2010 10:54:38 SYS: 105 DIA: 69 PULSE: 73
29/10/2010 10:56:51 SYS: 108 DIA: 72 PULSE: 69
29/10/2010 10:58:27 SYS: 99 DIA: 69 PULSE: 68
29/10/2010 10:59:55 SYS: 100 DIA: 66 PULSE: 69
29/10/2010 11:01:21 SYS: 115 DIA: 64 PULSE: 64
29/10/2010 11:05:35 SYS: 130 DIA: 80 PULSE: 54
Weekly info:
Morning[0 24/10/2010] = sys:100 dia:61 pulse:72.
It worked without having to press any buttons but I noticed on a second run, you had to press a button before it'd start reading. This seems odd?
To get around this, I think I ended up sending an empty 7 x 0x0 packet before hand that would cause the device to return.
It'd be great to get that functionality into a DLL that I can expose. I need something a little more reliable then what I already have.