Teensy 3.1 + Ethernet & RTC

Status
Not open for further replies.

Pointy

Well-known member
I finally got around to starting my next project and it requires an ethernet connection to send and receive data. So far I have the Wiz820 SDAdaptor and WIZ820io module connected and working with my Teensy 3.1, which is a good start.

The system is going to be running 24/7 and I need to switch things on and off at certain times of the day, so I am going to need to keep track of time. I found a piece of code that get the time from an NTP server but I was wondering if I should use a DS1307 and if so can it be connected along with the ethernet module?

Any suggestions on the best way to keep track of time? It doesn't have to be super accurate but I would like to also know what day it is.

Regards,

Les
 
The Teensy 3.1 has a real time clock (RTC) built-in. You will need to solder a 32.768 kHz, 12.5 pF crystal to the Teensy. If you hook up a 3v coin cell battery to the Vbattery/ground pings on the back of the Teeny, it should keep the RTC powered for several years, even if the rest of the Teensy is not powered. There are threads of how to correct the RTC based on the temp. of the Teensy. Or you could potentially use a ntp query to get the official time. http://pjrc.com/teensy/td_libs_Time.html#teensy3
 
The Teensy 3.1 has a real time clock (RTC) built-in. You will need to solder a 32.768 kHz, 12.5 pF crystal to the Teensy. If you hook up a 3v coin cell battery to the Vbattery/ground pings on the back of the Teeny, it should keep the RTC powered for several years, even if the rest of the Teensy is not powered. There are threads of how to correct the RTC based on the temp. of the Teensy. Or you could potentially use a ntp query to get the official time. http://pjrc.com/teensy/td_libs_Time.html#teensy3

Thanks Michael.

Not sure how I missed that!.

Regards,

Les
 
I've used RTP in the past, rather than the RTC. Once in a while, you have to set or resynch the RTC chip to real time anyway. May as well just not use an RTC if you have connectivity to the internet, or a PC with a time server on a LAN.
 
What's the worst case time variance with temperature, using the built in RTC? The unit is going to be housed in an outside building, so it will be affected by the temperature. As I have said it doesn't have to be super accurate, so if I can get away with just syncing one or twice a day it would be good. I have ordered some crystals and CR2032 holders to play with anyway.

Are there many breakout boards for the Teensy 3.1? I found this one so far.

EDIT. What pins are left for digital I/0 assuming I use both the sdcard and ethernet? Is it really just using 4,8,9,10,11,12,13?

Regards,

Les
 
Last edited:
What's the worst case time variance with temperature, using the built in RTC? The unit is going to be housed in an outside building, so it will be affected by the temperature. As I have said it doesn't have to be super accurate, so if I can get away with just syncing one or twice a day it would be good. I have ordered some crystals and CR2032 holders to play with anyway.

You likely will be fine if you sync daily, assuming that you only need seconds() to be accurate. See this test I ran on a CFS206 RTC crystal from Citizen:
Screen Shot 2014-09-21 at 6.41.14 AM.png
So your maximum deviation will likely be less than 100PPM. However, to really know, you have to test. For a longer discussion of RTC crystal drift vs. temperature, see the thread I pulled this image from.

Are there many breakout boards for the Teensy 3.1? I found this one so far.

There are multiple ones on Tindie. The question is what you want, i.e. a big breakout, a Arduino shield adapter, etc.
 
If you go to the top of this sub-forum, there is a sticky thread that has all sorts of tips and techniques for the Teensy 3.x. On page 2 of the thread, I put an updated list of the various breakout boards I was aware of for the Teensy 3.x: https://forum.pjrc.com/threads/25395-Teensy-Quick-Reference-Code-Examples-Tips-and-Tricks/page2.

Thanks Michael.

You likely will be fine if you sync daily, assuming that you only need seconds() to be accurate. See this test I ran on a CFS206 RTC crystal from Citizen:
View attachment 3256
So your maximum deviation will likely be less than 100PPM. However, to really know, you have to test. For a longer discussion of RTC crystal drift vs. temperature, see the thread I pulled this image from.

Thanks for the info and link.

There are multiple ones on Tindie. The question is what you want, i.e. a big breakout, a Arduino shield adapter, etc.

