Nikolay,
the documentation needs some updates, the vehicle type parameter
is new.
Easiest GPRS test is done by using the standard server and the iOS
or Android App.
To set up your own OVMS server, you need a public IP, a mysqld and
perl. See "server" directory in the git repository.
Set up some mysql schema e.g. "ovms" and access, prime the schema
using "mysql ovms < ovms_server.sql" and change
"ovms_server.conf" accordingly.
To be able to connect your module, manually add an entry to the
ovms_cars table like this:
insert into ovms_cars set vehicleid='...', carpass='...',
userpass='...', changed=now();
The server is started by "./ovms_server.pl" (or "perl
ovms_server.pl" if non-UNIX). Configure your module using "GPRS"
and "SERVER" and you should see log output from the server
(stdout).
It's best to start without paranoid mode, so you can read what's
happening.
Btw: I had trouble with my first SIM card as well in the
beginning. That was network/provider related, after letting the
module on for some hours, the GPRS registration suddenly succeeded
and has been quick + stable since.
Regards,
Michael
Am 02.01.2013 10:05, schrieb Nikolay Shishkov:
Thanks Mark,
Looking at the code the VEHICLE TYPE is the 4th parameter
of the MODULE command.
I will test this today and report back.
I was looking
at the user guide for Tesla and the MODULE command has
listed 3 parameters...
I forgot to mention that I tested 2 different sim cards in
Sweden:
1- mini sim format (like iphone 4) with adapter, operator
3 - did not work, the error code is blinking too fast for me
to reliably count it.
2 - standard sim format, operator telia - worked for sms
Still haven't tested the
gprs function. Any good advice on how to test the GPRS
function - can I setup a simple server to just register the
incoming messages?
Nikolay
Nikolay,
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.
So long as you've registered the hook correctly, it
should work. Are you sure you set the module correctly
to TC so your vehicle module is the one actually used?
This is the SMS MODULE command (I think it is the last
parameter).
You can SMS PARAMS? or MODULE? to see what
parameters are set.
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?
This is a new v2.x thing, used to tell the App what
the capabilities of the vehicle module are. We don't
use it at the moment, but plan to use this in the app
code in order to customise the functions and
appearance on a per-vehicle-module basis. For example,
if the vehicle module is able to support a lock/unlock
command, the capabilities will tell the Apps that, and
the apps can update the UI appropriately.
f 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?
The board will restart automatically after being
programmed by MPLAB-X. If you want to restart it, you
can also SMS RESET or just pull the power.
Regards, Mark.
On 2 Jan, 2013, at 9:22 AM, Nikolay Shishkov
wrote:
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
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@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@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
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
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev