ActiView TCP server

[H.Bowman@kent.ac.uk]

I have been coding up an equivalent of the Matlab TCP/IP client on the Biosemi downloads page, but in C++. The example code is very useful and I have got it to the point that I can regenerate the timeseries of a flashing photodiode. This also compares well to what one sees when running ActiClient 9.00 (Win). But there is one line in the Matlab TCPIP client that I am a little confused about. The code contains the following line:

normaldata = rawData(3,:)*(256^3) + rawData(2,:)*(256^2) + rawData(1,:)*256 + 0;

to map from three unsigned 8 bit integers (bytes) to unsigned 32 bit integers. I would have expected the powers to all be one less, i.e.

normaldata = rawData(3,:)*(256^2) + rawData(2,:)*(256^1) + rawData(1,:)*1 + 0;

I have run my code with both, and the first (with the higher powers), of course, generates higher amplitudes, but in my implementation it also generates considerably more amplitude variability, qualitatively worsening the match to the photodiode response.

Am I misunderstanding something?

Thanks again for the Matlab TCPIP client and ActiClient 9.00 (Win) – they are a great help.

Howard

Professor of Cognitive Neuroscience at Uni Birmingham
(honorary at Wellcome Centre for Human Neuroimaging, University College London)

[Coen]

What is sent by TCP/IP are the 3 most significant bytes of a signed 32 bit integer. The client should again construct the signed 32 bit integer from these 3 bytes (add a zero least significant byte). The MSB of the most significant byte is the sign bit.

Best regards, Coen (BioSemi)

[H.Bowman@kent.ac.uk]

Dear Coen,

Thanks, that is very helpful. So, just so I am absolutely sure, you are saying that there are 32bits at the sender side, which comprise four bytes (8 bits each), but only the three most significant bytes are sent. The least significant byte is not sent because its value is trivial compared to the three most significant bytes, and so, effectively, its value is treated as zero?

Thanks again,
Howard

[Coen]

The above is correct. The ADCs output 24-bit data words. The USB-receiver convert these words into 32 bit integers by just adding a least significant zero byte. ActiView processes these 32-bit integers, but only the 3 most significant bytes are streamed to BDF file and sent via TCP/IP. The only processing is the optional down-sampling; without down-sampling, the 24 bits are exactly as they are generated by the ADCs. So, the 4th byte does not contain actual information.

It is always good to check the conversion of 3 bytes to signed 32-bit integers with a rail-to-rail input signal (in your case you can connect a signal generator to the ERGO input). Errors usually show up as large jumps when the signal passes the zero level.

One last remark because you are streaming a photo-diode (trigger ?) signal. You cannot use the data streamed by TCP/IP for precise timing purposes. The streaming via TCP/IP causes delays in the order of a few hundred ms with a jitter of tens of ms. For semi real-time processing, a good solution is to add a separate thread to ActiView: the current thread reads from the ringbuffer and displays data on screen and saves to file, while a separate thread also reads data from the ringbuffer and performs real-time processing. Because the threads run independently, the (slow) display processes do not interfere with the (maximally fast) real-time processing. This method allow delays in the order of a few tens of ms. You will have to work in LabVIEW though.

Best regards, Coen (BioSemi)

[H.Bowman@kent.ac.uk]

Thanks - that is now very clear.

H

[H.Bowman@kent.ac.uk]

I am trying to set-up the rail-to-rail test suggested earlier on this thread:

“It is always good to check the conversion of 3 bytes to signed 32-bit integers with a rail-to-rail input signal (in your case you can connect a signal generator to the ERGO input). Errors usually show up as large jumps when the signal passes the zero level.”
[Post by Coen » Thu Sep 07, 2023 1:42 pm]

I currently have a photodiode connected to the ERGO input and I stimulate the photodiode with dark black and white, which I would have assumed were the two extremes of stimulation. However, both of these generate positive numbers on ActiView and ActiClient, and differences in grey scale sit between these extremes. So, is there a way to stimulate the photodiode that generates negative numbers and is it possible to perform the rail-to-rail test with by stimulating the photodiode?

Thanks again for all the assistance you have given,
Howard

[Coen]

The photosensor does not output negative values. You can connect a signal generator to the ERGO (see viewtopic.php?f=1&t=931&p=2854 ). Even easier is to connect a potentiometer (approx. 10k linear) between pin 1 and 3 with the wiper to pin 4 and pin 5 to pin 2 (ERGO will go from half the maximal value to half the minimal value, but that's enough to check the byte order).

Best regards, Coen (BioSemi)

[H.Bowman@kent.ac.uk]

Thanks - we are following that suggestion.

Howard

[H.Bowman@kent.ac.uk]

Thanks for your clarification. Can I just get clarification on one more point? And sorry for asking a very basic question, but I just want to absolutely sure of what I can do with the ERGO signal received through TCP/IP. You write that,

“You cannot use the data streamed by TCP/IP for precise timing purposes. The streaming via TCP/IP causes delays in the order of a few hundred ms with a jitter of tens of ms.”

Even though there is delay and jitter introduced in the delivery of data samples to my TCP client, the relationship between channels should be fine; that is, we can assume that the data samples across electrodes and auxiliary sensors (such as the ERGOs) is temporally reliable, e.g. a sample at electrode Pz at time-point X can be assumed to have arrived at the amp at the same time as a sample at ERGO 1 at the same time-point, X.

This is sufficient for us, since our real-time requirements are not very strict, i.e. delivery delays in the order of hundreds of milliseconds are not a problem.

Thanks again,

H

[Coen]

The timing across the channels is only determined by the sampling moments. All ADCs (EEG and sensors) in the AD-box sample at the same moment, controlled by the same clock pulse (sampling is synchronous within 10 picosecond). The trigger channel is added in the USB-receiver with a precision of one sample period (e.g. 0.5 millisecond on 2 kHz). Delay and jitter of the digital data stream does not affect the timing between the channels.

Best regards, Coen (BioSemi)

[H.Bowman@kent.ac.uk]

As I have indicated in previous postings, I am using a photodiode attached to the Ergo channel. I was previously getting very good signal when flashing a patch between white and black, with all the three ways I have of viewing its signal: auxiliary sensors tab on ActiView, ActiClient and the C++ Client I have written. After a period of others using the system and presumably changing settings, I found that the signal quality had worsened substantially, with high frequency fluctuations that were not previously present. Re-ticking the low pass filter box on the left side of the auxiliary sensors screen, returned the ActiView display of the relevant Ergo channel on the auxiliary sensors screen to good signal, with high frequency deflections smoothed out. However, unfortunately, this low pass filtering does not seem to apply to the output received by ActiClient or my C++ Client from the TCP server. Is there a way to get this low pass filtering applied to the TCP server’s output? I assume there is, since it seemed to be being applied previously.

On another point, I have now completed the rail-to-rail test and am now able to accurately reproduce what is shown on ActiClient, with my C++ Client. That was a great suggestion, which enabled me to find a pretty serious error in my code: it turns out that ^ is not raising to the power in C++, but rather performing a bitwise exclusive OR….. anyway, that is now corrected.

Thanks again for the assistance,
H

[Coen]

Filtering the TCP outputs is not a standard option in ActiView, it is only possible by modifying the (open source LabVIEW) code. You could consider programming a simple low pass in you C++ client.

High frequency interference on the photo sensor signal is usually caused by 100 Hz fluctuating light from fluorescent lamps.

Best regards, Coen