Continuously measurement with Nonin 9560BT pulse oximeter

570 views
Skip to first unread message

Christoph Jacob

unread,
Sep 18, 2013, 8:59:37 AM9/18/13
to antido...@googlegroups.com
Hi!

I'm a software developer and want to use the antidote 11073-20601 stack for receiving data continuously from the Nonin 9560BT pulse oximeter.
The problem I have is that after 1-2 received measurements the bluetooth connection goes down and the device is not reconnecting.
 
I have some questions about the Nonin 9560BT device and the antidote 11073 stack:
 
1) Does the Nonin 9560 pulseoximeter in HDP mode support only a single spot measurement or is it possible to do a continuous measurement (e.g. 1 per second)?
 
2) Does the selection of the data format (2,7,8,13) and ATR option in SPP mode have an effect on HDP connections?
 
3) Is it possible to realize a continuous measurement by modifications of the onHealthChannelStateChange callback in BluetoothHDPService?
 
I've tested with HEAD version on Android 4.1.2 and Version 2.0 final on Ubuntu 12.04, same problem.

Thanking you in anticipation
Christoph Jacob
 
Here is the log from Ubuntu 12.04 and antidote version 2.0 final:

DEBUG   <channel_connected in plugin_bluez.c:499> channel connected: /org/bluez/968/hci0/dev_00_1C_05_00_49_51/chan1
DEBUG   <channel_connected in plugin_bluez.c:550> File descriptor: 6
DEBUG   <call_agent_connected in healthd_service.c:850> call_agent_connected
DEBUG   <get_device_object in healthd_service.c:762> Create device object in /com/signove/health/device/1
WARNING <context_get in context_manager.c:196> Cannot find context id 1:1
DEBUG   <context_create in context_manager.c:154> Created context id 1:1
DEBUG   <fsm_process_evt in fsm.c:425>  state machine(<disconnected>): process event <fsm_evt_ind_transport_connection>
DEBUG   <fsm_process_evt in fsm.c:441>  state machine(<disconnected>): transition to <unassociated>
DEBUG   <data_received in plugin_bluez.c:1339> Recv: fd 6, 54 bytes
DEBUG   <get_apdu in plugin_bluez.c:1299> dbus get APDU stream
DEBUG   <get_apdu in plugin_bluez.c:1312>  network:dbus APDU received
DEBUG   <communication_process_apdu in communication.c:681>  communication: current sm(unassociated)
DEBUG   <association_process_aarq_apdu in association.c:143>  associating: processing association request
DEBUG   <association_process_aarq_apdu in association.c:146> associating: association protocol version accepted
DEBUG   <association_accept_data_protocol_20601 in association.c:332> associating: accepted data protocol id <20601>
DEBUG   <association_accept_data_protocol_20601_in in association.c:262> associating: accepted data protocol version <80000000>
DEBUG   <fsm_process_evt in fsm.c:425>  state machine(<unassociated>): process event <fsm_evt_rx_aarq_acceptable_and_known_configuration>
DEBUG   <fsm_process_evt in fsm.c:441>  state machine(<unassociated>): transition to <operating>
DEBUG   <association_accept_config_tx in association.c:382> associating: known configuration
DEBUG   <communication_send_apdu in communication.c:712>  communication: sending APDU
DEBUG   <send_apdu_stream in plugin_bluez.c:1374> Send APDU
DEBUG   <send_data in plugin_bluez.c:1415> Sending 48 bytes of data (offset 0)
DEBUG   <communication_send_apdu in communication.c:730>  communication: APDU sent
DEBUG   <device_associated in healthd_service.c:415> Device associated
DEBUG   <call_agent_associated in healthd_service.c:898> call_agent_associated
DEBUG   <device_getconfig in healthd_service.c:1493> device_getconfig
DEBUG   <data_received in plugin_bluez.c:1339> Recv: fd 6, 58 bytes
DEBUG   <get_apdu in plugin_bluez.c:1299> dbus get APDU stream
DEBUG   <get_apdu in plugin_bluez.c:1312>  network:dbus APDU received
DEBUG   <communication_process_apdu in communication.c:681>  communication: current sm(operating)
DEBUG   <communication_process_roiv in operating.c:218> received ROIV_CMIP_EVENT_REPORT_CHOSEN
DEBUG   <fsm_process_evt in fsm.c:425>  state machine(<operating>): process event <fsm_evt_rx_roiv_event_report>
DEBUG   <fsm_process_evt in fsm.c:441>  state machine(<operating>): transition to <operating>
DEBUG   <operating_event_report in operating.c:337>  operating_event_report
DEBUG   <operating_decode_mds_event in operating.c:1012>  operating: Event Type: 3357
DEBUG   <new_data_received in healthd_service.c:334> Medical Device System Data
DEBUG   <call_agent_measurementdata in healthd_service.c:949> call_agent_measurementdata
DEBUG   <channel_deleted in plugin_bluez.c:573> channel destroyed: /org/bluez/968/hci0/dev_00_1C_05_00_49_51/chan1
DEBUG   <fsm_process_evt in fsm.c:425>  state machine(<operating>): process event <fsm_evt_ind_transport_disconnect>
DEBUG   <fsm_process_evt in fsm.c:441>  state machine(<operating>): transition to <disconnected>
DEBUG   <manager_handle_transition_evt in manager.c:768>  manager: Notify device unavailable.

