[Ovmsdev] OvmsDev Digest, Vol 93, Issue 26
Mark Webb-Johnson
mark at webb-johnson.net
Thu Oct 24 09:50:48 HKT 2019
Sure. A techspecs kind of section sounds fine.
Regards, Mark.
> On 24 Oct 2019, at 7:09 AM, Glyn Hudson <glyn.hudson at openenergymonitor.org> wrote:
>
> That's good to hear, you power readings were very similar to mine. I
> pessimistically rounded up when the values were fluctuating.
>
> Where would be the best place to publish these readings in the
> documentation? Prior to measuring the power readings myself I tried to
> search for OVMS power consumption in the docs but could not find any
> results.
>
> How about adding a new section to readthedocs called "technical specs"?
>
> On Wed, 23 Oct 2019 at 18:32, <ovmsdev-request at lists.openvehicles.com> wrote:
>>
>> Send OvmsDev mailing list submissions to
>> ovmsdev at lists.openvehicles.com
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> or, via email, send a message with subject or body 'help' to
>> ovmsdev-request at lists.openvehicles.com
>>
>> You can reach the person managing the list at
>> ovmsdev-owner at lists.openvehicles.com
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of OvmsDev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: OVMS V3 power consumption readings (Mark Webb-Johnson)
>> 2. Re: Kona electric and http routing (Peter Lord)
>> 3. Re: Kona electric and http routing (Michael Balzer)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 23 Oct 2019 21:31:16 +0800
>> From: Mark Webb-Johnson <mark at webb-johnson.net>
>> To: OVMS Developers <ovmsdev at lists.openvehicles.com>
>> Subject: Re: [Ovmsdev] OVMS V3 power consumption readings
>> Message-ID: <29BFF543-9FDC-4EF7-A8B8-1F8ED92FCDD8 at webb-johnson.net>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Glyn,
>>
>> Powered exclusively by ext12v, @12v, I get:
>>
>> Wifi off/sleeping: 25mA
>> Wifi only: 49mA
>> Wifi + 3G: 85mA
>>
>> Powered exclusively by USB, @5v, I get:
>>
>> Wifi off/sleeping: 46mA
>> Wifi only: 104mA
>> Wifi + 3G: 180mA
>>
>> Note that in areas of low signal, the 3G power consumption can be higher. Similarly, if GPS is enabled that can have an affect as well. I?ve never seen it go over about 220mA (and even that was just for short bursts).
>>
>> If I power it from both USB and 12V simultaneously, I get:
>>
>> Wifi off/sleeping: 8mA (USB 5v) and 19mA (ext 12v)
>> Deep sleep: 8mA (USB 5v) and <1mA (ext 12v)
>>
>> (The 8mA is mostly from the CP2102 which is powered off when not in use)
>>
>> Regards, Mark
>>
>>> On 22 Oct 2019, at 2:41 AM, Glyn Hudson <glyn.hudson at openenergymonitor.org> wrote:
>>>
>>> I've just measured the power consumption of the OVMS V3 module using a
>>> bench power supply set to exactly 12.0V.
>>>
>>> OVMS consumed:
>>>
>>> 60mA = 0.72W with WiFi on (AP active) and GSM/GPS modem off
>>> 100mA = 1.2W with everything switched on.
>>>
>>> This is less than I was expecting, I would take weeks for OVMS to
>>> drain a healthy lead acid battery.
>>>
>>> --
>>> All the best,
>>>
>>> Glyn Hudson
>>> +44(0)1248672607
>>>
>>> https://openenergymonitor.org
>>> https://zerocarbonadventures.co.uk
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20191023/59137e1b/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 23 Oct 2019 16:44:41 +0100
>> From: Peter Lord <plord12 at gmail.com>
>> To: OVMS Developers <ovmsdev at lists.openvehicles.com>
>> Subject: Re: [Ovmsdev] Kona electric and http routing
>> Message-ID: <7FF66C27-4FF7-4629-9E17-40BED5460648 at plord.co.uk>
>> Content-Type: text/plain; charset=utf-8
>>
>>
>>
>>> On 23 Oct 2019, at 07:33, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>>
>>> The connection between the SIMCOM and the ESP32 is 115,200 baud. That could be increased (in software), and there is software flow control on the GSM MUX we use (although I have no idea if SIMCOM implements it); but without hardware flow control lines I don?t think it could/would approach 3G speeds.
>>
>>
>> Ah, I see thanks. In this case, though, the bandwidth & latency requirements are minimal ( occasional http get ) ... its not as though I want to watch youtube :-)
>>
>>
>>>
>>> The alternative is to swap it around. Put the modem and the SIM in some other device designed for that purpose, and have OVMS connect to that as a WiFi client.
>>
>>
>> Right, good point, thanks.
>>
>> I guess I need to order one :-)
>>
>>
>>>
>>> Regards, Mark.
>>>
>>>> On 23 Oct 2019, at 2:23 PM, Peter Lord <plord12 at gmail.com> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> I've been lurking here for a while still debating wether to ditch my autopi in favour of OVMS.
>>>>
>>>> One thing thats held me back is to find a way to use the wifi hotspot as a NAT router - this is
>>>> useful to allow my sat nav to get traffic and charging point updates. As far as I can see on
>>>> the web page this isn't currently supported.
>>>>
>>>> However I did see a couple of projects that adds NAT support to lwip :
>>>>
>>>> https://github.com/martin-ger/lwip_nat_arduino
>>>> https://github.com/jonask1337/esp-lwip
>>>>
>>>> Does anyone know if adding NAT has a fighting chance ?
>>>>
>>>> Cheers,
>>>>
>>>> Pete
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 23 Oct 2019 19:31:40 +0200
>> From: Michael Balzer <dexter at expeedo.de>
>> To: ovmsdev at lists.openvehicles.com
>> Subject: Re: [Ovmsdev] Kona electric and http routing
>> Message-ID: <ba93215a-e4c1-c5d6-a334-17e5ccf50bac at expeedo.de>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I've pushed my SIMCOM changes. With these optimizations, fifo overflows and frame errors have dropped significantly:
>>
>> OVMS# sim stat de
>> Network Registration: RegisteredHome
>> Provider: congstar
>> Signal: -97 dBm
>>
>> State: NetMode
>> ? Ticker: 73099
>> ? User Data: 0
>> ? HW FIFO overflows: 21
>> ? Buffer overflows: 0
>>
>> ? Mux
>> ??? Status: up
>> ??? Open Channels: 4
>> ??? Framing Errors: 24
>> ??? Last RX frame: 1 sec(s) ago
>> ??? RX frames: 151452
>> ??? TX frames: 5472
>>
>> PPP: Connected on channel: #2
>>
>> GPS: Connected on channel: #1
>> ???? Status: enabled
>> ???? Time: enabled
>>
>> ?but the overflow frequency differs between my modules (both v3.1, the one with the first gen CP2102 has more overflows), and I can still see a direct relation
>> to Wifi.
>>
>> With Wifi switched completely off, no overflows occurred over a period of ~5 hours. As soon as Wifi was reactivated (regardless of the mode), the errors were back.
>>
>>
>> Am 23.10.19 um 09:31 schrieb Mark Webb-Johnson:
>>> While there is flow control on the USB side, I don?t think there is any between the ESP32 and the CP2102. See Espressif?s example DEVKIT-C schematic:
>>>
>>> https://dl.espressif.com/dl/schematics/ESP32-Core-Board-V2_sch.pdf
>>>
>>>
>>> or the OVMS one (which we based on DEVKIT-C). Just RX and TX data lines to the ESP32.
>>
>> What about the RTS/CTS lines connected to IO13 & IO15 in the core board?
>>
>>> However, during flashing there is pretty much nothing else running on the system and no high level operating system.
>>
>> Indeed.
>>
>> Regards,
>> Michael
>>
>>> The good news is that these are very very short data lines. Just a few inches, I think. I did look at the signals in the early days of the project, and they
>>> seem quite clean.
>>>
>>> The GMS MUX flow control is at the frame level. I would guess that several frames would still need to be fit into the buffer for it to be effective. It is
>>> implemented on a per-channel basis, and a short description (from the blox manual) is:
>>>
>>> http://read.pudn.com/downloads406/ebook/1729787/MuxImplementation_ApplicationNote_(WLS-CS-11002).pdf
>>>
>>> 6.3 FlowControlonvirtualchannels
>>>
>>> The Flow control of the virtual channel is implemented in terms of MSC packets with the FC bit. If the application processor sets the FC bit to 1 for a
>>> particular DLC, the TE does not send data to the application processor for that DLC until FC returns to 0 for the same DLC. The TE has limited resources
>>> for buffering data, so if the DLC is involved in large data transfers (for example downloading data through a GPRS connection) a buffer overflow may occur
>>> if the time between FC=1 and FC=0 is too long; in this case data may be lost and there is no error indication.
>>>
>>> The application processor should avoid (if possible) the use of this feature or keep the time interval with the FC=1 as small as possible.?
>>>
>>>
>>> I never really did any optimisation of the SIMCOM (or MUX) driver at all. The MUX in particular was written by looking at other implementations, as the
>>> protocol specification has gone the way of most standards body specifications and is mostly undecipherable. I think there is some opportunity for improvement
>>> (but given our low bandwidth requirements at the time we never had the incentive). Flow control is not implemented at all.
>>>
>>> Regards, Mark
>>>
>>>> On 23 Oct 2019, at 3:01 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>>
>>>> Mark,
>>>>
>>>> also not trying to sound too negative? but please read: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/274
>>>>
>>>> The flashing process is done with hardware flow control. With Wifi enabled, we cannot even handle 115 kbit without fifo overflows.
>>>>
>>>> We can try the MUX flow control you mentioned, but will it be able to throttle transmission within frames longer than the HW FIFO?
>>>>
>>>> Btw, I've got an improvement on fifo overflow recovery in testing, if you want to work on this, I can push my changes this evening.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Am 23.10.19 um 08:50 schrieb Mark Webb-Johnson:
>>>>> But perhaps I am unintentionally sounding too negative...
>>>>>
>>>>> The biggest hurdle to this working technically is undoubtedly the LWIP support for SNAT and routing. If the library you caption (jonask1337/esp-lwip) solves
>>>>> that, it makes this technically feasible.
>>>>>
>>>>> My comments on baud rate on the UART link between ESP32 and SIMCOM are more about the practicality of it. That could be tested with a few simple
>>>>> modifications to our SIMCOM driver, to see how fast it could actually be driven. I know we get up to about 1Mbps for firmware flashing without an issue, and
>>>>> the ESP32 hardware UART is up to 5Mbps.
>>>>>
>>>>> It would be a fantastic feature to have, and incredibly useful.
>>>>>
>>>>> Regards, Mark.
>>>>>
>>>>>> On 23 Oct 2019, at 2:33 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>>>>
>>>>>> The connection between the SIMCOM and the ESP32 is 115,200 baud. That could be increased (in software), and there is software flow control on the GSM MUX
>>>>>> we use (although I have no idea if SIMCOM implements it); but without hardware flow control lines I don?t think it could/would approach 3G speeds.
>>>>>>
>>>>>> The alternative is to swap it around. Put the modem and the SIM in some other device designed for that purpose, and have OVMS connect to that as a WiFi client.
>>>>>>
>>>>>> Regards, Mark.
>>>>>>
>>>>>>> On 23 Oct 2019, at 2:23 PM, Peter Lord <plord12 at gmail.com <mailto:plord12 at gmail.com>> wrote:
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I've been lurking here for a while still debating wether to ditch my autopi in favour of OVMS.
>>>>>>>
>>>>>>> One thing thats held me back is to find a way to use the wifi hotspot as a NAT router - this is
>>>>>>> useful to allow my sat nav to get traffic and charging point updates. ?As far as I can see on
>>>>>>> the web page this isn't currently supported.
>>>>>>>
>>>>>>> However I did see a couple of projects that adds NAT support to lwip :
>>>>>>>
>>>>>>> https://github.com/martin-ger/lwip_nat_arduino
>>>>>>> https://github.com/jonask1337/esp-lwip
>>>>>>>
>>>>>>> Does anyone know if adding NAT has a fighting chance ?
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Pete
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at 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 at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at 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
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20191023/24d674a6/attachment.html>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>> ------------------------------
>>
>> End of OvmsDev Digest, Vol 93, Issue 26
>> ***************************************
>
>
>
> --
> All the best,
>
> Glyn Hudson
> +44(0)1248672607
>
> https://openenergymonitor.org
> https://zerocarbonadventures.co.uk
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
More information about the OvmsDev
mailing list