Open Source Instruments Forum

Rob Wykes reports the following error in one of his Neurorecorders:

ERROR: Failed to connect to 10.0.0.37:90, connection refused (10-May-2023 16:12:00)
WARNING: Recording resumed after interruption of 2 s. (10-May-2023 16:12:02)
WARNING: Encountered 2 errors in received interval. (10-May-2023 16:12:02)

Here we see the Neurorecorder trying to connect to Port 90 on a LWDAQ Driver at IP address 10.0.0.37. The connection is being refused. This is a TCPIP communication problem. It is not a problem with telemetry reception, but rather with downloading telemetry data to our data acquisition computer. The same problem may arise with an Animal Location Tracker or Telemetry Control Box, except that the IP address will be something other than 10.0.0.37 for such devices.

Rob also reports that the telemetry system was running fine for four days, and then suddenly started exhibiting the above errors, repeating several times a minute.

LWDAQ Drivers do not refuse connections on Port 90. Even if they are busy serving another client, they will accept and queue the connection. In order to get a connection refused error, the data acquisition computer must be trying to access address 10.0.0.37 on some network other than the one upon which the LWDAQ Driver resides.

Is the computer's wireless interface turned on? If so, turn the wireless interface off and see if the errors go away. The computer could be trying to perform an update over the wireless network, or backing up files to a network file server, and during this process it becomes confused about which network to use for address 10.0.0.37.

In your Windows network configuration for the wired interface, do you have the value "10.0.0.1" entered for the "gateway"? If so, delete this value and leave the "gateway" blank, see instructions below.

http://www.bndhep.net/Electronics/LWDAQ ... _Setup.pdf

Is there another LWDAQ Driver connected to your wired network? This is unlikely, but in general, it is another cause of this problem.

Rob: please try the above and report back. If you can cut and past error messages into your reply, I'd prefer that to screen shots, because the text can be searched for on the forum in the future, while images cannot be searched for text.

Thanks for the super quick response
Will try this
Thanks
R

Another customer reports:

We have three setups now, two of which are not causing us problems, one of which is consistently throwing errors:

Setup1: Laptop-->usbethernet-->switch-->2xLWDAQ driver-->2xoctal-->2xgroups of antennas. The laptop uploads the data to a cloud storgage via wifi and has no issues. There are no PoE cameras on this setup.

Setup2: Laptop-->usbethernet-->switch-->LWDAQ driver-->1x octal-->1x group of antennas. The laptop uploads the data to a cloud storgage via ethernet and has a static ip address. We have 10x PoE microseven cameras. There are no problems.

Setup3: Laptop-->usbethernet-->switch-->LWDAQ driver-->1x octal-->1x group of antennas. The laptop uploads the data to a cloud storgage via ethernet and does not have a static ip address. We have 10x PoE microseven cameras. There are problems.

The problems we have can be summarised by the attached picture. We can usually connect via lwdaq software to the driver and record for a while. Then errors start accumulating. The pattern of these errors is as follows:

1)Timeout reading _x_ bytes from sock_y_
2) Failed to connect to 10.0.0.37.90 i.e. the i.p. of the LWDAQ.

rarely, there will be reconnection: e.g. resumed after interuption of x num of secs.

Mostly, there is no reconnection.

Sometimes we can restart the recording by closing the LWDAQ software and then clicking reset and configure on the neurorecorder reciever.

Often, however, we can only get a reconnection with the LWDAQ driver by powering it off at the plug socket and then reconnecting.