Main thing I need is some mounting holes. I would like to solder some sockets into the breakout board so I can remove the Teensy if needed. It would also be nice if it had a space for the CR2032 battery holder and screw terminal connector options for the Teensy pins. Size does not matter too much as I have plenty of space to mount it.


Regards,

Les
 
Last edited:
Is there any interest in a PTP library?
(*not* NTP; PTP aka IEEE1588 allows for much tighter synchronization between systems on the same subnet)

I am tempted to write one and do a proof of concept where I trigger a digitalWriteFast to occur at the same time on 2 networked Teensy's and see how close they come..
 
If you don't need access to the pins on the bottom of the teensy, you might look at the Adafruit Perma-proto boards, such as the 30 pin variant: https://www.adafruit.com/products/571 that mimics a normal breadboard, and a 30 pin variant that is made to fit in an Altoids mint tin: https://www.adafruit.com/products/723.

You can solder two rows of 14-pin sockets from PJRC to allow easily removing the Teensy: http://www.pjrc.com/store/socket_14x1.html. Adafruit (and other places) has a 28 pin, 6" IC socket (https://www.adafruit.com/products/2206), but IMHO, if you are going to remove the Teensy more often, go with the 14-pin sockets. I have those IC sockets, and the pins are rather tight, and you might bend the pins on the Teensy if you aren't careful.

You can get a breakout board for the CR2032 at adafruit and other places: https://www.adafruit.com/products/1870
 
Last edited:
I am tempted to write one and do a proof of concept where I trigger a digitalWriteFast to occur at the same time on 2 networked Teensy's and see how close they come..

That would be pretty cool. That said, if the only goal is good timekeeping, you're likely better off with a GPS receiver. I'm amazed how well these work - even inside a stick-built home, receiving a strong signal through multiple stories, the roof, etc. The GPS solution, if it can be implemented, is also likely cheaper than networking the Arduino/Teensy.

Lastly, I wonder how accurately / well you can distinguish between various signals coming in at nearly the same time. Oscilloscope? Logic Analyzer? If so, how fast does either have to be to accurately tell the difference when the likely time difference is 1 micro-second or less?
 
Lastly, I wonder how accurately / well you can distinguish between various signals coming in at nearly the same time. Oscilloscope? Logic Analyzer? If so, how fast does either have to be to accurately tell the difference when the likely time difference is 1 micro-second or less?

Well I have a digital scope with 70MHz bandwidth and 2GSa/S sampling, I should be able to give a fairly accurate value.

In any case, I'll start a new thread to prevent hijacking of this one.
 
I still don't get it.. if you have an Ethernet interface and LAN/WAN access, is the reason to use GPS or RTC rather than a 'net time server just for learning purposes?
 
If you don't need access to the pins on the bottom of the teensy, you might look at the Adafruit Perma-proto boards, such as the 30 pin variant: https://www.adafruit.com/products/571 that mimics a normal breadboard, and a 30 pin variant that is made to fit in an Altoids mint tin: https://www.adafruit.com/products/723.

You can solder two rows of 14-pin sockets from PJRC to allow easily removing the Teensy: http://www.pjrc.com/store/socket_14x1.html. Adafruit (and other places) has a 28 pin, 6" IC socket (https://www.adafruit.com/products/2206), but IMHO, if you are going to remove the Teensy more often, go with the 14-pin sockets. I have those IC sockets, and the pins are rather tight, and you might bend the pins on the Teensy if you aren't careful.

You can get a breakout board for the CR2032 at adafruit and other places: https://www.adafruit.com/products/1870

