Craig, Mark,
I just stumbled upon a misreading from my
side:
I had accidentally taken the v3.0 schematics
of the main board for reference, that only had
pull-ups on ports 1 & 2. There was a
change in v3.1 adding pull-up resistors on
ports 0 & 3 as well.
So with a 3.1/3.2 module, there actually is a
10K pullup on both MDM_EN and MDM_DTR, before
the transistor.
With that 10K, we have this transistor
control:
<ojgbfmjianhnlmjd.png>
That should result in ~1.5V at the base on
MDM_EN high, enough for the transistor to
switch, so I don't know what's going wrong
here.
You can access both pullups from the side,
they are located left of the S2 switch on the
main board. R8 is on MDM_EN, R9 on MDM_DTR. R8
shows that very short rise in voltage on
transition to high, while R9 shows the
expected behaviour of a constant +3.3 when the
port is high.
Regards,
Michael
Am 18.11.19 um
02:47 schrieb Mark Webb-Johnson:
I don’t think that circuit has changed since the very first v1 of OVMS. Maybe we have been lucky in the past with the timing?
I will discuss it with the manufacturer, as that part of the circuit is his design and he should know the thinking behind it the best.
Our intention it have EGPIO #0 able to control the PWRKEY of the modem - so as to be able to power it up/down under program control. We are not really controlling the power to the modem - more telling the modem to control itself.
Regards, Mark.
On 17 Nov 2019, at 8:11 PM, Michael Balzer <dexter@expeedo.de> wrote:
I also saw this & can also reproduce this on my workbench.
Mark, it seems we've got a hardware flaw here: EGPIO output port 0 (MDM_EN) is connected to transistor Q2 base via R16 without any pull-up. As the EGPIO ports
are open drain, that can only work by chance. Maybe R16 was meant to be the pull-up, i.e. be connected to +3.3V, and MDM_EN should be connected directly to the
transistor base?
I've verified this by checking the voltage level at MDM_EN & PWRKEY. When setting the port to 1, MDM_EN only rises for a very short time (too short for my
multimeter to tell), and PWRKEY only drops very briefly. The modem needs PWRKEY low for at least 180ms to power up and at least 500ms to power down.
Manually pushing S1 reliably switches the modem on/off.
Maybe a fix for existing boards could be adding a pullup resistor at the transistor base?
Regards,
Michael
Am 17.11.19 um 02:39 schrieb Craig Leres:
Maybe this has been discussed and I missed it but occasionally I'll get a module with the modem/simcom stuck in the PoweringOn state. Rebooting does not fix
this.
I thought I saw that you could reset the simcom with:
power simcom off
[wait a minute]
power simcom on
but that doesn't work. I turned up some logging:
log monitor
log level verbose simcom
and I see this happen about every 30 seconds:
I (2204129) simcom: State timeout, transition to 2
I (2204129) simcom: State: Enter PoweringOn state
I (2204129) simcom: Power Cycle
I thought this level of logging would let me see the results of command like:
simcom muxtx 3 at+csq
(signal quality) but I don't see anything after sending it.
Is there a way to hardware reset the simcom? (Is there any reason this doesn't happen when the ovms module reboots?)
Craig
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26