[Ovmsdev] Framework V3.1

Mark Webb-Johnson mark at webb-johnson.net
Wed Jan 4 08:58:17 HKT 2017


Looks good. But I do see some compilation issues regarding flash space now.

Regarding the voltage drop, that is strange. We did test the hell out of this, back-in-the-day, but that was without GPS. Scoped it, and everything seems very smooth even under COPS searching for cellular towers. We have a big capacitor on the 12V side (before the power regulator). Maybe we’re hitting a limit on the power regulator and need extra smoothing on the 3.3V side?

Regards, Mark.

On 2 Jan 2017, at 7:44 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Happy new year everyone :)
> 
> As you may have seen, I submitted a rework of the network framework yesterday.
> 
> My goals were to a) eliminate hard coded delays as far as possible to get faster command responses, b) more stable/reliable tickers and c) higher frequency logging.
> 
> I've managed to achieve goals a & b. Commands are now processed in around one second instead of three, and logging is now very stable, for example GPS streaming will be very close to one entry every three seconds.
> 
> Higher frequency logging would be possible, but I've run into a hardware issue with this: the modem (both 908 and 808 versions) runs into under voltage problems if GPRS sends occur faster than once every three seconds on average. This will even work when the GSM cell does not change, but if the modem also needs to switch cells on the road, it occasionally just powers down without warning. This may also happen when the modem needs very high send power levels, i.e. if the next GSM tower is far away.
> 
> The hardware design document says:
> "The transmitting burst will cause voltage drop and the power supply must be able to provide sufficient current up to 2A. For the VBAT
> input, a decoupling capacitor (low ESR) such as a 100 μF is strongly recommended."
> 
> ...and the same problem could be solved here by adding a 10 µF buffer capacitor to the power supply line:
> https://forums.tessel.io/t/gprs-module-turns-off-randomly/250/7 <https://forums.tessel.io/t/gprs-module-turns-off-randomly/250/7>
> 
> So higher frequency logging may be possible when the modem does not need to power up its own GPS circuit, i.e. when the car supplies GPS coordinates.
> 
> One GPS (speed) mark every three seconds is still sufficient, now it's stable.
> 
> Btw, I also think I fixed the buffer overrun issue. I could reproduce the bug by timing a command send to arrive at the module at the moment the module starts a send itself. I then found some potential buffer problems with this case in the net_poll() code. Since fixing them I had no more events and can no longer trigger the bug with that command timing.
> 
> Please let me know if you run into new issues with this rework.
> 
> Regards,
> Michael
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20170104/77b77250/attachment.htm>


More information about the OvmsDev mailing list