rusefi.com

As is, STM32F4DISCOVERY does not have all the hardware components for RTC using LSE, whatever LSE is. Bottom line - for more precise time, you need to solder some extra components. Without the extra components I recall the RTC based on LSI was about 10% off.

So,
1) add X3 Crystal: SER2417CT-ND MC-306 32.7680K-E3
2) add C16 & C27 6.8pF 0603: I hope 399-7957-1-ND / mouser 77-VJ0603A6R8DXAPBC would work
3) remove SB15 & SB16 (these are on the back of the board)
4) check that your board has R21 and R22

A good post on this is here

What can I say, I am "looking forward" soldering some 0603

have you got the toast oven? what is the accuracy you are talking about? plus/minus a minute during a month seems quite enough.you believe we need a separate quarz?

could you be more specific? what does it mean " 10% off"?

puff wrote:could you be more specific? what does it mean " 10% off"?

It means that RTC says it has been 60 seconds while in fact it was 66 seconds. Or 30 days instead of 33 days. A 10% error for measuring time without the 2nd crystal. The value is what I remember from my tests a year ago.

then we definitely need one. at least on the final board. am i right in thinking that one needs a quarz, two caps and a cell battery? no need to alter the code?

I know that you need a crystal and two capacitors for RTC. I am not sure if it's just a battery or some extra components around the battery - but we already have the battery on our brain board

This would require a little bit of coding but I am working on it.

This might get you going.

abecedarian wrote:This might get you going.

Nope, it would be MUCH easier for me - ChibiOS has a RTC driver - see HAL Support section here

Only posted it because the guy had issues with losing RTC settings with hard reset.

well. i gonna start my procurement list

so, the quartz is MC-306, two(?) 0603 ceramic caps 6.8pF each (should I pay attention to voltage and tolerance?)
or it's useless unless you turn on quartz support in firmware?

So I did it!

Soldering X3, C16 & C27 was not that bad. R21 and R22 were already there.

Dis-soldering SB15 & SB16 on the back was not fun! I had to apply solder wick like 10 times to get everything off - with size so small there was a super-thin layer of tin connecting the pads which are supposed to get disconnected.

I've checked most of the needed configuration change, the one line which you would need to change if you want to use RTC is You want to change it to Now the fun part: for now, RTC is pretty much useless. With just a millisecond granularity, I am not sure how it could be used for anything meaningful. Maybe just to figure out a coefficient for internal, non-RTC clock correction?

just to make oscilloscope readings meaningful?
hard desoldering is probably explained by pbfree technologies?

I'm confused. Does this mean that the inaccurate RPM issue has been solved or not?

E4ODnut wrote:Does this mean that the inaccurate RPM issue has been solved or not?

Sorry for the confusion. No, inaccurate RPM has NOT been resolved yet. Upon further investigation I've realized that inaccurate RPM is maybe not related to RTC at all. Right now I am focused on the inaccurate RPM and scheduling precision in general, will let you know once I have progress

Thanks.

you sure it has been turned on in the firnware? how did you learn it hadn't been fixed?

I'm a skeptic that the accuracy is significantly effected due to xtal drift or other such issues. Generally at room temp xtal will hold a fairly good accuracy. However xtals are highly dependent on vibration, temperature and aging. I believe that the RTC will simply allow you to generate a more accurate timing reference. Then you can create a timer based off your normal xtal and see how far your normal xtal has wondered relative to the RTC reference. Once you know this drift, you can compensate your normal clock reference. I'm assuming you have a place where you say blah clock cycles = blah Hz. This RTC calibration thing would allow you to periodically change that ratio.

Here's a link to a generic wikipedia thing, as well there's a bunch of good info in the NIST recommended use of a stopwatch document.

http://en.wikipedia.org/wiki/Quartz_clock#Accuracy
http://tf.boulder.nist.gov/general/pdf/2281.pdf

In the NIST document, around page 74 it shows ball park variations due to things like aging, vibration, temperature, ect. Then take note on page 75, it shows when the room temp accuracy it around 1PPM, is around -20PPM at 0C, so the accuracy is 20 times worst based on a relatively small temperature change.

I see from here some folks are complaining that their RTC references are wrong by around 19 minutes in 12 days, and another that claims 2.5 minutes in 12-15 hours. http://mbed.org/forum/mbed/topic/3699/?page=1#comment-23581 Many RTC's use an XTAL, so I would expect most of the wondering issues to be the same as the original xtal. RTC's are generally very low power devices used to ensure long term accuracy of a clock reference. I'm not sure how RTC's will make a significant difference in the short term variations, but might help with longer term issues caused by temperature or aging. Take note that aging drift happens the most in the first several hours of use.

