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.

LNDB with two paths to Logger

ryan42 Dec 10, 2018 04:34 PM


I am looking at using LNDB to store our data but some of our sites have alternate comms paths to the loggers, such as 3G and satellite. 

It is possible to have two paths setup to a site and when one is down loggerNet collects via the alternate path and still stores data in the same LNDB table? We are using callbacks to trigger the downloads from site. 


jtrauntvein Dec 11, 2018 12:14 PM

If both the 3G and satellite represent TCP/IP links to the datalogger and you are dependent upon the datalogger opening the connection as a TCP client in order to initiate call-back, you would be best served by using a PakBus/TCP Server in your network map to which your datalogger is attached as a child.  LNDB looks for the presence of the datalogger and takes no notice of how that datalogger is connected.

ryan42 Dec 12, 2018 10:39 PM


Thanks for the response, and yes, both are IP connections to loggernet.

I have used the PacBus/TCP Server once or twice before. What do you think is the maximum number of sites that it would be able to handle? Would 250 be ok? Maybe up to 400?


jtrauntvein Dec 13, 2018 09:40 AM

The theoretical maximum limit is 4093 since that is the number of PakBus addresses that are available after you take into account  that LoggerNet has to have its own PakBus address.  In practice, I would recommend far fewer than that.  Within LoggerNet, each PakBus router uses what I call transaction focus queue which forces the commands for queued transactions to be serialised.  Without this queue, it would be possible for LoggerNet to flood the network with simultaenous commands.  If communications with a particular station is flakey or slow, this can have a detrimental effect on all of that stations within that same network because their transactions may be waiting in the queue while a flakey transaction is timing out. Depending on your network and its needs, I would recommend like no more than a dozen to two dozen stations for each PakBus/TCP server.  You can have multiple of these which are all listening for inbound connections on different ports. 

PPeters Dec 13, 2018 02:37 PM

I take it the TCP server in this fashion only works for call-back connections? i.e. logger initiated call scheduling?

i have tried the TCP server but I understand is limited to a single address per pakbus ID

We have experimented for a number of years with loggerNet initiated multiple comm path configurations so are always interested in new ideas.

Our current setup, if interested is to use a Load balancer (FortiGate 30E)

on loggernet we define an IP for example

then on the load balancer we load as many paths as we need under this incoming IP, use weighted, static and round robin calling

we connect to Cellular modems, IP links, and digital radios in this fashion

Can provide more details if anyone interetsed (paul.peters@horizons.govt.nz)



ryan42 Dec 16, 2018 06:55 PM

Thanks Paul.

Thats interesting. I am writing a program that runs on 3G as normal and when there are any issues with that shuts down that connection and brings up a satellite link. The idea was to then have the logger make the callback request to loggernet. 

I have expermented with the TCP servers but maintaining 15 to 20 seperate ones probably isn't going to be much fun. I think I'll end up using the HTTPPost to send the data to a webservice that then writes it into the db. The only issue is that the HTTPPost streaming is broken too so I'm having to make a workaround for that.


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