Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[BrianTRice@gmail.com]

Suggestion: it could be simpler to let an optional "hour shift" parameter in the parser and the viewer.
In such a way that the interested user could add or remove some hours to adjust the result to his local time.

I can definitely add that parameter to the Python script. I can then ask Greg Hassler about supporting it in his PHP server code, but that's more work that I can't demand of him. I'll update when the parser has that flag.

I do intend to re-host that parser on Google Cloud or the like where I can share responsibility and we have a more robust way to collect and store logs. But I haven't had time to fully get that working.

[BrianTRice@gmail.com]

Since the FXS has no timezone setting, the actual physical clock can only be set to local time. Zero appears to have added an arbitrary 7 hour offset to the timestamp. There is no logic in that. If they wanted it to be closer to a Unix timestamp in UTC, that would only be correct for bikes in California during the summer. So one can only subtract the mistake (7*60*60) and assume local time.

Then, for computational purposes, pretend the bike, logs, server, parser and viewer all exist in Greenwich. The script correctly does that using gmtime(). It can't use localtime() because that would be converting an already-local time to local.

I can confirm that strftime('%m/%d/%Y %H:%M:%S', gmtime(time())) produces the same output in python2 and python3 in any server time zone. (Interestingly, %Z output differs between python2 and python3.)

Yes, I checked that, too. I wonder more whether strftime changed between Python 2.7 (then) and Python 3.5 (now). (Yes, I'd like newer than 3.5 but Hassler's server had that.)

For what it's worth, I prefer to work with logs in CSV/TSV format, or even JSON, where I can fully specify every piece of data and let the viewer software decide how to process and display it. The reason we've worked in the text format so far is that we have to compare to Zero's claims typically, which made up this log format which has a lot of ad hoc printing styles and conventions, very typical of an automotive manufacturer.

Maybe SR/Fs modernized clock settings with timezone or cellular or GPS? No idea.

I'm still in the process of decoding SR/F (FST) logs, and the timestamp extraction is as yet not fully resolved. the SR/F localizes cellular/GPS activity to the CCM (cellular connectivity module), not the MBB.

[Crissa]

I guess we have to go back to marking down the clapperboard mark of what time we turned the bike off to get our time index right

-Crissa

[gt13013]

I can definitely add that parameter to the Python script. I can then ask Greg Hassler about supporting it in his PHP server code, but that's more work that I can't demand of him. I'll update when the parser has that flag.

That would be great. Thanks!

I do intend to re-host that parser on Google Cloud or the like where I can share responsibility and we have a more robust way to collect and store logs.

I keep all the logs of my bike. I have some with errors, strange behaviors, or some badly decoded data, and I can share them if you are interested. All my logs are decoded and the text is indexed, in such a way that I can find any string immediately. For example:

• MotTemp:-100C, CtrlTemp:5436C (or -100 in the new parser)
• Sevcon unable to be configured as 11kW
• Low Chassis Isolation
• ...

Some examples here.