You know sometimes Mr. Murphy just won’t give it a rest!
I have had many “challenges” with this latest project. The most recent one I posted on these forums about how I can create a daily log file and someone suggested logrotate. Excellent, and now I have that working.
Now I am at the next and hopefully last problem.
First a little history, I have built a microprocessor board which allows me to log my hydro usage. It involves a photo diode on my hydro meter which counts flashes.
Every 10 minutes I send the kWh out the serial port. Being power conscious I want to connect this to my servers serial port which is on anyway.
The problem is that I am loosing data. I know this because part of the data I send is a counter and there are counts missing. Sometimes 3 or 4.
Fortunately I have a second server (one that I don’t normally leave on) which is identical in both hardware and software (suse 10.1). If I use that server it logs the data perfectly.
The server in question has been running 24/7 for many years (since 10.1 was released) and has been “tweaked” over the years so I suspect one of my “tweaks” has caused this problem but I have no idea what or how to investigate this.
Thank you for any ideas you may have as I really don’t want another server running just to capture this data.
Even though you report this works ok on another machine with identical hardware, I wonder if the signal is marginal somehow… shielding>>noise… What baud rate are you using? Have you tried reducing this (if practical)?
In order to use a device, you (or the program you run if you have “set user id”) needs to have permission to read and write the device “file” in the /dev directory. So a logical way to prevent others from using a device is to make yourself the temporary owner of the device and set permissions so that no one else can use it. A program may do this for you. A similar method can be used with the group of the device file.
While lock files prevent other process from using the device, changing device file owners/permissions restricts other users (or the group) from using it. One case is where the group is permitted to write to the port, but not to read from it. Writing to the port might just mean a message sent to a text-terminal while reading means destructive reading. The original process that needs to read the data may find data missing if another process has already read that data. Thus a read can do more harm that a write since a read causes loss of data while a write only adds extra data. That’s a reason to allow writes but not reads. This is exactly the opposite of the case for ordinary files where you allow others to read the file but not write (modify) it. Use of a port normally requires both read and write permissions.
You know sometimes Mr. Murphy just won’t give it a rest!
I have had many “challenges” with this latest project. The most recent one I posted on these forums about how I can create a daily log file and someone suggested logrotate. Excellent, and now I have that working.
Now I am at the next and hopefully last problem.
First a little history, I have built a microprocessor board which allows me to log my hydro usage. It involves a photo diode on my hydro meter which counts flashes.
Every 10 minutes I send the kWh out the serial port. Being power conscious I want to connect this to my servers serial port which is on anyway.
The problem is that I am loosing data. I know this because part of the data I send is a counter and there are counts missing. Sometimes 3 or 4.
Fortunately I have a second server (one that I don’t normally leave on) which is identical in both hardware and software (suse 10.1). If I use that server it logs the data perfectly.
The server in question has been running 24/7 for many years (since 10.1 was released) and has been “tweaked” over the years so I suspect one of my “tweaks” has caused this problem but I have no idea what or how to investigate this.
Thank you for any ideas you may have as I really don’t want another server running just to capture this data.
Hello sd_read. I read with interest your problem, but it is not clear to me who is losing this data. The board that records it or the computer you are sending it to? I happen to work in the HVAC industry and recording KW, KWH & GPM’s for instance is very normal. The controllers that record this data are proprietary and utilize what would be equal to a Real Time kernel in Linux I suppose. While most PC’s work in a batch mode of sorts, real time computers are not allowed to miss a thing. Its imperative to keep a computer under it maximum ability or it will simply miss events. While this kind of holds true for any PC in some ways, a real time system is different from anything you have worked with. In the case of recoding data, it needs to have very few unnecessary duties running. When sending data to some where else, the frequency the data is sent needs to be around 10 times more often that the ability of the recording computer to save recorded data. Transmissions are cumulative, but over a short time frame. I can miss several transmissions without missing usage today or over several days, depending on the recording computers ability to retain data. Now, after that mish mash of statements, my normal response would be to use what works and not try to get everything to work. Or, you need to restore what works on one PC to another if you really need two PC’s to work identically. There are lots of controllers that could communicate to a PC running Linux. I work with a lot of LON (As in Echelon) based controllers and lots of controllers that use BACnet. Industrial controllers are not inexpensive, but a whole lot of them cost less than an iPhone or other such device if you are really into this. And in any event, good luck with your experiments.
Fortunately I have a second server (one that I don’t normally leave on) which is identical in both hardware and software (suse 10.1). If I use that server it logs the data perfectly.
I think you need to compare the processes that are running between servers.
I wonder if the signal is marginal somehow… shielding>>noise… What baud rate are you using?
I am running 57600 baud and I have connected this board to many computers and looked at the output on an oscilloscope and observed healthy signal swings so I am fairly confident that it is not a hardware or signal issue.
The board that records it or the computer you are sending it to?
Excellent question and I believe I can say it is the computer because the other server never misses data. If you recall I send an incrementing count which is how I am able to determine I am missing data. On the good server I never miss a count.
Another possibility is that another process or app is reading the buffer occasionally.
On my server that looses data I write the file to a directory which I share over samba (which is another reason why I want to run this on my main server) with the following permissions:
Something that might be interesting is the kernel modules loaded. You can list manually of course (lsmod) but I have a script that can be helpful as well:
deano_ferrari you were right. I had two instances.
At the beginning of this project I was running minicom on that server from my desktop using screen. I guess I detached from that session and left it running.
Actually, I stopped using screen as it requires a ctrl-A as well as minicom and I couldn’t get it to behave properly.
I was thinking about rebooting the server which I now know would have fixed it. But I wouldn’t have understood why it got fixed.
What is still confusing is that I had two instances of minicom sharing the same comm port without any obvious complaints. I know windows won’t let you do this.
deano_ferrari you were right. I had two instances.
At the beginning of this project I was running minicom on that server from my desktop using screen. I guess I detached from that session and left it running.
Actually, I stopped using screen as it requires a ctrl-A as well as minicom and I couldn’t get it to behave properly.
I was thinking about rebooting the server which I now know would have fixed it. But I wouldn’t have understood why it got fixed.
What is still confusing is that I had two instances of minicom sharing the same comm port without any obvious complaints. I know windows won’t let you do this.
deano_ferrari you were right. I had two instances.
I’'m glad to have been of help!
What is still confusing is that I had two instances of minicom sharing the same comm port without any obvious complaints. I know windows won’t let you do this.
Maybe it was run without the required privileges. (Just a guess on my part).
Serial port setup
*A - Serial device
/dev/tty1 or /dev/ttyS1 for most people. /dev/cua<n> is still possible under linux, but not recommended any more because these devices are obsolete and many newly installed systems with kernel 2.2.x or newer don’t have them. Use /dev/ttyS<n> instead. You may also have /dev/modem as a symlink to the real device.
If you have modems connected to two or more serial ports, you may specify all of them here in a list separated by space, comma or semicolon. When Minicom starts, it checks the list until it finds an available modem and uses that one. (However, you can’t specify different init strings to them …at least not yet.)
To use a UNIX socket for communication the device name must be prefixed with “unix#” following by the full path and the filename of the socket. Minicom will then try to connect to this socket as a client. As long as it cannot connect to the socket it stays ‘offline’. As soon as the connection establishes, minicom goes ‘online’. If the server closes the socket, minicom switches to ‘offline’ again.
*B - Lock file location
On most systems This should be /usr/spool/uucp. Linux systems use /var/lock. If this directory does not exist, minicom will not attempt to use lockfiles.
*C - Callin program
If you have a uugetty or something on your serial port, it could be that you want a program to be run to switch the modem cq. port into dialin/dialout mode. This is the program to get into dialin mode.
*D - Callout program
And this to get into dialout mode.
E - Bps/Par/Bits
Default parameters at startup.
If one of the entries is left blank, it will not be used. So if you don’t care about locking, and don’t have a getty running on your modemline, entries B - D should be left blank. Be warned! The callin and callout programs are run with the effective user id of “root”, eg 0!