PDA

View Full Version : Networkable logging software for Field Day?



AA9UF
09-05-2008, 11:43 PM
I am looking for a good networkable Field Day logging software program. Our club needs it. We have used N3FJP's Network Field Day program but his ADIF format is not compatible with my MixW 2.18 program. I have to do a lot of editing to get it all to work after the contest. We have at least two stations that have computers and a LAN at the EOC building that we operate from. Having the program networkable will let us see who has worked who so we don't have a bunch of dupes. What kind of software does your club or Field Day group use?

73,

John, AA9UF
aa9uf.gercken@gmail.com

DJ1YFK
09-05-2008, 11:59 PM
N1MM. Free, and works pretty well.

http://pages.cthome.net/n1mm/

KA7O
09-06-2008, 02:12 AM
Looks to be a nice contest logging application there - but looks to miss the requirements of the OP.

Networkable - maybe, using file shares for the logging file. Doesn't mention whether or not it's multi-user or not. May be a deal killer there. Data files tend to get really messed up if they're accessed by more than one instance of an application - unless it's designed for that.

Man - we gotta get some coders on this project (and I gotta get up to speed, FAST!) - this is something like the 3rd time in as many weeks a request for like this has come up.

http://forums.qrz.com/showthread.php?t=169315

NE3R
09-06-2008, 02:26 AM
I'm not sure I understand the problem. N3FJP works great for field day. Unless you are trying to use 1 N3FTP and 1 MixW, that could be a pain.

You could use 2 copies of N3FJP, and designate one station for a set of band/modes and another station for different band/modes. Since each band/mode counts as a seperate contact, there are no dupes. That is how we've been doing it for years. Most of us have a copy of N3FJP. Instead of networking, we just merge the files after field day.

73 de Jospeh Durnal NE3R

AE6LX
09-06-2008, 03:17 AM
The problem is that you need mulitple computers to be able to update one log database. I haven't seen a program that can do this, but it would be REALLY simple to enhance mixw, HRD, or some other logging application to make this work if you had the source code.

N4CR
09-06-2008, 04:55 AM
I am looking for a good networkable Field Day logging software program. Our club needs it. We have used N3FJP's Network Field Day program but his ADIF format is not compatible with my MixW 2.18 program. I have to do a lot of editing to get it all to work after the contest. We have at least two stations that have computers and a LAN at the EOC building that we operate from. Having the program networkable will let us see who has worked who so we don't have a bunch of dupes. What kind of software does your club or Field Day group use?

73,

John, AA9UF
aa9uf.gercken@gmail.com
FDLOG. Runs on Linux or Windows using python and tkinter. We used a wireless access point to provide networking. Close computers ran a cable from the wireless unit. All of the computers talk to each other and all of the computers have the entire log. Each station also selects a band and mode and that is indicated on each computer as well, so you can see where everyone is operating without making the rounds.

When you are done, you can dump out the log and it's properly formatted and ready for submission to the ARRL upload site.

We've been using it for three years now and it works great.

I would suggest that you mock up the network and computers ahead of time. Time sync is critical for it to work and has been a stumbling block for us a few times. Normally, we widen the time sync window to 3 minutes instead of the default which is rather narrow.

There is a picture of it and some notes here

http://antennalaunchers.com/fdlog/

Here is the story of how it was developed. Interesting read.

http://antennalaunchers.com/fdlog/FDLogA1.pdf

W8OSP
09-06-2008, 04:56 AM
Yup I asked this a couple weeks ago, I am looking for the same thing.

AE6LX
09-06-2008, 05:26 AM
Based on the description just posted, the fdlog app sounds like a work around, at best. It might be easier to just use MS excel with the shared spreadsheet functionality until someone codes this properly. I bey the HRD guys could get this done easily

N4CR
09-06-2008, 07:33 AM
Based on the description just posted, the fdlog app sounds like a work around, at best. It might be easier to just use MS excel with the shared spreadsheet functionality until someone codes this properly. I bey the HRD guys could get this done easily

