How does FreeEMS currently implement the standby mode?

[slacker.cam]

Ah, you guys must be referring to Q18 and Q19. Yeah, they we're supposed to turn on the 'switched 5V' regulator when the key was switched on by the looks of it. I didn't realise that they had been removed but it does make sense. I'm interested to know why it didn't work. It looks like it should do. Aside from maybe the lack of a pull up resistor on the base of Q19. I'll dig into some old posts and see if this has been covered.

In the future it will be far easier to simply use a voltage regulator (whether it be linear or SM) with an enable input

[Fred]

Ah, you guys must be referring to Q18 and Q19. Yeah, they we're supposed to turn on the 'switched 5V' regulator when the key was switched on by the looks of it. I didn't realise that they had been removed but it does make sense. I'm interested to know why it didn't work. It looks like it should do. Aside from maybe the lack of a pull up resistor on the base of Q19. I'll dig into some old posts and see if this has been covered.

They were specced as bjts which gave them an unacceptable v drop, however marcos originally intended them to be fets. I forget why it was omitted/dropped, but the FET idea could have worked OK. The bjt one, not so much.

In the future it will be far easier to simply use a voltage regulator (whether it be linear or SM) with an enable input :)

This doesn't solve the issue discussed in the other thread, though. And there is no real need, either, as the supply to this regulator can be supplied by a key controlled relay. I guess it'd be nice to not have to have the switch input be clean, too. Probably an enable reg like this is a very good idea from an external wiring simplicity point of view.

Fred.

[KW1252]

Enable line could be very beneficial in a certain way. It would be possible to delay the power off, with a signal to the MCU to write whatever data logs gathered to non-volatile memory before bedtime. USB would provide the power when accessing the data logs and tuning parameters, I think.

[Fred]

yeah, i guess the configuration would want to be:

cpu regulator > powers cpu
key input > triggers cpu wakeup
on board peripheral power control output > controls other regulator for extra stuff like sd card, and power gobbling sensors, etc.

I'd not considered the possibility of an sd card slot in this architecture when posting in this thread before this point. But, you're right, it would need to keep power until writing was done, or, alternatively, it would need to write in a safe way that didn't mind a power cut. IF that is possible.

There was some hope, cam, in case you were wondering, that we could use the ADC pins for wakeup too. I'm unsure if that's possible, but if so, battery V and wakeup could be on the same line. If so, that would need to come through a relay from a golden source, NOT straight from the key.

Spudmn might have a few things to say on this subject too. I might PM him now.

USB could provide power to various devices, but NOT the same USB as used for general tuning, otherwise there could be current flow and oscillation issues.

I think plugging USB into the ECU general 5v is not a good idea at all, really. Tempting as it is.

Fred.

[KW1252]

I totally agree that the entire ECU should not be powered by USB. For tasks that require the full functionality it's not a workable idea but for lesser tasks I see options.

I checked the Hawkboard schematics, they used a TI TPS2087 power distribution switch that looks quite a smart little chip. They have several modes with USB and PSU; when the device acts as a USB Device without power source attached, the chip connects the USB +5V to the system power net. When the PSU is connected, the USB voltage is isolated, and when the device acts as USB host, it feeds from PSU to USB.

In our use the USB host mode is obviously not relevant, but it would offer these interesting options: When connected to battery, MCU and the peripheral devices (LM1949's and analog circuits etc) are powered by the power source; when connected to USB and battery the main power source would still power the rest of the board. Finally when disconnected from battery, the USB will feed only the needed circuits (if only as a SD card reader), and leave the rest unpowered.

[Spudmn]

it would need to keep power until writing was done, or, alternatively, it would need to write in a safe way that didn't mind a power cut. IF that is possible.

I have done this before, with the power cut off during logging. The down side to this is you lose the last 512 bytes of the log. It is much better if we can flush the files and close every thing down in a managed order.


I see it working some thing like this.

Engine running everything powered up.
Key turned off. SD card flushed and and SD regulator shut down. Any other house keeping.
Micro put into sleep mode.

Interrupts used to bring Micro out of sleep. UART coms or some one turning on the key.
If UART coms and some one is trying to down load the data logs, Power up the SD Regulator and start the file transfer.
If no Coms for a time, go back to sleep.

I think plugging USB into the ECU general 5v is not a good idea at all, really. Tempting as it is.

+1 . With the micro in sleep there is always the car battery to power the USB transfer. There is no need to power the micro from the USB and it complicates the circuit.

[Fred]

I see it working some thing like this.

Engine running everything powered up.
Key turned off. SD card flushed and and SD regulator shut down. Any other house keeping.
Micro put into sleep mode.

Interrupts used to bring Micro out of sleep. UART coms or some one turning on the key.
If UART coms and some one is trying to down load the data logs, Power up the SD Regulator and start the file transfer.
If no Coms for a time, go back to sleep.

Sounds good, with the proviso that there is a power LED on the peripheral parts of the board such that you can see what the thing is doing.

It might be better to just always power up the other parts of the board, if waking from comms, and avoid the extra logic.

Fred