Your comments
Hi Alejandro
We don't recommend building the codebase directly on embedded devices. It would be technically possible except that earlier this year Oracle withdrew JavaFX support from the JDK for embedded ARM devices in 8u33. More information about their decision can be found here.
That said we *do* recommend running "device adapters" on the beaglebone black platform from the console. In this mode JavaFX is not required at runtime. This is why OpenICE built on an x86_64 platform can run on a beaglebone black. So the problem, really, is that our console-oriented code and JavaFX code are both housed in the interop-lab/demo-apps project and the build process expects JavaFX (hence the error you have received).
We'd like, in the future, to segregate JavaFX components in a separate artifact and provide build options that exclude those JavaFX components to allow a build on ARM. Based on our current workload and available resources it will be a few months before anyone here is able to take on this project. We'd welcome help from anyone in the community who would like to help refactor the codebase in this way.
For more information on building on an x86_64 machine and deploy to an ARM device see a previous answer:
http://community.openice.info/topic/805647-how-to-build-openice-source-on-bbb/
Thank you very much
Jeff Plourde
We don't recommend building the codebase directly on embedded devices. It would be technically possible except that earlier this year Oracle withdrew JavaFX support from the JDK for embedded ARM devices in 8u33. More information about their decision can be found here.
That said we *do* recommend running "device adapters" on the beaglebone black platform from the console. In this mode JavaFX is not required at runtime. This is why OpenICE built on an x86_64 platform can run on a beaglebone black. So the problem, really, is that our console-oriented code and JavaFX code are both housed in the interop-lab/demo-apps project and the build process expects JavaFX (hence the error you have received).
We'd like, in the future, to segregate JavaFX components in a separate artifact and provide build options that exclude those JavaFX components to allow a build on ARM. Based on our current workload and available resources it will be a few months before anyone here is able to take on this project. We'd welcome help from anyone in the community who would like to help refactor the codebase in this way.
For more information on building on an x86_64 machine and deploy to an ARM device see a previous answer:
http://community.openice.info/topic/805647-how-to-build-openice-source-on-bbb/
Thank you very much
Jeff Plourde
Thomas
You are correct on all accounts and I apologize for the delay in letting letting you know.
The Philips interface protocol bypasses the "Scanner" package of ISO/IEEE 11073-10201 by utilizing a "priority list". Once the list is configured the monitor will spontaneously emit as many of the values in the list as it can (constrained by packet size, etc.) Our driver creates a priority list from the values specified in intellivue.map. So you were correct to add what values you would like to see to that file; and remember that the ordering is important.
Regarding the adjustment to the VentilatorPanel UI to include MDC_AWAY_RESP_RATE by all means a pull request on Github would be great!
I added *_AWAY_CO2_ET to our canonical priority list at https://github.com/mdpnp/mdpnp/commit/8383f2c1c4c03edcd60676bdf899479ea69349b8
and we are able to receive this value from our Intellivue devices using Philips capnography. We do not have an intellibridge module configured for a Dräger vent in the lab but as I understand the Philips documentation I would have expected that your configuration was correct. Ideally you could get documentation on the Intellibridge module that would tell you how nomenclature has been mapped. Barring that you could try a few other nomenclature codes to determine if they are getting set. For instance NOM_VENT_AWAY_CO2_EXP/MDC_VENT_AWAY_CO2_EXP/NLS_NOM_VENT_AWAY_CO2_EXP seems like a reasonable mapping someone might have made.
Also, and this is empirically based only, you could try creating a "Label" with the value of 0x000250B0 (perhaps called NLS_ NOM_AWAY_CO2_ET) and specifying that along with NOM_AWAY_CO2_ET/MDC_AWAY_CO2_ET.
I hope this extra information is helpful. I'm know that the etCO2 value is in the system somewhere. We'll try to think of more resources we can draw upon here to find out its nomenclature code.
Thanks
Jeff Plourde
You are correct on all accounts and I apologize for the delay in letting letting you know.
The Philips interface protocol bypasses the "Scanner" package of ISO/IEEE 11073-10201 by utilizing a "priority list". Once the list is configured the monitor will spontaneously emit as many of the values in the list as it can (constrained by packet size, etc.) Our driver creates a priority list from the values specified in intellivue.map. So you were correct to add what values you would like to see to that file; and remember that the ordering is important.
Regarding the adjustment to the VentilatorPanel UI to include MDC_AWAY_RESP_RATE by all means a pull request on Github would be great!
I added *_AWAY_CO2_ET to our canonical priority list at https://github.com/mdpnp/mdpnp/commit/8383f2c1c4c03edcd60676bdf899479ea69349b8
and we are able to receive this value from our Intellivue devices using Philips capnography. We do not have an intellibridge module configured for a Dräger vent in the lab but as I understand the Philips documentation I would have expected that your configuration was correct. Ideally you could get documentation on the Intellibridge module that would tell you how nomenclature has been mapped. Barring that you could try a few other nomenclature codes to determine if they are getting set. For instance NOM_VENT_AWAY_CO2_EXP/MDC_VENT_AWAY_CO2_EXP/NLS_NOM_VENT_AWAY_CO2_EXP seems like a reasonable mapping someone might have made.
Also, and this is empirically based only, you could try creating a "Label" with the value of 0x000250B0 (perhaps called NLS_ NOM_AWAY_CO2_ET) and specifying that along with NOM_AWAY_CO2_ET/MDC_AWAY_CO2_ET.
I hope this extra information is helpful. I'm know that the etCO2 value is in the system somewhere. We'll try to think of more resources we can draw upon here to find out its nomenclature code.
Thanks
Jeff Plourde
Hi Thomas,
Thank you for the pertinent line from the log. About 6 weeks ago we stopped offering "BY_SOURCE" destination ordering (ordinal 1) and switched to "BY_RECEPTION" ordering (ordinal 0). The log message you included indicates the relevant reader is still requesting BY_SOURCE ordering and is therefore incompatible with what has been offered by the writer. The reader in this case is the hello-openice app.
The relevant commit that changed this QoS configuration in hello-openice is: https://github.com/mdpnp/hello-openice/commit/727527f8895ebbfcd115ebce7ec054d6903414ea
Essentially as long as your hello-openice is using the latest USER_QOS_PROFILES.xml and you are running the program from that directory which contains that QoS file I don't know what could be making your reader request BY_SOURCE ordering. We've tried to reproduce the problem here but hello-openice works every time. Are there any other anomalies in the log for which this may be a side effect? Maybe you could attach the whole file and we could have a look?
In case anyone is wondering data from a single writer is still guaranteed to be delivered in order with BY_RECEPTION ordering. This setting primarily affects ordering of samples from various writers for shared data instances (of which we currently have none).
Regards
Jeff Plourde
Thank you for the pertinent line from the log. About 6 weeks ago we stopped offering "BY_SOURCE" destination ordering (ordinal 1) and switched to "BY_RECEPTION" ordering (ordinal 0). The log message you included indicates the relevant reader is still requesting BY_SOURCE ordering and is therefore incompatible with what has been offered by the writer. The reader in this case is the hello-openice app.
The relevant commit that changed this QoS configuration in hello-openice is: https://github.com/mdpnp/hello-openice/commit/727527f8895ebbfcd115ebce7ec054d6903414ea
Essentially as long as your hello-openice is using the latest USER_QOS_PROFILES.xml and you are running the program from that directory which contains that QoS file I don't know what could be making your reader request BY_SOURCE ordering. We've tried to reproduce the problem here but hello-openice works every time. Are there any other anomalies in the log for which this may be a side effect? Maybe you could attach the whole file and we could have a look?
In case anyone is wondering data from a single writer is still guaranteed to be delivered in order with BY_RECEPTION ordering. This setting primarily affects ordering of samples from various writers for shared data instances (of which we currently have none).
Regards
Jeff Plourde
Hi Thomas,
Thank you for your feedback. Let me try to make sure I understand what has and hasn't worked for you. Also, for my reference, are you using the latest version 0.6.1 of the software?
If I understand you correctly running the OpenICE software on your laptop, specifying the IntellivueEthernet device and your phys. monitor's IP address allowed you to connect successfully?
Also when you say the device adapter has been unable to connect are you referring to a beaglebone device adapter?
Some other useful background information:
Thank you, it is very helpful to know you are seeing CONNECT INDICATION events to the broadcast address because it tells us you've gotten IP networking squared away on the monitor. If you leave the device adapter "address" specified as a blank string it ought to await these beacons and attempt to connect to the first monitor it "hears". We have limited resources so we don't get to regression test this behavior for every release but I'll double-check it in the lab. When you specify an ip endpoint for the connection these beacons are ignored by the device driver.
Currently we are using standards-based DDS middleware along with the standardized RTPS/DDSI wire protocol. The only standardized "platform-specific module" of that wire protocol is based on UDP/IP so an active network stack is indeed required. We are using a community-licensed implementation from RTI that we to-date haven't been able to configure to successfully use the loopback adapter so yes a true active network is currently required. You're not the first person to encounter this problem and we're trying to consider ways to ameliorate it. This is, in fact, the most common source of 'entity creation' errors people see as the DDS library will not successfully initialize when it has no means to communicate with other network nodes.
Also regarding the serial port connection I'm glad that you are also attempting that modality. A common source of PortInUseExceptions stems from the common use of RS-232 connections for consoles in the beaglebone community. So when we buy mini RS-232 capes they are hardwired for ttyO0 and the default debian distribution assigns a getty console to that port. In our images for beaglebone we've disabled that serial port console. In our images we also typically add the default 'debian' use to the dialout group because the /dev/ttyO0 port gets root ownership in the dialout group by default.
I hope with more info we can get you up and running!
Thanks
Jeff Plourde
Thank you for your feedback. Let me try to make sure I understand what has and hasn't worked for you. Also, for my reference, are you using the latest version 0.6.1 of the software?
If I understand you correctly running the OpenICE software on your laptop, specifying the IntellivueEthernet device and your phys. monitor's IP address allowed you to connect successfully?
Also when you say the device adapter has been unable to connect are you referring to a beaglebone device adapter?
Some other useful background information:
Thank you, it is very helpful to know you are seeing CONNECT INDICATION events to the broadcast address because it tells us you've gotten IP networking squared away on the monitor. If you leave the device adapter "address" specified as a blank string it ought to await these beacons and attempt to connect to the first monitor it "hears". We have limited resources so we don't get to regression test this behavior for every release but I'll double-check it in the lab. When you specify an ip endpoint for the connection these beacons are ignored by the device driver.
Currently we are using standards-based DDS middleware along with the standardized RTPS/DDSI wire protocol. The only standardized "platform-specific module" of that wire protocol is based on UDP/IP so an active network stack is indeed required. We are using a community-licensed implementation from RTI that we to-date haven't been able to configure to successfully use the loopback adapter so yes a true active network is currently required. You're not the first person to encounter this problem and we're trying to consider ways to ameliorate it. This is, in fact, the most common source of 'entity creation' errors people see as the DDS library will not successfully initialize when it has no means to communicate with other network nodes.
Also regarding the serial port connection I'm glad that you are also attempting that modality. A common source of PortInUseExceptions stems from the common use of RS-232 connections for consoles in the beaglebone community. So when we buy mini RS-232 capes they are hardwired for ttyO0 and the default debian distribution assigns a getty console to that port. In our images for beaglebone we've disabled that serial port console. In our images we also typically add the default 'debian' use to the dialout group because the /dev/ttyO0 port gets root ownership in the dialout group by default.
I hope with more info we can get you up and running!
Thanks
Jeff Plourde
Vasanth
Just to clarify in that image a Multiparameter monitor simulator (specified by /home/debian/device.this) should be started via the System V initialization script at /etc/init.d/device-adapter. I'm assuming that's the service to which you are referring? Perhaps we should add a "status" verb to that service script for debugging.
I'm also guessing that if you run the software directly from a console... something like
Also does anything appear in /home/debian/log/device-adapter.log? Especially entries above INFO criticality.
Thanks
Jeff Plourde
Just to clarify in that image a Multiparameter monitor simulator (specified by /home/debian/device.this) should be started via the System V initialization script at /etc/init.d/device-adapter. I'm assuming that's the service to which you are referring? Perhaps we should add a "status" verb to that service script for debugging.
I'm also guessing that if you run the software directly from a console... something like
/home/debian/OpenICE-0.6.1/bin/OpenICE -domain 15 -app ICE_Device_Interface -device Multiparameterthat it starts up successfully? I'm just trying to narrow it down to some facet of that initialization script.
Also does anything appear in /home/debian/log/device-adapter.log? Especially entries above INFO criticality.
Thanks
Jeff Plourde
Vasanth,
Thank you very much for answering your own question! Did it take any unusual steps to succeed? afaik the newer beagles with stock debian will automatically boot from the microsd (without depressing the "option" button)... has that been your experience as well? Also when you get a moment could you add a link to the windows disk imager tool you used? or it is built into newer windows versions?
For anyone else reading it the disk image Vasanth is referring to is posted here:
https://www.openice.info/device-adapter-setup.html#required-software
Thank you
Jeff Plourde
Thank you very much for answering your own question! Did it take any unusual steps to succeed? afaik the newer beagles with stock debian will automatically boot from the microsd (without depressing the "option" button)... has that been your experience as well? Also when you get a moment could you add a link to the windows disk imager tool you used? or it is built into newer windows versions?
For anyone else reading it the disk image Vasanth is referring to is posted here:
https://www.openice.info/device-adapter-setup.html#required-software
Thank you
Jeff Plourde
Thanks for watching out for it!
For the record the new images are linked from:
https://www.openice.info/device-adapter-setup.html#required-software
I see that you've got other questions that hopefully we can answer all together. So you know in addition to beagles connected to med devices we've got about 14 RevC beagles (pictured) and 7 RevBs currently running simulators in a 'testbed' in our lab and one of my colleagues is working on manageability and devops strategies for those beagles once they get into "the field". Also another colleague has installed different types of real-time clocks into two of the beaglebones (marked with white labels in the picture). As you know a beaglebone with a realtime clock would ameliorate a lot of issues with our 100% NTP-dependence.
We are still doing our own testing but I'm curious your opinion about the switch to Debian. I made it because Debian is now the "stock" install on the beagles. In addition the USB networking "gadget" is terribly useful for debugging (i.e. being able to ssh into the beagle over the USB connection) since we've disabled the console on the RS-232 port in favor of its use for med device connectivity. We were even thinking we could make modifications to the default "start" webpage that the beagle hosts for its PC peer to help make the process of getting started with beagles and OpenICE easier.
What do you think about the choice? There are definitely advantages to ubuntu as well but at this time Debian seemed to me to have more.
Thanks
Jeff Plourde
For the record the new images are linked from:
https://www.openice.info/device-adapter-setup.html#required-software
I see that you've got other questions that hopefully we can answer all together. So you know in addition to beagles connected to med devices we've got about 14 RevC beagles (pictured) and 7 RevBs currently running simulators in a 'testbed' in our lab and one of my colleagues is working on manageability and devops strategies for those beagles once they get into "the field". Also another colleague has installed different types of real-time clocks into two of the beaglebones (marked with white labels in the picture). As you know a beaglebone with a realtime clock would ameliorate a lot of issues with our 100% NTP-dependence.
We are still doing our own testing but I'm curious your opinion about the switch to Debian. I made it because Debian is now the "stock" install on the beagles. In addition the USB networking "gadget" is terribly useful for debugging (i.e. being able to ssh into the beagle over the USB connection) since we've disabled the console on the RS-232 port in favor of its use for med device connectivity. We were even thinking we could make modifications to the default "start" webpage that the beagle hosts for its PC peer to help make the process of getting started with beagles and OpenICE easier.
What do you think about the choice? There are definitely advantages to ubuntu as well but at this time Debian seemed to me to have more.
Thanks
Jeff Plourde
Hi,
First thank you very much Vasanth for helping Usharani to get started. Our intent in setting up this community site was to help people (including ourselves) learn from one another so that's exciting to see.
To build on Vasanth's answer since we are building a 'platform' it can be confusing because there is no singular use for the system. What you are seeing when you run the supervisory software now are a number of apps we've developed as demonstrations of the capability of the platform. We are working on documentation of these apps to coincide with our version 0.6.2 release this week or next. However these apps are exemplars and are not the end goal of our project in and of themselves.
Currently a number of people are interested in using our prototype platform to develop their own clinical applications. We do offer one of the only open source projects for connecting to medical devices of which I'm aware; but more importantly than mere integration we allow people to tap directly into a near realtime data stream from those devices for their own purposes. Another unique characteristic of our program is that we are actively seeking the feedback from those developers to guide the future development of the platform to understand what is required of a next generation platform to support next generation applications. The process is chaotic but in the end the answer to "what is required of this platform?" cannot be found in our lab alone; it can only be answered by the creativity of future application developers.
A necessary precursor to the development of a wide variety of applications is the collection of clinical data. A number of community members are pursuing data collection projects and we are helping to develop apps to serve this purpose practically (beyond basic demonstrations and examples). Ourselves we are engaged with a couple of clinical centers directly to help show the utility of OpenICE for bootstrapping itself; i.e. collecting high resolution, time-aligned, near real-time data that will be needed to develop newer apps that make use of such data.
There is more overview information available on our website. For example we have videos including an overview that helps to lay out the landscape in which our work resides that you might find helpful.
https://www.openice.info/#videos
And to reiterate what Vasanth already said please feel free to post questions about any specific objectives you might have so that the community can help provide you with guidance and help.
Thank you
Jeff Plourde
First thank you very much Vasanth for helping Usharani to get started. Our intent in setting up this community site was to help people (including ourselves) learn from one another so that's exciting to see.
To build on Vasanth's answer since we are building a 'platform' it can be confusing because there is no singular use for the system. What you are seeing when you run the supervisory software now are a number of apps we've developed as demonstrations of the capability of the platform. We are working on documentation of these apps to coincide with our version 0.6.2 release this week or next. However these apps are exemplars and are not the end goal of our project in and of themselves.
Currently a number of people are interested in using our prototype platform to develop their own clinical applications. We do offer one of the only open source projects for connecting to medical devices of which I'm aware; but more importantly than mere integration we allow people to tap directly into a near realtime data stream from those devices for their own purposes. Another unique characteristic of our program is that we are actively seeking the feedback from those developers to guide the future development of the platform to understand what is required of a next generation platform to support next generation applications. The process is chaotic but in the end the answer to "what is required of this platform?" cannot be found in our lab alone; it can only be answered by the creativity of future application developers.
A necessary precursor to the development of a wide variety of applications is the collection of clinical data. A number of community members are pursuing data collection projects and we are helping to develop apps to serve this purpose practically (beyond basic demonstrations and examples). Ourselves we are engaged with a couple of clinical centers directly to help show the utility of OpenICE for bootstrapping itself; i.e. collecting high resolution, time-aligned, near real-time data that will be needed to develop newer apps that make use of such data.
There is more overview information available on our website. For example we have videos including an overview that helps to lay out the landscape in which our work resides that you might find helpful.
https://www.openice.info/#videos
And to reiterate what Vasanth already said please feel free to post questions about any specific objectives you might have so that the community can help provide you with guidance and help.
Thank you
Jeff Plourde
Hi,
The file 'build/openice.info.js' is generated from src/openice.info.js with browserify. This is a tool that allows us to use node.js style dependency management in the browser. Further we typically invoke this tool through a task runner called grunt.
So after checking out the code, from the root of the repository, 'grunt' must be invoked. And you should see a result like:
Opening demo.html from your own filesystem should now succeed in retrieving data (though not video) from our development environment (https://dev.openice.info) by virtue of this line in src/openice.info.js:
Please let me know if this information was helpful to you.
Thank you
Jeff Plourde
The file 'build/openice.info.js' is generated from src/openice.info.js with browserify. This is a tool that allows us to use node.js style dependency management in the browser. Further we typically invoke this tool through a task runner called grunt.
So after checking out the code, from the root of the repository, 'grunt' must be invoked. And you should see a result like:
zeus:openice jplourde$ gruntThis will populate the required javascript files in the build/ folder. After any subsequent changes to files in the src/ folder grunt must be invoked again. Alternatively a call to 'grunt watch' will detect changes in files and automatically run the required tasks. This is useful during development.
Running "browserify:dist" (browserify) task
Running "browserify:lab" (browserify) task
Running "browserify:numerics" (browserify) task
Running "browserify:diagnostics" (browserify) task
Running "browserify:vitals" (browserify) task
Running "uglify:build" (uglify) task
Done, without errors.
Opening demo.html from your own filesystem should now succeed in retrieving data (though not video) from our development environment (https://dev.openice.info) by virtue of this line in src/openice.info.js:
var wsHost = window.location.protocol == 'file:' ? 'dev.openice.info' : window.location.host;Support for our extensive java code base (http://mdpnp.sourceforge.net) in addition to these HTML5 artifacts is just fraction of the responsibilities of our small grant-funded team. As a result we are not 'supporting' the rather complex and experimental server-side components that feed this data to javascript clients from DDS. If you have a particular interest in helping to test and further develop those components please let me know. I'm receptive to the help; I'm only trying to prevent more people suffering lengthy delays in hearing from one of us.
Please let me know if this information was helpful to you.
Thank you
Jeff Plourde
Customer support service by UserEcho
The "android-apps" project was a simple demonstration of connecting directly to the Nonin Bluetooth Pulse Oximeter from an Android device. The project is no longer part of the build since 19-June-2013. It remains in the repo for reference but it has been deprecated since that time.
https://github.com/mdpnp/mdpnp/commit/3ca61af431974744813a0c735b8d16104e16c6cc
Thank you
Jeff Plourde