DIYEFI.org Forum

jbelanger wrote:I've loaded the latest MTX version on Windows and it went well.

Firstly, good on you! :-)

I also noticed that you can't enter a down going RPM sequence, i.e., a higher start than end.

Secondly, it is a triangle wave form that he creates. It goes up, then down, then up, etc for ever. So unless you don't want to wait for the up part, I don't see a problem. It would be nice to take arbitrary files of rpm values to be fed into it sequentially with some UI set delay between entries. That can wait, though. There are bigger fish to fry :-)

Fred.

Fred wrote:

I also noticed that you can't enter a down going RPM sequence, i.e., a higher start than end.

Secondly, it is a triangle wave form that he creates. It goes up, then down, then up, etc for ever. So unless you don't want to wait for the up part, I don't see a problem. It would be nice to take arbitrary files of rpm values to be fed into it sequentially with some UI set delay between entries. That can wait, though. There are bigger fish to fry

Fred.

I did notice that it cycles up and down but there is nothing stopping me from entering the down part first and MTX won't handle it correctly.That was my main point. And since it can go in both directions, it should also handle either direction as an input.

As for what would be nice, there are a lot of different schemes that would be interesting but playing back a file is probably one of the most interesting. Having time information in the file, such as in a data log, would be more interesting in my view since it can be specified for each entry.

Jean

But wouldn't you generate such a file using some tool? Not by hand... so you could just fill it full of the same value if you wanted to maintain a set rpm for a while. I see your point, but I would expect that in the majority of cases it would mean larger input files due to ltos of timeframe duplication (shortest please!).

Depending on the RPM variation, either type of file can be the larger one. And it also depends if the software reading the file interpolates between RPM values and sends at the fastest speed for smooth transitions. In any case, it doesn't matter much because it's not too difficult to make an external tool to generate either type of files to the other if need be.

Jean

Fred,

Are you able to get the dynamic RPM working? As I mentioned, I can't get it to work with the released version.

Jean

It's 230am and I had a rod come out through the side of theblock earlier today. I will try it tomorrow for you/dave/myself/us/etc :-) It was working, but unsure about release version. I'll reset to the tag, build and install.

Dynamic RPM gives intermittent results for me. It seems to start work, then the jimstim gives random rpms sounding like music with a piezo attached to the ISR outputs of the freeems, and mtx loses comms with it. resetting it and doing a get data fixes that temporarily but it will soon do the same thing again.

Dave, let me know if/when you can log into my box to do some more testing.

This is all built from the RELEASE_0_9_23 tag, not the commit after it with other changes and the comment "tagged for release" :-/ Unsure what is going on there.

Hope that helps.

Fred.

There's bug in the release version where the command to enable interactive mode for jimstim is commented out, so odds are one of the bytes sent when sweeping is the equivalent ascii "i" which gives you the intermittent results.

Since I'm in the modular side of things, I fixed it there. modular_0.1 branch has it as well as the beginnings of the stuff for per ecu modularization. It currently works fine for me with linux, i still need to test on windows (I expect issues here) and on os-x.

feel free to pull (get the correct branch), ./autogen.sh --enable-debug ; make ; sudo make install

I'll give eee and mac a try today, if you can nurse me :-)

Fred.

EEE results: static rpm adjust works fine, sweeper segfaults most of the time. Still loses comms with the device too. Hit me up as soon as you wake up to to test on my box in my evening/your morning.