DIY LTCC or similar system for LT1s

[kur4o]

Thanks for the in depth explanations. I will look for some caps locally.

The bluetooth module draws around 40ma peak. I look at the voltage regulator max output is 1.5a normal, 2.5a peak. I am planning to put an external box[It will get to tacked up inside the 2.5hdd enclosure] for the bluetooth with on/off switch and rip some 5v from r1. If it doesn`t work I will add external 5v source to the module.

Any idea how much those leds draw. If I put higher value resistors will they lower consumption.




Now the main issue is uploading firmware and fixing the crank tables. I will need some links and brief step by step instructions.

Is there any test mode or the only way to test is to put in an opti signal and give it a spin. My main concern is bad batch of components or bad soldering skills..

Edit:
Just to make sure the shorter red coded 25v can cap goes to c3 and the longer 16v purple coded goes to c4


Edit2:

Most of the issues are cleared I had to pay more attention to the readme files in the latest upload. Great write up, all clear now, unless how reliable is firmware upload. Should I be worried of bricking or it is pretty straight forward and safe.

[spfautsch]

The bluetooth module draws around 40ma peak.

I don't anticipate that causing any kind of problem for the regulator. If you're worried try finding a sheet metal type heatsink for it and you should have plenty of safety margin.

Any idea how much those leds draw.

Discussed here [link] (fourth paragraph of first post).

With all leds on, and all 8 coil igniters being driven high total load on the AVR would be around 36 milliamps. This doesn't concern me whatsoever because in operation there will only be 4 to 5 coils being dwelled at max rpm, and the status led should be off.

Now the main issue is uploading firmware and fixing the crank tables.

Go here [link] and install the latest Arduino ide package for your OS platform.

When you launch the Arduino IDE for the first time I think it asks you where you'd like to store your sketches, and that will probably default to a folder under Documents named 'sketchbook'. I haven't used it on windows in at least 10 years so this could have changed, but I think you should be able to figure that out.

Extract the latest firmware to your sketchbook folder. The file / folder structure should look something like:

(Documents)\sketchbook\diy_ltcc_0_9_38\diy_ltcc_0_ 9_38.ino

Find that .ino file in windows explorer and double-click it. You should see a number of header (.h) files and several .ino files (no extension will be displayed in the IDE for these) represented as tabs at the top of the editor window. Find config.h and click it.

The default build is set to use the D580_dwell.h table - if you have different coils edit the include line appropriately.

You can fine-tune your voltage divider resistor values here as well - plug in the values measured for R1 and R2.

Scroll down to the definition of cranking spark table and put the values from your tune in the second column.

                                                     v 0x12075 table goes in this column
const uint8_t PROGMEM crankSpkTable[17][2] = {{  0, 14},  //  -40c
                                              { 16, 14},  //  -28c
                                              { 32, 14},  //  -16c
                                              { 48, 14},  //   -4c
                                              { 64, 13},  //    8c
                                              { 80, 13},  //   20c
                                              { 96, 12},  //   32c
                                              {112, 11},  //   44c
                                              {128, 10},  //   56c
                                              {144,  9},  //   68c
                                              {160,  8},  //   80c
                                              {176,  7},  //   92c
                                              {192,  6},  //  104c
                                              {208,  5},  //  116c
                                              {224,  4},  //  128c
                                              {240,  4},  //  140c
                                              {255,  4}}; //  152c

Click the save button or press [ctrl]+[s].

In Arduino IDE go to Tools > Port and select the com port your bluetooth adapter appears as.

Then go to Tools > Board and select 'Arduino Uno'

Click the check button or press [ctrl]+[r] to test compile the sketch. If no errors you can try uploading ([ctrl]+[u]). If you get any errors uploading follow the troubleshooting links that are presented. If you get a timeout from avrdude check that your bluetooth dongle is properly controlling the DTR pin. The drivers for the common bluetooth boards don't support this in the linux kernel, so I can't upload firmware using them. But I believe they work in windows.

Note: always disconnect the DTR pin from serial device you're using when operating the board. DTR must only be connected for uploading firmware to the board.

Is there any test mode or the only way to test is to put in an opti signal and give it a spin.

Different test modes are documented at the top of config.h. Simplest test if you have all the coil indicator leds installed and an opti signal is to uncomment

#define STANDALONE 1

and upload. Do not use this mode with coils attached unless you're ready to fire the coils. Spin the opti or crank the engine, and you should see the controller find sequence and begin a light show on the 8 indicator leds.

Just to make sure the shorter red coded 25v can cap goes to c3 and the longer 16v purple coded goes to c4

Correct

Should I be worried of bricking or it is pretty straight forward and safe.

The bootloader on the AVR is pretty robust, and it wont let you write any of the fuse bytes when programming over the UART. So you'd really have to make an effort if you wanted to brick it. The only time I've killed a 328P based system is by applying reverse polarity power. I'm not even sure it killed the AVR, but the 7805 regulator shorts immediately in this situation. I did this to my original prototype board when I started testing coils, and the AVR is soldered in so it's not worth the time to try removing the 328P.

P.S. - the reverse polarity "trick" mentioned above is also a really fast way to destroy a coil pack. Ask me how I know.

[kur4o]

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.

[spfautsch]

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.

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.

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.

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".

[kur4o]

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.

[NomakeWan]

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.

[spfautsch]

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:

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.