Why workaround? It builds the output file for you. It keeps multiple operators from working the same band same mode. It has a built in dup sheet that works great. Everyone can see what everyone else is doing in real time. If any of the computers die, all the rest of them have the entire log. It can work on a wired or wireless lan. Multiple operating systems. It understands that there are operators and loggers and both of them get logged with each input. Put a new computer on the net and it gets a flood from the other computers and gets caught up in seconds and then it has a copy of everything.

From my experience it's got field day nailed. The last thing you want is a single point of failure. The computer with the spreadsheet dies and poof, there goes your records. There's strength in numbers.

At the end of field day, it takes 3 minutes to get the output ready for the ARRL site from any of the logging computers.

It's not a workaround. It's a solution.

Did I mention, it's free?

AE6LX
09-06-2008, 07:56 AM
The computer with the spreadsheet dies and poof, there goes your records.

Yes, it happens all the time. That's why all companys are dumping PCs and MS Excel :rolleyes:

In all fairness, I haven't used the application so I can't really pass judgement. You said there were stumbling blocks, but it may be the best thing out there for the job. I really doubt anyone is going to come along and make some real quality software to do this; there just isn't any market in it. It would be very cool is some of the guys working on this stuff would make it open source so we could get more people tinkering with it.

KR2D
09-06-2008, 02:09 PM
Networkable - maybe, using file shares for the logging file. Doesn't mention whether or not it's multi-user or not. May be a deal killer there. Data files tend to get really messed up if they're accessed by more than one instance of an application - unless it's designed for that.

Man - we gotta get some coders on this project (and I gotta get up to speed, FAST!) - this is something like the 3rd time in as many weeks a request for like this has come up.



N1MM (and other networked logging programs) does not provide networked operation by simply sharing the log file on the network. Read the documentation. No programmer with half a brain would even think of doing it that way. A broadcast protocol so that each workstation gets all updates or a client/server database access are two possible methods of implementing this type of operation. It appears from the documentation that N1MM uses the broadcast implementation.

Unless your goal is to make your own logger, there is no reason to get any coders on it. It's been done MANY times. There are free and commercial solutions out there.

N4CR
09-06-2008, 02:47 PM
Yes, it happens all the time. That's why all companys are dumping PCs and MS Excel :rolleyes:

In all fairness, I haven't used the application so I can't really pass judgment. You said there were stumbling blocks, but it may be the best thing out there for the job. I really doubt anyone is going to come along and make some real quality software to do this; there just isn't any market in it. It would be very cool is some of the guys working on this stuff would make it open source so we could get more people tinkering with it.
The stumbling block is that you need to get a bunch of computers owned by a bunch of different people all on the same time. I don't think this requirement would be different for any logger. And where we are there's no internet access so we can't use a public time server. If you could put a time server on the network with you it would make time sync easy and this would not be an issue. Something like an IPCop firewall would be a good time sync source and we might bring one next year since it would also provide DHCP for automated network assignment.

You really don't want logging entries from any logging program put in with the wrong time, so the time sync requirement built into FDLog is a good idea. It's just that we found the window to be too narrow for our likes and for manual time setting.

This is why I suggested that you mock up the network ahead of time so you understand the subtleties of setting up a networked logging program.

