EPR Converter (e2a)

The Bruker spectrometers output data by default in the Bruker BES3T format, which whilst being perfectly usable is not recognisable by most operating as standard.

This script was originally written for the benefit of the project students in the lab who wanted to plot their cw EPR data in Excel without going to the trouble of learning how to use MATLAB. Or for going back to the spectrometer and trying to export their data in ASCII format.

Instead, they can call e2a (EPR spectrum “2” ASCII), they are presented with a standard “Open file” window to select the file.  A message box then asks whether they want the converted file put into the same folder or somewhere else, which if selected presents a standard “Save as” window to save elsewhere.

By default files are saved as standard comma seperated value files (*.csv) which are directly readable by Excel / OpenOffice / etc

More advanced users can specify delimiters and other file extensions, for example:

1
E2A = ('path/to/file.DTA',' ', '.txt')

Takes the file file.DTA and converts it to file.txt where values are separated with a space rather than the standard comma

Syntax

1
2
3
4
5
6
E2A
E2A ('path/to/file.DTA')
E2A (delimiter)
E2A ('path/to/file.DTA',delimiter)
E2A ('path/to/file.DTA',delimiter, extension)
E2A ('path/to/file.DTA',delimiter, extension, interval)

Inputs

input1      - The path to a file input2      - Delimiter is the separator in the file , for comma, for space, \t for tab, etc input3      - Extension is the file format to output eg .csv , .txt, .dat, etc input4      - Desired magnetic field interval eg 0.2 to use interpolation to give data points every 0.2 Gauss

 Outputs

output      - a file by default a common separated value file (.csv)

 Example

1
E2A

Standard use, a graphical user interface to select file to convert and where to put it

1
E2A = ('/path/to/file.DTA',' ','.txt')

Take the file file.DTA and convert it to file.txt where values are separated with a space rather than the standard comma


Available for download here This script also requires BrukerRead to run


This page previously appeared on morganbye.net[^1][^2][^3]

[^1:] http://morganbye.net/epr-converter-e2a [^2:] http://morganbye.net/eprtoolbox/epr-converter-e2a) [^3:] http://morganbye.net/uncategorized/2012/02/epr-converter-e2a

How do you define successful engineering leadership?

The Philosophy

Many view technical leadership as being the “smartest architect in the room.” I see it as the opposite. My job is to build a room where I don’t have to be the smartest person because the systems, culture, and communication are so robust that the team can out-innovate me.

The Strategy

  • Alignment: Does every engineer understand how their sprint task impacts the company’s bottom line?
  • Velocity vs. Stability: We aren’t just “shipping fast”; we are building a predictable, repeatable engine that doesn’t collapse under its own weight at the next order of magnitude.
  • The Human Growth Curve: Success is when the engineering team’s capability evolves faster than the product’s complexity. If the team feels stagnant, the tech stack will soon follow.

What is your approach to scaling technical organizations?

The Philosophy

Scaling isn’t just “hiring more people” - that’s often how you slow down. Scaling is about moving from Individual Heroics to Organizational Systems.

The Strategy

  • The 3-Continent Perspective: Having managed global teams, I focus on “High-Signal Communication.” As you grow, the cost of a meeting triples. I implement “Asynchronous-First” cultures that protect deep-work time while ensuring no one is blocked by a timezone.

  • Modular Autonomy: I advocate for breaking down monolithic teams into autonomous units with clear ownership. This reduces the “communication tax” and allows us to scale the headcount without scaling the bureaucracy.

  • Automation as Infrastructure: At petabyte scale, manual intervention is a failure. I treat the developer experience (CI/CD, observability, self-service infra) as a first-class product to keep the “path to production” frictionless.

How do you balance high-growth velocity with technical stability?

The Philosophy

Technical debt isn’t a “bad thing” to be avoided; it’s a set of historical decisions that no longer serve you. Like any loan, leverage can accelerate growth when investments payoff. But if velocity and returns are slowing you need a payment plan before the interest kills you.

The Strategy

  • The ROI Filter: I don’t refactor for the sake of “clean code.” I don’t refactor a micro-service with no users. I refactor when the pain on that debt - measured in bugs, downtime, or developer frustration - starts to exceed the cost of the fix.

  • Zero-Downtime Culture: Especially at scale, stability is a feature. I implement “Guardrail Engineering” where the system is designed to fail gracefully, ensuring that a Series B growth spike becomes a success story rather than a post-mortem.

  • The 70/20/10 Rule: I typically aim to dedicate 70% of resources to new features, 20% to infrastructure/debt, and 10% to R&D. This ensures we never stop innovating, but we never stop fortifying either.