FreeEMS Issues - Issues

0000336: Make N+1 Generic For Crank Use

Wed, 01 Feb 2012 16:55:28 +0000

Currently it assumes that the sync pulse is on the cam, make it possible for the sync to be on the crank and tidy up the defines that drive it more too.

0000136: Extend scheduling code for injection

Tue, 31 Jan 2012 21:07:10 +0000

Add stuff to allow timed injection with percentage scheduling and associated conditions on what to do/not do, no longer necessary as multi delay is std. Remove old stretch code? Includes migrating all injection from fixed event+mindelay scheduling to angle based scheduling.

0000510: Ctrl Q does not quit and Ctrl W does not close the last window (and effectively quit)

Tue, 31 Jan 2012 20:44:02 +0000

W possibly doesn't close any windows. Without this I'm left with a vast ocean of events as I try to quit using the mouse...

0000518: Add GM DIS Decoder And/Or Required Logic

Mon, 30 Jan 2012 01:17:28 +0000

Documentation is currently being collected here:

http://forum.diyefi.org/viewtopic.php?f=67&t=1549 [^]

It shouldn't take too long to knock out something suitable to do this job.

0000517: Write J Series Honda 2 or 3 input Decoder

Sun, 29 Jan 2012 18:16:16 +0000

http://forum.diyefi.org/viewtopic.php?f=56&t=1524 [^]

12 on the crank and two cam wheels with 4 in a 6 minus 2 pattern offset for quick sync. This shouldn't take me too long to knock out, but I'll be flying blind without a test rig.

0000513: Behaviour Of Media Style Controls Not Intuitive

Sun, 29 Jan 2012 17:15:37 +0000

scrolling is better. BUT stop should STOP the display not reset it to the beginning..., just like a cassette, stop stops at the CURRENT POSITION, it doesnt' rewind to the beginning of the tape

0000272: Improve RPM Accuracy & Granularity At All Scales

Sun, 29 Jan 2012 13:11:51 +0000

Currently RPM is calculated in an acceptable way at low RPMs and degrades as RPM increase to a granularity of 125 or so at 17000. Clearly this is unacceptable, however it's usable at 8k and below for the time being.

This can be achieved by using different scaling factors depending upon the raw RPM involved. A single figure can never be correct given the range required.

This change will carry with it the added benefit of a lower minimum RPM. Maximum levels will be more usable due to 0.5 granularity or close being restored.

0000256: Add Delay After Sync Loss Before Resuming Outputs

Fri, 27 Jan 2012 16:37:40 +0000

This affects all decoders, but for example, take the 24/1 decoder:

The pattern is read in, and the single input event comes in on the second RPM input, sync is obtained. The primary RPM input starts counting input events on its channel. Output events scheduled during the first part (1%-99%) get fired successfully. Then a noise pulse arrives and is caught, sync is lost, and any output events in the second part of the cycle are not fired. Then the single input event comes in on the second channel again, and we repeat.

The effect of this behaviour is to have the engine running on only 1 or 2 or 3 cylinders (for a 4) and running badly and in a biased way. On engines with sequential and COP this is the only effect, however on engines with semi or batch fuel, some cylinders will still be supplied some fuel and no ignition and so on and so forth. This can result in lean conditions or fouled plugs or washed out rings etc.

What needs to happen is that a delay between loss of sync and producing further outputs needs to be added such that after a loss of sync all cylinders get a rest for a while, and the engine stalls and is less likely to run in a potentially damaging way.

This must be implemented in a way that only affects things after a loss of sync, as opposed to during a fresh from nothing sync. If it is done any other way, starting will suffer, which is unacceptable.

There are some extensive conversations (and a lot of arguments) on this matter here:

http://forum.diyefi.org/viewtopic.php?f=8&t=1143 [^]

0000069: Add Useful COP Monitor Function

Fri, 27 Jan 2012 14:12:59 +0000