I certainly think the RTC effort is worth pursuing to see how it compares, but I'm a skeptic that it will make a significant change. I see the HC-49S-C20QSA-8.000MHZ has a 25C stability of +/-30PPM, then if we get a 20X multiplier based on temperature, I guess this could be an issue. However the MC-306 32.768K-E3:ROHS is +/- 20PPM, so I don't think it's going to help as much as we would like.

on the there hand when I googled the specs for the suggested xtal, I decided to find out what actually 20ppm means for that frequency. somewhat 1.5 secs per day. not that bad after all? or we're building atomic clock?

setting up a thermal-insulated thermostatically controlled box for the xtal? but that won't fix vibrations-related issues…

could it be so that inaccuracy is caused by RTOS?

puff wrote:could it be so that inaccuracy is caused by RTOS?

RPM inaccuracy is caused by rusEfi, not RTOS. There is more info @ https://sourceforge.net/p/rusefi/tickets/24/
Let's refrain from discussing this within this topic - this topic is called 'Real Time Clock', and real time clock is fine. RPM is not related to real time clock.

A more suitable topic would be http://rusefi.com/forum/viewtopic.php?f=5&t=517

so after all do I need to buy and solder on xtal and two caps on the discovery? (since it doesn't make things more accurate)

I suggest you wait till I figure out the whole deal. Right now I am not sure if RTC would be needed or not.

Hmmm, so 8MHz with 30PPM of error would be like this. According to this on-line calculator. http://www.jittertime.com/resources/ppmcalc.shtml

At a perfect 8MHz, it takes 0.000000125s per cycle. So one perfect RTC cycle at 32.768KHz. would take 244 ticks.

At 30PPM 8MHz, is really 8000240, so 0.000000124969s. So one perfect RTC cycle at 32,768Hz would still take 244 ticks.

On a side note, 5PPM http://www.digikey.com/product-detail/en/CFS206-32.768KHZFB/300-8763-ND/2217074 Not the correct form factor or anything like that, but 5PPM is reasonably low cost. I'd bet we can find a better RTC.

As far as I got we were talking about 32768Hz xtal with 20ppm as per specs, not 8mhz? right? (if it makes any difference)
the 5PPM seems cheaper than 20PPM))
but Russian says that current inaccuracy might not be caused by the absence of proper xtal…

The RTC get used as a reference to calibrate the normal operating clock, which is 8MHz.

For example, That jittertime web page notes that at 32768, with a PPM of 20, the change in Hz is 0.65536. However when we change the frequency to 8MHz, the change in Hz is 160. So when measuring a 1Hz signal, the 32768 RTC will be much more accurate, as there are less clock cycles that could be in error. By checking the 8MHz signal against the 32768Hz signal, you can obtain better accuracy of the 8MHz signal. You don't want to use the 32768 signal for your normal operation, as it's simply to slow.

2nd part of RTC functionality is powering the clock while rest of the chip is turned off. The problem is that stm32f4discovery board does not have VBAT (clock battery) pin on the header.

http://eletel.eu/mipsa/index.php/pl/component/content/article/85-polish-articles/bez-kategorii/baza-wiedzy/mikrokontrolery-z-rdzeniem-arm/151-stm32f4-discovery-rtc-hack describes a way of soldering a battery holder on top of the discovery into R26 or C28 pads on the PCB but that does not look right to me. I have an idea...

Phase #2: VBatt mod

Remove R26 to disconnect VBatt from +3v on discovery board.

Add a wire from below where R26 used to be/lower end of the capacitor to the right from R26 position to the unused NC on both discovery and Frankenso and it works!

Sweet, does that mean it can keep keep crank sync when turned off? AKA faster restarts.

kb1gtt wrote:Sweet, does that mean it can keep keep crank sync when turned off? AKA faster restarts.

For now all it means is nice log file names on the SD card Will need to look if there is any RAM powered by the battery, definitely not the whole chip.

kb1gtt wrote:Sweet, does that mean it can keep keep crank sync when turned off? AKA faster restarts.

Is that really a thing? Would be awesome!
I would have guessed that the engine keeps rotating a bit after turning off ignition and therefore losing the ability to count trigger pulses...