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