Hello from germany!

[boctok]

Hi folks,
Happy New Year!
С новым годом!

I am Oliver - a motorcycle enthusiast. Thanks to prior r&d projects i have some basic understanding of electronics stuff.

In my new project I try to equip my Yamaha Super Tenere (parallel twin engine) with fuel injection like the later Yamaha TDM 900 has. So I created the "Tuareg" ECU, targeted towards small 1/2 cylinder engines and to withstand all the heat, vibration, water, salt, sand that an adventure bike will see on a rtw trip.
Some parts of the schematics you may already know the 4 layer board is designed to fit into a chinch modice me enclosure. As development started with a Speeduino based homebrew firmware in mind, I am not sure if it supports all the rusEFI features.

May i ask for a design review? Will it be able to run a (customised) rusEFI firmware? If you want, I share all the project files with you.
Where to start? I have to start a new topic in the hardware section, upload the files to github an insert the links, right?

Cheers
Oliver

PS Говорим по русски

[AndreyB]

Where to start? I have to start a new topic in the hardware section, upload the files to github an insert the links, right?
PS Говорим по русски

This forum is a pretty relaxed tyranny, so you have some freedom

A three line technical summary of the board would be great, starting with what CPU are you using? You can attach PDFs and while you can attach ZIPs as well, maybe once you want to attach a ZIP you want a github? Anyway, whatever makes sense. If it's about hardware review - better post in hardware. If that's a weird mix of HW and SW, we can stay here for a bit. Your call.

[kb1gtt]

Hello and welcome along for the ride

I can offer a review. PDF's are handy. Is there any chance you did this in KICAD? I would prefer to review with the EDA if possible. Sharing in a repo like github is handy. Also what licence do you share it with? I don't want to step on any toes. I just need to know your desires and I can work with in those constraints. If you haven't decided on a licence, GPL or MIT are encouraged, but not required.

I have a single cyl motor cycle. Some day I plan to EFI that thing. It's an old 70's Jawa.

[boctok]

Great! So here we go

I shortly signed up for gihub and created some repositories at: https://github.com/kanavkin where you will find all project data. Its more or less a copy of my local working - seems I have to learn a lot about git ...

I used the latest Kicad 5.0.1 for board design. Publishing it under the GPL seems reasonable to me. Where do I have to print that?

For Tuareg I defined only a few requirements : The board shall be robust, minimalistic and needs to be assembled at home. So i preferred a 48 leg MCU. For fuel calculations I think it needs a hardware FPU, which led me to the STM32F410.

I am indeed no super experienced coding professional, thus your chibiOS approach with all the C++ code scared me a little. In previous projects I wrote plain C on AVR and like to have full control over hardware.

So a new requirement has been added: The board shall be rusEFI compatible. Because if I fail to develop a firmware for it on my own I want to switch to rusEFI code.

My current board features:
- dual VR sensor input
- 8 analog input channels
- 6 digital input channels
- 2 output channels to passive ignition coil
- 3 output channels for inductive loads
- 4 low power digital output (tach signal, user lamp, ...)
- 1 isolated UART interface
- sensor power supply
-2 channel knock sensor
-configuration data storage (eeprom)

Vital sensor channels will be:
-MAP
-barometric presssure
-IAT
-CLT
-TPS
-battery voltage
-wideband O2
-lean angle
-engine switch
-sidestand switch

BTW I have no rtc crystal and no backup battery equipped. Do you see any problems with this?

So please have a look at the files and don't hesitate to tell me that its garbage

[AndreyB]

Minor comment - you probably do not want your ".bak" files in github since githib gives you history by better means, you probably could remove these files to reduce potential confusion.

I know kb1gtt uses KiCad 4 also some people do not use any KiCad maybe you would publish schematics and PCB pdf as well?

Anyway, I am not a hardware guy at all so I can only give the above comments.

I am not a C++ developer and our C++ is very very light, we are pretty much 90% C wihtout "++". Also since I have no desire to learn the complete power of C++, it's in my own interest to not people get too crazy with it

[AndreyB]

BTW I have no rtc crystal and no backup battery equipped. Do you see any problems with this?

No prob at all, you would just have no real time which is not a big deal.

For your own firmware, how do you plan to communicate with your ECU, assuming you are planning to communicate with your ECU? Are you planning to be compatible with any tuning software or no tuning and no monitoring? Or just offline tuning?

[kb1gtt]

Oh no, your using my analog circuit. Just FYI, that has some room for improvements. The analog Vref is not linked to the op-amp 5V. So they do not track. This causes a certain amount of error as the STM's analog input as the ADC is ratiometric, and the op-amp as it is now, breaks this ratio slightly. AKA if 5V wanders, your 3.3V does not, and the ratio is not proper. So far, the 5V and 3.3V have not wandered much, so it's been a minimal problem. However a tracking supply would be an improvement. There has also been some talk about making the analog Vref 2.5V, as the op-amp can only drive up to 2.5V with that resistor diver on it's output.

