MBED, Arduino , STN1110 & BT

Are ken1784 and kinetik both talking about gen 2 (in US it's 2004 ~ 2009) Prius? Maybe Toyota changed the algorithm between model generations or even between model years within the same generation? (I don't remember the detail but I remember there was a PriiDash user that had problem with one of the values and it turned out for that CAN ID his Prius sent one fewer byte than mine.)
 
Kinetik has a gen 2, like me
we do not have Pid 611.
and 04B has only speed, and no distance.

ken, how do you know that a distance between two points is 1000 km? what is your reference?
 
Yoshi, I agree that if Prius trip meter is measured using 0B4 data and if you want to have the same value as trip meter, please use 0B4.

But I prefer to consider a real trip on a road. For example a 100 km trip. I'm almost sure 230 will give results closer to reality

For 5 trips, you will get for examples results like this

trip 0B4 230
100.0 100.2 100.0
100.0 100.3 100.1
100.0 100.1 100.0
100.0 99.9 100.0
100.0 99.7 99.8

Regards
 
regarding 0B4 & 230, IMHO it is the same:
0.1% has no importance for me.

but I agree with yoshi about efficiency:
we are dealing with small microcontrollers and using an efficient filtering (thx yoshi),
if we get odo & speed in the same frame is really good for me (but the guys with gen 2 do not have this info in 0b4)...

about olimeximo, I got one today. my feelings are mixed:
see a picture here & guess which one is the olimex ...

yes , it is small;
but :

  • they do not respect the holes's placement compared to arduino (the box would have to be adapted).
  • it seems the use of sdcard is problematic.
  • they do not have real lib & or experience with can
  • I wonder if it is possible to use 2 UART and a CAN simultaneously
  • for sure usb & can are not compatible
a question to gen2 's guys : is 611 operational? ( odo matching the board's odo)

edit: it took some time to write this post & some clever guys answered about 611 before I posted
 
ken, how do you know that a distance between two points is 1000 km? what is your reference?
My reference is Prius odo.
Assuming Prius odo is zero error with standard size tires.
In Prius, following data is based on the same reference as CANID:0x0B4[4]

  • odo
  • trip-A distance
  • trip-B distance
  • average speed
  • average fuel mileage
I would like to show these numbers same as Prius's without any adjustment.

Yoshi
 
I would like to show these numbers same as Prius's without any adjustment.
It is a pertinent decision.

Please Yoshi, try these two experiments between the same trip points:
- high accelerations and smooth brakings (or no braking at all, if possible)
- smooth accelerations and high brakings
You will see a noticeable difference due to tyre surface shear stress.
 
By the way,
CANID:0x61A[5][6] shows km/L number of Trip-A on JP Gen3 Prius.
If the number is 0x011A, it is 282 in decimal, then it shows 28.2km/L.

Please check the 0x61A frame on EU Gen3 Prius.

Anyway, I use above fuel mileage as a reference, the sum of CANID:0x3D3[0][1] / 1980 shows mL unit fuel consumption.

However, JP Gen3 Prius fuel mileage is shown 6.5% better than the real number, based on Trip-A distance and gas usage to fill up.

There is a question, we follow Prius number or real world number. :eek:

Yoshi
 
EU gen3 contains no data in 61A
you can see in this document: http://priusfan.info/canmonitor/mbed/log_analyser_passive1035.zip
Thank you for your excellent log.
I believe it was short (only 3km) trip, and the fuel mileage number did not change.

The 61A[6] shows 64. I think it is shown as 6.4 L/100km.
Please confirm it to compare actual meter reading.

By the way,
CANID:0x619[5][6] shows "km to empty" number.
It looks your log also shows it, 496 km to 494 km as you drive.
I knew about 3D3, but I didn't have the magic number 1980 :jap:
To know your own magic number, the 61A[5][6] is a good reference for calibration. :)

Yoshi
 
bravo Sherlock Holmes :jap:
It is well possible you are right...
6.4 L/100 is the average when my wife drives....
I will check all that on sunday (cannot before).

in the excel sheet, there are very "interesting" macros.
If you are familiar with excel, you can adapt it to your own log's format.
maybe you would get a problem with hex2dec: lowercase for me and uppercase for you.
also there is no test if max linenbr is reached, and it is easy to reach 65535 lines (less than 15 minutes of log for 020,024,025,0AA)
 
@priusfan

Regarding to a multiple response frame, you send...
msg_Continue[8] = { 0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };

I saw a log of ScanGauge-II's activity as follows;
msg_Continue[8] = { 0x30, 0x00, 0x14, 0x55, 0x55, 0x55, 0x55, 0x55 };

I think the last five bytes (0x55) means nothing, but the third byte (0x14) means something.
A friend of mine told me the third byte tells frame intervals between responses, and 0x14 means 20 msec delay.

Following is a log by CANUSB with time stamp.

