Custom Data Consumer

Hi Thomas,

This sounds like an exciting project! We have in fact implemented the Philips MIB protocol and tested on the MP70 and MX800. Other intellivue monitors should work but YMMV.

I would emphatically recommend option A. The easier to implement OpenICE than to re-invent the Intellivue device-adapter. Option A has a major advantage over a standalone implementation of the Intellivue protocol - the OpenICE system integrates the data from all supported devices and manufacturers on the ICE network. If your head-mounted device also wanted to include data from the patient's ventilator or anesthesia machine or use a monitor from a different manufacturer, that's possible without much additional development (presuming the device-adapter has been written already or you could write a new one yourself).

There is usually one or more Intellivue devices connected to our streaming demo. You can check it out here: https://www.openice.info/diagnostics.html. For example, select the patient "John Sullivan" in the "Partition" field to see the Philips MX800. An application written for OpenICE would be able to receive any data on the page. 

Our platform is still in alpha and is moving quickly so the documentation has been unfortunately sparse lately. We do however have some resources available:
A wiki of sorts - https://sourceforge.net/p/mdpnp/wiki/Medical%20Device%20Plug-and-Play%20Interoperability%20Lab/
A description of an app's architecture: https://docs.google.com/document/d/1g1zYd3kdxk8tL3zzkTJM38ied9Mi-prGTvvsf9LkDJw
"Hello OpenICE" - https://github.com/mdpnp/hello-openice
The vast majority of OpenICE (not the web demo) is written in Java. Check out the repo here: https://sourceforge.net/projects/mdpnp/

We'd love to help you however we can on our end. Keep us posted on your progress as well!
Also, is it okay if I post your question on our community support page? I like to try and share resources for others looking for the same information.

Thanks!
Jeff Peterson

Hey Jeff,

"Hello OpenICE" looks to be just what I was looking for, thanks very much!
Given that I'll be going option A and building the app to hook up to an OpenICE network.

All very exciting... I'm already having ideas for the studies we could run if we deployed a dozen or so Beaglebones into the OT suite.

And sure, feel free to post to the support page.

Cheers,
Thomas

So, I can get the demo-apps running fine, with an ICE Supervisor and a simulated Pulse Oximeter. That all works fine, really easily out of the box.

Then I've gone and cloned the hello-openice repo, compiled that, and trying to get that to run. However, I'm getting this set of errors:

# ./hello-openice  
 WARN | [D0000|ENABLE]NDDS_Transport_UDPv4_Socket_bindWithIp:0X1CF2 in use
 WARN | [D0000|ENABLE]NDDS_Transport_UDPv4_SocketFactory_create_receive_socket:invalid port 7410
 WARN | [D0000|ENABLE]NDDS_Transport_UDPv4_create_recvresource_rrEA:!create socket
 WARN | [D0000|ENABLE]NDDS_Transport_UDPv4_Socket_bindWithIp:0X1CF4 in use
 WARN | [D0000|ENABLE]NDDS_Transport_UDPv4_SocketFactory_create_receive_socket:invalid port 7412
 WARN | [D0000|ENABLE]NDDS_Transport_UDPv4_create_recvresource_rrEA:!create socket
 WARN | PRESParticipant_assertRemoteParticipant:Warning: remote participant on same host (with name 'Device') has disabled shared memory and this participant ignores UDP loopback. To allow communication, set ignore_loopback_interface to 0
 WARN | PRESParticipant_assertRemoteParticipant:Warning: remote participant on same host (with name '(null)') has disabled shared memory and this participant ignores UDP loopback. To allow communication, set ignore_loopback_interface to 0
 WARN | PRESParticipant_assertRemoteParticipant:Warning: remote participant on same host (with name '(null)') has disabled shared memory and this participant ignores UDP loopback. To allow communication, set ignore_loopback_interface to 0
 WARN | PRESParticipant_assertRemoteParticipant:Warning: remote participant on same host (with name 'Device') has disabled shared memory and this participant ignores UDP loopback. To allow communication, set ignore_loopback_interface to 0
ERROR | DDS_QosProvider_get_profile_xml_objectI:ERROR: Profile 'ice_library::waveform_data' not found
ERROR | DDS_QosProvider_get_datareader_qos_from_profile:ERROR: Profile 'ice_library::waveform_data' not found
Exception in thread "main" com.rti.dds.infrastructure.RETCODE_ERROR
	at com.rti.dds.util.Utilities.rethrow(Unknown Source)
	at com.rti.dds.infrastructure.RETCODE_ERROR.check_return_codeI(Unknown Source)
	at com.rti.dds.domain.DomainParticipantFactoryImpl.get_datareader_qos_from_profile_w_topic_name(Unknown Source)
	at com.rti.dds.subscription.SubscriberImpl.create_datareader_with_profile(Unknown Source)
	at com.rti.dds.domain.DomainParticipantImpl.create_datareader_with_profile(Unknown Source)
	at org.mdpnp.helloice.HelloICE.main(HelloICE.java:49)