I suggest keeping your analog on one side of the PCB and digital on the other side. This helps keep the noise floor down. AKA you are separated by a GND flood.

Crikey, KICAD 5 is slow on this PC. I guess that's a feature of 5. I have 4 on this PC as well, and that's much faster with 3D and flood's. This PC is KICAD 5.0.2, which I installed a couple days ago. Perhaps your 5.0.1 vs 5.0.2 is adding some sluggish tendencies. My normal KICAD is 4.0.7, and I'm stuck with that for a while as there are many things to port over when I make the jump. I plan to update to KICAD 6 when that comes out.

Do you know your crank wheel pattern? at cranking RPM does it have more than 85mS between teeth for either cam or crank? The MAX chip's auto adaptive features have some problems with crank wheels that have a low tooth count.

Beware we have had trouble getting the TPIC8101 XTAL to start oscillation. Once started it's OK. It's like 50% of the time, it simply doesn't start. Then you touch it with your finger and it starts. It has been a real thorn in our side.

I'm assuming your fuel pump driver is driving an external relay. I don't think your PCB can handle the fuel pump directly.

Oh, I like RBO40-40G.

The primary side of your coils is likely around 450V to 500V normal operation. I suggest using the KICAD calculator and 500V to check your electrical spacing. I think you want more of a gap on the ignition, or perhaps you want to hot snot that area, or something to get more of an isolation. I think what you have will work when dry, and dust free. However with some humidity, or some dust, I fear it could arc and bad things happen.

You can get schematic ERC to stop complaining if you add the power flags to the schematic. When you place a component, you can search for "flag" and you'll find the flags.

For some reason I get DRC issues on the PCB. Two areas claim the flood is to close. I'm not sure what's up with that, but FYI.

All in all, it looks like a decent effort. Keep up the good work.

[boctok]

Minor comment - you probably do not want your ".bak" files in github since githib gives you history by better means, you probably could remove these files to reduce potential confusion.

OK. deleted all .bak files in the repository. Shall i delete the kicad_pcb-bak too?

[AndreyB]

Shall i delete the kicad_pcb-bak too?

Yes, same backup just different extension.

[boctok]

I know kb1gtt uses KiCad 4 also some people do not use any KiCad maybe you would publish schematics and PCB pdf as well?

Oh right! They are here: https://github.com/kanavkin/Tuareg_hw/tree/master/output

[boctok]

Shall i delete the kicad_pcb-bak too?

Yes, same backup just different extension.

deleted

[boctok]

I am not a C++ developer and our C++ is very very light, we are pretty much 90% C wihtout "++". Also since I have no desire to learn the complete power of C++, it's in my own interest to not people get too crazy with it

Great. I will study your codebase carefully, of course! Lets see...

[boctok]

For your own firmware, how do you plan to communicate with your ECU, assuming you are planning to communicate with your ECU? Are you planning to be compatible with any tuning software or no tuning and no monitoring? Or just offline tuning?

I mainly use the (archaic) speeduino interface to TunerStudio. It works not so bad. look, its hot https://github.com/kanavkin/Tuareg_sw/blob/master/TunerStudio.c

BTW I am planning to write a functional requirements specification this month and define some use cases for it.

[boctok]

Oh no, your using my analog circuit. Just FYI, that has some room for improvements. The analog Vref is not linked to the op-amp 5V. So they do not track. This causes a certain amount of error as the STM's analog input as the ADC is ratiometric, and the op-amp as it is now, breaks this ratio slightly. AKA if 5V wanders, your 3.3V does not, and the ratio is not proper. So far, the 5V and 3.3V have not wandered much, so it's been a minimal problem. However a tracking supply would be an improvement. There has also been some talk about making the analog Vref 2.5V, as the op-amp can only drive up to 2.5V with that resistor diver on it's output.

I like your analog cirquit for being so minimalistic!
I will look how to get a tracking supply. What about feeding back the analog sensor supply voltage through an in-line ferrite bead and 1/1 resistor divider + RC filter + clamping diodes to Vref. This would probably introduce noise and will upset battery voltage measurement in case of an short circuit on sensor supply line.
Perhaps it would be better to monitor the analog sensor supply voltage only and correct AD conversion results in software?

I definitely agree with you to make Vref 2.5V!

TODO added...

[boctok]

I suggest keeping your analog on one side of the PCB and digital on the other side. This helps keep the noise floor down. AKA you are separated by a GND flood.

All the long analog lines sit in the middle layer, separated from the digital ones by a via barrier and from the bottom layer by ground flood.
Do you think thats not sufficient protection?

[boctok]

Crikey, KICAD 5 is slow on this PC. I guess that's a feature of 5. I have 4 on this PC as well, and that's much faster with 3D and flood's. This PC is KICAD 5.0.2, which I installed a couple days ago. Perhaps your 5.0.1 vs 5.0.2 is adding some sluggish tendencies. My normal KICAD is 4.0.7, and I'm stuck with that for a while as there are many things to port over when I make the jump. I plan to update to KICAD 6 when that comes out.

