Hello from Norway! VW Beetle w. 3D printed intakes, 2x DBW and staged injection

[tmbryhn]

First order of business to turn on stm32 while holding "program" button and see Windows recognize stm32 DFU device based on stm32 hardcoded bootloader.

Alternatively run St-Link utility and have your chip recognized via ST-LINK when you hit "Connect"

Ok, so I've soldered the USB connector. Which MCU pin is the "program " button connected to? I assume either SWDIO, NRST or BOOT0?

Hehe, could be worse, could be a 5v regulator, and you'd get 4.7 volts on the 3.3v rail!

I know, right?

[tmbryhn]

I downloaded the ST link utility and have connected and verified:
"
11:51:13 : Device flash Size : 1MBytes
11:51:13 : Device family :STM32F42xxx/F43xxx
"

Looks good.
I proceeded to jump the BOOT0 pin to 3V3 and cycled PWR while having the USB cable connected, but nothing's showing up on the device manager.

[tmbryhn]

Downloaded the f4 .hex-file for Proteus. Got it uploaded via ST-Link and connected the USB cable, which showed up as a generic COM port in Device Manager. Got some blinking/flashing LEDs going on too (COM and Warning).
Struggling to re-connect with ST-link regardless of USB connection; seems it's "held in reset".

I also got connection in TunerStudio and can read battery voltage, MAP and BARO with the 12V connected, so that's a significant milestone

IMG_20201014_123150.jpg

Anyway, I guess next step is to replace the 3V3 regulator and get to do some actual testing. I guess I'll learn and experience as I go...
So far, so good!

[tmbryhn]

Didn't see a reason not to solder the connector.
The case will require some basic machining for the USB connector and MAP/BARO inputs, and I'm still waiting for the insulation thermal sheets to go between the top side thermal pads and case for heat transfer (especially crucial with the IGBTs)

IMG_20201014_134349.jpg

IMG_20201014_134126.jpg

Next steps are:
- Acquire 3V3 regulator
- Machine case and fit board
- Re-wire the test bench fitted with 2x TBs, 4x coils/injectors, motor driven 36-1 w. VR and basic sensors
- Configure ECU and conduct initial bench test

[mck1117]

Downloaded the f4 .hex-file for Proteus. Got it uploaded via ST-Link and connected the USB cable, which showed up as a generic COM port in Device Manager. Got some blinking/flashing LEDs going on too (COM and Warning).
Struggling to re-connect with ST-link regardless of USB connection; seems it's "held in reset".

Reminder that official STlink programmers are only $10, and connect with a 10 (or 14) pin ribbon cable, no fiddly jumper wires

[tmbryhn]

3V3 regulator in place and working
Let's wire this thing!

IMG_20201019_125613.jpg

[tmbryhn]

That went pretty smooth. RPM hard limit set to 4krpm, hence spark and fuel cut when i "reved" it.

Excuse my temporary wiring The harness were previously pinned to another ECU and standalone DBW module.
I just de-pinned the old 56/24-way FCI connectors and inserted them into the new 90-way FCI connector.

Video, or it didn't happen they said

[tmbryhn]

Got the WBO2 standoff board operational.

IMG_20201019_205408.jpg

Now I'm only waiting for the thermal conducting sheets to arrive so I can machine the case and fit the board.
Then I can re-wire the cabin side of the engine harness for the new connector, and I should be ready to start some real life testing

IMG_20200705_212701.jpg

Has anybody worked on some code for staged injection btw? It's a feature I'd like to play with on my current setup.

IMG_20200707_214545.jpg

[AndreyB]

At the moment we have nothing for staged injection https://github.com/rusefi/rusefi/issues/1890

It was recently discussed nicely at https://rusefi.com/forum/viewtopic.php?f=3&t=1846

[tmbryhn]

Did some milling today and got the MAP/BARO nipples and USB connector properly accommodated in the enclosure.

IMG_20201020_181749.jpg

IMG_20201021_003619.jpg

Just hope I get to do some actual testing before I'm leaving the country in November...

[tmbryhn]

I'm currently working on BT implementation for the next rev.:
https://rusefi.com/forum/viewtopic.php?f=4&t=1807

I've had great success with multiple generic HC-05 "fleeBay" modules that has been set up for MS-based ECUs through a simple terminal program using the AT-commands, and been paired directly through TS. I've experienced reasonable reception, even when enclosed in an aluminum case and mounted on the opposite side of the firewall. I however recommend mounting the ECU on the inside for increased coms reliability.

