gemellocattivo.com

Which means "Evil Twin". Lets see your projects where you change boring into fun or create the fun from scratch.
It is currently Thu Mar 28, 2024 12:48 pm

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
 Post subject: Re: o5e firmware
PostPosted: Mon Jun 15, 2020 8:11 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
Got curious this morning and found some speeduino accuracy test data
https://speeduino.com/forum/viewtopic.php?f=13&t=223

At 13000rpm, 3.5 degree worst case and 1 degree typical error. 1/2 that at 1/2 the rpm

Some else commented that the bosch ecu are 0.75 degree at 12000...which seems high honestly but still 5x better then the speeduino. The thread is from oct 2015 so this may be out dated but it was all I found.


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Mon Jun 15, 2020 10:44 am 
Offline

Joined: Fri Jun 12, 2020 11:49 am
Posts: 14
exactly thats 2015 the timing calculation were written again in 2019 or 2018 if i remember the accuracy is around 0.5 degree more or less but there was someone claiming 0.1
same for rusefi, i think rusefi has that better documented


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Mon Jun 15, 2020 10:46 am 
Offline

Joined: Fri Jun 12, 2020 11:49 am
Posts: 14
speeduino is now compatible with teensy 4.0 and 4.1 which is 600mhz


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Mon Jun 15, 2020 11:47 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
I'm not sure if processor speed is the critical driver to accuracy....it can help but I'm pretty sure its not the only factor.

rusEFI is NOT 0.1...its more like 1 at 6000rpm last I saw, if I'm remembering right. I think the 0.1 was was what I was telling them it should be.

The data I posted was all I could find with a quick search....for sure it MIGHT be different today but just because there was a re-write doesn't mean its now better, the only way to know is to measure it. The old data said 0.5 degree average error at around 6000, which became 1 degree average error at 12k but then there was the pesky max error which was much higher. I'd say that if there is no data for the new code/processor then the only safe assumption is that they have not solved the "clunker" max error points issue where most triggers are good but about 1% are WAY late due to events overlapping in the scheduler. This issue only has 1 solution, dedicated timers linked to dedicated co-processors. I say that because there is a reason ALL OEMs use chips with dedicated timers/co=processors and that reason is its the only way they can achieve the required specs...if they could hit spec with a chip this is even 1 cent cheaper they would switch, I know for sure Ford killed an entire vehicle project when it came in 9 dollars over target....that was 20 years ago, so they might tolerate a bit more these days but they track costs to the penny and feel the expensive processors are a required expense. All the commercial aftermarket ECUs, even MS, follow the OEM model and use the same OEM grade processors...again because they feel they need to. That is why o5e had an OEM spec chip that was a pain in the butt to deal with and why I keep saying to anyone who will listen the only open source path that can hope to be OEM good is adding a FPGA to get the timers and co-processing the OEMs have.

That doesn't make speeduino or rus EFI bad and I'm in no way saying it does, but I am saying there is no way to get OEM quality timing control using a SW scheduler in place of dedicated HW.


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Mon Jun 15, 2020 12:12 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
Read in the thread they are only using a 4us (250Khz) timer as well? Presumably this has improved with the Teensy, but still, measurement accuracy matters a lot when you are trying to calculate crank accelerations between teeth accurately.

Processor speed definitely matters very little for high precision timing accuracy. The timer peripheral itself is a big deal here.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Mon Jun 15, 2020 12:34 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
apalrd wrote:
Read in the thread they are only using a 4us (250Khz) timer as well?.


It says
Quote:
The way the scheduler code is written means that the timers are accurate to 4uS


I didn't take that the timer is running at 4uS, but instead to mean they can only respond to the timer within 4uS......but he doesn't say why so that may or may not have improved with a faster processor I guess.

I chuckle a little here in that the eTPU inputs that they say they can hold are uS, so nS accuracy. Lots of talk in the spec sheets about crank position max error never exceeding 0.1 degree. Eginelab recently switched to mS inputs to make the user interface simpler but, it used be 0.1 uS and still accepts 0.0001mS, which seem comparable to the eTPU specs.