DEBUG   <device_disassociated in healthd_service.c:430> Device unassociated
DEBUG   <call_agent_disassociated in healthd_service.c:1337> call_agent_disassociated
DEBUG   <destroy_context in context_manager.c:71>  communication: destroying context 1:1
DEBUG   <call_agent_disconnected in healthd_service.c:1384> call_agent_disconnected
DEBUG   <disconnect_channel in plugin_bluez.c:588> removing channel

victor yeo

unread,
Sep 18, 2013, 9:53:58 PM9/18/13
to antido...@googlegroups.com
on your questions:

1) Nonin 9560 pulseoximeter cannot support continuous measurement, after it takes one measurement, it will power off.

2) which SPP mode is that? SPP mode should not matter to HDP mode.

Victor

Christoph Jacob

unread,
Sep 19, 2013, 5:31:11 AM9/19/13
to antido...@googlegroups.com
1) The device I tested doesn't power off after 1 measurement, only the bloetooth conenction is going down. The device is still operating and I can read the measurements on the display of the device until i pull out my finger. Then after a couple of seconds the device is powering off.

2) I mean the Serial Port Profile (SPP). Data format 8 provides real-time oximetry measurements every second. But i think you are right, the change of the data format only affects the SPP mode..

MUKESH MANSANE

unread,
Jan 7, 2014, 11:45:08 PM1/7/14
to antido...@googlegroups.com
Hi Christoph,

Hope you are doing well. I also working in medical health application for android, can you pls provide me code sample that how should i make connection between
Pulse Oximeter (Nonin 9560) and retrieve measurement in android.

Your any suggestion is helpful for me.
Thanks,

Roman Popov

unread,
Mar 16, 2014, 8:19:40 AM3/16/14
to antido...@googlegroups.com
Hello Christoph,

Did you solve your problem with continuously measurement? I'm trying to implement such things and got stuck in the same place. Did you find any work-around?

Christoph Jacob

unread,
Mar 17, 2014, 4:42:43 AM3/17/14
to antido...@googlegroups.com
No, i have given up to use 11073 and used the SPP mode instead..
--
You received this message because you are subscribed to the Google Groups "Antidote: open-source IEEE 11073 stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to antidote-lib...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Message has been deleted

Jimmy

unread,
Nov 18, 2014, 4:59:23 PM11/18/14
to antido...@googlegroups.com
Hi Christoph,

I hope you are doing well.

I am trying to get continuous measurement data from Nonin 9560BT pulse oximeter. I noticed that the default data format 13 which doesn't support real-time data. The things is how to change the data format from the antidote project? I mean make the whole things work. 

sample code will be better.

