work in progress stimulator board

[Sudo]

We might have to be careful with ground referencing. Most RS232 are not isolated. For example, if our stimulator only provide VR signal and nothing else, then it is all good. But that's not the case, we have other signals as well, which can create a potential ground loop if the stock ECU designer decided the VR input to be at a certain reference. Philosophically, the stock ECU designer can safely and appropriately assume that the VR sensor is floating. Which means, they are open to use whatever reference they choose. Therefore, our stimulator cannot assume that they will use something like a Maxim VR IC which is a differential input. While most of our ideas will work for the most part, it is a more intrusive design to tie grounds together for especially for the VR inputs. The other sensors are not as critical since they are mostly voltage dividers and the stock ECU normally supply the reference and no negative voltages. But I think I am against the idea that we force the stock ECU VR reference to the same ground even thought it will work for the Maxim VR IC. While most RS485 drivers tolerate a different ground, certain implementation of the RS485 drivers requires a ground reference to some extent. So I think a truly isolated differential driver is the most appropriate. We can either use an isoalated RS232/RS485/LVDS, or we can add a tiny transformer to the output of whatever driver we choose to isolate it.

Maybe I drilling too deep into this. But I don't have enough experience stock ECU to know if differential input for VR is the norm. So I take a very defensive approach on the design covering all possibility. What are the odds that it can be a problem with grounds tie together? I am sure it is a very small chance. But it is certainly possible. Sorry if my OCD is starting to show a bit.

[Sudo]

x3 MCP42010-I/SL-ND
x2 10x2 pin headers (black on the sketch)
xX 5.08 screw-in terminals (red on the sketch)

There are few things I want to clarify.

1. Russian, is there a reason you choose the 10x2 header at those positions?
2. I don't see VCC on the header. Do you intend to power this externally?
3. Do you intend to use the USB on the STM32? I assumed you do.
4. Do you plan to use a logic analyzer to scope the outputs? I want to create a header so we can use something like the OLS (Open Logic Sniffer). That way we can control both the stimulator and the the capture mode and triggers all via USB.


Stimulator features I have in mind:

* Uses the discovery board as the controller
* 6x 10k digipot via 3x MCP42010-I/SL-ND
* 18 pins header for logic analyzer, 16 signals, 2 GND, designed for OLS (Open Logic Sniffer)
* 2x VR/Hall outputs, routes to OLS
* 4x configurable Highside/lowside/CMOS outputs, routes to OLS; 1 or more of these output can be used to trigger OLS
* 10x configurable Pullup/pulldown input buffers, routes to STM32 and OLS

The way this stimulator will be used is the STM32 will generate the VR/Hall wheel ouputs, control the digipots, and set the trigger for OLS. Then the OLS will capture all injectors/ignitions/etcs at exactly when we want to trigger. There is no need to capture analog outputs via the digipots since we are controlling it. With this setup, we should be able automate any kind of scenarios to capture whatever we want.

Did I miss anything? Any more suggestions?

[AndreyB]

@, your description is pretty close to what I had in mind.

Why this location? Because of SPI pinout - there is one SPI in the lower-left corner, and there is another SPI section in the middle on the right.
Yes external VCC - I guess it's easier to get external VCC than trace four wires for external SPI, but I am open to suggestions

I was actually thinking to use stm32 both as signal source and signal analyzer: for that we would need to trace ECU outputs (injectors/igniters) to stm32 timer input pins - PC6, PA8 etc. There was something about any pin being able to generate an interrupt I would need to figure that out, but even now we have four input channels that should be something for a start

Anyway there is nothing wrong with having an option to also use external logic analyzer, but using stm32 for capture helps because stm knows what signal it generates so it can analyze/record knowing the timing and the logical state.

We need to double-check vertical clearance: the buttons and the audio jack are in the way in case of upper mounting, we might end up mounding on the bottom.

[Sudo]

Yes, the STM32 can capture as well as the OLS. I have already planned to route to both. Because the STM32 knows the state, STM32 can provide a trigger for the OLS to capture as well. I don't think STM32 will be a very good capture tool on its own. STM32 will be good for capturing timing for intended signals, but you will miss the error cases that you didn't intend to capture. The STM32 will do decently, but wIth the external $50 OLS, I believe we have a very flexible and powerful capture tool with enough bandwidth and memory. With simple software or Python scripts, we can automate everything and possibly post-process the waveform for more data. Plus, its just adding a header, so it is easy enough to do and basically free.

