rusefi.com

(fork of https://rusefi.com/forum/viewtopic.php?f=4&t=1856 thread)

LQFP-32 seems to be pretty unavailable these days while there might be some hope with LQFP-48?

Would STM32F103C8T6 or STM32F030C8T6 or else in 48 pad package be an option to have WBO fabricateble again?

AndreyB wrote: ↑

Thu Apr 01, 2021 5:07 pm

LQFP-32 seems to be pretty unavailable these days while there might be some hope with LQFP-48?

Would STM32F103C8T6 or STM32F030C8T6 or else in 48 pad package be an option to have WBO fabricateble again?

the availability problem is with the f042 die, not just with the lqfp32. The F030 doesn't have CAN iirc, so that's a non-starter. Dave's variant of the board uses an F103, so that's a viable option.

I've wasted too many hours of my life chasing and soldering stm32f042. STM32F103C8T6 wideband has to happen in light of JLCPCB availability.

I am embarrassed to admit that only today I've realized that STM32F103C8T6 being LQFP-48 is same physical size as stm32f042 in LQFP-32 package, i.e. I can hope to fit STM32F103 into same overall physical size dimension?!
https://jlcpcb.com/parts/componentSearch?isSearch=true&searchTxt=STM32F103C8T6

mck1117 wrote: ↑

Thu Apr 01, 2021 6:30 pm

Dave's variant of the board uses an F103, so that's a viable option.

Is there any additional info on this anywhere? Schematics? Firmware? status update? else?

My version:
-Ordered 20 units, have them.
-Started to look at the HAL stuff to configure the I/O. Got frustrated. Put it aside
-Got consumed by things that make money, life.

there is status update.

AndreyB wrote: ↑

Sun Nov 07, 2021 5:30 pm

Is there any additional info on this anywhere? Schematics? Firmware? status update? else?

one significant obstacle is firmware update from rusEFI - I don't remember exactly, but there was some significant obstacle to writing a CAN bootloader for the board. Not to mention that rusEFI would have to bring along TWO DIFFERENT WIDEBAND FIRMWARE IMAGES, one for f0 and one for f1.

mck1117 wrote: ↑

Sun Nov 07, 2021 11:17 pm

TWO DIFFERENT WIDEBAND FIRMWARE IMAGES

Yes, this is absolutely LAME.

But hand soldering 042 in US is worse. We have to F103 to save Jesse and myself. I can see WB reporting F0 or F1 type and rusEFI reading from SD card maybe?

AndreyB wrote: ↑

Mon Nov 08, 2021 12:49 am

rusEFI reading from SD card maybe

this is not a bad idea, actually

mck1117 wrote: ↑

Sun Nov 07, 2021 11:17 pm

rusEFI would have to bring along TWO DIFFERENT WIDEBAND FIRMWARE IMAGES, one for f0 and one for f1.

Is there a chance to make a universal f0+f1 firmware image? Just an early chip detection (using an external mcu pin tired to gnd or something?) and two branches of code to configure the hardware.

andreika wrote: ↑

Mon Nov 08, 2021 3:46 pm

mck1117 wrote: ↑

Sun Nov 07, 2021 11:17 pm

rusEFI would have to bring along TWO DIFFERENT WIDEBAND FIRMWARE IMAGES, one for f0 and one for f1.

Is there a chance to make a universal f0+f1 firmware image? Just an early chip detection (using an external mcu pin tired to gnd or something?) and two branches of code to configure the hardware.

they're m0 vs m3, different instructions supported...

sounds like a challenge or you mean it is completely impossible? besides m0, there is also m0+?
can a simple bootloader be compiled with just m0 instructions set? or m3 chips don't support code in m0 set?

I have one question .. about F103 wiring. ...

F072 and F103 in LQFP-48 has same pinouts ...

Has "planed" F103 LQFP-48 controller same wiring / MCU pinouts as F042 (F072) ..??

because I have these boards in production, ant it can be used for both MCUs

Someone would have to tell @stefanst that he is getting one of these for Xmas

Look it uses Molex MX120G 0367831201 male I have a dozen of those! Next step finding out female PN and pins PN

https://www.molex.com/molex/products/family/math2o_sealed_connectors
https://www.content.molex.com/dxdam/literature/987650-6511.pdf

Female: 36792-1201 https://octopart.com/36792-1201-molex-24622492?r=sp
Terminal 17-20AWG / 0.50-0.75mm 36799-0001 https://octopart.com/36799-0001-molex-24622493?r=sp
Terminal 20-22AWG / 0.35-0.50mm 36799-0002 https://octopart.com/36799-0002-molex-24622494?r=sp
Cavity Plug 36804-0001 https://octopart.com/36804-0001-molex-24622495?r=sp
Male Right angle 36783-1201 (-120* seem to be the same part, with different markings. -1208 seems to be cheapest at time of writing) https://octopart.com/search?q=36783-120&currency=USD&specs=0

WARNING!!! My F103 controller does ***NOT*** use the same MX120G pinout as Matthew's. Pins are in different spots and there are two PWM-DAC analog outputs. Do not plug in a harness for Matthew's design unless you want smoke!

Order placed.

My focus here is JLCPCB assembly of all the small parts. stm32f103 is no longer available at JLC so next step for me is GD32F190C8T6 (5 volts?!) and GD32F130 which JLC has 5K units at the moment, both under $2.

In current design PC13 heater PWM is not a hardware timer and has a note regarding limited current output. I guess with our low speeds we can afford software pin toggle via a callback? One step towards fully software 1MHz timer

AndreyB wrote: ↑

Sat Jan 01, 2022 6:48 pm

In current design PC13 heater PWM is not a hardware timer

In order to reduce software change a hardware modification of existing design would be to repurpose PB6 to become heater PWM. At the moment PB6 is nicely exposed on the GPIO header.

On the other hand I really like the idea of software timer that would go handy if we ever decide to go with a multi-channel controller with one chip.

I think you've misread the limitation on PC13-15. It says "2mhz with 30pf is maximum" which means you can maybe exceed either but not both. I think our circuit would actually work fine.

edit: it also says maximum 3mA, which we're well under without the LED.

We can probably do soft PWM for the heater (~400hz), but not for the pump DAC (~47khz).

I suspect the heater will work as-is on PC13, and will certainly work if we remove the LED.

I am stuck with CAN configuration Anyone with a blue pill and logic analyzer to available to help? Assuming blue pill and logic analyzer is a valid way to reproduce this issue.

https://github.com/mck1117/wideband/issues/44

Got this to work once real transceiver got connected. Also no idea why real board did not work at 500Kbps before and works now.

Matt says schematics has mistakes

that's true ...U1A U1D (and .. ?)

Both U1A and U1D have IN+ and IN- swapped.

Status update: with op-amp hack and heater control hack https://github.com/mck1117/wideband/pull/50 F103 maybe works? At the moment this pile of contributions is waiting for someone motivated to give it a try.

After I assembly one board for the wideband with f042, I miss that I can't get the MCU for a reasonable price. I would like to give a try with the f103.

I check the schematic and seems that there's some changes and they are not yet exported to the Gerber's. It's possible to generate new Gerbers on git?

In order to make this board also compatible with LSU adv, in terms of hardware it's just not connect IA pin?
I know that there will be necessary change the SW to work correctly with this sensor.

@dron0gus is making progress

https://github.com/rusefi/rusefi-hardware/issues/38

Ok. I faced with some issue.
I'm debuging Nerst Ri measurement circuit. I started with connecting a test 100R resistor between LSU_Un and LSU_Vm.
I was expecting to see 100R measured Ri. But sow 5 Ohm.
On LSU_Um I see 1.64V of DC and 20mV of AC.
Calculation shows me 110 of Ri. Looks correct. This diff amp should subtract virtual ground voltage and mul x3.
This will cut negative part of AC signal. As it will be below of 0V. Also it will cut some part around zero as OpAmp is not ideal rail-to-rail.
So what I get after this cascade is meander from 3mV to 31mV. This gives something about 50 Ohm of internal resistance.
I know that test with resistor instead of sensor is not correct. And there is always at least small (0.1V) shift generated by sensor cell.
The question is, with lanbda sensor is it possible that same signal limitation can happen?
Another question is that cascade is used only for Ri measurement. Maybe it is easier to cut DC part with capacitor and add more comfortable shift to this signal?

Dron_Gus wrote: ↑

Sun Mar 27, 2022 6:02 pm

The question is, with lanbda sensor is it possible that same signal limitation can happen?
Another question is that cascade is used only for Ri measurement. Maybe it is easier to cut DC part with capacitor and add more comfortable shift to this signal?

The nernst sense is used for two things:

• The DC component is used as feedback for the pump controller. The pump is servoed to maintain 0.45v DC on the Nernst cell.
• The AC component is used for internal resistance measurement of the sensor, which is a proxy for temperature (the sensor is roughly an ideal voltage source in series with an NTC thermistor). The heater is controlled to maintain the set peak-to-peak AC on the nernst sense voltage, something like 50mV peak to peak, off the top of my head.

Try testing with a bench PSU set to 0.45 volt with a 300 ohm resistor (the target ESR for an LSU 4.9), and that should work. 100 ohms is also a bit low to test with - 100 ohms means we've massively overheated the sensor. 300-2000 works very well in my testing.

The difficulty with measuring ESR down near the bottom rail isn't a very big deal, since the sensor has to be very very rich (with an undriven pump - as soon as we drive the pump it pops up to 0.45v). I think this is actually the purpose of the 20uA bias current (copied from the CJ125, in our case a pullup resistor on Un to 3.3v) - when the sensor is high impedance (cold), they pull it up far enough that we can sense the ESR. Once the sensor is hot and the ESR low, we closed loop control the voltage in to the range we know we can sense.