cintakc: I'm in the process of updating the USB drivera - you'll see this in .10.108/109 soonish in the next couple of days, then it will be worth testing again. 1.10.107 will be going live tonight for everyone else and then assuming nothing bad happens with that I'll be progressing with the USB updates

Capp777: I like the way you think - that /should/ work, though it may need to change in the editor a bit (havent had time to test myself either) - I may add a function (that's less of a hassle to tyoe) to do this after I've got .107 out of the way with

we wait

Wiki modes 0134 to 013B ?

Mode 2A response fix for A... N0...
addressing ?

Capp777, your formula is incorrect
if the time is 1 second, then the result increases in 1 second,
if time is 2 seconds, then the result is increased in 0.5 seconds
and so on, the rate of increase in the result increases with time

Quote from Capp777 on November 10, 2019
Equation: tot(1:lookup([1F]::0=0;1~65535=1))

Cap777, Your formula does not work, you need a new special function to do.

Since I was testing offline I used...

tot(1:lookup([1F]+1::0=0:1~65535=1))

since [1F] was not available. but it
totalized in seconds, saved results and
resumed when I restarted Torque.

tot(1:lookup([1F]::0~10=0:11~65535=1))

would allow the delta time catchup to
update before resuming timing.

Sorry it didn't work for you.

Hello!

After this last update i cannot see values of my coolant temperature on the Map View. It used to show temps every 1 second on the track now it does not. it shows the gradient color line but NO numbers next to it. Please help! 🙂

Quote from cintakc on November 10, 2019
Capp777, your formula is incorrect
if the time is 1 second, then the result increases in 1 second,
if time is 2 seconds, then the result is increased in 0.5 seconds
and so on, the rate of increase in the result increases with time

End Quote.

Cintakc,

My suggested equation uses a one second time base period
and totalizes only a 0 or 1 value. The time base should never
be 2. Typically the base period would be...

1 for seconds
60 for minutes
3600 for hours
etc.

It's basically a timer maintained in Torque since the ECU
will always reset [1F] based upon standard. Not sure if
[7F] would be better.

Torque's totalizer function does have a catchup
feature that will have an impact if Torque starts
totalizing value other than zero right away on
startup. That's where the range limits should
help.

Edited.

Hi! Noted the issues in the map view - something I'll try to get into the next update in a day or so - lots of stuff to work on at the moment!

Hello Ian.
I rummaged the entire Internet, all forums, but so and not found formula, which is used you Have in program Torque, for parameter:
Run time since ancient times = PID [1F]
I understand that You are busy, but could you tell me the formula for conversion of units of time to that mean?
https://drive.google.com/open?id=1ROseHe5mIzT_fzHTysU38emvYnmSjSvd
Thanks in advance!

Capp777, this formula works on my emulator
tot(1:(lookup(([1f]&1)::0=0:1=1)*2))

Cintakc,

The lookup delimiter needs to be a : not ;

My equation with the +1 offline worked
because the value never exceeds 1 but when
I simulated values greater than one I found
the semi colon issue...needs to be a colon.

Incorrect delimiter...

tot(1:lookup([1F]::0=0;1~65535=1))

Correct delimiter...

tot(1:lookup([1F]::0=0:1~65535=1))

Typo.

Capp777, I saw from the very beginning that your formula was logical, but that I didn’t see the error at the semicolon
correct
tot(1:lookup([1F]::0=0:1~65535=1))
https://yadi.sk/d/IIpEbVWV5akGbQ

Quote from Capp777 on November 11, 2019
The lookup delimiter needs to be a : not ;

My equation with the +1 offline worked
because the value never exceeds 1 but when
I simulated values greater than one I found
the semi colon issue...needs to be a colon.

Incorrect delimiter...

tot(1:lookup([1F]::0=0;1~65535=1))

Correct delimiter...

tot(1:lookup([1F]::0=0:1~65535=1))

Typo.

Capp777, today I filmed the work Of your formula, in the running program TORQUE in the car.
In the video, there is a conversation in Russian.
https://drive.google.com/open?id=18yII_ta41iVqH6JVLcxzk_bbM0gvJICP
Your formula does not work in reality!!!
Does not work saving parameters, in the TORQUE:
1. Store the value in the vehicle profile
2. To preserve the value of the global"
Not in 1 not in 2 option.
About than I previously and wrote already.

Quote from admin on November 11, 2019
Hi! Noted the issues in the map view - something I'll try to get into the next update in a day or so - lots of stuff to work on at the moment!

Awesome! Thank you! 🙂

Again I say I'm sorry it doesn't work for you.

tot(1:lookup([1F]::0~29=0:30~65535=1))

When I test offline using a simulated counter
it ...

Let timer count to 75 seconds.
Exited Torque.
Waited several minutes then restarted Torque.
Timer resumed counting at 75, not 0.

Saving pid results works for me. [1F] is just a
timer just like my simulated counter. [7F] might
be worth testing if your vehicle supports it.

Ian has stated that he will look into adding a
new function when he can.

int(tot(1:lookup([0c]::0~299=0:300~65535=1)))

Edited.

Quote from Capp777 on November 11, 2019
Ian has stated that he will look into adding a
new function when he can.

piemme, Thank you, looking forward to it :)!

Hi!

The USB update is mostly done now (including a small speedup for FTDI based devices, further than what was already quick on the OBDLink scantool) - I have just to test on the only other non-ftdi based adapter here to sure things are ok and the next beta will be sent out. You'll see an increase of about 20PIDs/sec for the OBDLink adapter on CANBUS (taking it to about 180PIDs/sec max)

One significant change with the USB stuff is that the app will default to using the USB adapter if one is plugged in and the user chooses to start the app (so if bluetooth is selected, this will be overridden). There were a bunch of issues fixed with USB in this update

After that, it's a couple of map activity fixes and also looking at this new function request in a bit more detail (plus anything else that people have mentioned) - as always betas will appear first on this so expect frequent updates when I implement stuff.

piemmm, v1.10.107
also does not work with FTDI, I sent you debugging logs last time, CP21xx does not detect

Hi!

Finally released 1.10.110 which has the USB updates in - I also managed to fit in time to update the Trip View activity to fix an issue in there

USB should be a lot easier to use now once you have the update (it's just waiting on google to review and approve the beta). Unfortunately I could not find my prolific based adapter but it should still work for non-ftdi based devices as well