Add a COP ISR handler that packages up the registers states, sends them out using the serial code and when done resets the device.

This shouldn't take a significant amount of time at all, but is low priority.

An addition to this at a later date could be to fill the free code space with jump instructions to run this code, however the chance of hitting such space is currently around 50% and dropping daily. It will approach zero in the medium term, so I deem that change ineffectual and a waste of time. (nice idea for a lightweight unreliable app though).

0000514: Code Responds To Wrong Button Events

Thu, 26 Jan 2012 16:39:25 +0000

Instead of performing an action on button release, if and only if the mouse is still within the button, you perform the action when the mouse goes down, consequently the valid behaviour of holding a button and moving the mouse before release results in an action that it should not. This is bad and wrong. Please fix.

0000511: Remove All Signs Of Ant Now That We Have Releases

Mon, 23 Jan 2012 01:09:37 +0000

As per title, rip out build.xml and update readme and forum.

0000315: Get horizontal scrolling to scroll the graph left and right.

Fri, 20 Jan 2012 21:49:09 +0000

Get horizontal scrolling (laptops with horizontal scroll on touch pad and certain mouses) to scroll the graph left and right.

0000509: OLV main window fails to use window size commanded from the window manager.

Fri, 20 Jan 2012 14:27:08 +0000

At initial program load, while running stumpwm (a tiling window manager), in fullscreen mode, the application draws a window that does not utilize the entire space available for it. This results in a smaller than necessary program, set within a big grey 'L' representing the unused screen space.

To fix this, the screen can be split, and then the spit can be removed. This results in a OLV main window that has been properly maximized for the space it is allotted.

I suspect that the issue is a combination of the application assuming that it can assert an initial window size, and the application expecting a resize event if changed.

I suspect that firing a resize event after painting the initial window would solve this problem, but I have not tested my theory.

For example: http://puddle.ca/~sim/volvo/FreeEMS/OLV/OLV-small.jpg [^]

0000505: Fix Excess CPU Usage With Mouse Over Graph

Wed, 18 Jan 2012 11:09:11 +0000

Most noticable when playing as frame rate drops a HEAP. I know this doesn't happen on your box, or this one, but you can likely look at which code runs and try to figure out how it can be done more efficiently with less redrawing and more applying patches of image from different buffers to a single buffer and redrawing only the bit that you need to as the image moves, etc.

0000504: Builds Fail On #include Line

Mon, 16 Jan 2012 17:06:12 +0000

FreeAir:src fred$ grep -rn include bfd/ | grep malloc
bfd/configure:13665:ac_fn_c_check_decl "$LINENO" "malloc" "ac_cv_have_decl_malloc" "$ac_includes_default"
bfd/configure.com:287:/* Whether malloc must be declared even if is included. */
bfd/elf32-xgate.c:29:#include

I'm 99.99999% sure that you should not be including that file. Please remove it on your side as the generated headers probably already provide it for you. If the build stops working, look at other headers included by other bfd impls, such as libiberty.

0000352: Make ctrl C/V/X/Z work in the file chooser on Mac

Thu, 12 Jan 2012 21:52:43 +0000

Firstly, are they working on win? If they are, then it's just a mapping issue on Mac. On mac it's command C/V/Z/X and not control. Might need some mapping at boot time between system keys and internal keys to achieve this properly. Yes, I think that is the right approach. Abstract the keys away.

0000500: Missing Events On MissingTeeth Decoder - Can't Reproduce

Wed, 11 Jan 2012 13:40:12 +0000

This morning while testing config for the slater I saw an instance of missing events. I've been unable to reproduce it, however I have a log file (attached) which shows it. I don't yet know why this happened. I tried the same settings and could not make it happen again. I thought maybe it was dwell length related, but that didn't help. This is to not forget that it happened.

0000499: Find Source Of 0.109ms timing error

Wed, 11 Jan 2012 12:23:05 +0000

