[cgrey8]

I think Clint has almost perfected the Bluetooth experience with the QH. BE version 5.109 was a start, but there's been a few updates he's done and given me in pre-release versions of 5.109. All those will make themselves into 5.110. So when it releases releases, it'll be pretty solid as it relates to Moates Bluetooth.

The next thing I'm working with Clint on is better support of the Superlogger, and specifically accessing it over Bluetooth. I don't think the technical details of Bluetooth will be a challenge since those have been worked out for the QH. But the SL has some additional I/O that BE currently doesn't support, for example, the accelerometer. There's also a push-button stand alone logging mechanism of which I don't know if BE will ever support.

But I'm hoping to go over all the various details and aspects of what it means to use the SL, along with the QH, over Bluetooth. The only I/O I will be planning to use is to wire my Innovate LC-1 WB (0-5v) to one of the analog inputs on the SL. This is only the beginning of what the SL is capable of. But my hope is that my coverage of what's required will cover the most of what people would want to do with the SL.

It may be a few weeks before I can get the time to actually get the SL installed. But as I do, I'll post my findings and any relevant pictures here.

For starters, here's Craig's Superlogger documentation that he just put together this weekend.

Moates_Superlogger_Instructions_v1.doc

[jsa]

Thanks for the info, keep it coming. M SL1 is in transit.

[decipha]

I have a superlogger in my 03 marauder im daily driving right now. It works flawlessly.

I posted my Universal ADX that supports the superlogger, Its on my website.

Im also working on coming up with a way to make the SL send the same packet in pass through. Then i'll be working on writing code to execute on the SL that the ECU will act upon.

[jsa]

Mike, what have you got from Craig to allow you to do custom SL1 code?

[decipha]

nothing, the SL uses the same class atmel I use for the DEC, I can write code for that in my sleep, once I come up with a way to get the packet constant between modes I'll be porting over some of the DEC code

[cgrey8]

You are glossing over a lot there.

But if I follow, what you are wanting to do is update the SL to modify the active tune in the QH, at runtime, based on feedback it is getting either from the QH or from its own inputs. If that's true, the SL will need to know strategy-specific info about the tune to know what to modify where, and to what value(s). Is this SL code going to be very married to a strategy or are you writing it in such a way that it can be given directives in the form of:

when input A is ><=, modify tune B at offset C as a Byte/Word to value of D

If the SL could receive a series of directives like this, then it could be strategy-generic. However a config tool, like TunerPro or BE, that does know the strategy details would be required to produce those directives and error-check them to make sure they don't have conflicts or overlaps. You might would even need the concept of nested directives so you could make decisions based off multiple conditions existing simultaneously, not just a single input.

The other thing I'm not sure you'd want to do is constantly evaluate the directive, thus the entire time the directive is being met, that the SL is wasting the QH's time by constantly updating the tune with the same exact value. Some latch of only execute once while in the condition would have be implemented.

[decipha]

nope, there's only one tune EVER, I personally don't believe in multiple tunes and that's more hassle IMO more chance for error too, its just not good all the way around

All I'm doing is having the superlogger act upon the inputs its given and spit out a correction that the ecu will use, with my universal adx I standardized the memory locations for all payloads throughout all eec's. They are all the exact same now so there's no such thing as strategy specific anymore that's all gone in the ways of the past. With my universal patch code i'm simply putting a reference list at the tail end of the payload list to directly modify spark and fuel corrections.

All I plan on telling the superlogger to do is execute the code (same as the ecu could do) and shoot out a fuel and spark correction value to the ecu.

its nothing fancy, all straight forward and very simple. All the logic is done on the SL, the ecu is only taking the correction and applying it.

IIRC that's the same exact wish you had many many moons ago by having all the logic done externally and using the ecu as a basic input/output controller. Same principle but far less involved as the ecu is still doing all the controls the superlogger is just spitting out a correction value that's being applied.

[cgrey8]

nope, there's only one tune EVER, I personally don't believe in multiple tunes and that's more hassle IMO more chance for error too, its just not good all the way around

I disagree, but I also built my setup such that multiple tunes are required for me...one for when I'm on gasoline, and one for when I flip the switch over to CNG. The same toggle that switches tunes also disables the gasoline injectors and enables the CNG injectors.

[95GTSpeedDemon]

All I'm doing is having the superlogger act upon the inputs its given and spit out a correction that the ecu will use, with my universal adx I standardized the memory locations for all payloads throughout all eec's. They are all the exact same now so there's no such thing as strategy specific anymore that's all gone in the ways of the past. With my universal patch code i'm simply putting a reference list at the tail end of the payload list to directly modify spark and fuel corrections.

All I plan on telling the superlogger to do is execute the code (same as the ecu could do) and shoot out a fuel and spark correction value to the ecu.

its nothing fancy, all straight forward and very simple. All the logic is done on the SL, the ecu is only taking the correction and applying it.

This sounds like a megasquirt, basically.

I have my SL1 in the car, but i haven't hooked it up yet.
I'm going to log several pressure sensors and PWM a water injection solenoid. I cant wait!

[snowdave]

Greetings and Hello. I am curious how you ended this project and if you would provide an overall summary/recommendation? I currently have a QH with PLX WB plugged into the EVP input and it is working great with decipha's excellent tuning guide(s). I would love to capture a few more data inputs and it seems the SuperLogger could be the right way to go, but I also like the idea of rolling my own using one of the ArduinoPros I've got lying around. As of now, I am strictly using USB to the QH. The PLX has BT on it, but the app is so terrible it has bordered on worthless.

[95GTSpeedDemon]

I have been using it. It works great. There were several bugs/issues that craig and clint helped me get through. I would say it's not for the average guy.
If i get some time this weekend i will gather up pictures and type up some info.
Im logging all sorts of stuff. I rigged up a bread board to clean up the install some.

[snowdave]

Good to hear. I guess I was discouraged by the discussion at the end of this thread:

viewtopic.php?f=1&t=22123&start=30

that implied limitations with QH, SL, BT while using BE. I am using TunerPro RT, but hoping to setup some type of dashboard using the proposed hardware setup going forward. Whether that is a Win10 tablet running TunerPro directly or an Android running TunerView, I am not quite sure.

My only other apprehension is cost. I picked up my QH 2nd hand, but the addition of BT & SL start pushing overall cost into the MegaSquirt range (not quite). At least in my area, tuners are much more familiar with MegaSquirt tuning than EEC-IV. For now, I am still happy working on my own tune and I greatly appreciate tuners that help remotely, but I still like the option to run down to my local dyno and have the tuner add their $0.02.