[info] Frankenso - ECU shield compatible with OEM case / official

[spags]

So this is why that steady stream of commits to the repo suddenly stopped.

This is awesome! I just had a look at known_issues.txt and I see a lot of meaningful improvements over 0.1.
Can't wait to see it in action!

Unbelievable what you guys have accomplished.

[AndreyB]

how about

Code: Select all

35)                  test pads explicit silkscreen
36)                  test pads on the back of the board

[kb1gtt]

Added to known_issues.txt will figure out what they mean later on. I agree that we should plan for a test fixture at some point, such that we can automagically test and validate a board is built properly.

[AndreyB]

Added to known_issues.txt will figure out what they mean later on.

We have these very handy squares for GND and 5v on the front side of the board. #35 is about saying "GND" and "5v" on the silkscreen, and #36 is about adding same nice squares on the back of the board. Since we have some stuff on the back, sometimes I am playing with a multimeter on the back and would be nice to know where to touch and not risking shortening pads on the 25x2 header.

[AndreyB]

37) U601/2/3: hard to see pad #1 label on the silkscreen
38) cap values format inconsistency: C165 is ".1u", C24 C355 C471 C701 are ".1uF" and C104 C211 C291 etc are "0.1uF"

[juanj]

hi friends, when is 2.0 board for sale? i see that testing now i want order now. i think to order 1.0 but i prefer wait to release

[AndreyB]

hi friends, when is 2.0 board for sale? i see that testing now i want order now. i think to order 1.0 but i prefer wait to release

Thank you for your interest! There would be no 1.0 or 2.0 until 2018 probably, but there are the green 0.1 and red 0.2

Right now I have exactly one bare board or one kit for sale:
https://www.tindie.com/products/russian/frankenso-02-bare-pcb/

http://www.ebay.com/itm/331332410287 same as https://www.tindie.com/products/russian/frankenso-02-diy-kit-/

I am hoping to have some completely assembled boards hopefully before Xmas.

[juanj]

hi friends, when is 2.0 board for sale? i see that testing now i want order now. i think to order 1.0 but i prefer wait to release

Thank you for your interest! There would be no 1.0 or 2.0 until 2018 probably, but there are the green 0.1 and red 0.2

Right now I have exactly one bare board or one kit for sale:
https://www.tindie.com/products/russian/frankenso-02-bare-pcb/

http://www.ebay.com/itm/331332410287 same as https://www.tindie.com/products/russian/frankenso-02-diy-kit-/

I am hoping to have some completely assembled boards hopefully before Xmas.

Lol sorry ready, i ordered the 0.2 board+stm32f4discovery brain board, i just wait to shipping, thanks

[AndreyB]

[video][/video]

[AndreyB]

[video][/video]

[AndreyB]

Re: HIP9011

Chip select for SPI communications (active low with internal pullup)

We do not have a trace or a through hole for HIP9011 CS line. We have our own 5v pull-up probably because we are pulling all SPI lines to +5v

I think HIP9011 deserves it's own SPI bus to eliminate conflict with any other SPI device, so we would need to simply pull this pin down so that it's always active - no need for a real CS line.

47) HIP9011 CS line needs to be pulled down, not pulled up

[AndreyB]

51) CAN_RX line should be connected to PB12, not PD12

[DaWaN]

Re: HIP9011
We do not have a trace or a through hole for HIP9011 CS line. We have our own 5v pull-up probably because we are pulling all SPI lines to +5v

I think HIP9011 deserves it's own SPI bus to eliminate conflict with any other SPI device, so we would need to simply pull this pin down so that it's always active - no need for a real CS line.

I would check whether the HIP9011 can live with the CS line pulled hard to the low level. I have come across some SPI devices which need the CS to be toggled as it can leave the SPI slave part of the chip in an unexpected state. So I would always connected it to a GPIO.

At the same time I am thinking: how hard would it be to mimic the HIP9011 with the STM32 ?
Just connect the microphones to an amplifier, sample it with the ADC and do the band pass filtering and integration digitally.
Not worth spending the effort on at the moment of course, but the functionality of the HIP9011 is no black magic

[AndreyB]

I would check whether the HIP9011 can live with the CS line pulled hard to the low level. I have come across some SPI devices which need the CS to be toggled as it can leave the SPI slave part of the chip in an unexpected state. So I would always connected it to a GPIO.

Where would you check that?
In fact I do have some issues working with HIP9011 so I might try GPIO CS, thank you for the idea!

[AndreyB]

HIP9011 now has CS control but still only mirroring SPI commands



The test code is here.

[AndreyB]

@ has pointed out the problem - it was about SPI configuration, the SPI connectivity issue is now resolved.

50) HIP9011 CS should be connected some GPIO pin, PD11 would work

[AndreyB]

55) knock1 is actually knock2 and vice versa. Need to fix net names & the pinout picture

[AndreyB]

The five boards from China are mostly tested, with the exception of couple of LEDs everything looks good!

Two boards are for sale.


