Works. I've also pushed my latest (minor) Twizy update. Regards, Michael Am 13.03.2016 um 14:14 schrieb Mark Webb-Johnson:
Michael,
Thanks for your fast help. I was worried about that.
I’ve re-worked the NET_INIT1 logic. Can you try to pull and see if that now works for you?
With the SIM808, we can’t include anything else on the AT+CGPSPWR=1 command (or it gives ERROR). But, putting +CGPSRST=0 in front of the first CMINS? seems to work ok.
I tried here on my SIM908 and it seems ok. Could you try on yours?
Regards, Mark.
On 13 Mar 2016, at 7:43 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
unfortunately the new GPS init does not work, the module doesn't get coordinates.
I remember adding +CGPSRST on purpose, somewhere the docs suggested it's necessary...
...found it: section 12.2.2 AT+CGPSRST GPS Reset Mode (HOT/WARM/COLD) "Note: COLD start mode is recommended For first time reset."
I now added it to NET_WAKEUP_GPSON, and the GPS init works again:
rom char NET_WAKEUP_GPSON[] = "AT+CGPSPWR=1;+CGPSRST=0\r";
...but according to your findings on SIM808, this will occasionally fail, so that's no solution.
If we need to retry NET_STATE_START if the PWR command fails, maybe we can prepend RST to NET_INIT1?
Or, if the SIM808 doesn't need the RST, maybe a simple solution is to create SIM808 / SIM908 specific images?
Regards, Michael
Am 13.03.2016 um 10:13 schrieb Mark Webb-Johnson:
I’ve just committed the code changes discussed below. This is v2.8.3.
I few changes to be aware of:
* MPLABX 3.1x support * An OVMS_BUILDCONFIG #define has been added to the build configs. This passes in a string that is used during the VERSION commands to include the build config selected during the build. So we can tell a V2_Production build from a V2_Twizy build, etc. Should make support easier, but you may need to tweak your own build configs to get them to build with this. * The GPS initialisation code has been re-worked. Instead of the AT command used for wakeup, in the configurations with a GPS, I replace that with the AT_CGPSPWR command appropriate (to power up the internal SIMx08 GPS if internal GPS is requested by the vehicle module). As a side-effect, I dropped the AT+CGPSRST=0 that was used during initialisation to do a cold boot - I don’t think that is going to be an issue, but please let me know if you think it will.
The build config strings I am using are three character:
* V1P - V1 Production * V2P - V2 Production * V2E - V2 Experimental * TRP - V2 Tesla Roadster Production * RTP - V2 Renault Twizy Production
I would appreciate it if you guys could test this out on your SIM908 modules. In particular, for cars with GPS. This is a release candidate firmware and I am intending to send it to the factory building the first batch of SIM808 modules, later next week. Any feedback you can provide would be appreciated.
Regards, Mark.
P.S. If this is ok, it should bring to a close the v2.x firmware that I am working on (other than simple maintenance). I’m now full time concentrating on the v3 firmware that is being built using FreeRTOS on the FRDM-K64 platform (as a development platform for the upcoming v3 OVMS hardware). More on this soon...
On 8 Mar 2016, at 4:24 PM, Mark Webb-Johnson <mark@openvehicles.com <mailto:mark@openvehicles.com>> wrote:
An update on SIM808. It is just a stop-gap solution, but it buys us some time.
The changes I’ve made / problems I’ve had:
1. Power button needs to be held for 1 second to power down/up the modem (SIM908 was much faster). Not a bad issue, but it did waste a week going back and forth trying to find the cause. 2. The SIM808 doesn’t echo LineFeed characters. That is a pain for DIAG mode console, but doesn’t affect anything else. Only workaround possible is to use a terminal program that can map CR->CRLF, or CF->LF (and live with the horrible display in DIAG mode). We’ll just develop on SIM908 modules or use a fancy terminal emulator. I guess if people are using scripts to talk to DIAG mode, they may need some tuning if they are expecting CRLF and just getting CR now. 3. GPS initialisation (this is the biggy - more below). 4. Build profile in version string. This is just a simple fix to include a #define in the build profiles, and to include that where we show the version string. It means that as well as the version of firmware, we can now see the build profile. Helpful for support of new users.
The biggest issue has been with GPS initialisation.
Looking at the current code:
#ifdef OVMS_INTERNALGPS // Using internal SIM908 GPS: rom char NET_INIT1[] = "AT+CGPSPWR=1;+CGPSRST=0;+CSMINS?\r"; rom char NET_REQGPS[] = "AT+CGPSINF=2;+CGPSINF=64;+CGPSPWR=1\r"; #else // Using external GPS from car: rom char NET_INIT1[] = "AT+CSMINS?\r"; #endif
So, if the build profile includes OVMS_INTERNALGPS (ie; one or more vehicles in the profile require GPS), then we use a big sequence of initialisations "AT+CGPSPWR=1;+CGPSRST=0;+CSMINS?\r”. We have two issues with this:
1. We’re powering up the GPS, even if the actual vehicle we selected doesn’t need SIM908/808 GPS. That costs watts - and with my new fancy bench power supply I got for OVMS v3 development (ok, cheap chinese ebay) I can now see exactly how much ;-). 2. The SIM808 randomly doesn’t like AT+CGPSPWR=1 and in particular seems to hate it 100% of the time it is included with other options. You get an ERROR response back from the modem, and as this is done in NET_STATE_DOINIT, it looks like a SIM card error (but is nothing to do with SIM card). We just never saw AT+CGPSPWR=1 fail on SIM908.
Now, as well as the #defined OVMS_INTERNALGPS to enable the SIM908/808 GPS, we’ve also got NET_FN_INTERNALGPS in net_fnbits which is set during vehicle module initialisation. The first brings in the code, the second should turn it on. Except it doesn’t. The first one turns it on.
Accordingly, I’m having to change the net.{h,c} layer to split off GPS initialisation into its own states and use a simple AT+CGPSPWR=1 for vehicles that require SIM908/808 GPS and AT+CGPSPWR=0 for vehicles that don’t. I’ve taken the opportunity to switch from using OVMS_INTERNALGPS to using NET_FN_INTERNALGPS in net_fnbits as the decision as to whether to power up the SIM908/808 GPS or not.
Building and testing that has taken me the most time. It is almost done, and I should be able to commit the code soon.
Production firmware then goes to the manufacturer in China, and we give the go-ahead for the production run. We should have the modules back in stock towards the end of March / first thing in April.
Regards, Mark.
P.S. I can actually recommend that cheap(ish) chinese ebay power supply. It’s available from various eBay sellers, or banggood <http://www.banggood.com/CPS-3205C-0-32V-0-5A-Portable-Adjustable-DC-Power-Supply-180-264V-p-974495.html>. Controls are precise, output is rock solid, ammeter is as accurate as my multi-meter, and it is built like a tank.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26