Programming Module Operations

Owned by Andrea Dennis
Last updated: Jan 26, 2023 by Anders Damkjaer Nielsen
6 min read



This section provides:

  • a reference to example code that illustrates a minimum module application using ModuleAPI objects

  • guidelines for implementing Noah 4 printing requirements

  • guidelines for implementing inter-module communication

  • an overview of the Noah session list functionality



Sample Modules

With Noah 4, HIMSA provided a sample module. The module is intended to provide examples of how to access the basic functionality of Noah. They do not consider any audio logistic aspects of module programming. The sample includes a fair level of error handling, but does not take into account error handling, installation or any other aspects of the module regarded as being exemplary or adequate for module development or certification.
The sample modules are provided in C# using Visual Studio 2010. The modules require that the development environment be installed on the computer in order to debug them.
IMPORTANT: The sample code provided by HIMSA is provided as is, without further support, including but not limited to, the specifics of the development environments. HIMSA has no plans (nor knowledge) to develop sample modules for other development environments. HIMSA may change parts of the samples without notice. Furthermore, HIMSA makes no warranty of any kind with regard to this sample code, including, but not limited to, the implied suitability of the code for a particular purpose.
IMPORTANT: Do not copy the entire sample projects and use them in your own module development, as they contain unique information that, if re-used, could lead to unpredictable results. Instead, you will need to create your own projects and copy-paste the relevant code from the samples, if necessary.



Noah 4 Printing Requirements

In Noah 4, the modules can handle printing themselves. The actions can off course be launched with a Print parameter or Print Action Group parameter, if the user wishes to print any of these directly. In order to identify these, just look at the LaunchInfo properties. For further details of LaunchInfo, please refer to the ‘Namespaces,' under 'ModuleAPI Assembly' in the Noah 4 'ModuleAPI.chm' file.



Implementing Inter-Module Communication

Inter-module communication (IMC) was introduced in Noah 2.0 as Online Communication. Its purpose is to allow two modules to communicate directly with each other through a well-defined protocol, without using the services of the Noah framework.

This form of communication is mainly used by fitting modules to launch and control a Real Ear Measument module.
At the current time, three protocols have been defined:

Protocol Number

Name

0

View Data

1

Real Ear Measurement

2

IMC Protocol 2


However, HIMSA licensees will be able to define new protocols as necessary.
For more information on these protocols, refer to:

  • IMC (On-line) Protocol No. 0, View Data Specification

  • IMC (On-line) Protocol No. 1, Real Ear Measurement

  • IMC Protocol 2

The Noah IMC protocol 2 is used when a fitting module connects to a Real Ear Measurement module and wishes to receive REM data while fine-tuning a fitting. It is an application-level protocol, that used as an extension to the basic on-line communication facilities supported by the Noah Framework. This protocol was released in November 2015.

Available from Inter-Module Communication (IMC) Documentation when logged in as a member, members\development projects, or simply search for IMC.



Limitations

It’s Not possible to start a Noah 4 IMCServer from a Noah 2 module. All other combinations are supported.

IMC between Noah 3 and Noah 4 modules in any combination is fully supported from Noah version 4.4.0.2280



Implementing details

When implementing either an IMC Client or an IMC Server in Noah 4 it is important to do the following.

Implement either of the IMC interfaces declared in IMCInterfaces.dll, IIMCServerEx or IIMCClient.

Don’t implement the interface IIMCServer since the Command method can’t return data.

In the Class where you implement the one of the IMC Interfaces, IIMCServer or IIMCClient, the following must be done :

  • The Class must inherit from MarshalByRef.

  • The Class must override InitialLifeTimeServices and return null.



How IMC Works

In order for the developer’s module to participate in IMC, an IMC interface must be implemented.

The interfaces are in IMCInterfaces.dll

 One of two types of interfaces can be chosen for implementation:

  • Himsa.Noah.IIMCClient – if the module is acting as an IMC Client

  • Himsa.Noah.IIMCServer – if the module is acting as an IMC Server

 

Precondition

The IMC server is registered in Noah as an IMC server with the supported protocols.

 

Starting IMC

The IMC Client and IMC Server will be connected the following way:

The module that implements the IIMCClient interface will find the Module it wants to launch by iterating through the ModuleAPI’s module collection. Once the IMC Server is found the Module calls Module.LaunchIMC.

The Noah Framework will now launch the IMC Server module.

Once the IMC Server gets launched it shall call ModuleAPI.Connect,  and a direct reference to the IMC Client is given to the IMC Server module.

Remember the IMC Server must use the same ModuleID when calling ModuleAPI.Connect as when I originally registered itself to Noah.

The IMC Server now acknowledge the IMC connection by calling IIMCClient.ServerReady.

IMC Communication

The IMC Client controls the IMC Server by calling IIMCServer.CommandEx (IIMCServer.Command has a bug)

If the IMC Server has data for the IMC Client then the IMC Server can call IMCClient.DataReady.

IMC End communication

The IMC Client calls IIMCServer.Stop() to end the IMC Communication.

NOTE:

The Noah framework takes no part in the communication between the IMC Client and the IMC Server it is entirely up to the modules to conform to the defined protocols.

NOTE: The View Data Protocol was invented in Noah 2.0 as a method for a fitting module to visualize an audiogram while running. This was not possible otherwise, since Noah 2.0 allowed only one module to be shown on the screen at any one time. In Noah 4, an audiogram module can be shown alongside a fitting module, thus enabling the user to view both an audiogram and a fitting at the same time. Therefore HIMSA does not recommend usage of the View Data Protocol for viewing audiograms in Noah 4.

NOTE:

We strongly recommend that you look through the Noah4 IMC Sample modules, Inter-Module Communication (IMC) Documentation.

Session List Overview

When a module performs an action, such as a hearing aid fitting, this action is added to a session of the selected patient. The Session list is a list of the selected patient’s sessions and each session represents a calendar day. Each session consists of all the actions; fitting, measurement, journal entries, that have taken place during a patient’s visit.

It is assumed that a patient will only visit the hearing specialist’s clinic once on a particular day. Therefore, if an action is added to a patient’s session list within one calendar day of the time that the last session was opened, it will be added to that session. If more than one calendar day has passed since the last session was opened, Noah will open a new, “current session” and the new action will be added to it.

Action description

The name of an action can be divided into two parts:

·Information provided by the Noah system

·Information provided by the module which created the action.

Figure: Action Names


The first part of the name consists of The User who created the module and the name of the manufacturer. The second part is The Module Description, which is given when the module is registered.

Additional Action Information

It is possible to mouse over a fitting or hearing instrument selection action so that it supplies additional information provided by the module which created the action.