How strange! On my computer its fast as hell. Are you on windows?

[boctok]

Do you know your crank wheel pattern? at cranking RPM does it have more than 85mS between teeth for either cam or crank? The MAX chip's auto adaptive features have some problems with crank wheels that have a low tooth count.

85 ms equals 180°, when cranking is at 350 RPM or 90° when cranking at 175 RPM. Lets see:

I want to use the old fashioned '89 Super Tenere flywheel for compatibility which provides 4 teeth at all. Its layout is as following:

40° tooth, followed by 50° gap (TDC mark),
10° tooth, followed by 80° gap,
5° tooth, folowed by 95° gap,
5° tooth, folowed by 95° gap

Seems that I always want a fully charged battery for cranking

Which nasty side effects of this little bugger I should also expect?

This bike has a '98 Denso TCI equipped which handles the VR sensor with some low component count analog circuit. I should draw its schematic in kicad and post it here.

And BTW, cam shaft sensor will be a OEM hall one, so the second channel is more or less standby...

[boctok]

Beware we have had trouble getting the TPIC8101 XTAL to start oscillation. Once started it's OK. It's like 50% of the time, it simply doesn't start. Then you touch it with your finger and it starts. It has been a real thorn in our side.

I really like this TPIC8101 less and less. Please tell me the truth about it. How many value did you get from it? I heard the rumours about the software based alternative. How far did you get with that?

То be honest, I would really love to go closed loop with ion sense cylinder pressure measurement and wideband o2 sensor. TPIC8101 smells so old school

[boctok]

I'm assuming your fuel pump driver is driving an external relay. I don't think your PCB can handle the fuel pump directly.

The track is about 3 mm long and 2 mm in width. Gives about 14 deg temperature rise @ 5 amps.
However 3mm track width would give only 7 deg. at all...
TODO added: use the layers beneath for parallel connection

And CINCH rates its MODICE contacts at about 10 amps at 85 deg.

[boctok]

The primary side of your coils is likely around 450V to 500V normal operation. I suggest using the KICAD calculator and 500V to check your electrical spacing. I think you want more of a gap on the ignition, or perhaps you want to hot snot that area, or something to get more of an isolation. I think what you have will work when dry, and dust free. However with some humidity, or some dust, I fear it could arc and bad things happen.

It was this calculator telling me about 0.8 mm spacing @ 500V, which i selected for design rules...
I like "KONTAKT 213 Plastik 70" for coating.

Would you add more spacing?

[boctok]

You can get schematic ERC to stop complaining if you add the power flags to the schematic. When you place a component, you can search for "flag" and you'll find the flags.

For some reason I get DRC issues on the PCB. Two areas claim the flood is to close. I'm not sure what's up with that, but FYI.

You must be reading my mind
TODO scheduled for further investigation ...

[boctok]

Boys, thank you very very much for your time and support!

[kb1gtt]

Generally your interior planes want to be power and GND. The chips punch through both power and GND as close to the chip as reasonably possible. The current loops get to flow in the shortest possible path. With a flood the current can choose where ever it wants to go which is the physically shortest possible path. This helps decrease the effective antenna(s). Even the flood isn't enough, you generally have a decoupling cap at each chip. Pulling high frequencies across the board is a bugger, these decoupling caps allow the high frequency portion of a signal to flow from the local cap, again decreasing the current loop and decreasing the effective antenna.

Have you found this page yet?
https://rusefi.com/wiki/index.php?title=Manual:Hardware:PCB_design_rules

Specifically you might like the maximintegrated article interesting. It talks about what happens when you put physical barriers on the GND plane. When you put your analog signals on this plane you are creating barriers. This likely increases the antenna size of other current loops and likely creates a bunch of problems.

I would suggest keeping the GND plane as much of a flood as possible. Avoid running any signals on these layers if you can. Also it's your design, and most of this isn't really very functionally critical. We are dealing with reasonably low frequency signals. I'm also assuming your not looking to pass EMC or regulator RF testing. The rules can be bent quite a bit and still provide a functional design.

Is 5A enough for your fuel pump? I believe most fuel pumps are on a 10A to 20A fuse.

About trace width, I just eyeballed it. As long as your paying attention to this thermal issue I'm sure it's fine. Of course real world testing is how you know if there really is a problem or not. These prediction tools are only predictions. If thickness is a concern, I've seen the mask left open along the trace. Then add a layer of solder, thickening the track. I avoid it as it could cause stress issues. Different materiel expansion rates and all that goes with it. However you have short runs, so it might work and might be worth considering.

About clearance, I see your expecting conformal coating. If you can put in more space, that's good. It might allow you to go with out coating. Or if there is some kind of issue with the coating, it offers better protection. I would make it as large as reasonably possible. If it fails, it likely toasts the entire MCU.