Thanks Michael, I prefer the one I linked to (TallDog's).

I still don't get it.. if you have an Ethernet interface and LAN/WAN access, is the reason to use GPS or RTC rather than a 'net time server just for learning purposes?

Belt and braces I suppose, just in case the network goes down for any length of time.

Edit. Forgot to say I found this awesome Arduino Ethernet Shield Web Server Tutorial which seems to work with the Teensy and is exactly what I was looking for.

Regards,

Les
 
Last edited:
FWIW, I've heard many issues re: embedded system stability when the internet is involved. Most such systems incorporate a watchdog to kick the reset button if the MCU becomes unresponsive for some reason. It's why I like GPS better... likely more accurate and definitely more stable, though with the requirement for some sort of LOS to the satellite constellation. However, if your project requires connectivity to start with, then it definitely makes sense to make use of NTP.

Because measurements are paramount to my application, I try to compartmentalize the internet portion from the rest of the project. The high-latency issues associated with a GPRS modem are off-loaded to a module that can work on its own, without the need for a fancy RTOS or similar approach.

The potential stability issue is one of the reasons that I placed my GPRS modem on a separate module with its own dedicated processor - if it goes down, oh well... but the system master MCU and the other slaves will remain unaffected. Is dedicating a Teensy to just running a RS485 / GPRS bridge overkill? Perhaps, but consider the benefits of having multiple hardware serial ports, oodles of memory, etc.
 
Last edited:
FWIW, I've heard many issues re: embedded system stability when the internet is involved. Most such systems incorporate a watchdog to kick the reset button if the MCU becomes unresponsive for some reason. It's why I like GPS better... likely more accurate and definitely more stable, though with the requirement for some sort of LOS to the satellite constellation. However, if your project requires connectivity to start with, then it definitely makes sense to make use of NTP.

Because measurements are paramount to my application, I try to compartmentalize the internet portion from the rest of the project. The high-latency issues associated with a GPRS modem are off-loaded to a module that can work on its own, without the need for a fancy RTOS or similar approach.

The potential stability issue is one of the reasons that I placed my GPRS modem on a separate module with its own dedicated processor - if it goes down, oh well... but the system master MCU and the other slaves will remain unaffected. Is dedicating a Teensy to just running a RS485 / GPRS bridge overkill? Perhaps, but consider the benefits of having multiple hardware serial ports, oodles of memory, etc.

A GPS receiver can, after initial startup lock, determine date/time (GPS time which differs slightly from UTC), with one satellite in view.

I and many others use off-loaded TCP/IP stacks like WizNet's 812Mj or 820. This, plus well designed software and avoiding flaky amateur libraries, yields embedded systems that don't have watchdog timer timeouts.
 
Thanks to the help so far on this forum and the tutorials I posted above I now have the Teensy acting as a web server hosting files from the sd card. I can read pin values and switch outputs, so that's great. The only issue I have is speed. A simple web page with a single 50KB image takes several seconds to load. I tried a different SD library which according to some benchmarks was 4 times faster, but I made no difference. So is the bottleneck the Ethernet? Any suggestions on speeding things up?

Regards,

Les

Edit: I decided to post a new thread about network speed.
 
Last edited:
Hi Guys,

I am pretty happy with where my project is at, and the last piece of the puzzle is the timing.

I have the Teensy 3.1 with the crystal and battery backup, I am also able to get the time from an NTP server. I am just struggling to get my head round how that whole thing goes together. This is what I hoping to achieve...

I simply need to be able to schedule events to switch pins high/low. Currently I am thinking of controlling 4 pins, with the option of switching them on and off twice a day, giving a total of 16 events.

My questions are...

What is the best way to set this up?

How does the Teesny3clock integrate with the the system? (The 'TimeAlarms' library says it doesn't need any external hardware, so does it rely on millis() and does setting the Teesny3clock change millis()?)

Should I attempt to write my own schedule code or is there something out there for use with RTC or the Teensy3Clock?

I currently check the NTP time against the Teesny time and then set the Teensy time if they are not the same on system boot. I am then thinking, I should set the sync provider to the Teensy and then sync the Teesny to the NTP once a day, does this sound right?

Any thoughts or suggestions welcome.

Regards,

Les
 
Accuracy needed? A few seconds?
If there is WAN and NTP, I'd just synch the Teensy to NTP every 4 or so hours, not just once a day.
No RTC hardware or crystal needed. User the C library (libc) time functions for getting and setting time, getting calendar date/time, etc.
 
EDIT. What pins are left for digital I/0 assuming I use both the sdcard and ethernet? Is it really just using 4,8,9,10,11,12,13?

Hi,

Sorry to drag this thread up again but I just wanted clarification/confirmation on the above question when using the Wiz820+SD Adaptor. (I am hoping to get moving on this project again soon, at last!)

Regards,

Les
 
As mentioned above, GPS is inexpensive and easy, and needs only a single satellite for time so it has a better chance of working indoors.
As I recall, GPS time differs by 4 seconds from UTC.

crystal/RTCs drift.
 
Status
Not open for further replies.
Back
Top