The Proteus STM32F427ZGT6 utilizes "USART3" on the same port pin names as the STM32F407VGT6 used in the MRE v0.5.0:
TX: PB10, pin# 69
RX: PB11, pin# 70.

As far as I understand, all official RusEfi firmware builds are currently released with Bluetooth code included.

Firmware:
- Is the BT code by default for the UART3/USART3 regardless of MCU?
- Does the firmware require additional activation by any means, or is the UART port continuously standing by for incoming messages on the RX pin?
- Will the firmware auto-detect BT module baud rate? Eg. will it be possible to set up the module for 115200 for potential increased data rate?

BT module options:
- Current firmware supports HC-05, HC-06 and SPP-C modules?
- Are there support for other modules, eg. with coax connector for external antenna?

HW-Implementation:
- When making the next PCB rev. with built-in bluetooth footprint, are there any considerations other than routing the TX->RX and RX->TX that should be taken into account?

[AndreyB]

I am happy to answer the more generic BT questions on one of the BT threads.

Please help us building knowledge by clearly separating questions related to custom design from generic universal issues.

[tmbryhn]

I am happy to answer the more generic BT questions on one of the BT threads.

Please help us building knowledge by clearly separating questions related to custom design from generic universal issues.

Re-posted in BT thread:
https://rusefi.com/forum/viewtopic.php?f=4&t=340&p=38816#p38816

[tmbryhn]

Working on rev.b until I get back from the Faroe Islands and can start some proper real life testing.

rev_b_routing.jpg

