PLX-DAQ and time synchronizing

Hello guys,

I've built an acquisition system based on Arduino Uno and PLX-DAQ. Basically, the systems counts the number of activations of several relays during a specified time (10 min). I managed to configure the PLX-DAQ to show the system time, elapsed time, and number of activation of relays. Everything works perfect. However, I need some sort of time synchronizing with the Arduino. I would like the acquisition to occur at exact times, like 12:00, 12:10, 12;20, and so on. The most important is to get the data on "round" number of minutes, tens of minutes. Is there a simple solution for this problem?

Thanks,

Anton.

Is there a simple solution for this problem?

An RTC is about as simple as it gets.

PaulS, thanks for your answer. I thought about the RTC too. Any possible software solution? I tried the Time library and Processing script, but, since the serial port is busy with PLX-DAQ, synchronizing the Arduino with system time seems impossible. Or maybe I am missing something.

Any possible software solution?

Of course. You could re-write the PLX-DAQ plugin to send the PC time to the Arduino.

PaulS:
Of course. You could re-write the PLX-DAQ plugin to send the PC time to the Arduino.

Where can I find the examples of PLX-DAQ mods?

I don't think you should bother looking, you are just being sucked in by a smartarse. If it was practical to get PLX to handle two-way traffic, I bet somebody would have already done it, and we would all be using it. I'm sure you could get the time off the PC clock by means quite independent of Excel but I bet it isn't worth bothering with them either. I submit you will be far better off taking a deep breath, concluding that your clock is at the wrong end, and coming up with the $2.50 for an RTC.

The Excel TIME command is just a convenience, but not convenient for you, and it isn't too hard to send the real time data from Arduino. The RTC can trigger the event in round numbers by several simple means, including the TimeAlarms library.

If the event sequence is not actually real-time-critical but merely needs to be at ten minute intervals, and you don't feel like spending the money, I think you could do this just as easily by using millis, i.e. Arduino's internal timer. I understand it has about the same accuracy as a DS1307.

Nick_Pyner:
If the event sequence is not actually real-time-critical but merely needs to be at ten minute intervals, and you don't feel like spending the money, I think you could to this just as easily by using millis, i.e. Arduino's internal timer. I understand it has about the same accuracy as a DS1307.

OK, I will try RTC. Thanks!

Nick_Pyner:
The RTC can trigger the event in round numbers by several simple means, including the TimeAlarms library.

OK, I added the DS1307 RTC. Using the TimeAlarms library, I managed to evoke the Alarm.timerOnce at a "round" time (hh:10, hh:20, hh:30 and so on). This starts the acquisition. Then, I need the Alarm.timerRepeat to put the time and data on Excel spreadsheet every 10 min. For some reason, it does not work properly. When initialized in setup(), the Alarm.timerRepeat starts even before the Alarm.timerOnce. When initialized inside the loop() or any other function, it prints the data several times. Is there any other simple way to do this task? The method with millis(), when the Arduino millis are counting the time but the time stamp is the RTC (not PC) time , works. However, the millis are either lag or going faster then RTC. In general, I would like to evoke two functions with the RTC time: 1) start of acquisition at round time; 2) acquisition every 10 mins.

OK, I added the DS1307 RTC. Using the TimeAlarms library

and some code I didn't post...

When initialized inside the loop() or any other function, it prints the data several times.

That's not obvious to me.

Is there any other simple way to do this task?

Absolutely.

anton74:
OK, I added the DS1307 RTC. Is there any other simple way to do this task?

You need to be a little less secretive about you code and post it in the proper manner using the </> tags.
I was thinking of this under the shower the other day and maybe I was giving you a bum deal with TimeAlarms. It might be simpler to use modulo division.

  1. In setup, establish a condition to proceed. I THINK it is something like
 if (!minutes % 10 == 0)   //first time remainder=0  
{
return
}

i.e. only proceed when reaching the first round ten minutes, and irrespective of the hour. I only want one specific time each day and have not used this, but I recall el Supremo is a bit of an expert on it.

  1. establish a condition to do in a similar manner at the end of the loop
 if (minutes % 10 == 0 && second ==0)  // go when remainder =0 but only if seconds=0
{
send stuff to PLX
}

I guess the above approach might depend on the time of your loop cycle.

Nick,

Your last post was really helpful. Please see my code here. The code is quite long so I posted it on the pastebin.com. It probably looks bad, sorry for that. I incorporated your suggestion with the modulus thing at the end of the loop(). It seems to work OK now. However, I am not sure about the proceed in the setup(). Even without this, the code waits until the minutes turn 10 or increments of 10, and then starts acquisition every 10 min. The only thing I am not happy with is the delay(1000) at the end of the loop(). Without this delay, the data is introduced into the Excel several times. I would rather avoid the delay but don't want to use millis, if possible. I would be happy to hear any suggestion how to improve the code.

anton74:
It probably looks bad, sorry for that.

