[Ovmsdev] SIM808

Sun Mar 13 19:43:19 HKT 2016

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 at openvehicles.com
>> <mailto:mark at 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 at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20160313/05bfa24f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20160313/05bfa24f/attachment-0002.vcf>