Things I have troubleshot so far:
I have tried a different LWDAQ driver and power supply. However, the problem perists.
I have tried running this from a different surge protector (i was worried the power to the LWDAQ driver would be unstable/inadequate when connected to a surge protector supplying power from multiple devices.

Based on the above information and attached error messages is there anything that jumps out at you as a likely cause?

Dear Nat,

> Setup1: Laptop-->usbethernet-->switch-->2xLWDAQ driver-->2xoctal-->2xgroups of antennas.
> The laptop uploads the data to a cloud storgage via wifi and has no issues. There are no PoE
> cameras on this setup.

Does Setup1 have a static IP address? If so, your observations are consistent with problems in the laptop's handling of TCPIP connections.

> Often, however, we can only get a reconnection with the LWDAQ driver by powering it off at
> the plug socket and then reconnecting.

You should get the same result when you press the reset button on the front of the driver. Several things happen when you power-cycle or reset the driver. If the driver is stuck half-way through a data acquisition, it will become unstuck. When it reboots, it announces itself to the network switch. I'm not sure if the announcement helps. And as to the driver being stuck, it should not be stuck for more than ten seconds if the tcp_timeout is set to 10. You can check this setting with the Configurator Tool. If you at some point reset the driver to its factory default configuration, the tcp_timeout will reset to zero, which means no timeout at all, and the driver will get stuck when your computer abandons it half-way through a download.

Now, you might ask why the factory default is no timeout, and that is indeed a good question, to which I don't have a particularly good answer, but there are a lot of drivers out there, and I don't want to change the factory default now. I feel it's too late.

Anyway: do let me know how it goes.

Best, Kevan

Thank you for your detailed reply, Kevan.

I have removed the 'default gateway = 10.0.0.1' on the IPv4 settings of our USB-to-ethernet dongle, as per your instructions to Rob.

I have also requested that IT give us a static IP address (for connections to the internet-internet via ethernet port on the laptop to the ethernet socket on the wall).

Hopefully this will resolve the issues.

On the topic of time-outs for the driver, is there a preferred setting for stability/increasing the likelihood of successful reconnection following a driver timeout (e.g. reading _x_ bytes from sock_y_)?

Much appreciated!

Dear Nat,

> On the topic of time-outs for the driver, is there a preferred setting
> for stability/increasing the likelihood of successful reconnection following
> a driver timeout (e.g. reading _x_ bytes from sock_y_)?

I like to use ten seconds, for which we set tcp_timeout to "10" in the Configurator. To change tcp_timeout, contact your driver with the Configurator. Read its EEPROM settings. Copy them to the Write array. Set tcp_timeout to 10, enter your name as the "operator". The date will be filled in automatically when you press Write to store to EEPROM. You must then Reboot to get the new values loaded into the driver's run-time memory.



You can leave the IP address at 10.0.0.37 with gateway 10.0.0.1, but note that you can, in principle, put the LWDAQ Driver on your local wired ethernet, by assigning it a static IP address on your network. In the OSI office, the driver on my desk is 192. 168.1.11, using gateway 192.168.1.1. I can contact it over the wireless network from any place in the office. If we want to record continuously from a driver, we find that we must plug the recording computer into the wired ethernet as well. The wireless network seems to drop out now and then, causing interruption in our recordings.

Best Wishes, Kevan

Thank you, Kevan - removing the 10.0.0.1 on the default gateway of the USB adapter improved stability a lot. We went from a crash a day to 1 per week. I have now also changed the tcp_timeout to 10 as indicated and will monitor connection over the coming days.

I compared some advanced settings of a stable computer/telemetry set-up to the one we are having a few problems with.

On the stable setup 'NetBIOS over TCP/IP' is disabled on the dongle. On the undatable one it is not, it is set to default. Do you think this could cause an issue?

A question from another user is if we are recording through a few microseven cameras via the same switch are we more likely to get crashes on a driver that operates on the same network/through the same switch.

Thanks!!!!

Nat

Thanks!

Nat

Dear Nat,

From what I'm reading, enabling "NetBIOS over TCP/IP" allows twenty-year-old applications to connect to your network via TCP/IP. It's a translator between an older networking protocol and TCPIP. Any such translator can cause problems with your network settings. So, I recommend you disable "NetBIOS over TCP/IP", and let's see if that takes your crash rate from once per week to never.

No, I don't think that recording from other MicroSeven cameras on the same switch is going to crash the LWDAQ Driver. Not unless the MicroSeven cameras consume so much power that they bring down the PoE switch's power supply. But that's not going to happen if you are using the switches we recommend. Those switches will provide at least 15W per socket.

Best Wishes, Kevan

Thank you, Kevan -- just to update you: unticking "NetBIOS over TCP/IP" from advanced settings of the ethernet-usb dongle improved stability.

Thanks

Nat