Adding some stuff to the current design:
- Bluetooth (HC-05/06)
- SD-card
- 2x analog filter inputs for knock monitoring
- Utilizing an unused opamp/buffer by adding an extra analog input for further expansion if possible (PF10, MCU pin#22 -> "AV12")

According to the Proteus v0.4, the USART2 has been routed out to a header, apparently for expansion or futureproofing (PD5 & PD6).
Will this be the right way to approach Bluetooth implementation?

[mck1117]

- Utilizing an unused opamp/buffer by adding an extra analog input for further expansion if possible (PF10, MCU pin#22 -> "AV12")

it'd be a bit tricky to get that to work, since knock sense needs nearly-exclusive use of ADC3.

According to the Proteus v0.4, the USART2 has been routed out to a header, apparently for expansion or futureproofing (PD5 & PD6).
Will this be the right way to approach Bluetooth implementation?

Yes, that should be okay. That way the required software changes will also enable other people wiring in a bluetooth module to the header on normal Proteus.

[tmbryhn]

- Utilizing an unused opamp/buffer by adding an extra analog input for further expansion if possible (PF10, MCU pin#22 -> "AV12")

it'd be a bit tricky to get that to work, since knock sense needs nearly-exclusive use of ADC3.

That makes a lot of sense. Just checked the datasheet, and it seems there are no spare analog inputs left if knock DSP is active.
Would it be possible to configure it as an optional input while knock DSP is disabled? There analog inputs gets used up quickly w. 2x DBW implementations

According to the Proteus v0.4, the USART2 has been routed out to a header, apparently for expansion or futureproofing (PD5 & PD6).
Will this be the right way to approach Bluetooth implementation?

Yes, that should be okay. That way the required software changes will also enable other people wiring in a bluetooth module to the header on normal Proteus.

Nice. I'll proceed with wiring the BT-module to USART2. How's the setup procedure in firmware to make it work? I'm already familiar with the usage and setup of HC-modules with terminal and pairing in TS (old MS user).

[tmbryhn]

I'm currently working on the knock sensor input.
I'd like to implement both the Proteus analog filter and HIP9011 (through aux SPI) knock circuits in order to be able to evaluate both solutions.
My first test engine is currently fitted with a knock sensor.

Question: How would I go about compiling a custom firmware package that includes support for both the analog and DSP knock circuit?

[AndreyB]

Question: How would I go about compiling a custom firmware package that includes support for both the analog and DSP knock circuit?

There is no easy way. We have very limited developer resources and I believe we would not be able to help with the hard way of doing that.

[tmbryhn]

Rev.b done and ready for the board house.

rev_b_done.png

New features:
- On-board Bluetooth (HC-05/06)
- SC-card slot for internal logging
- Knock DSP w. headphone output and volume control by means of gain adjustment through digital potentiometer.

New features.png

[Simon@FutureProof]

The long term solution to this may be that we make some modules that connect via CAN that have some additional not time critical analogue inputs. Thus we can expand some of the ECU inputs via CAN.

This is a long term goal though.

[tmbryhn]

After successful bench testing and fabrication of harness adapter, rev. C is ready to fire up on the latest Proteus release and I've been through all diags in TS and have it set up pretty well apart from trigger which seems a bit confusing for my particular setup.

My engine is equipped with a 36-1 VR crank trigger with tooth #1 lining up with the sensor 287°BTDC cyl#1 and a single cam flag passing a VR distributor sensor about 90°BTDC @ compression stroke cyl #1 (been previously running this in fully sequential mode on my MS3 ECU).

Looking for input on how to configure the two trigger input channels in TS so that I can run fully sequential fuel/direct spark.

Thanks for all the help It's getting really close!

[AndreyB]

Looking for input

Please post your tune & log files at rusEFI Online. I believe it would be best for you to at least give it a try and for us to say how it looks?

https://github.com/rusefi/rusefi/wiki/Online

[mck1117]

My only advice is to get it running crank-only in wasted spark mode ("two wire wasted" lets you run individual coils in wasted mode) first, then add cam sense later.

[tmbryhn]

I've been prepping a .msq ("2332") on my desktop computer to suit my current engine setup before heading out with the laptop to get it going.
When i connect the ECU to the computer to upload, I get this error after cycling power, and the trigger setup diag is also completely blanked out.
I have copy/pasted the .ini file from the RUSEFI drive to make sure I'm using the right TS config for the current firmware version loaded on the ECU.

ETB & Trigger diag error.jpg

If I load the older "testbench" .msq which I started making on an older firmware version, everything is working fine and doesn't give any errors.

Attached is a pic with the "2332" firmware loaded and error messages, the current .ini file and the .msq files in question.

Also, the raw TPS gauges for both channels are not active in the release version I'm currently running, while it seems to be active in the Nightly Build.
The raw TPS values are convenient when checking the TBs before calibration.

[AndreyB]

We are really trying not to operate with attached files.

It would be nice to see you following the https://github.com/rusefi/rusefi/wiki/Online link and using the web based toolset to make our efforts more efficient.

[tmbryhn]

Thanks. I'll get around to using the RusEFi online for uploading tunes etc. once I get going.
I set up a new .msq from scratch with the latest nightly build, so that's fine now.

Some other issues I found:

Battery and Alternator Settings -> Battery Input Divider Coef:
This value seems hard-coded into firmware. Every change of the variable that is being burned in order to fine tune the battery sensed voltage will reset back to "9.2" whenever power is cycled, thus throwing the battery voltage calibration out the window.

Trigger Setup:
I'm still playing on the bench tester with my motorized 36-1 VR crank input. I'm running "36/1", "4 stroke without cam sensor" and no VVT or secondary trigger inputs enabled.
If I define "Individual coils" and "Sequential" under ign and inj settings, the coils and injectors will fire in fully sequenced mode (1,2,3,4 ...) - even without a cam sensor present. This behavior would work 1/2 times on an actual engine given that the ECU doesn't know the engine phase - the other half, you'd get nasty backfires

Megasquirt fixes this by running in wasted spark and semi-sequential fuel delivery until a valid cam pulse is present - even if fully sequential/direct spark is defined in settings. Thus letting you start the engine as fast as possible or with eg. a faulty cam sensor. It will also only use the cam sensor upon initial sync (obviously given that no VVT is activated), and as long as there are no missed trigger events on the primary tach input (crank), the cam input will be ignored. If a primary tach trigger miss occur, the MCU will temporarily go back to wasted spark/semi-sequential operation, start looking for the cam signal on the secondary tach input for phase detection, before resuming direct spark etc. once phase has been detected.

I think it would be nice with a similar logic in RusEfi, or at least gray out modes that require a camshaft input signal for phase detection so that the user cannot choose the wrong inj/ign mode.

Feel free to move this to an appropriate "issues" thread if the developers find this input useful.

[mck1117]

Thanks. I'll get around to using the RusEFi online for uploading tunes etc. once I get going.

It's great even for non-running testing tunes. It's infinitely easier for people to glance at a tune at rusefi.com/online than it is for you to download the msq, open in TS, try to find the right ini that matches that msq (remember, just about every build has a unique ini - hundreds per week).

Battery and Alternator Settings -> Battery Input Divider Coef:
This value seems hard-coded into firmware. Every change of the variable that is being burned in order to fine tune the battery sensed voltage will reset back to "9.2" whenever power is cycled, thus throwing the battery voltage calibration out the window.

Yes, this is a feature. If you're running Proteus firmware, it expects you to be using a Proteus, where the divider is 9.2.

Trigger Setup:
I'm still playing on the bench tester with my motorized 36-1 VR crank input. I'm running "36/1", "4 stroke without cam sensor" and no VVT or secondary trigger inputs enabled.
If I define "Individual coils" and "Sequential" under ign and inj settings, the coils and injectors will fire in fully sequenced mode (1,2,3,4 ...) - even without a cam sensor present. This behavior would work 1/2 times on an actual engine given that the ECU doesn't know the engine phase - the other half, you'd get nasty backfires

Megasquirt fixes this by running in wasted spark and semi-sequential fuel delivery until a valid cam pulse is present - even if fully sequential/direct spark is defined in settings. Thus letting you start the engine as fast as possible or with eg. a faulty cam sensor. It will also only use the cam sensor upon initial sync (obviously given that no VVT is activated), and as long as there are no missed trigger events on the primary tach input (crank), the cam input will be ignored. If a primary tach trigger miss occur, the MCU will temporarily go back to wasted spark/semi-sequential operation, start looking for the cam signal on the secondary tach input for phase detection, before resuming direct spark etc. once phase has been detected.

We do something similar, where we start in wasted before full sync, then transition to sequential. However, we don't fall back to wasted if you lose the cam, since there really isn't a need to - so long as you don't lose sync, the ECU will stay in-sync even without the cam sensor.

It will also only use the cam sensor upon initial sync (obviously given that no VVT is activated)

You don't really want this - it'll slow engine start compared to just using the crank. Right now we can start the engine in under one revolution with a good tune and a trigger type with lots of teeth (24-1, 36-1, 60-2, GM 24x, etc).

[tmbryhn]

I assumed that were the case with Proteus HW. Is there a plan to make it changeable with respect to fine tuning for components tolerance? A bit pedantic, I know

With respect to sync, I think we're not on the same level. By "initial sync", I mean the MCU looks for a cam signal until it finds it if set up to do so.
In the meantime it syncs on the crank and runs wasted/semi-seq - thus, the startup is potentially super swift just like you describe above. MS also don't fall back on the cam signal unless it eventually gets a trigger miss on the primary (crank) because, like you say, unless there's a disruption, the MCU keeps track on the phase after one sync event on the cam signal. So in the event of a crank sensor trigger miss, it goes back to wasted/semi-seq temporarily until it finds the cam signal again, and proceeds to run direct/fully.

I can't see how RusEFi does this given that I get direct spark/fully seq. on the first couple of turns on the trigger wheel even without a cam sensor attached or let alone configured (confused).

[tmbryhn]

Getting awfully close to testing in the car first time. Have been installing the harness adapter and got everything set up, calibrated and tested including the dual DBW system. Unfortunately, the battery got drained while leaving the ignition on for a long time (the sound amplifier apparently has a fairly high standby current consumption while active ), so while I'm waiting for charging, I thought I'd do some more bench testing.

I'm still very confused about the trigger setup situation: the current .msq has been uploaded to RusEfi online:
https://rusefi.com/online/view.php?msq=614

I'm currently running the Proteus nightly build from "20210714", but the following characteristic have been observed on multiple releases and NB bundles.

My bench tester still only has a single 36-1 motorized trigger wheel with a single VR sensor (connected to "VR1").
In addition, just to be 100% certain, I have de-soldered the "VR2" pullup between the MAX9926 output and MCU, and disabled injectors/coils for zero noise operation. It should't matter anyway, given that ONLY "VR1" has been configured as an input.

Setup.jpg

As far as I can understand, current config setup should't look for a cam sensor, but regardless of settings, the trigger log clearly shows what looks like a camshaft input (one green trace pulse per 720 degrees). It does also correlate with "Trigger angle advance"; the green pulse appears at the same point relative to the missing tooth as the value defined under trigger settings - eg. if i set "180", the green pulse appears right in the middle of the two missing teeth in the log. 287 deg defined during the screen capture above.
Worth mentioning is that the "cam signal" appears just the same if I'm running the internally generated ECU stimulator "Trigger Simulator" feature.

Dual trigger.jpg

Further, if I activate "Individual coils" under Ignition mode, I get direct spark (firing on coil at a time) as if a cam signal were present.
The same applies for injectors in fully sequential mode. This shouldn't be possible given the current setup and hardware. How and why is this happening?

The reason why I'm particularly concerned about this is that I have a cam sensor set up on my engine ready to run fully sequential/direct spark, but if I can't make logical sens of these settings to produce the results I'm looking for, I'm reluctant to get it all set up IRL. Especially since my 3D printed intakes probably wouldn't like a back-fire during overlap because of engine phase issues

[AndreyB]

given that ONLY "VR1" has been configured as an input.

I believe there is an inconsistency here. Not saying that this is relevant or else but just stating that VR2 is in an interesting state.

image.png