Stable file copy from DR-22WL/DR-44WL through a router with DR File Transfer Tool

[vicpdx]

FYI:
Using TASCAM DR FILE TRANSFER 1.00 on a Windows 10 system, a home router, and TASCAM DR-44WL with 2.10 firmware, I was able to connect the DR-44WL to router and transfer files using DR FILE Transfer.

When the DR-44WL connected to the router, it displays an IP (ipv4) address.
Enter this IP address into DR FILE TRANSFER's setting SSID field. No need for the fancy .local ssid. Simple IP v4 address will do.

Connecting through the router maintains a stable connection. With DR-44WL acting as a wireless AP, depending on the laptop's wireless device setting, I would frequently get disconnected, very frustrating when transferring large files.

In fact, using the IP address, I got my desktop system with "wired" only connection to transfer files from DR-44WL to Windows 10 desktop.

I'm not sure what ports are being used. I can only image DR-44WL should be accessible from anywhere if it is assigned an ip address and the required ports opened.

 

[vicpdx]

 

[GTBecker]

Excellent. Thanks for the tip to use the recorder's IP instead of its SSID, which never worked here.

Tom

 

[GTBecker]

FWIW, file transfer to/from my DR-44WL via USB2.0 ran at ~18MBps/144Mbps.

WiFi transfers to DR File Transfer via WiFi and router on Win8.1 ran at ~0.448MBps/3.6Mbps, roughly the same speed that DR_Control shows on both iOS and Android - so the speed is limited by the recorder's WiFi (see http://www.tascamforums.com/threads/dr-44wl-router-device-mode-ipad.4608/). Clearly, if you have the option, use USB or move the SD card.

Large WiFi transfers from the recorder to DR File Transfer via a router were, I believe, error-free. Although there were a few very short pauses, never did the transfer quit nor show long pauses as occurs with DR_Control via a router.

This suggests that the stumbling and failures of DR_Control transfers are due to the smartphone apps, though it is puzzling that the same behavior is seen on both iPhone and Android. Perhaps the apps are written in the same development environment, but compiled for the different platforms? In any case, it is a little comforting to expect that the DR_Control faults might be correctable in a subsequent release.

Tom

 

[vicpdx]

I don't believe the problem is with the app. I believe the problem is with DR-44WL acting as a Wifi Access Point (AP).

On Windows, when DR-44WL acts as a direct AP, the Windows wifi connection would constantly drop.

Possibly the DR-44WL does not have enough on-board memory to run as an AP and continue with the file transfer. Another possibility is a Power Managment issue or a bug in their AP side of the firmware. Keeping everything the same, switching from direct AP to a router, I never get a dropped connection. I was able to transfer over 30GB of files through the router without a disconnect.

The short pause during wifi file transfer clearly points to DR-44WL on-board buffer management and/or flow control.

 

[GTBecker]

> ... I believe the problem is with DR-44WL acting as a Wifi Access Point (AP).

Do you mean what the recorder calls "TODEVICE" mode?

The errors with the DR_Control apps appear in both TODEVICE and VIAROUTER recorder modes. Initially, I thought that the router mode was better but it doesn't take long here to see errors in both.

Tom

 

[younameit]

Great. Thanks for the IP tip. Finally working. Altough it is VERY slow (5 minutes to copy 130mb)
I'd be 10x faster to take out the sdcard, put it in laptop and copy files manually...

why is it so slow? I have high speed internet.

 

[GTBecker]

One difficulty with TODEVICE mode to DR File Transfer on a Win8.1 desktop here is that the DR-44WL assigns 192.168.1.1 to itself and 192.168.1.2 to the connecting machine's WiFi adapter. My wired network gateway is 192.168.1.1 and another AP is already 192.168.1.2, quite the conflict.

I'm not aware of any way to change the recorder's IP assignments so it looks like I'll either need to reconfigure the wired network or shut it down while working with the recorder in TODEVICE mode, very inconvenient.

Tom

 

[Sunil]

guess this problem is still unsolved for ubuntu. 14.04

 

[GTBecker]

> ... still unsolved for ubuntu...

Which problem?

If you're referring to the 192.168.1.1 conflict, you can choose to use a different subnet, like 192.168.0 for your network, or just don't use 192.168.1.1 and ...2 if you use them now.

This isn't an Ubuntu issue, it's a poor arbitrary choice by Tascam, I believe, which they could resolve by adding an option to the DR-22/44WL menu to allow other IPs.