https://www.tindie.com/products/russian/frankenso-01-assembled/


https://www.tindie.com/products/russian/frankenso-01-full-bundle/

[kb1gtt]

Various tests were preformed on Frankenso's R0.3 power supply, including load dumping. The 5V is very solid, while there is some ripple from the 12V. Yellow trace below is 12V ripple, and blue is 5V signal. The normal load is .120 amps, which is what's seen in the middle section of the below. While the 5V load dump was a resistor that passed an additional 1.25A. I had the blue scope probe connected to the load resistor. Ripple at the normal .120 amps load is about 75mVp-p and ripple at 1.25A load is 225mVp-p. The 5V ripple is below what I can measure with the DSO Quad, which means the ripple is below 5mV on the 5V signal.



The LM2596 datasheet suggest C1001 to be 680uF, we were able to fit 470uF. I changed this up to 980uF and saw minimal differences in the ripple. So the 470uF is fine. To remove this ripple from the 12V I'll likely add a choke. See below spectrum analyzer picture, it shows the switcher frequency of 150kHz and it's harmonics are playing a huge role in the ripple.

[kb1gtt]

Added to known issues list
68) Look into LCD dimming R99, perhaps replace with a POT. Perhaps connect to a GPIO

[AndreyB]

) place USB connectors closer to board edge or notch the board

There is an opinion that we have placed these USB connectors too far from the edge of the board and this actually causes poor mechanical connection, @ had to grind his cable a bit to work around this. I guess notching the PCB would be another option to resolve this?

[kb1gtt]

I'll have to look at this. I seem to recall the issue is caused by the vertical mount connector that's also there. I seem to recall it take up the space at the edge.

[AndreyB]

That's version 0.3 on the picture, MAX9926 chip input



I wonder if W1002 silkscreen is actually not where it should be?

Also I think we should eliminate these jumpers altogether, maybe leave a through-hole for a test point pin, but not a jumper? Since we have pads for a pull-down and a pull-up, that should be enough.

[AndreyB]

) W1002 - silksceen on the wrong place? remove these jumpers anyway?
) 1K and 0R on the MAX9926 input: need to put a comment on the schematics page explaining that none or just one of them should be installed depending on the use-case

[kb1gtt]

Do we need more / clearer explanation, or was the below perhaps not enough?

Capture.PNG

[AndreyB]

https://sourceforge.net/p/rusefi/tickets/184/

dev console/microUSB connection dies

on a real engine dev console sometimes disconnects and can not connect back - looks like an issue more with the port then with the console. this does not happen on a bench

[AndreyB]

https://sourceforge.net/p/rusefi/tickets/184/

dev console/microUSB connection dies

on a real engine dev console sometimes disconnects and can not connect back - looks like an issue more with the port then with the console. this does not happen on a bench

There are reports that multiple rpm hard limit events kill even the USB/TTL port with some certainty

[kb1gtt]

Is there a way to can get these reports from the horses mouth? I've only heard of the issue as relayed through russian. There are many engine layout items that might be effecting it as well as my guesses below. It might be as simple as a poor wiring connection, or an incorrectly selected AWG wire. Are we talking a setup with 1 injector, or 8 injectors? I have almost no data to work from, which makes it hard to help offer a solution. However below are my best guesses with a blind fold on.

I suspect part of the issue is partly affected by the laptop's floating ground. The discovery has via's, stubs and no GND plane which are know for increasing the Bit Error Rate (BER) as those are known for decreasing the eye diagram. These discovery board layout doesn't help the issue, but there also isn't much we can do about it. What we have some control over is your referenced USB GND voltage. If that is wandering around, the combination of all of these weaknesses could apparently be putting your USB in unhappy land. I believe the bench test is successful, either because the GND is more solid in that setup, or perhaps it has less current running through the GND wire which keeps the GND voltage at a lower level.

A suggestion for the short term would be to make sure you have a fat / over sized GND to the Frankenso board, this will help prevent generating a voltage on the GND wire as you run injector currents through the GND wire. As well adding a separate GND strap to the latop. This will help keep the laptop GND reference at the reference voltage as the Frankenso board.

Does the reporter have a scope? DMM? Other test equipment? I can think of several tests that would let you check the GND voltages.

Probably the best short term solution, is to avoid using the Discovery USB when you know you have a problem. It's not likely you really need to do both TS and dev console at the same time. If you can put the dev console on the FT232 chip and only run one connection at a time, you will likely find the problem doesn't exist on the Frankenso USB. You will likely get better performance out of the FT232 chip, as it does not have via's, stubs, and uses a GND plane. The eye diagram should be much better on the FT232 USB, and should have a much lower BER.

[AndreyB]

Starting to place an order for frankenso_rev00.40 ETA mid-June.

[AndreyB]

Starting to place an order for frankenso_rev00.40 ETA mid-June.

Order placed! Looks like there would be a ~$40 bump in the price. Time to test http://rusefi.com/forum/viewtopic.php?f=4&t=577 this would shave about $20 off the price.