Martin Meyer HB9BGV 22-Jan-2004

m.meyer@fh-aargau.ch

Variable Buffer in the console

Please refer also to my text „DRM with the SDR-1000“ (dated 3-Jan-2004).

New in this text is:

• It applies to the console version 1.4
• There are three different buffer sizes now
• There is a new checkbox on the window of the console (see below, bottom right)

The buffer size can be configured by the user:

DRM-buffer applies, when mode = DRM
Data-buffer applies, when mode other than DRM and checkbox = on
Original buffer length applies, when mode other than DRM and checkbox = off
Modifications in the SDR-1000 Software, ver 1.4

Two modules have been changed: introduction of new variables and modification of existing
ones. The same holds true for subroutines. Below you find a list with the modifications. You
find the details and the explanations in the code-files.

1. Module frmConsole

New variables:

InBuffBlocks
OutBuffBlocks
InBufferUsage
OutBufferUsage
InPtrHead
InPtrTail
mixW Object, type = mixW-application
MixWIsLoaded shows wether the mixW-application has been started
oldFqA contains the frequency of the console

Modified variables:

hEvent(127) instead of hEvent(1)

EVNT(127) instead of EVNT(1)

Modified subroutines:

SetEvents
No more notification points, but arrays instead

ckPWR_Click (earlier: cmdCTRL1_Click)

This routine is executed when pressing the power button. New: the routine checks the selected
mode. If DRM, then the DRM-buffer-size is active. If mode other than DRM and checkbox
on, then the data-buffer-size is active. Otherwise, the original buffer-size is active. The
pointers InPtrHead, InPtrTail, OutPtr and the variables for the buffer management are set to
zero.

OptMode_Click (earlier: cmdMode_Click)

This routine is activated by changing the mode. New: console will be stopped and started
again, if there was a change between an analogue mode and DRM. This avoids a buffer
underrun.
DataBuffEn_Click (new routine)
This routine is invoked by changing the checkbox „Data Buffer enable“. The entire process is
stopped and restarted. This avoids a buffer underrun.

DirectXEvent8_DXCallback
An event from DirectX starts this routine automatically. There is no more a switch back and
forth between write and read. New: the actual position of the pointer is evaluated from the
Event-ID. The pointer InPtrTail is decremented by 1 after each block read. This gives an
information about the used space of the buffer. The maximum value is read every half a
second and visualized by the bar graph (see page 28 of the .pdf-file).

EraseSoundBuff
This routine erases the output buffer when the console is stopped. The constant value of the
buffer size has been replaced by the variable OutBuffBlocks.

Form_Load
The variables InBuffBlocks and OutBuffBlocks are initialized here. This prevents from a
division by zero, in case of a call of the Options-window without having switched on the
console. The object mixW is also initialized here. It is important, that MixW has been started
before the console. Otherwise, the variable „MisIsLoaded“ is set to zero and the „Timer2“
remains switched off.

CreateBuffers
The values for the buffer size and block size have been modified.

KillEvents
erasing of the DirectX-events has been expanded to the whole array of events.

SaveState
Now also the state of the checkbox „Data Buffer enable“ is stored.

GetState
Reads the stored values, including the checkbox.

itmOtions_Click
new: also „Timer2“ from the module „frmOptions“ is started.

Timer2_Timer (new routine)

If the MixW-application is active, this routine checks periodically for changes in MixW. If the
frequency in MixW has been changed, the new value is forwarded to the console. If T/R-
switching occured in MixW, the variable „ckMOX“ is changed too.
2. Module frmOptions

In the setup-window of the console two registers „DRM-Buffer“ and „Data-Buffer“ have
been introduced (see the copies of the screens above). The following subroutines have been
modified:

Info1_Click
Buffer size in DRM-mode

Info2_Click
Buffer size in Data-mode

Sl1InputBuffer_MouseDown / sl1OutputBuffer_MouseDown: new routines

(Sl1 = slider 1) DRM-Mode: the values of the faders for the input buffer size and output
buffer size are given to the module frmConsole. Prior, the process is stopped to avoid a buffer
underrun.

Sl2InputBuffer_MouseDown / sl2OutputBuffer_MouseDown
Data-mode: the values of the faders for the input buffer size and output buffer size are given
to the module frmConsole. Prior, the process is stopped to avoid a buffer underrun.

Timer2_Timer
This routine is activated every 0.5 seconds and shows the buffer usage with a bar graph
(mentioned above). The Timer is deactivated when the DRM-window is closed. This saves
ressources.

SaveOptions: modified: to keep the settings for the next start of the program, they are stored
in the registry.

GetOptions: modified: the options are read from the registry.

Communication with MixW
MixW offers two software-interfaces: DDE and AciveX. DDE is pretty old and has not been
developped further since years. So we choosed ActiveX.

MixW has a number of AcitveX-methods to exchange information:

• mixw.AudioFq: returns current audio frequency
• mixw.FqA: returns current RF frequency
• mixw.Mode: returns current mode name
• mixw.ExecuteMacros(text): places text into the TX window or runs macros
• mixw.ExtReceive: returns received data
• mixw.AXSendString(text): sends string in PACKET mode
• mixw.AXReceiveString: returns received data in PACKET mode
• mixw.Azimuth: returns rotor azimuth
• mixw.Azimuth(x): sets rotor azimuth
• mixw.PTT: returns PTT state (0 is OFF, 1 is ON)
• mixw.PTT(x): sets PTT state

First it needs a connection between the client and the server:

Set object = GetObject(,"Name.Application")

In our software, it is the command

Set mixW = GetObject(,"MixW2.Application")

Maybe the server-application has not been started yet, an error handler deals with this.

After this object has been created, you have admission to methods and variables of the other
application:
object.Method
object.Variable.

We only used the variables mixw.FqA and mixw.PTT .

This worked fine with OS Windows 2000 pro and WindowsXP.

To connect another Software than MixW, two methods in the module frmConsole need to be
adapted:

Subroutine Form_Load()
Invoked at the start, this method creates the object mixw. If it is succesfull (the program
MixW is already running), the Timer2 is started, which polls the variables periodically.
Instead of "MixW.Application" you simply write "DigiPan.Application" (example, I hope
DigiPan supports ActiveX!!).

Subroutine Timer2_Timer()
This method is invoked every 200 ms and checks first, wether MixW is up and running. If
yes, the frequency and the PTT-state are read from MixW and transferred to the console. If
MixW has been terminated, the user is informed with a message box.
Adaption to another Program: change the names of the variables and methods (mixw.FqA
and mixw.PTT).