I tracked the data that read and write between the android device and the pulse oximeter.

 thay are like :

read from oximeter:e2000032800000000001002a507900268000000080008000000000000000008000000008001c05010000d6bd01910001010000000000

write to oximeter:e300002c0000507900268000000080008000000000000000800000000008112233445566778800000000000000000000

write to oximeter:e700000e000c000001030006000000000000

read from oximeter:    e70000b800b60000020300b00000000900aa098f00040072d1c00a4b0016000200120201000801000001000200040202000200000a5a000800010004100400010928002200144e6f6e696e204d65646963616c2c20496e632e00000a4d6f64656c20393536300984000a0008001c05010000d6bd0a4400020191092d001e0002001a00010000000a30313030303044364244000500010004302e39430a450010e0001f00ffffffff0064005000000000098700082007100104002500

read from oximeter :e7000036003480000100002e0000007380700d1d0024f00000000002001c0001000a00622007100104002900000a000a00542007100104002900

oximeter send command to close bluetooth connection.


srikkanth iyer

unread,
Feb 4, 2016, 4:50:43 AM2/4/16
to Antidote: open-source IEEE 11073 stack
Hi All,

This might probably be really late, but i thought of replying to this as it might help someone else looking for the same in future.

To get Continuous data from Nonin OnyxII 9560 BT pulse oximeter over HDP/IEEE 11073 layer the Manager application(Phone/PC i.e. the PulseOximeter Manager) has to reject the initial configuration 0x0191(i.e 401) reported by Nonin device and accept the next configuration 0x0190(i.e. 400). Once the Manager is assosiated with the 0x0190 configuration of the Nonin device, then there is continuous data coming from the Pulse Oximeter.

This is because according to the "IEEE 11073 10404 Pulse Oximeter Device Specialization" the Standard Configuration 0x0191 has an supplemental Attribute called as SPOT MODALITY which is used in the "Spot - Check" Measurement mode of PulseOximeter. "Spot-Check" mode is where only the first "best" measurement is sent across to the Manager from the Agent device.

The Standard Configuration 0x0190 is used to report continuous measurement values to the Manager.

Hope this helps people who want to go with HDP/IEEE 11073 instead of SPP.

Regards,
Srikkanth

Badri K

unread,
Feb 4, 2016, 5:05:02 AM2/4/16
to Antidote: open-source IEEE 11073 stack
Hi,

Adding to the above input, here is a Product Note document (https://cw.continuaalliance.org/document/dl/11858) from Continua that lists all qualified IEEE products with brief technical notes. The how-to of the 9560's streaming mode is better given in this document than the products technical specification. This might also be the case with other such devices and this document might be handy for people experimenting with such devices.

Cheers!

angrybird

unread,
Feb 22, 2016, 11:55:55 PM2/22/16
to Antidote: open-source IEEE 11073 stack
Hi Srikkanth,

Iam trying to use nonin pulse meter for one of my apps to read the pulses using Bluetooth. I have paired manually and connected , but not understanding how to read the data..Can you give sample if u have any please?

angrybird

unread,
Feb 22, 2016, 11:56:25 PM2/22/16
to Antidote: open-source IEEE 11073 stack
Hi Srikkanth,

Iam trying to use nonin pulse meter for one of my apps to read the pulses using Bluetooth. I have paired manually and connected , but not understanding how to read the data..Can you give sample if u have any please?

On Thursday, February 4, 2016 at 3:20:43 PM UTC+5:30, srikkanth iyer wrote:

Andreas Hansen

unread,
Jan 11, 2017, 10:11:48 AM1/11/17
to Antidote: open-source IEEE 11073 stack
- srikkanth

How do you tell the manager to reject the initial configuration (0x0191) and only accept the next (0x0190). Is that possible to do using the Manager API?

I'm working on a Nonin 3150 oximeter that is currently configured in DF13 with ATR enabled. A connection is established when it wakes up, then it sends a single measurement and disconnects. This is not good enough for my application, where I need continuous measurements.

Best Regards,
Andreas
Reply all
Reply to author
Forward
0 new messages