RAX Fast Logging
I dimly recall tephra telling some tale of corresponding with Colby, getting a revised OP2.0 firmware version, and having his logging speed up. That was ages ago, and I can't find it right now.
25 lines/sec is great. What "sampgroup" settings are you using?
Rich
25 lines/sec is great. What "sampgroup" settings are you using?
Rich
I put them all in the same sampgroup! Next time I may try not logging A, E, G, and H bytes since I don't really need the parameters stored in those and see how fast it'll go. Probably will go back down to 10
This latest firmware is pretty quirky. I've had 3 different results from logging with it. I just logged some WOT pulls using the Rax addresses because the normal way stopped applying the scaling to the numbers. The first time I tried it with the new version I was only getting 10 lines like before but this time it sped up to 25 with no changes.
I put them all in the same sampgroup! Next time I may try not logging A, E, G, and H bytes since I don't really need the parameters stored in those and see how fast it'll go. Probably will go back down to 10
I put them all in the same sampgroup! Next time I may try not logging A, E, G, and H bytes since I don't really need the parameters stored in those and see how fast it'll go. Probably will go back down to 10

Code:
; uncomment the line below to minimize the information written to logcfg.out ; this will greatly decrease the startup time to begin logging if you already ; have a working logcfg.txt without any problems ; ;debug=noout ; sample logging configuration file for openport 2.0 ; must be named logcfg.txt and be placed in the root directory of the ; microSD card inserted in the openport in order to work ;----------------mrmacan evox---------------- ; log channel settings type=mrmacan ;-------------options---------------- ;zerotimecount=1 ;zerosamplecount=1 ;-------------parameters------------- paramname=RAX_A paramid=0x8051AC databits=32 scalingrpn=x sampgroup=1 paramname=RAX_B paramid=0x8051A8 databits=32 scalingrpn=x paramname=RAX_C paramid=0x8051B0 databits=32 scalingrpn=x paramname=RAX_D paramid=0x8051B4 databits=32 scalingrpn=x sampgroup=1 paramname=RAX_E paramid=0x8051B8 databits=32 scalingrpn=x sampgroup=1 paramname=RAX_F paramid=0x8051BC databits=32 scalingrpn=x sampgroup=1 paramname=RAX_G paramid=0x8051C0 databits=32 scalingrpn=x sampgroup=1 paramname=RAX_H paramid=0x8051C4 databits=32 scalingrpn=x sampgroup=1 ;-------------triggers--------------- ; ; note that parameters must be previously defined ; before defining triggers using them ; ; triggers allow you to control when logging starts and stops ; this example sets up triggers such that logging only occurs ; when the engine is running (RPM > 0) ; ; triggers consist of some evaluation of the form [trigparam] [condition] [value] ; and a resulting action which is done if the evaluation is true paramname=CruiseLight paramid= 0x8045C5 databits=1 offsetbits=5 isvisible=0 sampgroup=1 conditionrpn = CruiseLight,1,== action = start conditionrpn = CruiseLight,0,== action = stop ;----------------inno---------------- type=inno ; log from an innovate bus via the 3/32" jack ; currently the LC-1 is the only supported device paramname = mylc1.afr paramid = 0x0101 scalingrpn = x,14.7,*
One day I'll figure this out
If they are ALL the same "sampgroup", you'll be making ONE request per cycle (ie. line). When two items share one sampgroup, they are processed round-robin. Only one request per cycle per sampgroup.
Rich
Rich
I guess I'm still confused about this. So if I want to update B, C, and D every cycle I should put them each in their own sampgroup, and then everything else I dont care as much about should be grouped in the same sampgroup?
If you want B, C and D to update every cycle, don't put them in any "sampgroup" at all.
I'd suggest:
RAX_A_Dat ... Use sampgroup=1
RAX_D_Dat ... Use sampgroup=2
RAX_E_Dat ... Use sampgroup=2
RAX_F_Dat ... Use sampgroup=1
RAX_G_Dat ... Use sampgroup=1
...and the rest with no sampgroup.
See how that runs. It will mirror my "Priority" setup in EvoScan.
Rich
I'd suggest:
RAX_A_Dat ... Use sampgroup=1
RAX_D_Dat ... Use sampgroup=2
RAX_E_Dat ... Use sampgroup=2
RAX_F_Dat ... Use sampgroup=1
RAX_G_Dat ... Use sampgroup=1
...and the rest with no sampgroup.
See how that runs. It will mirror my "Priority" setup in EvoScan.
Rich
I'm in search of some web space to host this 2-3 meg zip file. If anyone knows where I can host it I'm ready to release.
I also have spoke with Travis about integrating Rax Logging into my program and I think it seems somewhat straight forward so I'll give it priority for a future release.
Hope everyone had a good holiday!
I also have spoke with Travis about integrating Rax Logging into my program and I think it seems somewhat straight forward so I'll give it priority for a future release.
Hope everyone had a good holiday!
Rich,
Have you noticed when logging MAF voltages that the fast logger drops some voltage ranges? These drops are outside of the ranges we can adjust any how, but I was wondering if this was intentional. I've gone back to using the old logging method for maf, more because my spread sheets don't like the missing values as opposed to me caring about the missing voltages.
Have you noticed when logging MAF voltages that the fast logger drops some voltage ranges? These drops are outside of the ranges we can adjust any how, but I was wondering if this was intentional. I've gone back to using the old logging method for maf, more because my spread sheets don't like the missing values as opposed to me caring about the missing voltages.