req: t7E080221015555555555455E : 17758 msec
res: t7E88101B6101000000004561 : 17761 msec : 3 msec delay
req: t7E0830001455555555554562 : 17762 msec : 1 msec delay
res: t7E8821116641625300004563 : 17763 msec : 1 msec delay
res: t7E882200014D002B7C2B457A : 17786 msec : 23 msec delay
res: t7E88230C009501DE39114591 : 17809 msec : 23 msec delay

I have no data about setting the third byte 0x00 yet, but I think the 20 msec delay is a good example not to lose any response frames.

Regards,
Yoshi
 
Bonjour Yoshi
about multiframes, I receive everything (nothing is missing).
Back in 2009, when I was spying techstream, my logs showed 40 as the third byte.
I found detailed infos regarding this flow control frame in msg 10 of this discussion (there is a mistake with a correction in msg 11).


and a more formal:
The flow control frame has three PCI bytes specifying the interval between subsequent frames and how many consecutive frames may be sent (Block Size). The initial byte contains the type (type = 3) in the first four bits, and a flag in the next four bits indicating if the transfer is allowed (0 = Clear To Send, 1 = Wait, 2 = Overflow/abort). The next byte is the block size, the count of frames that may be sent before waiting for the next flow control frame. A value of zero allows the remaining frames to be sent without flow control or delay. The third byte is the Separation Time (ST), the minimum delay time between frames. ST values up to 127 (0x7F) specify the minimum number of milliseconds to delay between frames, while values in the range 241 (0xF1) to 249 (0xF9) specify delays increasing from 100 to 900 microseconds. Note that the Separation Time is defined as the minimum time between the end of one frame to the beginning of the next
at the bottom of this page

and another excellent page here

Last sunday I tried to make somes logs, but the netbook I Was using died ( a old eeepc from 2008 )...
Tomorrow, I will drive around 250 kms, I will try to log without filters and analyse the 6xx family...
 
Bonjour Yoshi
about multiframes, I receive everything (nothing is missing).
Back in 2009, when I was spying techstream, my logs showed 40 as the third byte.
I found detailed infos regarding this flow control frame in msg 10 of this discussion (there is a mistake with a correction in msg 11).
Hi priusfan,

Thank you for the reference links.
So, my friend is correct about the ST(separation time).

Nice to know no frame missing, thank you for the great buffering routine. :wink:

However, I still believe it is better to have some ST delay for better cpu load distribution, like ScanGauge does.

Regards,
Yoshi
 
Hello
I tried yesterday with a delay 14 (20mS) in flow_control_frame.
It works perfectly, but instead of getting 11.6 requets/sec, I get 5...
So I will try 6 (=6ms)...

Also, I ordered and received a very nice & clever small touchscreen to replace the serial 4x20 LCD (fed up of buffer_overflow).
this is very easy to interface: 5 wires TX,RX,Reset,+3.3V & Gnd.
it seems very easy to communicate with...
this thing is not so expensive, (but the freight is huge)...
 
Quand aurons nous une première version de série ?
 
here are 2 pictures from the smartgpu

a test showing it is possible (using font 7) to print 8 lines of 20 cars.



a test showing it is easy to use a background:
just prepare bmp files 320x240, 24 bits & load on sdcard.

it is easy to switch from a display to another just touching the screen.



it is also possible to show small bmp wherever we like.

à propos de version de série: il semble que winston se désintéresse du truc (il ne répond pas aux mp ni aux mails).

le montage de cartes individuelles me semble assez simple.
le truc étant modulaire, il est possible de choisir les options que l'on souhaite:
USB: il est toujours présent.
BT: Oui/Non
SDcard: Oui/Non
Ecran: Oui/Non (LCD Serial 4x20 ou SmartGpu)
Pile de sauvegarde heure: nécessaire si logging sur SD
 
Penses-tu que c'est suffisamment abouti pour que je commande des pièces, et demande à mon fils de faire le montage ?

Même si je ne doute pas que cela va encore évoluer.
 
@thierry
je te propose de venir te rendre compte sur pièces.
le montage est assez basique.
 
Je vais venir, avec mon fils. Il sera content.

Donc, je suppose que tu considères que je peux me fabriquer une première version et que je serai satisfait.
 
Bonjour,

je me lance dans un nouveau projet basé sur Arduino & STN1110.

.../...

edit: changement de fusil d'épaule.
plateforme retenue: mbed, accompagné d'un transceiver mcp2551 et d'un module BT.
Pourquoi pas Arduino ?

PS : j'ai édité l'url qui allait vers sigalabs.com, apparemment un Wordpress infecté (dixit Avast) :

URL: http://sigalabs.com/2011/09/vehicle-obd2...
processus: C:\Apps\ Firefox\firefox.exe
infection: JS:Redirector-RH [Trj]
 
bonjour,
pour info, Thierry a également un module opérationnel, il lui reste à adapter le code pour la P2...
et de mon coté, j'ai complètement refait le mien.

voir photos des 2 modules ici
 
Génial. Finalement quelle est la liste des composants ?
 
Pages vues depuis le 20 Oct 2005: 309,151,204
Retour
Haut Bas