Bringing TBI and Multi Port Fuel Injection to a New Level.     EFI Conversions and Tuning! Seattle to Portland! E-mail Tuning Consultant!
Page 46 of 47 FirstFirst ... 3641424344454647 LastLast
Results 676 to 690 of 692

Thread: DIY LTCC or similar system for LT1s

  1. #676
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    967
    I am almost setup for the first test of firmware upload.

    I will try first usb serial connection and than will hook up the bluetooth more testing. A quick question is about rx and tx between board and serial cable. Should they be straight or crossed. tx=>tx rx=>rx or tx=>rx and rx=>tx.

    The bluetooth module have some state pin[PIO9] that can be repurposed as dtr. STock is set to pull pin high on connection. I change it to pull it low on connection.
    The module is HC05, cheap china crap for around $3. Will see it how it goes later.

    I am having postman coming tomorrow so it is getting exciting.

    Some voltage protection circuits will be nice addition for the later revisions if there are any. The pcm have all kind of them and Tom H can give some ideas how it is wired.

  2. #677
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    608
    Quote Originally Posted by kur4o View Post
    A quick question is about rx and tx between board and serial cable. Should they be straight or crossed. tx=>tx rx=>rx or tx=>rx and rx=>tx.
    I think they should be crossed. I.E. tx on the controller board should pin to rx on the serial module. But it's a crapshoot with only two outcomes and nothing can be permanently harmed by guessing wrong.

    Quote Originally Posted by kur4o View Post
    The bluetooth module have some state pin[PIO9] that can be repurposed as dtr. STock is set to pull pin high on connection. I change it to pull it low on connection.
    The module is HC05, cheap china crap for around $3. Will see it how it goes later.
    No wisdom to share here other than it should honor whatever the host device is telling it to do. This pin is making the AVR reset to the bootloader and then avrdude sends a pre-defined sequence (may just be holding tx low for a certain # of milliseconds) and that's what tells the bootloader to switch to serial programming mode instead of jumping to the program start vector.

    Quote Originally Posted by kur4o View Post
    I am having postman coming tomorrow so it is getting exciting.
    I'm just as excited. The reason I killed my prototype board and a D580 coil by connecting the battery clamps backwards is because something new had just arrived (I forget if it was the adjustable voltage regulator or something else) and had the "christmas morning jitters".

    I also have a DIY wideband controller arriving from Sweden in the next few days, and already have the christmas morning jitters for testing it out. But I'm going to be cautious with it because the car is running so well I would be sick if I broke it (the car) by adding something like this haphazardly.

    Quote Originally Posted by kur4o View Post
    Some voltage protection circuits will be nice addition for the later revisions if there are any.
    If you're meaning reverse polarity protection, it's just putting a large diode between the + and - inputs, backwards. The idea is if connected backwards it will conduct and blow a fuse (if there is one) before any components are damaged. It's probably worthwhile, but if I work it into the PCB design (along with an onboard fuse) it will only protect the PCB. I intended to add this when designing the schematic, but pushed it off for later and only realized it had been forgotten after the magic smoke had already been released.

    I'm sure there is extensive reverse polarity protection in the PCM. I don't have enough fingers and toes to count how many times my non-mechanical type friends have called me in a panic because they got the wrong battery at the parts store and connected the terminals backwards, and all of a sudden nothing turns on. My robotic response is always "go buy a bulk pack of AGM fuses and start replacing everything that looks even remotely stressed".

  3. #678
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    967
    A quick update.

    I got some d514a[stamped 12573190] coils with harness in great shape. No corrosion at any of the terminals. Still have to test them for proper operation.

    Also figured how to upload firmware through usb. Even did some datalog on the avr. Not sure how much time it takes to reboot but there is some considerable delay between power up and the time it starts responding to pid requests. I just hope that logging is some low priority.

    A thought about the resistors value. At what temp should I measure them and does it worth the trouble since the resistance will vary with temperature anyway.

    Next on the list is to try bluetooth and clean up the wiring and test the coils and assemble the opti for testing.

  4. #679
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    296
    The Arduino boot loader itself has a startup delay, that may be what you’re experiencing. It is what allows for quick reprogramming over serial. You can nuke the bootloader and burn the program directly to the chip (“export binary” in the Arduino IDE; it’ll save 2 HEX files into the project folder, one with bootloader and one without), but doing so means you can only reprogram the chip using an ICP header and associated ICP programmer.
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  5. #680
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    608
    NomakeWan: his board lacks an ICP header, not that it's needed...

    Once again (the dad in me wants to add: "for the umpteenth time"), make sure the DTR line between the usb / bluetooth adapter and the controller board is disconnected when you're doing this. If not the bootloader programming delay could be invoked and that takes about 2 seconds. The only time the DTR line should be connected is for uploading to the flash. Put a switch between the controller board and the uart adapter or something.

    Edit: If I owned an airplane, and had a nickel for every time I've uploaded a new flash image, forgotten to disconnect the DTR pin and then cranked the engine over with a serial logger pulsing the DTR line only to have it flood because of the programming delay, I could kill you all by raining bags upon bags of nickels down on you. But I wouldn't do that, because I like you. :-D

    Also, don't try spamming the uart with requests while powering on - I've never tested this but it might potentially cause problems.

    This is an approximation because I don't really want to take the time to build a proper and accurate timing mechanism, but from power on to the end of the setup routine takes less than 8 ms for me. At that point you're in the main loop. If you want to see it visually, at the very end of the setup() routine put a line like:

    Code:
    Serial.println(F("ready"));
    Open a serial monitor program (i.e. [ctrl]+[shift]+[m] from the Arduino IDE) and then apply power to the board. If you can perceive a time delay with your senses alone (no instrumentation) you'd better lay off the caffeine / amphetamines / cocaine.

  6. #681
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    967
    After some very weird serial communication problems I had to bring in some serial loggers to identify the issue. It is always harder than needed.

    First I got a response each 10 pid request after that each 20 pid request. Than after some logs I found that the controller response with some extra bytes in the end. It turns out that this is for new line and carriage return.

    So unless these 2 bytes are added to the string you send an all kind of weird issue can be expected.

    I guess a small update to the read me can be added, stating that for proper communication NewLine and CarriageReturn must be enabled.


    Now everything works as expected. And it wasn`t 8ms delay perceived. It was something like 30-60+ seconds until I send 10 pid requests.
    I even try bluetooth firmware update but it didn`t work the first time[I had to revive it with usb upload]. I will give it another try when the wiring is cleaned up. Now it is a real mess.

  7. #682
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    608
    Sorry, I failed to mention that the CR and / or LF bytes are sort of assumed when dealing with ASCII over RS232.

    Did you follow my suggestion and add a Serial.println(F("ready")); at the end of setup()? That's the only real way to know when it's ready to function.

    Also, is your DTR line disconnected when you do this? There's no point trying to proceed until you answer that.

  8. #683
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    967
    Quote Originally Posted by spfautsch View Post
    Sorry, I failed to mention that the CR and / or LF bytes are sort of assumed when dealing with ASCII over RS232.

    Did you follow my suggestion and add a Serial.println(F("ready")); at the end of setup()? That's the only real way to know when it's ready to function.

    Also, is your DTR line disconnected when you do this? There's no point trying to proceed until you answer that.

    Didn`t have a chance yet.

    Yes dtr is disconnected but I tested the communication connected and works either way disconnected or connected. It could be windows drivers.

    I think the issue was the extra bytes[NL and CR] that are not send by standard comm terminals. Only arduino port monitor have that built in and I specifically get it long time ago to program my bluetooth module.

  9. #684
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    608
    Ok, so once again just so there's no ambiguity...

    DTR is connected to the AVR's reset pin. When it is pulled high (or low, I forget which) by the host computer it tells the AVR to jump to the start vector. When this happens with power applied (there's a brown-out detection bit internal to the AVR that will not be set) the bootloader will wait for avrdude to send some data to tell it to start the flash routine. This has approximately a 2-3 second timeout before the bootloader then jumps to the beginning of "user" program space.

    DTR is not required for serial communication, only to reset the AVR so the programming mode in the bootloader can be accessed without having to manually reset the AVR (Arduino boards have a button to do this).

    If you're able to talk to an OBDI / OBDII PCM with whatever serial device you're using, it should almost certainly work with this application. However, the bluetooth module I have can be configured to use DTR or RTS on the sixth pin by bridging a configuration pad with solder so maybe yours has something similar. Drivers shouldn't be an issue, but port configuration can be. I use the gnu utility stty to configure the port before opening it. This is the command line I have to use.

    Code:
    stty -F $port 115200 -brkint -icrnl -imaxbel -opost -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke min 0
    I would suggest the Serial.println() thing mentioned previously. This will not only tell you when the board is ready to respond to logging, but it will also show you if the AVR is being reset after power has been applied.

    Don't attempt to communicate with the board until you see it send data at the end of the setup() routine. You could be unintentionally crashing the AVR.

  10. #685
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    967
    Some indepth experiments.

    DTR connected. Power up the board with usb unplugged from PC. Status led is solid. Plug in the usb to PC status led blinks for 2-3 seconds.
    Open serial monitor the board communicates fine, compile a sketch and upload to board. The status blinks than turn off, When program is done it goes solid again.
    The board is power up all the time, Definitely windows driver makes the difference. I guess the only time it resets with dtr on is when usb is plugged to PC and than when a firmware upload is initiated. Of course disconnecting dtr is a must with running engine.

    I tried the suggested ready print but I am getting an error "n is not declared in this scope".

  11. #686
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    296
    Quote Originally Posted by kur4o View Post
    I tried the suggested ready print but I am getting an error "n is not declared in this scope".
    I just tried it. I copied the text from his post, and pasted it just before the final } in setup. It verified and compiled properly.
    Attached Images Attached Images
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  12. #687
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    608
    Yes, he's got a syntax error somewhere. I've done this before by accidentally selecting a lot of code and typing / pasting over it. In the end it's a c compiler error you're getting kur4o.

    I think by default verbose error / warning info is turned off in Arduino. To enable, go to File > Preferences and turn on the checkboxes for 'Show verbose output for: (compilation) and (upload)'.

    I'm working on stuff for my wideband at the moment, including an ECT based turn-on delay to give temperature based burn-off of condensation in the exhaust. If I get a chance today I'll clean up 0.9.39 and upload it with a serial "ready" notifier ready to go.

    This new Arduino based lambda controller is pretty sweet - at least to me. Where commercial products can only offer a linear interpolation map for the analog output, it looks like adding a non-linear map via a lookup table would be fairly trivial. It also responds quickly enough that I can clearly see my lean surge at idle. The icing on the cake is I don't have to use a pos windows virtual to talk to it.

  13. #688
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    608
    Latest release attached.

    Added "ready" serial message and temperature vs runtime table for wideband power control at startup.

    I'm really loving this new Arduino wideband. I thought I'd have to build a non-linear interpolation table to get accurate data to the PCM, but turns out I didn't need to. All that was needed was to hold the wideband analog output at lambda and log the raw ADC input value with eehack. By knowing this and what 0v represents (0.75 lambda in this case) a new linear equation could be derived - perfectly accurate wideband readings in eehack now!
    Attached Files Attached Files

  14. #689
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    967
    I didn`t even run the system yet and maybe I have found some serious bug.

    Finally managed to wire everything[almost need to wire the coils as a last step] and decided to do some realtime test by hooking everything and spinning the opti by hand.

    After some hand spinning I noticed some of the coil indicator leds stay on when I stop spinning. Kept spinning and the same led keep stay on. Kept spinning and more leds stay on[upto 5-6 leds on]. It must be some bug at very low revolutions that the coil is triggered and stay triggered with ignition on. Some potential fry coil situation where a very brief crank is initiated with very low speed.
    To make sure I checked voltage output at coil pins and it was a solid 5v.
    The status led is on when there is no opti signal and turns off when it pick some opti rotation.

    I think that will be easy fix making sure no coils stay on more that some fixed threshold when ignition on engine off.

    I am also suspecting the pcm is delivering multispark trigger at extremely low rpms at startup but it is not confirmed yet.

    If you need more details or custom log or more test will be happy to help.

  15. #690
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    608
    The reason you're seeing that is most likely because the EST line from the PCM isn't triggering the fire when you're spinning the opti by hand.

    I suggested enabling standalone mode to test by spinning the engine or a loose opti over to test. i.e.

    Code:
    #define STANDALONE 1
    But I honestly havent tested that in a while and had similar issues when spinning my opti base by hand. The reason this happens with just the opti is because the distributor hub alone doesn't have enough inertial resistance to not spin backwards when it comes to rest, etc. This confuses the sequencer. Another thing that confuses the sequencer is when you spin the opti counter-clockwise.

    I had all sorts of noise on the EST line. There are debouncing mechanisms in place to prevent false triggers.

    Take your time and make sure the coil igniters are wired correctly to the appropriate cylinders.

    Code:
      front
    1    2
    3    4
    5    6
    7    8
      rear
    Then try firing it. I know you're trying to be super protective of your hardware, and I don't blame you. But I've got almost 6000 miles on mine. Almost 1200 on the 0.9.38 build, and I'm averaging 20.3 mpg running the A/C.

    I spent 30 minutes idling in the drive-thru getting lunch yesterday with the air on max, and the coolant climbed all the way to 95c. I was gritting my teeth the whole time, but it hasn't let me down yet.

Similar Threads

  1. Which TBI system is better?
    By KeyAir in forum GM EFI Systems
    Replies: 41
    Last Post: 05-13-2019, 09:39 PM
  2. Hard start 93 LT1 with LTCC Ignition Mod
    By beestoys in forum GM EFI Systems
    Replies: 0
    Last Post: 05-18-2015, 08:58 AM
  3. ABS system?
    By K1500ss4x4 in forum Gear Heads
    Replies: 3
    Last Post: 02-06-2014, 06:21 AM
  4. Vortec EGR System?
    By EagleMark in forum OBDII Tuning
    Replies: 40
    Last Post: 06-02-2013, 10:07 PM
  5. Quicker way to do Spark Hook test on the street for LT1s and others?
    By sherlock9c1 in forum Fuel Injection Writeups Articles and How to New and Old
    Replies: 15
    Last Post: 03-03-2013, 01:52 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •