Raw CAN data from OBD2 - obd-ii

I am new to OBD 2. I want to get RAW CAN data from my vehicle(Duster from Renault,India). I am using OBDlink connector. Basically my question is how to extract only CAN data from vehicle OBD connector? I want to get the data from CAN. Is this possible?
Any comments are appreciable.

Cheapest best option IMO is a Teensy with CAN bus shield you can read more about here: https://oshpark.com/shared_projects/VeJFD9qA
The other off the shelve option would be to use an OBDLink SX adapter, they can support reading at the commonly used 500kbps.

If you're serious about receiving all CAN data and not losing any frames, you should buy a SocketCAN-capable CAN adapter. These do not pipe all the frames through serial ICs like ELM327 or STNxxxx and allow for better bandwidth.

Related

BLE communication data type

Bluetooth newbie here.
Is there a best practice among the data type used for BLE communication?
In my case I am setting up a ESP32 that acts as Server: it has a single Characteristic with a Notify property, so it repeatedly sends data to all the Clients once they connect (a raspberry pi as Client, in my case).
Right know the data exchanged is just bytes (based on the Neil Kolban "BLE_notify" Arduino example) but it would be great to send Strings or better JSON data. Is that possible?
You can send in whatever format you want if you use custom characteristic uuids. Although generally BLE data transfer is slow so you'd better make your data as compact as possible. Json might not be the best option here. I've not heard of anyone sending json over BLE. Some binary format is what's generally used.

Fast, simple data storage with a JSON API

I need to store a small and simple dataset online that is retrievable as JSON. I'm thinking of something along the lines of Google Spreadsheets, had that service not been a bit unreliable from time to time.
I'm building a small web app that will display some numbers. Rather than hardcoding the numbers into the application, I need to go through the whole deployment process beforehand. When I get my hands on the numbers, I just want to pop them into the data storage service and have them available via a JSON API within a few minutes.
What is the easiest, simplest and cheapest (but reliable) way to do this?
Cheers!
have a look at :
couch: http://couchdb.apache.org/
mongodb: http://www.mongodb.org/
When you are hosting the small web app yourself anyway, you might just static serve the JSON document with the required parameters for your app and FTP it without a whole new deployment when update is needed.
But when you have less control about the deployment, then the cheapest but least elegant way might be a shared (read-only) text file in Dropbox or similar. But check about throttling and limits and TOS first before using such a way.
Probably the easiest and simplest is https://parse.com/ , there is a very easy to use jquery api for this storage: https://github.com/srhyne/jQuery-Parse
An example on how to put a new data into the storage:
$.parse.post('mykey',{ value : 'myvalue' }, function(json){console.log(json);});
An example on how to get this data from the storage:
$.parse.post('mykey', function(json){console.log(json);});

How to do Realtime/fast processing of GPS data in web application?

I am writing a web application for mapping Real-time GPS coordinates on Google maps coming from a GPS device, for fleet managment.
Since the flow of data is very fast from the GPS device to web application for database it becomes very heavy and the database is being queried every 5 seconds(via AJAX from web browser running the website) it becomes more heavy.
Keeping the updates in real-time is becoming very difficult a lagging of 30 seconds to 60 seconds is created between the actually update and its visibility on the website.
I am using Django + Apache + MySQL on CentOS 6.4 64 bit.
Any advice in what direction i should move to make the processing/visibility of data in more real-time would be helpful.
I would suggest you to use NoSql database like MongoDB. It would really help you to achieve real time application performance.
Have a look at Django-With-MonoDB.
And if possible try to replace default python interpreter to PyPy.
I think these two are enough to give you best performance. :)
Understanding Django-using-PyPy
Also for front-end you should use KnockoutJS or AngularJS.
Some tipps:
Avoid xml, especially a DOM based xml parser (this blows up data by a factor of 100). (A lat long coordinate without time, needs 8 bytes, not more)
favor a binary represenattion of the coordinates, and parse them by hand, instead using an slow generated parsing code taht probaly uses reflection to parse.
try to minimize the use of databases, especially relational ones.
raise the intervall that clients are sending: e.g evry 20min instead
evry 5.
if you use a db, minimize the transactions, try to do all processing
in one transaction.

How to obtain amount of transferred data through Wi-Fi from other applications?

I'm facing to this problem. I spent much time by searching some API or "something" with it's possible to obtain transferred data through Wi-Fi from other applications (how screenshot bellow shows).
Does someone know a way how to do it? Is here someone who tried (or has already done) for something similar? Or a little differently: Is this possible to do it?
Currently i think that this is not possible because i think that non-system application cannot retrieve data from other application(s) installed on device. But maybe i can "missing" something so i placed this question and will be glad for whatever suggestion.
Thanks in advance!
TrafficStats
Class that provides network traffic statistics. These statistics include bytes transmitted and received and network packets transmitted and received, over all interfaces, over the mobile interface, and on a per-UID basis.
This means you can use getUidTxBytes to get whole transmitted data and so far getUidRxBytes to get whole received data.
And you can get application's UID with:
getApplicationInfo().uid
or for other applications refer THIS
While Sercan's answer is correct, must warn you that TrafficStats is not always guaranteed to give you correct stats. Basically TrafficStats will check files in the directory /proc/uid_stat/1094/ and various files like tcp_snd, tcp_rcv etc under this directory. On some devices, these (pseudo)files are not updated. Hence you should always check for a return value of UNSUPPORTED (-1) http://developer.android.com/reference/android/net/TrafficStats.html#UNSUPPORTED
Also, typically these stats have not been including UDP data. So the numbers you report will be wrong for apps that use UDP (like VoIP apps). For more details, look at
https://code.google.com/p/android/issues/detail?id=32410
On latest Android versions, there is another /proc file that gives you a lot of details. This is at /proc/self/net/xt_qtaguid/stats. But this pseudo file will only show the stats of an app reading that. Any Android app tries to read this file, it will not get stats related to any other Android app.
Why not try reading config files containing network information?
try this:
adb shell
cd /proc/uid_stat/XXXX(Proc id)
cat tcp_rcv/tcp_snd

XMPP, Strophe and raw/stream data channels

I was using a jquery plugin to talk with bosh:
https://github.com/maxpowel/jQuery-XMPP-plugin
I read that i can use strophe to send data in stream mode, in order to save bandwidth.
What i need to have:
One normal channel where i exchange commands between chat computer users
Several channels to send not formatted data, but with the smallest amount of information, because the time of each message can round between 100ms
I've made a graph for better understanding.
How to do this with Strophe?
Second question is that i read about this json plugin for strophe http://code.google.com/p/prosody-modules/wiki/mod_json_streams .
Do you have already tried this? Is it stable and gives really a good win in bandwidth?
Thanks for your answer.
Best Regards,
Regarding your second question, thats just an april fool joke (note the date it was published), and also, the XEP 0295 that the page references make that clear:
NOTICE: This document is Humorous. It MAY provide amusement but SHOULD
NOT be taken seriously.