It looks bloody terrible... A few For.... next loops can fix all those long lists of ifs and serial prints, surely? The last time I saw stuff like that, it was in Fortran. It was fixable then, so it must be fixable now. Having said that, you're telling me it works, so it can wait - although the local tigers might snap at you in the meantime.

I incorporated your suggestion with the modulus thing at the end of the loop(). It seems to work OK now.

OK, that's good

However, I am not sure about the proceed in the setup(). Even without this, the code waits until the minutes turn 10 or increments of 10, and then starts acquisition every 10 min.

This (ahem) speculative code is intended to do nothing until the correct time, i.e. don't proceed with the setup. It came from the test for the presence of a kosher SD card. I understood you wanted to start at an "exact round ten minute" I don't understand how you are doing that.

The only thing I am not happy with is the delay(1000) at the end of the loop(). Without this delay, the data is introduced into the Excel several times.

This is because, without the delay, the loop is whizzing round at blinding speed, for no sensible purpose, and thus reading seconds=0 several times, hence my previous about loop time. Putting in a delay of one second fixes the problem and, if you have nothing better do do with the time wasted in the delay, is an entirely legitimate method of doing so. Maybe not very elegant. If you have lots of things going on, you probably need to tune the delay. My main project has a quite accurate one second loop by inserting an 850ms delay.

You could use the clock and a proceed condition, whereby you only advance when the seconds read is not the same as the previous seconds reading. There is also a one second square wave output from the RTC, and you just wait for a change in state therefrom. That's the mysterious SQW pin. I have never actually used either method, but they are useful to know about.

Well, I will try to use these For...next loops. Thank you for the suggestions!

Nick_Pyner:
I understood you wanted to start at an "exact round ten minute" I don't understand how you are doing that.

This is done by the last if at the end of loop():

  if (tm.Minute % 10 == 0 && tm.Second ==0)  {// go when remainder =0 but only if seconds=0
    if (runnum == 0) {
      OnceOnly();
    } 
    else  
      {
       SendToExcel();
      } 
    delay(1000);
    runnum++;  //increment run number
  }
 }
}  //end of loop

The loop() acquiring the data but does not send anything to Excel until the "exact round ten minute". Even at that minute, at the first run, I am not interested in data and send the "---" instead of numbers to Excel (function OnceOnly()). Then, at the next run after 10 min, the data is sent to Excel.

One more question: the RTC has some drift. This is DS1307, not the most accurate RTC, I know. I am setting the time manually. I have seen that synchronizing it automatically by serial communication is not so accurate, the RTC lags about 8 sec or so. Do you think that it worth adding the synchronizing code with some correction for the lag?

Thanks!

OK, I understand what you are doing for sending data to Excel, and it is exactly what I hoped. But that is in the loop - the do. What I don't understand is how you get Arduino started at the right time, which is in the setup - the proceed.

Maybe you are getting round this by sending Excel a dummy

Do you think that it worth adding the synchronizing code with some correction for the lag?

No. I don't know anything about it, and I bet it's nonsense anyway. I submit it will be a lot better, and certainly a lot simpler, to get a DS3231. They are only a dollar or so more and far more accurate. Down here in God's own, the vagaries of the DS1307 were not immediately apparent and I wouldn't hear a word said against them. They were fine in the office but, now one is outside on a winter's night and the problem has become apparent.

I am in the process of replacing them with DS3231s. Jack Christensen is the RTD guru. I understand the DS3231 runs on DS1307 code. Be aware that the typical DS3231 is not nearly so easily integrated into a shield as the Tiny DSS1307. The battery holder is as much of a problem as anything else!

I did not mean to imply in reply #5 that the DS1307 is the way to fly, only that Arduino's clock is about as accurate. There are other RTCs but I understand the 3231 is the most common choice.

Well, I am still using the DS1307. The accuracy seems OK for now. However, I have encountered another problem: the system stops the acquisition sometimes and requires restart of the Arduino. I believe this could be related to the serial communication. Is this a known issue with PLX-DAQ?

No. PLX has been around for a long time and, if there was a problem like that, it would probably be common knowledge. I have had a similar problem recently, where the temperatures on display all read zero. This required a restart. I am not using PLX at the moment but I am using serial for graph via bluetooth. I can't see how serial can be the problem. It has only happened once, and after months of continuous operation.

The accuracy of DS1307 only becomes a problem when there greater variations in diurnal temperature. I had to go outside to get that. I still use them!

Nick_Pyner, my code has many 'if' loops, many serial commands and now also includes RTC. Do you think the code could freeze the Arduino because the memory limit is reached?

I would not have thought it likely. It can easily happen with data aquisition, but I recall all you are doing is pushing buttons and rattling relays. Check the programme size when compiling. If it is over 30k, it indeed is quite likely. The other Valley of Death is using strings. In both cases, you screw up the system while running. If the programme is over 32k, you won't be left in any doubt about the problem, as the IDE will refuse to compile.