That is the accuracy dedicated HW produces with no "most" outputs are within x but some are 10x :o


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Tue Jun 16, 2020 2:20 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
The accuracy of the eTPU is a direct function of engine speed, TCR1 rate, and crank interpolation ratio (angle ticks between physical teeth). During transients you can also get acceleration errors, but at some point you're only going to get so accurate with the number of teeth you have. But, you are always certain what your error is and can tweak the TCR1 rate and interpolation ratio to get a happy balance for your operating speed range and number of crank teeth.

My interpretation was they are prescaling the timer to 4us and that 1 tick = 4 us, but you are right it could be a deficiency in their calculations or interrupt handling latency. If they are relying on an interrupt handler to actually set the output pins, then they will always have latency issues. On an atmega chip, they may be limited by the 16-bit counter not having enough range for a higher speed counter without causing overflow at low engine speed, assuming they calculate timing events every tooth or rotation or something engine-synchronous. The 24-bit eTPU counter has 255x the range, and even then we can see counter rollover in ~3/4 second @ 10Mhz. That's enough that a normal TCR1 timer could overflow before one full engine cycle at low cranking speed.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Tue Jun 16, 2020 3:01 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
I think you hit the, I'll call it concern not issue, on the head. They only have a couple or handful of timers so interrupts are the only way to do it. The rusefi guys were talking about time stamps and and believed that was helping, not sure what the speeduino guys are doing but I assume something similar....but they lost my confidence at interrupts.....bad points. Lag is ok really when its repeatable it washed out in the tuning, when its repeatable. Interrupts are by definition interrupting normal operated and therefore will never be a normal and not repeatable....mostly it happens within a set time window but not always. That is why OEMs don't do it that way.

Then the 16 bit thing....MS is 16 bit and I assume, and its just an assumption, that they are doing all the timing stuff with 16 bit, and as you point out if you set it to not rollover through the missing tooth at cranking then you end up without a lot of clock ticks between teeth at redline. The eTPU went to 24 bit (and I think the bosch gtm is also 24 bit )because they had to and have 255x the resolution. That is just simple math.

So there it is....o5e existed to try to get OEM level accuracy in a user configurable and mostly open platform that was affordable. Projects like speeduino and rusEFI exist to get a low cost user configurable platform that works well. Different goals, and as a result different HW. My first introduction to an opensource ECU was freeEMS (s12) and it quickly became clear it was way to limited for what I had in mind. The S12 chips have gotten better and the I'd guess the ARM based projects are generally not far off what the S12 delivers accuracy wise.....but neither option gets you to OEM quality timing control because the HW is fundamentally not capable of that level of performance.


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Tue Jun 16, 2020 7:28 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
I asked on the rusefi forum ...they run 1 32bit timer at 1Mhz. If my math is right that gives them just about exactly the resolution possible in a S12 with a 36-1 wheel, they do better for lower tooth wheels, worse with higher tooth wheels.....and 1/255 modern OEM resolution.


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Wed Jun 17, 2020 11:48 am 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
Multiplexing a lot of high speed IO on a smaller number of timers is a recipe for disaster if they ever happen to overlap or be close to overlap.

Timestamps can help with inputs (where the hardware timestamps the pin transition, then an interrupt does computation) but they can't really help with outputs if you don't have enough timers to allocate one per output. The eTPU internally timestamps events before running microcode, although I've seen some less experienced eTPU programmers read the timer value in thread instead of the timestamp, and I've also seen less experienced eTPU programmers set output pins in thread instead of using the match opac. You can still mess up code in the eTPU.

I don't do piston engine work any more (and turbines are.. stupid simple to control), but the user adaptability of open software is also really useful for people doing more exotic projects where 'racing' ecu features just don't help. Some of the usefulness is reduced if it's too difficult to modify.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group