Add quick plane switching capability to BK biplane probes

[Sunderlandkyl]

With the current vtkBkProFocusVideoSource switching between sagittal and axial transducer requires disconnect and connect. Now Plus supports multiple output channels (each with a different video stream) for devices. However, the BK video source should be update to take advantage of this. The BK video source should detect which scan plane is used for each acquired frame and emit the video on the appropriate corresponding output channel.

Implementation steps:

• mechanism to get the plane info from BK (Andriy)
• second output channel (Andras, Adam)
• test everything with the real hardware (Andriy)

Migrated from https://app.assembla.com/spaces/plus/tickets/674/details

[Sunderlandkyl]

2013-02-15 10:55
Andrey Fedorov
Getting plane info from BK update:

BK supports a list of events attached at the bottom of the message. Subscription to events is done as follows (we have oemClient in bkProFocusVideoSource):

this->oemClient->RegisterCallbackFunc(AutoUpdate, this->buffer, sizeof(this->buffer),"EVENT:");

When event arrives, buffer looks like this: "EVENT:<event_type>;". I tested, and this does work for events like FREEZE/UNFREEZE and TRANSDUCER_CONNECT (by the way, I think it may make sense to handle FREEZE event, to notify the user at least).

According to the BK technical contact, there is also event SCAN_PLANE that should be sent when sagittal/transverse arrays are switched on 8848. However, experiments show that when this switch happens, the event received is DIAGNOSTIC_SETUP_SELECTED, not SCAN_PLANE.

I emailed our contact at BK about the inconsistent event message, will update when hear back.

--- List of supported events ---

7.11 Event Messages
External -> Scanner
Event messages are used by the scanner to send back event notifications to external. The
event messages always start with the token EVENT or the abbreviated token EVEN and are
followed by a program message subtype that defines the event type. See section 7.4
Configuration Messages for details on how to set up the scanner to send event messages.
EVENT:SHUT_DOWN; Sent when the scanner is shutting down.
EVENT:ACQUIRE_3D_START; Sent when a 3D acquisition starts.
EVENT:NEW_PATIENT; Sent when a new patient is activated on the
scanner.
EVENT:FREEZE; Sent when the scanner is frozen.
EVENT:UNFREEZE; Sent when the scanner is unfrozen.
EVENT:TRANSDUCER_CONNECT; Sent when a transducer is connected to the
scanner.
EVENT:TRANSDUCER_DISCONNECT; Sent when a transducer is disconnected from
the scanner.
EVENT:TRANSDUCER_SELECTED; Sent when a new transducer is selected as
active transducer.
EVENT:DIAGNOSTIC_SETUP_SELECTED; Sent when a new Diagnostic Setup is selected.
EVENT:NEW_MEASUREMENT_RESULT; Message sent when a new measurement result
is available.
EVENT:CROSS_HAIR_OUTSIDE_IMAGE; Message sent when a cross hair or some of its
parts is placed outside of the shown ultrasound
image.
EVENT:OEM_SYNCHRONIZATION; Message sent when the user-programmable key
is pressed on the
scanner.

2013-02-15 20:07
Andras Lasso
Great, the results seem promising.

2013-02-16 11:33
Adam Rankin
Hey Andrey,

Once you've got the API under control, I can help explain to you which buffers should receive the data.
Skype me if you need help!

2013-02-19 16:08
Andrey Fedorov
I received the response from BK. They suspect there may have been be a bug in the Grabbie library, so they sent an updated one. I will now test with the new library to make sure the issue is resolved, then the new library need to be update to work with Plus video source (I think Andras did some fixes), and hopefully nothing else breaks. I did not have time to work on this today, will do on Friday and will update the ticket when I have news.

@lassoan: if you can give me a high-level idea what you changed in Grabbie, this might help. BK people told me there was not much changes in Grabbie functionality other than bug fixes and addition of Matlab interface.

2013-02-19 16:28
Andras Lasso
Grabbie was a huge mess. I had to clean it up a lot.

In the short therm the best is to a diff for the old and new Grabbie and redo the relevant changes in GrabbieLib (the cleaned up version).

In the long term they should clean up their Grabbie SDK. We can send our GrabbieLib to give them an idea what was wrong with their implementation and if needed I can review new Grabbie versions.

2013-02-21 10:15
Andras Lasso
You can find the source code of both Grabbie-1.1.0 (the original SDK that BK provided) and the corresponding cleaned up GrabbieLib-1.1.0 in PLTools/BK/ProFocus. The structure of the code and file names are the same, so with a compare tool you can see what changes were made.

2013-02-22 14:27
Andrey Fedorov
Comparison of Grabbie 1.1.0 and 2.2.0 showed there are no relevant changes. After additional communication with BK team, it turned out the mechanism to subscribe to these events is a bit different:

this->parSyncConnection->SendOemQuery("CONFIG:DATA:SUBSCRIBE "SCAN_PLANE";");

This appears to work as expected.

2013-02-22 14:31
Andrey Fedorov
added subscription to this event in GrabbieLib

https://www.assembla.com/code/pltools/subversion/commit/45

2013-02-22 14:33
Andrey Fedorov
(In plus:2526) Re #674: enable subscription to scan plane change events; need to investigate how to assign handler for these events outside of CommandAndControl.

2013-05-24 12:20
Adam Rankin
Recommend:
Instead of a single vtkInternal, we have a list of them, each one corresponding to a certain ID (transducer? plane? aggregate ID?)

When a scan plane switch event is triggered, we record the current vtkInternal and when new data is acquired, we allocate data to the channel in the current vtkInternal

This would require that at least one output channel exists for each possible output type (as usual)

2013-05-24 16:14
Adam Rankin
There's a lot we can do here. We can subscribe to the following events:
TRANSDUCER
SCAN_PLANE

We can also query TRANSDUCER_LIST to retrieve a full list of transducers attached.
We can also query some of the values of each transducer by providing the connector ID.

2013-05-27 16:52
Andras Lasso
It should be enough to detect if the user switched between two predefined scan planes.

Instead of duplicating the vtkInternal we should just define a ScanPlaneInfo structure that contains SCAN_PLANE-specific information and put into the vtkInternal class:
std::vector (or std::map<std::string, ScanPlaneInfo>)
int ActiveScanPlaneIndex (or std::string ActiveScanPlaneId)

2013-05-27 17:08
Andrey Fedorov
It might be a good start to first support multiple scan planes as defined in the config file, and when a different plane is selected by the user, re-query the parameters over OEM.