ABRT problem creation: 'success'
 WARN | PRESParticipant_assertRemoteParticipant:Warning: remote participant on same host (with name 'Device') has disabled shared memory and this participant ignores UDP loopback. To allow communication, set ignore_loopback_interface to 0
 WARN | PRESParticipant_assertRemoteParticipant:Warning: remote participant on same host (with name '(null)') has disabled shared memory and this participant ignores UDP loopback. To allow communication, set ignore_loopback_interface to 0

This is running on a 64-bit Fedora (RHEL) Linux host, if that makes any difference.

Cheers, Thomas

Hi Thomas,

This sounds like an exciting project!

RTI's DDS implementation allows for Quality of Service settings to be stored in XML 'profiles' (this is an extension to the DDS standard which allows QoS to be set only via API calls).  By default the implementation will look for the USER_QOS_PROFILES.xml file (from which these profiles can be loaded) in the program's working directory.  That is where the profiles for hello-openice are stored.  Ensure that you are running the example program from the root of the project directory (which contains USER_QOS_PROFILES.xml) or move the xml file to wherever you'd like to run the program.

For deployment in the 'demo-apps' runnable package we've bundled these QoS profiles in the application jar which is an option we can discuss long-term as well for your project.  I hope this helps.  Let us know how your work progresses; and perhaps at some point as your plan comes together we can discuss your specific needs from the platform so we can incorporate them into our plans for OpenICE.

Thanks
Jeff Plourde

Hey Jeff,

Thanks, executing the program with USER_QOS_PROFILES.xml in the working directory seems to have improved things.

Now when I execute the program I get the following output:

WARN | DDS_XMLParser_parse_from_file:Loading : USER_QOS_PROFILES.xml
 WARN | [D0000|ENABLE]NDDS_Transport_UDPv4_Socket_bindWithIp:0X1CF2 in use
 WARN | [D0000|ENABLE]NDDS_Transport_UDPv4_SocketFactory_create_receive_socket:invalid port 7410
 WARN | [D0000|ENABLE]NDDS_Transport_UDPv4_create_recvresource_rrEA:!create socket
 WARN | [D0000|ENABLE]NDDS_Transport_UDPv4_Socket_bindWithIp:0X1CF4 in use
 WARN | [D0000|ENABLE]NDDS_Transport_UDPv4_SocketFactory_create_receive_socket:invalid port 7412
 WARN | [D0000|ENABLE]NDDS_Transport_UDPv4_create_recvresource_rrEA:!create socket
 WARN | RTICdrTypeObjectStructureType_is_extensible_assignable:types are not assignable: types have different number of key members
 WARN | RTICdrTypeObjectStructureType_is_assignable:types are not assignable: structures are not assignable: ice::Numeric, ice::Numeric
 WARN | RTICdrTypeObjectStructureType_is_extensible_assignable:types are not assignable: types have different number of key members
 WARN | RTICdrTypeObjectStructureType_is_assignable:types are not assignable: structures are not assignable: ice::SampleArray, ice::SampleArray

I assume that this means that I need to tell the ICE supervisor to listed on 7410 or 7412, but I'm unsure how to do this. It's not a firewall issue as these are both running on the same host, and I also trialled disabling the firewall just in case.

Cheers,
Thomas

Hi Thomas

The warnings regarding bind errors ought to be non-fatal.  In a more permanent deployment multiple participants on the same domain running on the same host can be explicitly set to bind to different ports.  Alternatively what you're seeing is DDS 'discovering' that certain ports are already in use by another participant and moving on to use others harmlessly.

The subsequent unassignable data type warnings are more serious and probably are the result of the hello-openice project using our data structures as defined in version 0.4.3 to try communication with the 'demo-apps' bundle that you downloaded at version 0.5.0.  Our data model is still subject to a lot of change as we experiment with different approaches.  In version 0.5.0 we have marked all our types as 'MUTABLE' which should help going forward to increase compatibility between versions with changes to the data model.

I pushed changes to the hello-openice project to have it use version 0.5.0 of the data model (matching our current 'demo-apps' distribution) and I added a note about this to the README.md.  If you 'git pull' the latest you ought to have more success.  

While I was 'in there' I also added a second code path to the example showing the sometimes simpler case of receiving data availability signals directly from a middleware thread (instead of signaling your own thread via condition variables).  In the lab we've also started experimenting with our own abstraction layers and I will try to include demonstrations of those soon.

Regards
Jeff Plourde

Hey Jeff,

Thanks for updating hello-openice for me. I will look into this further, and let you know how I get on.

Thomas

Hi Jeff,

Using the updated hello-openice I successfully connected to my OpenICE supervisor.

Thanks for all your assistance.

Thomas