My 87 toyota supra hardware build

[Fred]

Cool. If you have built config, please push it to a branch for review. If not, we'll need to build one for you.

[via]

I went ahead and forked freeems and put my changes into a branch there. I need to clean up a few things (namely naming of the MAP sensor) before I'd make a pull request, but here it is: https://github.com/via/freeems-vanilla/ ... er...supra

I still need to calibrate the TPS, and right now the 3.5 bar map is based on the graph on the website, so I'll probably need to fine tune it (And rename the defines).

One thing to note is that with the curve they specify, 0-3.5 bar is .5 V to 4.5 V, which puts the 0V value below 0. Is it valid to use signed numbers there?

[Fred]

Negatives should be OK, and any out-of-range initialisers should cause a compile fail if using the macro, and possibly anyway in some cases.

TPS cal is just for ease of review right now, don't worry about it for the time being.

Will try to review tomorrow. Been mostly offline for 4 days. Bliss.

[via]

Okay, cool.

I have all sensors now connected in the car. I modified the MAP and TPS constraints to match reality, and pushed them to my branch. Of note, the decoder appears to work correctly as well. I get a cranking rpm. There are a couple of sync resets though -- is this typical during cranking? Especially considering its -5 C here and my battery is probably getting a little weak, the cranking speed is a little on the low side.

Tomorrow I'm hooking up ignition, and maybe I'll get to mess with a timing light and see things happen.

[Fred]

You'll have to remind me which decoder, though it's probably in the branch, I'll be looking at that later.

There a few settings that affect cranking behaviour, I should do a separate post on them and link it here... one moment.

[Fred]

Here ya go: viewtopic.php?f=54&t=2369

Let me know if I missed anything or if anything needs clarification! :-)

[via]

Okay, thank you, I'm looking that over. My decoder is a 24/1. Actual CPS is 24/1/1 where the two cam syncs are 180* apart, I'm just using the one that should fire at #1 tdc.

I've spent the last 2 hours trying to get a proper log out of my ems. Much to my frustration, OpenBSD has been really holding me back here. cu is built into base, but inexplicably cannot be set to use odd parity. Tip, also in base, has no way to log to a file. Minicom I typically use all the time, but for some reason, even set with 8O1/115200, the files it dumps don't pass freeems-parser cleanly. I switched to fedora and used cutecom, which does work, the logs are valid according to freeems-parser. However, when I load it into OLV, the field information is all messed up (appears as binary junk). To make matters worse, my worry about the battery was correct, I can barely turn over before it stops cranking. I jumped it for a few minutes to get a surface charge, but I think its too much of a pain in the ass to keep working on it in -10C weather tonight.

When you get a minute can you fire up this log in OLV to see if you see what I'm talking about wrt messed up field information? If you do get it working, keep in mind the power dropped enough for the ecu to reset in the middle of cranking. This isn't typical, its just because my battery is dead.

[Fred]

Does cutecom run on OBSD? Alternatively, if the OS/drivers are giving trouble, turn off the parity code in the firmware and try again?

For a N+1 style setup, you want a low number of running confirms anyway, 10 is excessive. 2 or 3 might be reasonable? Cranking should be 0 or 1. The trouble is that you could think you are synced and then fire stuff in the wrong place with zero. N+1 is one of the least robust types, sadly. Slow to start too, relative to others. Works fine when setup right, though.

Log is perfectly not corrupt:

Code: Select all

FreeAir:~ fred$ Desktop/workspaces/home/freeems-vanilla.native/bin/a.out Downloads/via.24plus1.log.bin 
The length of file Downloads/via.24plus1.log.bin is 102764

Attempting to parse file...

Packet number 612 ending of length 201 at char number 65240 failed checksum! Received 28 Calculated 252
Data stream statistics :

Packets and checksums :
965 packets were found
964 had good checksums
1 had incorrect checksums

General issues :
105 leading characters were dropped
0 false starts occurred
0 double start bytes occurred
0 stray part packets occurred
0 chars lost from false starts 

Escaped byte profile :
179 escape bytes were found
97 escaped stop bytes were found
62 escaped start bytes were found
20 escaped escape bytes were found
0 escape pairs were mismatched

Report counts for all non-zero packet types
    Packet of type 0x0191 / 401 was found 964 times!

Good packet length stats :
100256 total sum of good packet bytes
104 average good packet length (with remainder of 0)

Let's take a look inside.





The file name tells you what you need to start looking at the fields: http://stuff.fredcooke.com/ULV.via.no.R ... at.all.png

I'm guessing that that's because it didn't turn over at all, just went straight to low voltage.

Please call your logs .bin and compress them, bz2 suits me. I'm removing .log from allowed suffixes now such that .log.zip or .log.bz2 are something that'll work.

Also, non-EMStudio logs contain no metadata and I generally reject them: viewtopic.php?f=54&t=2323

Fred.

[via]

I'll try building cutecom on OpenBSD.

Thats a shame to hear about the n+1 system not being great. Is it possible to use another rpm input and use the second cam sync? Is it technically possible for me to AND them together and use 2 cam syncs since I'm using wasted spark/semi-sequential fuel? Regardless, that can wait.

Wrt the parser, it worked fine for me too there, I wasn't sure why OLV wasn't reading it. I suppose it must be an issue with my java. I'll try a few other systems later and see if they work. Sorry about not following conventions for log files I first tried just uploading the file 'log', and when it didn't accept that extension I through .log on the end hoping that would work. I'll bz2 them in the future.

I'm not quite clear on how to make emstudio log to file. I haven't glanced too much in the menus, I'll give it a shot later. I did see that its dumping some form of log files to the working directory, but I couldn't get any of them to open in OLV. Possibly related to my OLV not working as above.

Anyway, I might get to some of this tonight, but probably not. I'll get some real logs tomorrow morning.

[Fred]

No worries re minor indiscretions, it's been a pleasure helping you so far, you're the most onto it n00b we've ever had? Appreciated! :-)

Yeah, if you have emstudio working, then you have logs being dumped automatically. You just need to get a working Java setup, I guess. Maybe start a thread in the OLV section about your issues? Perhaps it's something silly? I will try the OLV bin for winblows from the build server with your log in a few minutes and post about how I get on.

EDIT: Works fine on winblows with the exe version from the build server.

No rush at this end, take your time :-)

Fred.