Newcomer from MS world — questions + some Linux UI feedback

[Frank818]

Hello guys,

Recently discovered Axiom, coming from the MegaSquirt world like some here probably are. Love the idea of taking the MS concept to the next level as a clean-sheet top tier product — and if you know MS, the software feels familiar right away.

Cool to see I am member #20! My car is a Factory Five 818S with a turbocharged VW VR6 12v and fully custom wiring harness built for this precise car. Currently troubleshooting a cranking/sync issue, but long-term I'm very interested in Axiom as an upgrade path. Some questions/comments below — no rush on answers, and hopefully some of this is useful feedback too:

Technical:

• Do the DBW outputs drive the throttle body motor directly (half-bridge), or is an external DBW controller still required?
• For coil packs like MSD-8224, is an external high-current driver still required (same as MS), or can the spark outputs drive them directly? If they cannot drive them directly, what's the reasoning (cost, accuracy, flexibility, relevance)? No strong opinion either way, just curious about the design tradeoff.
• What chip/strategy handles Crank and Cam signal conditioning — adaptive threshold or fixed threshold? What was the reasoning to select one over the other?
• How does it handle LC ringing near or at the gap tooth on VR signals — is the adaptive threshold (if equipped with) tolerant of that, or does ringing risk false triggers?
• I noticed shunt options selectable in the software for the VR/Hall inputs — what's the input capacitance/impedance these are working against, and is there any onboard clamping (TVS or similar) on these inputs as well?
• Same edge-polarity behavior as MS (i.e., signal inversion such that a clean falling edge on the scope means selecting Rising Edge in software)?
• Out of curiosity, has anyone run a 60-2 wheel (or maybe 36-1) with a high-output VR sensor (like 800Ω+ class)? If yes, any sync issues at 4000+RPM, or has that combo been clean across the board?
• What overvoltage/clamping protection exists on the inputs — both for normal high-RPM VR signal levels and edge cases like a disconnected ground or main ground feeding voltage back into a signal pin?
• I recall reading about a built-in oscilloscope feature — if I was not mistaken about its existence, is that a true raw-signal capture at the ADC front end (pre-processing), like an external scope would show?
• For the integrated wideband O2 controllers — can the signal feed an external gauge/display, or ECU-only?
• No onboard MAP sensor, correct? — I don't see a barb fitting on the case. If that's right, what's the reasoning (cost, accuracy, flexibility, relevance)? I don't mind, mostly curious.
• GPS input is supported but there's no onboard GPS module, correct?

UI/software feedback (Linux build):

• At the moment, how can one mimic a composite/tooth logger?
• The "+" button next to the Home tab doesn't appear to do anything.
• Widening the left sidebar via the drag separator snaps back to default width.
• Projects save to

  Code: Select all

  ~/Documents/AxiomEFI/

  with no apparent option to choose a different folder.
• Pure-text sidebar navigation makes it easy to click a parent menu vs. a sub-item by mistake — could be tricky for in-car tuning, especially on a topless/no-windows car in direct sunlight.
• Expanded sidebar menus push everything else down, so the main menu structure scrolls out of view — hard to keep the big picture while navigating, unlike when using buttons.
• Long-term UI vision for the dashboard sidebar — staying as a list of live values, or eventually supporting gauges, custom layouts, high/low alerts, etc.?
• And please keep the Linux build alive.

Thanks!

[Prof315]

Let me answer the technical questions that I can.

The half bridge outputs can directly control a DBW throttle (or Egate) with no external controller needed. Dual throttle is supported and there is an autocalibration procedure for the throttle itself that works very well indeed.
The half bridge outputs can also be used for low or high side drivers.
Ignition drivers are logic level so an external high current driver is needed for "dumb coils". The developers will have to chime in on the reason.
I don't know all the technical details on the Crank and Cam inputs , Maxx 99xx series I believe.
I have used falling edge input for all Cam and crank inputs. That is the recommended setting.
I have a 2009 BMW M3 with the 4.0L S65 up and running on Axiom. It uses a 60-2 VR for crank input. I had to turn on the shunt resistor above 2000 RPMs but with that active the car revs cleanly to 8500 RPMs.
More technical details I am not sure of.
The Crank/Cam and Tach Scope show processed signals not sure about the analog scope as I haven't used it yet.
O2 signal is ECU only but O2 data can be displayed on any CAN based dash or gauge as well as in the tuning software.
No onboard GPS but there are onboard accelerometers.