Yes external VCC - I guess it's easier to get external VCC than trace four wires for external SPI, but I am open to suggestions

I don't understand what you mean by this?

As far as power, I wanted to use the same power source as the STM32 board via the header, which I assumed was 5V from USB/external. The header position you drew didn't include any power pin. The question I had was if you plan to apply 5V to this stimulator board daughter board directly? I just thought it'd be nice to use what's available on the headers. For header position and the size, I was planning to make uses of all pins, not just what you boxed in. Do you have plans to used the unboxed pins for other things? I am not sure if you have something else in mind for the unboxed pins.

Clearance may not be an issue if we spec taller header sockets.

[AndreyB]

if you want to use the discovery +5 pin, you would probably need more then just a 10x2 so that you reach SPI pins (you can only use some specific pins for SPI which controls the digipots)

which is fine. it's just that originally I was looking for a small board and a small one is too small to reach both +5 and SPI pinout. I am not planning the space for anything else so we can use the pins or the space any way we want to.

This is probably a smaller detail, we can figure it our along the way. Have you tried/can you try KiCad for this board?

[Sudo]

I normally use OrCad. So far, it looks straight forward using KiCad, so it not be a problem. I'll create small KiCad modules like all of the other designs you guys have already. I'll most likely use existing modules like the "high side and low side driver module - TC4427." It should drop right into the 4 outputs/2 halls.

[kb1gtt]

Cool and if you have any questions, please feel free to inquire. I'd be happy to help.

[Sudo]

Progress...
https://github.com/DanMoto/ECUStimS

[Sudo]

I am a bit frustrated with Kicad now. It seems all footprints for the newer version is on github, separately for each class? Anyone know an easy way to get all the footprints? I might just end up making all my own footprint.

[kb1gtt]

Why does it not surprise me that I can't get TortiseGit to check out the above repo. Rumble Groan Moan freaking git.

[Sudo]

Hm I don't use TortiseGit, only the command line, but did you try adding .git? https://github.com/DanMoto/ECUStimS.git

Sorry I realize git isn't popular here, but it is the only one I know how to use. I can move it to SVN if this a problem.

Edit: I just found out that you can checkout github respositories with SVN as well. So maybe you can try SVN?

[kb1gtt]

TortiseSVN saves the day, thanks SVN for being a functional tool

I took a quick look at it. Most of the circuits look like a good starting point. I see those digi pots can handle up to a 10MHz SPI bus, so those should work well for simulating devices. I think the diff VR driver might not function quite as you might expect. It can only drive between GND and V+. I'm not sure if that's jumping out to you or not, but wanted to note it, just in case it wasn't noticed. To get the signal to vary above and below GND, you'll need something like an isolated amplifier, or you'll need to couple it via small transformer or something like that.

[kb1gtt]

Some potentially helpful KICAD tools found at these links.

http://cyclerecorder.org/footprintbuilder/
http://kicad.rohrbacher.net/quickmod.php
http://per.launay.free.fr/kicad/kicad_php/composant.php

[Sudo]

kb1gtt, as you mentioned before, the Maxim chip inputs are listed to be -0.3V to Vcc+0.3V. I don't see why it IN+ needs to go negative at all with respect to ground. IN+ only needs to be negative with respect to IN-. In this case it will be. IN+ will be opposite logic of IN- and will cross their 'zero' (in this case zero will be 2.5V) on every toggle. At the same time it will be within the spec of the Maxim chip input range. I really choose to use the SN75ALS192(RS422) instead of a RS485 driver based on your suggestion of the Maxim's voltage specs. If anything, wouldn't you say what I have now would work especially with the Maxim chip? I can't say it will work for all ECU though.
S
Sorry I didn't get a chance to explain the theory behind the SN75ALS192 before drafting the schematic. I know there are better ways to do this, but I am sticking to the simplest way at the moment. I've given up on trying to simulate the exact VR signal for now and focuses on what will most likely work well. I think the SN75ALS192 is actually the closest/simplest. Even more so than the already working R232. But It is still experimental and definitely will need to be tested. I'll volunteer to be the guinea pig!

[kb1gtt]

