[Ovmsdev] SIM808
Michael Balzer
dexter at expeedo.de
Sun Mar 13 21:45:38 HKT 2016
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 at expeedo.de
>> <mailto:dexter at 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 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
>> <dexter.vcf>_______________________________________________
>> 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.teslaclub.hk/pipermail/ovmsdev/attachments/20160313/1924df69/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20160313/1924df69/attachment-0001.vcf>
More information about the OvmsDev
mailing list