[Ovmsdev] some partial success
Nikolay Shishkov
nshishkov at yahoo.com
Wed Jan 2 09:22:27 HKT 2013
A quick report.
I manged to flash the firmware and register a phone.
I also started on a Think EV file based on the Twizy one. I setup the CAN filters and changed the code to handle a state of charge message.
Unfortunately it did not seem to work. On STAT request the response was generated from the net_sms code and not my new code for the Think EV.
On checking the code all seems fine - my stat function was plugged correctly.
I will continue tomorrow, but wanted to ask if anyone has good ideas to try?
Also - what are the capabilities used for?
What does "C6,C200-207" mean? I get the 200 to 207 are the extra commands but how are they plugged to the rest of the code?
If I reprogram the board, do I need to restart it somehow? Or is it enough to just reprogram it from the mplab x and the board will restart?
Any help is appreciated,
Nikolay
________________________________
From: Michael Balzer <dexter at expeedo.de>
To: ovmsdev at lists.teslaclub.hk
Sent: Tuesday, January 1, 2013 9:37 PM
Subject: Re: [Ovmsdev] sprintf / crashes
Mark,
transparent chunk splitting seems to be non-trivial, so I split my
data transfers. Everything's working fine again, so I'll merge into
the master next if you don't object.
Btw, AT+CIPSEND? gave me 1460 bytes, so that's supposed to be the
size limit we should keep in mind until we find a better solution.
@Nikolay: please note, that's the total size that can be sent within
one net_msg_start() ... net_msg_send(), the buffer size
(net_scratchpad) further limits a single MSG line to currently 199
bytes max.
Regards,
Michael
Am 31.12.2012 16:23, schrieb Michael Balzer:
Mark,
>
>I think I found my link dropping problem: scanning a diag log I
took, I found out CIPSEND will fail with a plain "ERROR" if the
data size exceeds about 1500 bytes. I guess that's either the
SIM908 buffer size or the max network packet size. I thought the
SIM908 would handle dividing data into packets as needed. The
SIM908 manual mentions the max packet size depends on network
status and should be queried by "AT+CIPSEND?". After the overrun
net_state_activity() will not recognize "ERROR" to terminate the
pending msg, so will run into the timeout and start a network
re-init.
>
>My battery status data exceeds 1500 bytes on first run and later
on if enough cells need updates. I'll think about how to split up
data packets into multiple CIPSENDs. Would be nice if the net
functions take care of this transparently.
>
>A secondary issue turned up from the diag log: the SIM908 crashed
in the middle of a CIPSEND command while the module continued to
run normally. The module still thought it's in NET_STATE_READY, so
did not re-initalize the modem. The connection could then be
established on the next CIPSTART, but the complete INIT stuff had
not been done. So it seems independant SIM908 resets need to be
handled as well, and they can occur anytime. I'll see if I can
solve that too.
>
>Regards,
>Michael
>
>
>Am 30.12.2012 15:42, schrieb Michael Balzer:
>
>I hesitate to merge into the master because I currently have link / connectivity problems, especially during driving. I introduced a GPS logging to optimize my antenna positions and managed to get some really nice tracks three days ago, so I don't think this is related to my changes... but I'm not 100% sure. I tried different antenna positions and another GSM network, but the connection keeps dropping when moving the car, and GPS position updates need minutes. Could be weather conditions ...or some tricky race condition bug?
>>
>
>
>
>
>_______________________________________________
OvmsDev mailing list OvmsDev at lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * 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/20130101/1c185c7d/attachment.htm>
More information about the OvmsDev
mailing list