Ooops, my bad. I had it in my head that the MAX chip was isolated. I just double checked the datasheet and noticed the rail diodes. I agree the VR will get pulled between the rails. No worries about drawing a schematic, I understand the concept there, I just blundered about the MAX chip.

[AndreyB]

Today I will open your board and respond...
Today I will open your board and respond...
Today I will open your board and respond... (repeating this to myself, I am too behind with kickstarter PR)

[Sudo]

Don't worry, it's not even close to completion. I haven't had time to continue yet. I do have a few questions for yo. And I will need you or anyone to help with pinout at the top level for the STM32.

STM32 Pins that needs to be assigned:

In1-In10: Inputs to the STM32

G: enable pin for VR drivers; High-z when off.
1A-4A: control pins to the VR/Hall drivers

HL1-HL6: control pins for the high/low drivers

CS, SCK, SI,/SHDN, /RS, (SO) for Digipot SPI. ; Do you prefer 3 seperate SPI, or seperate CS only, or daisy chain? It is daisy chain at the moment.

[AndreyB]

I'd say share the same SPI but three separate CS?

There probably should be jumpers from GND to PA* and from +5 to PB*? So by jumping or not jumping each of these you can get either a custom pull-up, pull-down or a voltage divider.

[Sudo]

Finally have some time to assign some preliminary pins. Let me know if any of these IO is a problem. Updated schematic as well.

Inputs with timer:
PA1 Timer2
PA0 Timer5
PA2 Timer9
PA7 Timer14
PA6 Timer13* (must remove MEMS to use)
PB1 Timer3
PE9 Timer1
PB14 Timer12
PB8 Timer10
PB9 Timer11
PB7 Timer4
PC8 Timer8

Inputs with alt timer:
PA3 Timer5
PB0 Timer3
PE6 Timer9
PC9 Timer8

Hi Lo Outputs:
PD8 HL1
PD9 HL2
PD10 HL3
PD11 HL4
PD12 HL5
PD13 HL6
PD14 HL7
PD15 HL8

Digipot I/Os
PB4 SPI3_MISO ('OR'ed outputs of the digipots)
PB5 SPI3_MOSI
PB3 SPI3_SCK
PD7 SHDN
PD6 RS
PD3 CS_12
PD1 CS_34
PD2 CS_56
PD0 CS_78

VR/Hall Outputs:
PE11 G
PE12 1A
PE13 2A
PE14 3A
PE15 4A

[AndreyB]

This starts to sound too complicated

Q1: I suggest we make the board compatible with Frankenstein. The benefit would be that Frankenstein would take care of some outputs, to some extent. Frankenstein pinout is https://docs.google.com/spreadsheet/ccc?key=0Arl1FeMZcfisdE1JN0pfSFV0Yk1RcGFyVjA0ZDkxdFE What do you think?

Q2: should we start with a tiny small stimulator with not so many features, but one we can send to a fab pretty soon? Like 2x1 inches, with just a couple of d-pots and minimal circuitry? Thing is that RIGHT NOW, as we speak, I am stimulating an OEM ECU with x1 digipot and x1 resitor+x1 capacitor+x1 diod to capture one signal (fuel injection duration). I suggest we start with a tiny simple stimulator and then make second step once we have something simple and functional. (for trigger output, I have discovery pin connected directly to stock ECU in open drain mode). What do you think?

[Sudo]

Ok, maybe I am making this a bigger board than it needs to be. The reasoning for that is because I feel if we are going to make a shield that's dedicated for automated stimulation, we might as well use up more IOs and make it more versatile as possible.

However, we can certainly put this full version on hold and create a smaller version. Since, I have already figured out all of the usable pins and have most of the circuit done, making smaller modules would be easy. But I do suggest that we don't make a shield, but instead just a module board so you can connect manually just like the other modules. It would certainly make routing trivial.

What would you suggest this minimum stimulator board be? Just 6 digipot as you initially stated and add the simulated VR signals? We can remove all other features since we have other modules for those already. Its just a matter of removing what we don't want and continue with layout.

[AndreyB]

I've added more info into the first message of this thread. Tell me if we should just talk on the phone to make things easier

[Sudo]

Ok, I get the idea of what you want. You basically want a 2"x1" mini shield with (2)10x2 socket headers, and as much digipots, inputs, and 5.08 terminals I can fit on it. All other features will be handled by Frankenstein and/or external modules.

[AndreyB]

