Main Site Documentation

Fez spider keeping time


#1

I setup a real simple time keeper, something like the following, however now it has run for a few hours 4 and i noticed the counter have increased to more than 2x the value i would have expected so obviously its firing faster than once every second… could you guys advise on a better way doing this? maybe using RealTimeClock or something.

private readonly GT.Timer _timer = new GT.Timer(1000);

  _timer.Tick += TimerTick;
            _timer.Start();

void TimerTick(GT.Timer timer)
{
_ticks++;
}


#2

What is the type of your _ticks variable?


#3

decleared like this

private int _ticks;


#4

Ok, what was the value you got and for how long did it run exactly? Also did you reset _ticks to 0 before starting the timer?


#5

well i have it still running since last night around same time as now

and right now it is at 250000 wich would make nearly 70 hours when only 24 has passed… i can also print the _tick on screen when scanning an RFID card. and scanning them quickly its quite easy to see its running to fast…

no since it was an int and non nullable, i figured it would start at 0


#6

You running on the latest firmware right?


#7

i would expect so i recived the module monday and followed instructions to upgrade


#8

I does look weird. There was a bug recently with SignalGenerator that was off. I wonder if what you experiencing related to that. I will check timer timings on my Spider later tonight.


#9

I would expect the Timer not to be accurate. Not quite that bad, but certainly not timing-level accurate for a MTB/running race. So you really do need to look at RTC


#10

Sometimes i think i would need to operate without internet, and i would like to be able to reset/resume / restore after a crash.

any advise on how to setup the RTC i tried it out initially but had dificulty setting it right…

im guessing an algoritm like, save start time, in the tick event save current time in the tick event while the timer is running, i i need to pause restore reset RCT to last time, then for the events just take the timespan between start and now() and convert to seconds for easy saving and datatransfer.

would give me all options needed for start stop resume. recover from a power down or battery change or something.

or are there any smarter way working around that?


#11

this issue was happened on G120 and Cerberus, not on Spider.


#12

Thanks Dat. :slight_smile:


#13

RTC = Real Time Clock.

You can get a “pretty good” approximation using the current processor ticks and dividing by the ticks-per-second, but that does assume that the ticks-per-sec is accurate. RTC is definitely the best way to go here.

RTC needs a battery backed source. It needs to be supplied to the Spider on the Z socket, as you can see from the schematics http://www.ghielectronics.com/downloads/Gadgeteer/Mainboard/Spider/FEZ%20Spider%20Schematics.pdf

Then you need RTC code. That should be the easy bit :slight_smile:


            // only need to use this once, to set the clock when the battery was lost
            //RealTimeClock.SetTime(new DateTime(2013,03,22,08,09,35));

            try
            {
                lastRebootTime = RealTimeClock.GetTime();
            }
            catch { }
            if (lastRebootTime.Year > 2010)
            {
                rtcIsWorking = true;
                Utility.SetLocalTime(RealTimeClock.GetTime());
                Debug.Print(" : System time set : " + RealTimeClock.GetTime().ToString());
            }
            else
            {
                Debug.Print(" : Error setting system time (RealTimeClock battery may be low).");
            }


(Note: this is a snippet of some 4.1 code for a Panda not a 4.2 EMX device, so you may have to suss out new methods)


#14

i was thinking my algoritm of storing dates on SD card and just let the RTC run when device is powered would make the battery un needed, I do not need it to be “real time” I just need the number of ticks or seconds between start and current to be fairly accurate. also controlling the RTC like this would make pausing or adjusting on the fly possible.

else i guess hooking the extender module and solder in a 3v lithium cell would be an option, anyone know if 3.7 would damage the board?


#15

It shouldn’t. That pin has max rating of +4.6V


#16

You can arbitrarily load a date and time into the RTC any how you like - reading a fixed date off SD card is as equally valid as a hard coded value like I have in my code !

To check what RTC VBat you want to use, I would suggest you grab the LPC2478 datasheet and check it’s specs (hint: page 52 says max VBat is +4.6v) Edit: Architect has better search foo than me :slight_smile: )


#17

@ Imageicon - We have used this “tick” approach on previous battery monitoring systems and there are some serious down sides on this.
The EMX has a RTC and you just need to add the crystal and a cell to have everything you can want.


#18

I think the crystal is already on the Spider board is it not?

And i think ill swap to using the RTC, first a non battery approach and if i find it neccessary ill try figuring out to add a battery…

Decent idea for a module extender board with coin cell clip on board


#19

You can also get “out of the box” external RTC solution:

http://www.dfrobot.com/index.php?route=product/product&path=144&product_id=840#.UUuMHSTD9aQ


#20

Yes, one that instantly came to mind when I first saw your topic - weekend project coming up !