[Ovmsdev] 1.2.9 going on 1.3.1
mark at webb-johnson.net
Wed Aug 29 08:24:23 HKT 2012
I've just built the firmware labelled 1.2.9, as a pre-release candidate for 1.3.1. It contains all the major structural changes, as well as those that could impact reliability or have a big affect on the functionality of the system. I build all versions of the firmware to .hex files, for those who don't/can't build from source, and everything is in github already.
Here is the changelog since 1.2.7:
2012-08-28 1.2.9 Preliminary firmware 1.2.9
1.2.9 - an (almost feature complete) release candidate for 1.3.1
This version is an (almost feature complete) release candidate
for 1.3.1. It addresses a few known bugs, but primarily works
on (a) adding support for v2 hardware, (b) improving recovery
from loss of GSM signal in poor cellular coverage areas, and
(c) changes to the alert notification mechanisms to try to catch
more 'charge stopped' type events.
The following issues have NOT been addressed, but should be
fixed in the final 1.3.1 firmware:
#57 Car: Motor temperature overflow
#58 Car: Strange range when low on power
The following issues have been specifically addressed:
#60 Car: Still getting some GSM unrecoverable issues
#61 Car: Acknowledge settings with detailed parameters
#64 Support for v2 base hardware
#65 Increase timeout in NET_STATE_NETINITP
#66 Increase modem reset timer to 2 secs
#67 Car: Raise charge interrupted alerts based on charge state (stopped vs done
#68 Give COPS a chance
As you can see, we've still got two bugs outstanding. These are both minor edge cases that shouldn't affect the core operation and most importantly shouldn't affect the normal operation of the system - unlike the changes 1.2.7->1.2.9 which are major in places and might impact the system.
The reason for this build is to get it in some cars to make sure everything still operates ok. The major changes that might impact things are:
Changes to the modem control logic, to introduce longer delays, retries and some new 'settle' states to try to improve the recoverability when the module/car is in areas of poor cellular connectivity. This will take a long time to tets in real cars. What we're hoping to fix here is the situation where a car loses GSM lock in poor connectivity areas, but can't recover lock when it moves back into a good cellular coverage area.
Introduction of a linear backoff algorithm to server connections. This is to address a reported issue where the server is down/unreachable and the module repeatedly tries to connect, driving up cellular costs. The number of bytes for each connection is minimal (80 bytes or so), but in cases where the mobile provider either charges for these bytes (most don't seem to), or horribly rounds them up (we've seen evidence of mobile providers rounding connections up to 100KB or 1MB!), the new algorithm should minimise the impact. This also helps in cases where the vehicle ID or server password doesn't agree with the config at the server, or the incorrect server IP address has been entered. This has been quite thoroughly tested on the bench.
Change to the notification system, to be more expandable to new notification types, include SMS notifications for trunk opening in valet mode, and most importantly change from using charge sub-state to the main charge state when deciding whether to SMS/Push notify when charging is stopped. The new logic is that SMS/Push notification should occur whenever a charge is stopped (either inside the car or outside), except for two cases: (a) the car itself stops the charge because it determines the charge completed normally (charge done state), and (b) within 30 seconds after an authorised App/SMS requests the charge be stopped. This has been minimally tested, and I need the most help with testing this.
Support for v2 hardware. I'll handle the testing for this, as I'm the only one with v2 hardware in hand at the moment ;-) It has been tested on the bench and seems fine. I don't expect any issues in real cars, but we'll know within the next week or so.
The final 1.3.1 should be released around the upcoming weekend. The v2 hardware is arriving this week, and we need the firmware locked down ready for that.
I would really appreciate it if some of you have time and can test this out in your cars, to give us some confidence that these major changes don't impact the reliability or functionality of the upcoming 1.3.1. Let me know here of any problems you find.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev