Our full technical support staff does not monitor this forum. If you need assistance from a member of our staff, please submit your question from the Ask a Question page.


Log in or register to post/reply in the forum.

remotly connect, up speed for download data with CR3000


RamonLopez Mar 31, 2020 11:58 AM

I have CR3000 datalogger with NL116 adapter.
I save the eddy covariance data in CF Card to 10Hz.
I connect remotly using a 4G router with SIM, connected to datalogger with ethernet cable.
When download data the speed is 3KB/s, very slowly. When connect a PC, I can trasmit data 300 KB/s, Why the speed from datalogger is slowly?, Can I do to up this speed for download data?.

Thanks


JDavis Mar 31, 2020 02:30 PM

FTP file transfer is more efficient than Pakbus file transfer. You can add FTPClient to a slow sequence in the datalogger program to push out data files with FTP protocol.


Nico Feb 9, 2021 04:48 PM

Hello Ramon.

Did you ever solve this issue?

I'm in a similar situation and have the same problems (peer-to-peer I get 40kB/s Loggernet and -120kB/s FTP compared to modem I get 4kB/s LN and 6kB/s via FTP).
So FTP is ~25% faster, but at those speeds its rather silly.

But I'm also running a CCFC and the download speeds from this do not change as much when running peer-to-peer compared to running it via a modem (~290kB/s) when downloading images from it via browser (Chrome).
My research so far points to this being a TCP buffer issue in the firmware of the logger..

Thanks.


cabraybr Jul 26, 2021 06:18 PM

Hello Ramon and Nico, 

I am wondering if you were able to solve the issue of data transfer. We have a CR3000 logging EC measurements at 10 Hz. We are connected to a LTE bullet modem provided by CSC. Similarly to you, data download is extremely slow and we have tried to set up an FTP server. 

Nico, you mentioned a TCP buffer issue in the firmware of the logger. Can you elaborate on this? 

Thanks! 


Nico Jul 27, 2021 03:26 AM

Hi cabraybr

This is an open issue with Campbell and there is a support ticket (#80269) in their system.

The last status was that a technician of theirs was preparing a report of his tests on the issue but Covid seems to have thrown a spanner in the works there (Again). This was 2 month ago..

As for the issue itself and TCP buffers being the likely issue..

When you download from a logger directly on your network (LAN, very low latency link, see ping times to a logger from your machine with loggernet on it) they are fast.
We tested this with different loggers (CR1000X, CR3000) and a campbell CCFC camera.
No real difference between them really.
Hundreds of kb/s transfer speed.. either via FTP, HTTP or PakBus.
All good there.

Then we slowed down the link via software (ping times increasing up to values one gets via modem routers.. several hundred ms, but nothing else changed - loggers are still on the local network, so bandwidth is not an issue and the transfer speeds for the loggers go down (FTP/HTTP as well as Pakbus) while the CCFC still keeps pushing hundred kb/s via HTTP or FTP.

Now, the Pakbus protocol is built around a packet size of 1 kbyte which explains why it goes down so badly and why its not a bandwidth related issue (modem connection), but a round-trip-time-issue. The link only ever transfers 1 kbyte then the receiver acknowledges and the next is being sent.. aso asf. The higher the ping, the slower this whole process.. drop by drop over links with 300ms or more in each direction.
FTP/HTTP are able to transfer bigger packets, several hundred kbyte per transfer direction (= larger TCP buffer), but the loggers don't seem to make use of that, while the CCFC does. So as soon as the ping times increase, the loggers slow down, while the CCFC doesn't..

My guess is that the TCP/IP protocol and buffers in the loggers have been implemented ages ago (a CR1000X is just an evolution of a CR1000 which is an evolution of a CR10X, so decades ago) and no one bothered to upgrade to changing conditions, as for Pakbus real time data viewing the trickle speed is fine.. but for bulk downloads of several MB of data from a fast sampling system over a TCP/IP connection within minutes as is common these days just didn't appear on their radar?
So I don't know how long it will take to fix this, probably depends on having someone on the team that is able to modify the TCP/IP stack in their firmware (while I hope older 'retired' loggers can be upgraded for this - i.e. the hardware is capable).

For a workaround I am currently waiting on one of those tiny Raspberry Pi clones (Orange Pi Zero in my case) and my goal there is to run this as a FTP relay of sorts.
The Logger data will be downloaded via low latency (LAN, FTP) and then that Pi machine will send it on to the cloud with proper TCP buffers..
Cost wise hardware is $50 stuff, software wise most of it should be of the shelf + a couple python scripts and power control to the Pi will make sure it's only online when needed.
Not cool, but should work.
I try to remember to post here once I got this working..

Log in or register to post/reply in the forum.