Thanks
Nat
Statistics: Posted by nathanaeloneill — Mon Feb 26, 2024 10:27 am
]]>
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
Statistics: Posted by Kevan Hashemi — Fri Feb 02, 2024 2:53 pm
]]>
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
Statistics: Posted by nathanaeloneill — Fri Feb 02, 2024 2:10 pm
]]>
> 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
Statistics: Posted by Kevan Hashemi — Mon Jan 29, 2024 2:27 pm
]]>
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!
Statistics: Posted by nathanaeloneill — Mon Jan 29, 2024 2:06 pm
]]>
> 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
Statistics: Posted by Kevan Hashemi — Mon Jan 29, 2024 11:54 am
]]>
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?
Statistics: Posted by Kevan Hashemi — Mon Jan 29, 2024 11:42 am
]]>
I am going to answer your question in detail, because it is a good question, and I feel that a short answer will be more confusing than a long answer.
> Am I right in thinking that from the back of the LWDAQ driver to the Octal it should be a specific LWDAQ cable.
In your question, you are implying that the cable from the LWDAQ Driver (black box) to the Octal Data Receiver (silver box) connects to the "back" side of the driver. In our documentation, the "back" side of the driver has one RJ-45 socket, one power plug, and one switch. The "front" side is the one with eight RJ-45 sockets, thirteen LED indicators, and one switch. Here is a picture of the front side:
The cable from the receiver plugs into one of the eight sockets on the front of the driver, usually socket No1, closest to the LEDs. This cable functions as a "LWDAQ root cable". If the cable is longer than ten meters, the cable needs to be a "LWDAQ Cable", or else the communication between the driver and receiver will be unreliable.
Network cables contain eight wires. The wires terminate at either end with an eight-way modular connector. All modern network cables, and all LWDAQ Cables, are "straight-through", meaning that pin 1 on one end is connected to pin 1 on the other end, the same for pin 2 on both ends, and so on.
To the first approximation, LWDAQ and Ethernet cables are the same. Provided the cables are short, this approximation is good enough. Inside the cable, however, the eight wires are twisted into four pairs. Twisted pairs are good for transmitting high-frequency logic signals over long distances. In Ethernet cables, the pairs are 1/2, 3/6, 4/5, 7/8. In LWDAQ Cables, they are 1/2, 3/4, 5/6, 7/8.
When I chose the pinout for the LWDAQ connector back in 2003, I made a mistake. I thought I was picking the same pinout as Ethernet, but I was wrong. By the time I realized my mistake, it was too late to fix it.
The LWDAQ uses 3/4 to download data from the receiver to the driver. In a LWDAQ cable, 3/4 are twisted together, so they can go a long way without distortion. With a solid-wire LWDAQ cable, you can read out your receiver from 130 m away. Hence the name "Long-Wire DAQ". With an Ethernet cable, the communication will be reliable only up to ten meters.
In your system, ten meters is more than long enough. You can use a short Ethernet cable to connect your driver to your receiver. And of course you can use an Ethernet cable to connect your driver to the Ethernet.
> Firstly, are these available for purchase and if so can you quote me for 5 of these?
As you can see: buy network cables from your local cable supplier and they will be fine.
> The second question i have is about ethernet cables to that allow power and data transfer to/from the cameras.
> We currently have shielded cat6 ethernet cables going from the switch to the ethernet block outside the canopy.
> Shielded cat 5e cables are contact the ports on the inside and connect to the camera.
I believe you have Ethernet Feedthroughs on the floor of your Faraday Canopy, like this:
You have your Power over Ethernet (PoE) switch outside the canopy and you are running Ethernet cables from the switch to the feedthrough, and from the other side of the feedthrough to the cameras inside the enclosure. Please correct me if I'm wrong.
> I note on your website that it says that ethernet can/should be unshielded outside the canopy.
> Is there a problem with running shielded ones?
The cables from the switch to the feedthrough can be shielded or unshielded. Depending upon how the cameras are designed, it is possible for shielded cables between the switch and the feedthrough to cause problems with PoE startup. But we have tested three types of MicroSeven camera so far, and none of them show any startup problems with shielded cables. So you can use shielded everywhere if you want to. The cables inside the enclosure must, however, be shielded, in order to permit telemetry reception.
> Thanks in advance for your response
I hope I answered your questions. If not, please register on this forum and ask again.
Best Wishes, Kevan
Statistics: Posted by Kevan Hashemi — Sat Jan 20, 2024 3:09 pm
]]>
I was recently involved in upgrading the system and installing PoE microseven cameras and moving a currently unused octal/LWDAQ driver/attena set up into an existing faraday to up the number of recording slots.
Something caught my eye when I was looking on your website. Specifically here:
https://www.opensourceinstruments.com/E ... 7/SCT.html
and here:
http://www.bndhep.net/Electronics/LWDAQ ... t%20Cables
and it is on the use of ethernet cables and LWDAQ cables.
Am I right in thinking that from the back of the LWDAQ driver to the Octal it should be a specific LWDAQ cable. Firstly, are these available for purchase and if so can you quote me for 5 of these?
The second question i have is about ethernet cables to that allow power and data transfer to/from the cameras. We currently have shielded cat6 ethernet cables going from the switch to the ethernet block outside the canopy. Shielded cat 5e cables are contact the ports on the inside and connect to the camera. I note on your website that it says that ethernet can/should be unshielded outside the canopy. Is there a problem with running shielded ones?
Statistics: Posted by Kevan Hashemi — Sat Jan 20, 2024 2:30 pm
]]>
Please try the new version and let me know how it goes. Kevan
Statistics: Posted by Kevan Hashemi — Mon Oct 02, 2023 10:14 pm
]]>
We apologize for the problems you are having with the Videoplayer. What version of LWDAQ are you using? What operating system?
The Videoplayer in LWDAQ 10.6.1 is broken on MacOS and Linux. We are working on fixing the Videoplayer right now, and hope to release LWDAQ 10.6.3 later today.
Best Wishes, Kevan
Statistics: Posted by Kevan Hashemi — Mon Oct 02, 2023 12:01 pm
]]>
%----1---%
Event: "Neuroplayer_play"
ERROR: can't read "vtime": no such variable
Error Information:
can't read "vtime": no such variable
while executing
"if {($vtime <= $datetime) && ($vtime + $clen >= $datetime + $length)} {
set vf $fn
break
}"
(procedure "Neuroplayer_video_seek" line 17)
invoked from within
"Neuroplayer_video_seek $vpos $missing"
(procedure "Neuroplayer_video_play" line 23)
invoked from within
"Neuroplayer_video_play [Neuroplayer_clock_convert $info(datetime_play_time)] $info(play_interval_copy)"
(procedure "Neuroplayer_play" line 823)
invoked from within
"Neuroplayer_play"
("uplevel" body line 1)
invoked from within
"uplevel #0 $LWDAQ_Info(current_event)"
%---2----%
Event: "Neuroplayer_play"
ERROR: can't read "start_s": no such variable
Error Information:
can't read "start_s": no such variable
while executing
"if {$start_s + $missing <= $clen} {
set vpos [expr round($vpos + $missing)]
set end_s [format %.2f [expr $start_s + $missing]]
set missing "0..."
(procedure "Neuroplayer_video_play" line 37)
invoked from within
"Neuroplayer_video_play [Neuroplayer_clock_convert $info(datetime_play_time)] $info(play_interval_copy)"
(procedure "Neuroplayer_play" line 823)
invoked from within
"Neuroplayer_play"
("uplevel" body line 1)
invoked from within
"uplevel #0 $LWDAQ_Info(current_event)"
Statistics: Posted by ucbthaf — Mon Oct 02, 2023 11:37 am
]]>
Best, Kevan
Statistics: Posted by Kevan Hashemi — Sun Aug 27, 2023 5:05 pm
]]>