Linux UI stuff.

Crank/Cam and Tach scope both show information similar to the composite/tooth logger.
"+" button is for adding new panels. But Edit panels must be active first. There are some prebuilt panels available and you can also create custom panels to save and export/import between projects if desired. This is where gauges can be added and displayed.
Work in progress
At present no options to choose a different project location.
Menu navigation is easiest and least cluttered using the search feature. Again work in progress.
The dashboard sidebar will likely stay a list of live values it can be customized. As mentioned above Panels are for gauges , indicators and the like.

The Linux build isn't going anywhere. The devs and I all use Linux (Win 11 caused me to make the move)

[Frank818]

Thanks for your time.

I have used falling edge input for all Cam and crank inputs. That is the recommended setting.

On MS3 Rising Edge works best for me. So with Axiom we have to flip it around and follow the true signal edge?

"+" button is for adding new panels. But Edit panels must be active first. There are some prebuilt panels available and you can also create custom panels to save and export/import between projects if desired. This is where gauges can be added and displayed.

Got it. Yes seems pretty cool to have a bunch of specific panels with tuning menus in them as well as gauges.

Menu navigation is easiest and least cluttered using the search feature. Again work in progress.

At the moment the search field lags a few seconds before anything is displayed, but WIP, perfectly understandable.


A similar question to the one I posted in the Dyno Graphs thread (viewtopic.php?t=4), but this time in one of your Shorts (https://www.youtube.com/shorts/vDb6aoARbTY), you (or that guy) mention that "...starts are noticeably improved." wrt to MS from where the car comes from.
Can you define "improved"?
Do you mean it fires up faster? Or more stable to maintain RPM after start? Or something else.

[Prof315]

Noticeably improved starts has been the engine catching quicker on start, CL idle control works better and the step O2 correction can get you on target with a stable idle faster than I was with the previous ECU. (in general I did not use O2 correction at idle with the old ecu.)

[Frank818]

Oh that's excellent stuff!

Thanks

[muythaibxr]

Ignition drivers are logic level so an external high current driver is needed for "dumb coils". The developers will have to chime in on the reason.

Mostly because of space on the board. We prioritized other things over driving "dumb" coils.

I don't know all the technical details on the Crank and Cam inputs , Maxx 99xx series I believe.

They are MAX9925 IIRC. We can use both manual and automatic thresholds. Default is automatic, but I'm using manual on my 2nd trigger input on my 20v 4AGE, and it filters out the crosstalk between signals just fine (they all share a ground on that engine).

I have used falling edge input for all Cam and crank inputs. That is the recommended setting.

Yes that is. It's not the same as MS3... we have you specify the edge at the connector (signal going from + to -) as that is where you want it to trigger on a VR sensor. MS3 specified the signal at the processor pin, so it was the opposite setting.
Falling on Axiom is like Rising on MS3.

The Crank/Cam and Tach Scope show processed signals not sure about the analog scope as I haven't used it yet.

The tach scope logger shows the cam and crank analog signals at the top, and the processed signals beneath it. I've used it to see noise on the analog signals and set up the trigger thresholds.

No onboard GPS but there are onboard accelerometers.

Correct, you can hook it up via RS-232 and we can log the data.

Menu navigation is easiest and least cluttered using the search feature. Again work in progress.

Agreed, the search is quite useful if you know what you're looking for. I use it extensively. We've recently added the ability to search inside dialogs, which highlights the menu item it found the text in on the menu tree. More generally, several MS users coming from TS have commented that they prefer the "buttons" method but at least one of those users (and myself and James) all like the menu tree once we're used to it, especially with the search functionality. Another key thing we did there is we only show menu items for features that are enabled in the feature selector. This dramatically reduces clutter and gives you a clear idea of what you can actually tune with a given set of features.

The dashboard sidebar will likely stay a list of live values it can be customized. As mentioned above Panels are for gauges , indicators and the like.

Correct. Also correct that if you add a panel you can get text-based gauges, indicators, and chart gauges, as well as settings. We may eventually add dial gauges, and/or the ability to create a "dash" panel that has more "pretty" options for gauges and such, but that's lower priority as what we have right now is customizeable and gets you the information you need on the screen.

The Linux build isn't going anywhere. The devs and I all use Linux (Win 11 caused me to make the move)

Correct. All three of us develop on Linux, and I do all my tuning with it. We have a windows build since we use Qt, and it ends up just being a recompile in Windows, but we all prefer Linux.

More answers to any unanswered questions in another post.

[muythaibxr]

At the moment the search field lags a few seconds before anything is displayed, but WIP, perfectly understandable.

I have fixed this in later builds of the software.

[muythaibxr]

[*]What chip/strategy handles Crank and Cam signal conditioning — adaptive threshold or fixed threshold? What was the reasoning to select one over the other?

I already answered what chip, but the answer to adaptive over fixed is "both, and it's selectable in software"

[*]How does it handle LC ringing near or at the gap tooth on VR signals — is the adaptive threshold (if equipped with) tolerant of that, or does ringing risk false triggers?

The fixed, but configurable (in a curve) threshold should take care of that I'd think.

[*]I noticed shunt options selectable in the software for the VR/Hall inputs — what's the input capacitance/impedance these are working against, and is there any onboard clamping (TVS or similar) on these inputs as well?

I'd have to look in our schematics to answer this. What do you need it for?

[*]What overvoltage/clamping protection exists on the inputs — both for normal high-RPM VR signal levels and edge cases like a disconnected ground or main ground feeding voltage back into a signal pin?

for VR I'd have to check, for analog inputs, voltage feeding back in is likely to break your sensors, but not our ECU. I believe we tested up to 30V.

[*]I recall reading about a built-in oscilloscope feature — if I was not mistaken about its existence, is that a true raw-signal capture at the ADC front end (pre-processing), like an external scope would show?

It captures the analog signal and the resulting digital signal. This lets you see noise on analog turning into input to the processor, and solve it using the manual threshold if needed.

[*]No onboard MAP sensor, correct? — I don't see a barb fitting on the case. If that's right, what's the reasoning (cost, accuracy, flexibility, relevance)? I don't mind, mostly curious.

We have onboard baro, but not onboard MAP. This is because since baro is just reading atmospheric pressure, it's not likely to break, but several things can cause a MAP sensor to break, so we wanted users to be able to replace them easily.

[Frank818]

Yes that is. It's not the same as MS3... we have you specify the edge at the connector (signal going from + to -) as that is where you want it to trigger on a VR sensor. MS3 specified the signal at the processor pin, so it was the opposite setting.
Falling on Axiom is like Rising on MS3.

Then I have to swap my setting, good to know.

The tach scope logger shows the cam and crank analog signals at the top, and the processed signals beneath it. I've used it to see noise on the analog signals and set up the trigger thresholds.

Very interesting!

Another key thing we did there is we only show menu items for features that are enabled in the feature selector. This dramatically reduces clutter and gives you a clear idea of what you can actually tune with a given set of features.

Yeah I noticed that right away, it surely is handy.

Correct. Also correct that if you add a panel you can get text-based gauges, indicators, and chart gauges, as well as settings.

Yes the ability to have the settings inside the panel as well as the "values" (no matter gauges, text, etc.) is very handy!! This is something I truly want to exploit as much as possible, no more settings dialogs hiding the values in the background, thanks for the clever idea!

I already answered what chip, but the answer to adaptive over fixed is "both, and it's selectable in software"

Also very interesting! Gives a lot of flexibility.

I'd have to look in our schematics to answer this. What do you need it for?

I believe that may no longer be necessary after seeing other responses.

We have onboard baro, but not onboard MAP. This is because since baro is just reading atmospheric pressure, it's not likely to break, but several things can cause a MAP sensor to break, so we wanted users to be able to replace them easily.

Again, perfect sense.

Tnx!

[Frank818]

I noticed both the Tuner and LogViewer use the same icon. If some people are like me and pin those to task manager/dock usually there is no name associated so it looks like 2 icons that are the same.

Since this is Linux open-source I took the liberty to create an icon for the LogViewer.

AxiomEFI-LogViewer-icon-256.png (11.87 KiB) Viewed 621 times

I manually associated it to the LogViewer and if a further software update breaks it I can create a simple script which will automatically re-link it after an update. Again, love Linux.