Exactly!
I am not even sure if I need 5.08 terminals, they would probably be a waste of space for such a tiny board. I'd rather have two 2.54 pins for each connector. Two so that I can route same input or output to two external devices simultaneously.

[Sudo]

Ok. I will work up something for you next time I get a chance. It should be pretty straight forward.

[Sudo]

Check it out.

https://github.com/DanMoto/Stimulator

[AndreyB]

Looks like you are using "2014-04-17 BZR 4805" - is that a stable release or just their trunk? I only see a 2013-07-07 binary offered for Windows.

Update: nevermind, I've removed that line from the file and it has opened.

[kb1gtt]

Interesting use of Q10. I see that circuit like this, when the external signal goes low, it will pulls the MCU signal low. When the input signal raises above a threshold, it allows the MCU to pull up. That threshold is somewhere between .8V to 2.3V. You might want a TVS or some kind of transient suppression as Over Voltage Protected MOSFET's can get up to 70V, which would likely exceed the 60V limit of the 2n2007. Perhaps a 50V TVS would work well as a protection. Hmmm, why is the stimulator board with a pile of inputs? Shouldn't those be outputs? Hmmm can it be used as an output?

Why the use of SO on the digi pots? I see they are muxed together. I guess that's just for verification that the SPI command made it full circle.

About header connections that are NC, perhaps bring them to a test point, such that you can install a wire if so chosen for who knows what.

I haven't found much use of the power flags in KICAD. They seem to do odd things which I don't understand. I understand the theory, but there are several items that happen in the background that don't seem to match my expectations. I generally just make every thing passive then DRC checks and such seem to play nicer and follow rules I expect.

You might want to set the border/title block stuff, marking things like revision and setting the paper size to 8x11.5 and such.

Hmmm, can we make it such that we can stack this onto another discovery board and all the pins connect to the other discovery? As it stands now I believe intent is that you put this on a Discovery board, then you connect with a pile of wire to frank or what ever comes down the road. However we might be able to simplify things if we can directly stack a rusEFI on top of the the stim board.

[AndreyB]

The digipots look exactly like I wanted them.

What kind of input signal conditioning does the board do now?
@, where is 70v coming from? The purpose of this board is to stimulate an ECU on a bench, so no live injectors - at least that's the way I see it. The input signal would be either floating or ground, and that's what I am converting to GND or +5v with my diode+resistor+capacitor circuit. Would this board do the same?

Let's change the PCB so that we can snap this board right above the discovery, I think reducing the amount of needed wires would make it much easier. Here is my suggestion for the pinout:

The left 10x2 would snap on discovery just for the GND pin to the left from PB2. The rest 19 pins would be NC.

The right 10x2 would be 0.1 inch lower, this case it would snap on
spi MISO PB4
spi cs1 PD7
spi cs3 PD5
spi MOSI PB5
spi SCK PB3
input #1 PA8
the rest 14 pins would be NC

This case we would eliminate 7 wires. While we would probably lose in $ (tall headers would cost $), we would gain a lot in usability - not having these 7 wires would reduce the chance of a loose connection or mis-wiring, and that's huge. If whoever would not want to use tall headers, he can still wire the board to discovery.

What do you think?

[kb1gtt]

Hmmm, I'm experiencing internet connection issues. I got an update, but I don't have a PCB layout, so something's not working correctly. Ah, I see ECUStimS is different than Stimulator. I was looking at the wrong set of files. I'll see if I can get the new files checked out. Rumble groan moan, stupid ISP.

I see the input's are to measure the injector and ignition outputs. I'm not sure why that didn't click to me when I was looking at it before. I guess I was thinking signal generator, not signal validation. If there aren't any inductive loads involved, why do we have Q1? I see that as handy for over voltage protection, but if we are 5V on either side, we aren't ever expecting an excessive serge. Why now simply connect the two GPIO's together, perhaps with a pull up resistor?

Should the simulator include a couple outputs to simulate switch signals like NO2, AC load, and potently some other misc items that are convey'd via switch inputs? Hmm, should we have a signal to simulate the MAP / MAF?

To get this to open, I did the same thing. I deleted the line 57 which contained the text of " (grid_origin 124.46 62.23)" Then I was able to open it with my windows based KICAD.

It should probably have GND flood top and bottom. It also looks like you have space, so perhaps we should make R21, ect a jumper-able option.