Static bench test with 1250RPM 5000 tick per event 12-1 bench test hack

Dwell of 1000 ticks/0.8ms or 10000 ticks/8ms behaves the same.

Timing is correct with different decoder offsets and different timing values, however it always has 0.109ms error in it. Dwell end is slightly late.

This doesn't change with RPM or dwell or timing, it's always there.

0000474: Provide Up Time Through Various Mechanisms

Sat, 07 Jan 2012 13:29:27 +0000

Up time in seconds sounds reasonable:

((((2^16) / 60) / 60) / 24)

If we have an uptime counter in seconds, and it's 16 bit, then we have 18 hours of uptime before the roll over, easy to detect and handle. 24 bits is 194 days and hugely excessive. This same var could be used for longer term things like fuel pump turn on/off and similar. Care will need to be taken to ensure that roll overs don't do weird stuff.

Possibilities are poll for this number and maybe some other stats as a sort of stats/health package and/or include it in various datalogs. Personally I don't care about uptime when reviewing a datalog in most cases, so that feels wrong to do.

0000498: Remove all CLEAR_ flags and replace with a macro that clears

Wed, 04 Jan 2012 14:14:20 +0000

Current stuff is error prone and bad for maintenance with duplicated flag defines everywhere, yuck. Probably move to something like this:

SETBITS(variable, MASK);
CLEARRBITS(variable, MASK);

or

ENABLEBITS(variable, MASK);
DISABLEBITS(variable, MASK);

or similar.

0000497: Debian 32 bit packages build different binaries to all other platforms

Wed, 04 Jan 2012 12:44:01 +0000

Debian 32 is considered correct at this time. 64 bit packages, windows packages and mac packages should NOT be used to run engines until this issue has been resolved.

Both should be disassembled, even in part, and compared to determine the difference in machine code generated and which is wrong/right/better/worse.

0000472: Provide Get Data/Store Data Per Page

Mon, 02 Jan 2012 21:04:57 +0000

On each tab, at least, or more granularly, provided a way to refresh data from the ecu, and burn data to the ecu ONLY for what you're looking at.

Additionally, once 0000261 is implemented provided a get from flash and/or reset to whatever is in flash function so that mal-adjusted things that are in ram can be discarded without manually doing it or a reset/reinit that affects everything being performed.

In MegaSquirt where settings for one thing are spread across many pages, this will likely require a map of what is in the current view/tab to be stored such that it can be updated/pulled from at will.

Finally, as a first step, it would be better if the current buttons were renamed to:

"Get All Data" and "Burn All Data" or something else as short and meaningful.

I'm writing this now because I nearly filed a bug report on the table having colour refresh timing still in it, but it was just that i pulled back the entire ecu contents in order to refresh one table (thereby blowing away valid changes in other tables not yet burned in the process, which is bad...) and it was therefore slow.

0000477: Odd Behaviour With Broken Firmware

Mon, 02 Jan 2012 21:00:18 +0000

Interrogation succeeds despite timeouts and nothing returned for firmware version. Firmware version has to be at least one character to be valid, for a start, but I would expect timeouts to kill the interrogation effort. It just so happens that the interface version sneaks through the bad checksum check randomly, and everything else fails. Attaching bad firmware s19 for you to play with, checksum rX code is borked in it. But it illustrates a flaw in mtx nicely.

I would make it a bit more strict if I were you, but do whatever you think is appropriate, including closing and doing nothing. I don't want to argue about this.

0000493: Bad config in fuelAndIgnitionCalcs produces dangerous output!

Mon, 02 Jan 2012 15:39:01 +0000

This will go away once all things are scheduled, but perhaps some compile time sanity checks of some sort are in order to prevent idiots such as myself from doing things badly wrong and harming engines.

0000490: Make XGATE Binutils Perfect

Fri, 30 Dec 2011 01:46:01 +0000

You asked for it! Make it happen! :-)