AE6LX
09-06-2008, 05:28 PM
n2jso understood where I was coming from. The client/server/database design would be the only way I would build it. The "broadcast" method as he put it is just too prone to potential problems in my book. (Granted this isn't an industrial-strength use case, though.) It really would be straight forward to convert a MixW or HRD to use a legit DBMS for the log. The client application would just need a "multi-user" switch so it knows to check the db for updates regularly from the other stations. Maybe the "timing" just seems simple to me since this is the type of work I deal in all day, every day...

KA7O
09-06-2008, 06:27 PM
N1MM (and other networked logging programs) does not provide networked operation by simply sharing the log file on the network. Read the documentation. No programmer with half a brain would even think of doing it that way. A broadcast protocol so that each workstation gets all updates or a client/server database access are two possible methods of implementing this type of operation. It appears from the documentation that N1MM uses the broadcast implementation.

Unless your goal is to make your own logger, there is no reason to get any coders on it. It's been done MANY times. There are free and commercial solutions out there.

Sorry if I stepped on your toes. I read through the N1MM "quick-start" guide and looked through what I thought was a feature list. If this logger is designed as a network ap, it's not mentioned where I can see it. Don't mean it's not - just not obvious. Apparently more of a comment on the site design than the program itself.

It really looked 'stand alone' to me and my mention of file shares was offered as a 'work-a-round'. That's why I mentioned the data integrity concerns - parallels your 'half a brained programmer' quip. Since it's a windows ap, no way I can load it and try it out here. I'm depending on the descriptions on the site to see what it does. But obviously, if it meets Johns needs it's a good fit.

As I've said before - my dream is for a logging/recording/documentation tool that can be used by anyone that shows up (multi-user, multi-site). Nothing to install - bring your own laptop/PC - be it Windows, Mac, *nix or whatever. So long as it can speak 'http', it'll work. Gut thinking is MySQL and PHP on Apache - just cuz that's what I'm used to. Not only a usable tool for Field Day/contests - but other planned or unplanned events where "BYO tools" may be part of the 'get it done' requirements. But, that's more than well covered in the thread I linked earlier and should follow on there. http://forums.qrz.com/showthread.php?t=169315

FDLOG looks very promising! Gotta give that one a closer look - http://antennalaunchers.com/fdlog/
Time synch issue can be minimized by implementing an NTP server on the LAN (the program does something similar internally?) - then passing the server info out via DHCP to the clients (but seems not all clients are capable). See http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.10. for one method. I know newer windows clients can get 'time synch' from an AD controller - can they also get NTP server info via DHCP? Having all time stamps/tracking done on the logging server would eliminate this issue.

KR2D
09-06-2008, 10:43 PM
I read through the N1MM "quick-start" guide and looked through what I thought was a feature list. If this logger is designed as a network ap, it's not mentioned where I can see it.

N1MM calls it "Multi-User". It's in the feature list, it's in the online Help (Reference section), and section 41 of the Manual. It's not something a new user would do, so it's not in the Quick Start guide (along with a huge number of advanced features).

N4CR
09-07-2008, 06:18 AM
n2jso understood where I was coming from. The client/server/database design would be the only way I would build it.

How many platforms would your design support?


The "broadcast" method as he put it is just too prone to potential problems in my book. (Granted this isn't an industrial-strength use case, though.)

Yeah, TCP and UDP communications has only been working for about 35 years now. It still has to prove that it can work on a local subnet with a half dozen machines. Right. If it won't work, neither will your client/server application. And by the way, I don't believe it actually uses broadcast packages.


It really would be straight forward to convert a MixW or HRD to use a legit DBMS for the log.

You have the source code?


The client application would just need a "multi-user" switch so it knows to check the db for updates regularly from the other stations. Maybe the "timing" just seems simple to me since this is the type of work I deal in all day, every day...

Me too. I write software for a living, but only for the last 25 years or so.

I can't think of a good reason to have a server at field day. Client/Server/Database for field day is like bringing a Carrier Group to swat flies. What else will you bring with it? A rack? Redundant power supplies? Big UPS's that can run for 24 hours? Diverse power?

If you actually try FDLog, you will find that it works great and handles all of the chores of field day logging in a simple, low risk and effective manner. Speaking from experience, I believe the potential problems you write of are only in your imagination...

Or maybe you want to reinvent the wheel. I can't stop you from that. I can only tell you that you can get free wheels already round and working right over there...

N4CR
09-07-2008, 06:28 AM
Having all time stamps/tracking done on the logging server would eliminate this issue.
Having the server go down would eliminate all the logging.

ad: dxeng